For people interested in an example of a Qt app, check out (my) cross-platform file manager https://fman.io. It currently uses PyQt. I hope Qt for Python will become stable enough so I can make the switch.
Developing cross-platform desktop apps is hard. To help with this, I open sourced my build system [1]. It lets you release (Py)Qt apps in minutes instead of months. It aims to make (Py)Qt a more viable alternative to Electron. It already has preliminary support for Qt for Python, and I want to expand it in the future.
1) No idea why that happened. I'm really not doing anything special on the web site.
2) You're right, sorry. The Windows binary is an online installer. I'll update the web site to mention that once the load is off the server.
5) Hm... Sorry about that. Would be extremely interesting to know if this happens on your computer every time. It's probably too much to ask since you already uninstalled, but if you have a few mins, can you try again?
> if you want people to use this, you should probably think about fixing some of the steps to be less cumbersome
That's literally what I spend my days working on. Desktop apps are a lot of work...
Went back and installed a second time. The web page no longer blinks and after the installation finished, the program did not crash and I was able to finish the tutorial.
I wanted to try a third time, but after a third reinstall, the tutorial no longer pops up. Is there a way to clear EVERYTHING away and try again as if this was a new computer?
My understanding is that much of the official work on the Qt libraries over the last few years, has been to do with assisting rapid application development. What was your reason for going with Python over the nearest official alternative, 'Qt Quick'?
(Qt Quick uses webby technologies like JavaScript, but of course retains support for C++. Incidentally it also seems to be where their backend work is focused - their shiny Direct3D 12 engine is for Qt Quick only, as far as I know.)
Rapid application development involves an application, and for the purpose of writing application logic Python tends to be more advanced than Javascript, easier to write than C++, and with a better set of libraries than both.
How do you package the binary for release? I think that's one of the biggest pain points right now, otherwise I would be much more inclined to do something with Qt.
I tried PyInstaller for some scripts a few weeks ago and it worked perfectly and easily, but I don't know if it works with Qt.
Thanks! Yes, my goal is to bring innovation from ST to the file manager niche. Besides the UI, Cmd/Ctrl+P for jumping to folders and a similar Command Palette, this shows in the Python-based plugin API [1].
Actually, I'm very happy with PyQt. It works great. But I'm afraid that its more restrictive licensing limits the global audience of "Qt & Python" users. My hope is that Qt for Python will make the combination even more popular.
To be honest, I'm holding back with switching until Qt for Python is more mature. My app is installed on tens of thousands of machines and I don't dare risk breaking it yet.
Check out (my) https://build-system.fman.io. It's literally meant to solve this problem. Unfortunately, Fedora isn't yet supported. But Windows, Mac and Ubuntu(-based) are.
If you're distributing your app which relies on native libraries you've got two options really. Either make sure you support all the dependencies on supported systems, or distribute with dependencies vendored. If you're going with the second option, maybe Flatpak could help you?
I don't believe pipenv really solves these issues.
I'd say if you're going with the second option, stop, think, then go with the first option. This would mean either limiting your supported systems to recent ones or limiting the features you use to those available in whatever "enterprisy" (i.e. RHEL / Debian stable / LTS) versions you want to support.
If it's a GUI app, there's a good chance you can ignore the enterprisy distributions.
Sure, but the signal from nearly every other camp at this point is that package management (especially for combined native dependencies and scripting deps) isn’t a solved problem.
Do I wish everyone used their distro package manager? Yes. Do I wish there was one package manager? Yes. Do I develop with Nix myself? You bet. But I fear that this sort of quixotic battle has already been lost; frankly I don’t blame people for finding it a confusing mess.
Unless I misunderstood your comment, in which case I apologise!
It looks like the binary wheels include the Qt libraries. So yes, this should mean you can just install Qt through pip, pipenv, or any other Python package manager.
I was just trying to figure out why Qt might have chosen to actively support PySide rather than PyQt, I guess that licensing might be the answer. I wonder what implications this might have for PyQt?
I agree. Arguably, the GPL has probably done more harm than good to open source in the long run, and will continue to be a dividing issue for a long time, sadly
Well, the second license isn't that useful, as no one could distribute the code under it, as long as it's still using PyQt (and he doesn't buy a license).
Also you can't include non-GPL compatible code (Apache is incompatible with GPLv2 for example).
Well, the GPL itself, for starters! GPL isn't acceptable for many people, for a variety of reasons. Personally, i'd rather my open source to be actually open source, and free to use, not "kinda" free
Where do these beliefs come from? The GPL is the most free licence there is specifically because it prohibits future users from using copyright to restrict other users. It's a globally optimal solution rather than a locally optimal one.
Free is letting your users choose what to do, and just making sure you get credit for your work. You can't take ownership of code that's been permissivly licensed, you just don't have to share your contributions. Nobody could just copyright OpenBSDs code and then sue them
Should you be free to take the freedoms of others? Are you free to move into your neighbour's back garden? Freedom extends to the point where it becomes taking the freedom from others.
Allowing a company to use your code how they want doesn't take away anyone else's freedom to use your code how they want. Its an absurd and comparison and claim; in what way are you taking away someones freedoms by using a permissive license? please explain, as your previous claim that anyone can take the rights to your project is incorrect
Of interest: Since ~two years or so you can actually pip install PyQt on major systems, since they made wheels available. Note how PySide2 is wheel-only on pypi as well.
The whole package is 166.4 MB for Linux (PyQt5 is 117.9 MB ). This is even much bigger than Electron's base bundle size. This matters much for Linux devs who want put everything into a single package (e.g. AppImage) to avoid dependency problems in each Linux distros. I hope Qt would divide Pyside 2 into components (for example, QML) so that devs can easily optimize their package size.
This includes _everything_, including webengine(which bundles chromium). It's not ideal, but Pyinstaller prunes unused libraries, so Pyinstaller bundles shouldn't be too large.
I can't find any mention of commercial license pricing anywhere, can anyone enlighten me?
Because python links dynamically, I believe it's possible to use python Qt bindings commercially without a commercial Qt license. Does pyside2 support this?
Dynamic vs static linking makes no difference for commercial use (common misconception).
If you link statically to LGPL libraries from commercial software you must provide object files (or provide link to where anyone can get them). Just as easy as providing dynamically linked library.
Note that you can use the GPL commercially, too. It matters only if you want to license under anything non-GPL (which admittedly most commercial projects do).
This is great, but I do wonder if the lifespan of Qt and other frontend frameworks is somewhat limited. UI development seems to be converging more and more on the web stack (HTML/CSS/Javascript)
With WebAssembly and other recent developments, I think that the opposite is going to happen in the future. We are (hopefully) going to have native (online) apps.
I hope you are right; I see WebAssembly (or a potential successor) to be the missing gap in the ecosystem, which Java (as well as some previous small attempts) attempted to be. Since javascript (or ecmascript for the purists) now runs server-side (e.g. node.js), there's no reason wasm could not run everywhere.
What makes you think so? WebAssembly is about making it possible to compile from any language into subset of javascript (which is well JIT-table), it doesn't say nothing about neither which layout/gfx engine the apps will use, nor about any ISA. Many want the bindings to DOM, actually.
If browser vendors don't change course in regards to WebAssembly's roadmap, Flash and Applets are back, just give it one more year to mature the eco-system.
Seems unlikely. Developers are already using the DOM model outside of the browser entirely a'la Electron because in modern times it's such a productive and accessible development environment. I can't imagine we'd try to bring back the pain of Flash. What we have now is drastically more portable and a delight to use compared to that era.
Instead of bindings to DOM, you can offer bindings to native API - Webassembly makes it safe. Another approach is running your app on webgl. WASM is not a subset of JavaScript at all, it has similar modularization, but that's about it.
WebAssembly will make it simpler to port non-DOM UI libraries to the web, which probably some people will use - though the DOM based UI libraries are already quite strong.
- Native Qt and a WASM runtime that has bindings directly to the native library (basically PyQt, but WASM instead of Python)
- Qt apps in canvas (webgl)
The first two are definitely accessible (by default or very easily). The last one not so much, but it's still possible, and project like Qt should have enough resources to pull it off. The second approach should be the most performant.
Developing cross-platform desktop apps is hard. To help with this, I open sourced my build system [1]. It lets you release (Py)Qt apps in minutes instead of months. It aims to make (Py)Qt a more viable alternative to Electron. It already has preliminary support for Qt for Python, and I want to expand it in the future.
[1]: https://build-system.fman.io