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.
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.
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.
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.
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.
- 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.
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?
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
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
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.
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.
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.
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?
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.
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.
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?
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).
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.
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!
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.
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.
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.
88 comments
[ 3.2 ms ] story [ 165 ms ] threadIn these times of web stuff, it's really nice to work with a framework that is absolutely stable. (well, except Qt5 is quite a change :-))
http://blog.qt.io/blog/2018/05/22/qt-for-webassembly-example...
http://platform.uno/Playground/index.html
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.
Can Native Qt on web assembly be accessible? How would that work cross-platform?
- Web apps (using DOM like usual)
- 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.
Used to use PyQt on a bunch of projects. It was a fairly decent framework. Not bad for native-looking UIs.
It's also available under the commerical license, too, so customers don't have to purchase from the Qt Company AND PyQt.
And how does this make the slightest difference for open source projects?
Exactly. So no practical difference. Just a religious one.
Also you can't include non-GPL compatible code (Apache is incompatible with GPLv2 for example).
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
> A consequence is that if you choose to use GPL'd Perl modules or Java classes in your program, you must release the program in a GPL-compatible way,
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
[1]: https://fman.io/docs/api
Why do you want to switch?
PyQT are free to extract fees from the ecosystem as long as they can, just as some open source devs are free to try to eat their lunch money.
That means not everyone has a business model that supports paying a license fee.
1) went to your link -> intensive blinking, firefox reporting that it "forbade access to graphics card" for whichever reason
2) Was impressed that Windows file is only 1 MB (turns out the installer downloads a lot more than that, which is ok but could be mentioned)
3) Started the program and agreed with tutorial
4) Followed tutorial to C:\Users\myusername\Desktop
5) Followed tutorial by pressing Backspace -> program stopped working and crashed
No hate intended, but if you want people to use this, you should probably think about fixing some of the steps to be less cumbersome :).
FWIW the program looks cool.
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...
> FWIW the program looks cool.
Thanks!
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?
[1]: https://fman.io/docs/data-directory
[2]: https://fman.io/docs/tutorial
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.
EDIT: Wait, what about BSD/MIT/etc licenses?
(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.)
If only I had F10 on my keyboard ... Is it even possible to use PyQT and have features like touch bar support?
https://pypi.org/project/PySide2/#description (currently empty)
Because python links dynamically, I believe it's possible to use python Qt bindings commercially without a commercial Qt license. Does pyside2 support this?
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.
"Install PyQT and QT Framework, no not that version, no not that one? Your on Fedora? Oh okay, add this rpm repo, no the developer version"
The ability to install it through Pipenv should make this easier, right?
I try to like Qt, but this cost a bunch of confidence.
That's what you get from users when you try to be nice and don't invent your own package manager.
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!
This does become hairy when you try to inter-operate, but for development, at least, it seems to work quite well.
https://xkcd.com/1987/
I don't believe pipenv really solves these issues.
If it's a GUI app, there's a good chance you can ignore the enterprisy distributions.