Qt for Python available at PyPi | Hacker News Reader

Qt for Python available at PyPi

blog.qt.io

171 pointsmariuz87 comments

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]: https://build-system.fman.io

Just FYI: I saw this comment and:

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.

Thank you for the feedback.

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!

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?

Thanks! You can close fman and delete the data directory [1]. Or, you can start the tutorial again via the Command Palette [2].

[1]: https://fman.io/docs/data-directory

[2]: https://fman.io/docs/tutorial

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.

https://build-system.fman.io/

I can't believe I read around the important bits of the second paragraph. Thanks.

EDIT: Wait, what about BSD/MIT/etc licenses?

GPL or commercial only, sorry. I really do need the income.

I've been following your project for a while and I wish you good luck. I like what I'm seeing and I hope it succeeds! :)

Thank you :-)

I just tried fman and it is quite impressive. Fast af and clearly (?) inspiered by Sublime Text. Beautiful!

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].

[1]: https://fman.io/docs/api

Nice work with fman I have been playing with it over the last couple of weeks and like it alot.

Thank you! I'm very happy to hear you like it.

> I hope Qt for Python will become stable enough so I can make the switch.

Why do you want to switch?

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.

TL;DR you want avoid paying the PyQT developers for a commercial license.

There's nothing wrong with hoping a freely licensed open source competitor will come along and lower the cost of developing in the space.

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.

No, that's not it. As I said, PyQt is excellent and I'm happy to be paying for such quality work.

> its more restrictive licensing limits the global audience

That means not everyone has a business model that supports paying a license fee.

"If you need a special feature .... pressing F10"

If only I had F10 on my keyboard ... Is it even possible to use PyQT and have features like touch bar support?

What issues have you experienced with PySide2 so far that is preventing the switch?

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.

I just started developing a Python app with a GUI and the faff around getting in running on other developer machines was crazy!

"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?

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.

Anaconda python contains both pyqt and qt. That’s what we use. Pip contains just the python bits, not the Qt bits - at least this is true for PyQt.

Trying to have a look at (BUILT INTO QT CREATOR) QML examples was pretty much this experience, but worse.

I try to like Qt, but this cost a bunch of confidence.

> 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.

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!

The trend goes pretty clearly towards a package manager per platform (programming language).

This does become hairy when you try to inter-operate, but for development, at least, it seems to work quite well.

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.

Relevant XKCD

https://xkcd.com/1987/

Just curious how this is different from PyQt.

Used to use PyQt on a bunch of projects. It was a fairly decent framework. Not bad for native-looking UIs.

For open source projects, it is available under LGLP, which is less restrictive than PyQt's GPL.

It's also available under the commerical license, too, so customers don't have to purchase from the Qt Company AND PyQt.

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?

PyQt refusing to license under LGPL is basically the reason for PySide to exist.

It's sad to see programming effort going into a redundant library that differs only by a license, when it could be used to implement something new.

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

That's because "open source" came after the GPL ("free software") and was positioned as something decidedly different.

> For open source projects, it is available under LGLP

And how does this make the slightest difference for open source projects?

They can chose any open-source license. With PyQT being under GPL you're force to use the GPL, too (you can always dual-license though).

> you can always dual-license though

Exactly. So no practical difference. Just a religious one.

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).

Why would you want them to distribute it? Distribute under GPL, offer a proprietary licence and they'd have to buy the proprietary licence to Qt too.

Which is a practical difference.

Only for those who don't want to contribute to open source. If we're just talking about open source it doesn't matter.

open-source != GPL-licensed

You can use it in BSD/MIT/MPL/Apache/whatever licensed projects. A library licensed under GPL can only be used in GPL licensed projects.

It's unlikely that Qt will be added to an existing project, so just license the new project under GPL. What's the problem?

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.

That's not free. That's a restriction.

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

You can't incorporate code from / link with other GPLv3-incompatible open source projects, such as GPLv2 projects.

Not really a problem with Python. There's no linking.

GPL is pretty clear on this one: importing modules counts as linking. https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

> 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,

Excluding C extensions, isn't Python linking (via import) dynamic only?

"import" or rather combine then.

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.

Nowadays there is also Qt.py, "API-selector-as-a-package": https://github.com/mottosso/Qt.py

Please add a project description on your PyPI entry :)

https://pypi.org/project/PySide2/#description (currently empty)

Yes ! Super good work, long awaited !

In 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 :-))

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.

Oh, I didn't know about Pyinstaller actually. I am going to look at it. Thx!

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.

This is PySide, which is LGPL - so you shouldn't have any trouble using it commercially.

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.

WebAssembly + Canvas/WebGL.

http://blog.qt.io/blog/2018/05/22/qt-for-webassembly-example...

http://platform.uno/Playground/index.html

Would a less-specialized rendering engine not be even less performant if trying to make web-app like things?

What web-app like?

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.

I am also interested in this, but I'm concerned about the accessibility aspects. Native Qt can be accessible. Web apps can be accessible.

Can Native Qt on web assembly be accessible? How would that work cross-platform?

There are 3 approaches:

- 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.

Reply on news.ycombinator.com