We use Qt heavily at Starsky Robotics. We initially used it because it has tight integration with ROS via RQT [1], but I'm pretty impressed with the framework in general. Lots of great tools out of the box, QtCreator is awesome and once you get the right signal/slot model in your head everything is a breeze. Plus getting to prototyping in python is always fast!
For our use case, relative speed of the GUI isn't a factor. We've considered moving to electron just for ease of development, but python is winning out.
I'm presenting QGIS-ROS at ROSCon this year. It's a QGIS plugin for integrating real time robot data. Was relatively easy to do thanks to QGIS being Qt 5.
This is a case where the "in 2018" in the title is very helpful, as Googling information about Python and Qt usually returns something dreadfully out of date. (and as other comments note, there are lots of new companion tools/competitors like Electron)
The API still looks messy and unpythonic though, sadly. Look at the basic hello world example. Why do I need to pass QApplication an empty array? Why am I calling a method ending with _ to launch the program? And the fact the label magically attaches to the app through some side effect is also confusing.
Does anyone know if there's any good shim/wrapper around PyQt that has a better API?
I wish all the effort to make Qt available in Python was going in to exposing a C API. I of course know this is difficult due to Qt relying on OO extensibility in many cases and I am aware of many efforts in many languages that just use the C++ API directly by essentially building their own C API layer.
That I have to choose between C++ or Python makes it very difficult for many use cases in other languages. What essentially ends up happening is you create the UI in C++ then build a communication/bridge layer with your Go/Rust/JVM/etc app via C and the respective language's FFI features.
The hardest problem in this space is not writing the code, but packaging the app. All the freeze utilities have their quirks which ensure no one solution works for all three OS consistently.
I've been using wxPython for many years, and it works very well. What are the advantages of PyQT over wxPython? Anyone experienced both 'worlds' in a non-trivial application?
1. wxPython has inconsistent looks and layouts between platforms and monitor resolutions (or DPI). For example, on PlayOnLinux GUI app I cannot click an "OK" button while using Surface Pro because the button is hidden outside of the window.
2. QML is an amazing language. It is modern, declarative and reactive but still very simple to use. Personally I don't want to go back to the traditional GUI coding styles after experienced QML.
3. Qt Designer is a great GUI tool that you can quickly prototype a GUI app.
4. Qt has the best documentation among cross-platform GUI frameworks.
5. Qt is a much bigger framework having more features. For example, you can easily embed WebKit or Chromium very easily.
The reason why I chose PyQt over wxPython was the former's support for custom styles. I wrote an article with my thoughts on picking a GUI framework [1], in case you're interested.
PyQt5 is really great. I wish I could convince some of my co-workers at SNC to use it instead of random solutions ranging from a full-blown WPF app, hand-rolled win32, heavily customized imgui, vt100 over telnet (apologies on behalf of *), to... 5000 lines of AutoIT for a simple gui... smh. I mean we already use python for some build steps. They seem to not be able to get over the python stigma, which I don't think needs to exist, or the pythonic paradigm "breaks their brains."
In commercial settings, I wonder how hard it really is to package this up? I've been building/distributing fully cython'd installers for a while (to sort-of hide the source as well as make a convenient package)... I wonder if that would be harder with PyQt for some reason?
"In the Python world, the process of turning source code into a self-contained executable is called freezing. Although there are many libraries that address this issue – such as PyInstaller, py2exe, cx_Freeze, bbfreze, py2app, ... – freezing PyQt apps has traditionally been a surprisingly hard problem.
We will use a new library called fbs..."
click to fbs...
"You can use fbs for free in open source projects that are licensed under the GPL. If you don't want to open your code up to the public, you can purchase a commercial license for EUR 249 per developer"
I'd happily pay the 250 euros but I somehow doubt fbs will also convert my code to C and compile it.
I'm sometimes considering porting the UI of a relatively complex management app I wrote sometime ago for a small company, from Ext JS to a Python-flavored traditional GUI framework like PyQt (it would essentially become a desktop app powered by an already Python-based backend, which wouldn't be really a problem deployment-wise, as it's an internal-facing app). I think there would be some benefits, but what stops me is a relatively concrete consideration: the primary UI widget on which my app relies are complex data grids, which must support a lot of functionalities (sorting, filtering, etc; which is an area where Ext JS clearly shines), and I'm wondering which framework would offer the best support (in terms of both functionalities and abstractions) for this kind of needs. Any ideas about this?
How do things work regarding the boundary between .NET and Qt memory management? What was the hardest problem you faced regarding this issue (resource leaks, etc.)?
I'm using PyQt for a project right now, and overall it's a nice feeling as always. The model/view classes are great, once you get the hang of them. There are a lot of utilities for things like persistence and threading (but I wouldn't cross the streams with python threads), and it's all crossplatform and very mature by now, the only issues are usually around packaging. QML is also very powerful, but I'm usually happy with Designer -- I guess I'm old-school.
If you need some help with PyQt development, call me up, I'm cheap ;)
I recently went through almost the exact same exercise (use PyQt5 to write a desktop program that would wrap our warehouse management system's web interface with QtWebKit and - upon receiving a specific download - call out to the REST API for a separate shipping system to book a shipment and print the shipping label). I was developing on Linux (I use Slackware day-to-day), but the pack stations at our warehouses run Windows 10, so it needed to be cross-platform.
The Linux side was surprisingly painless, but getting the Windows side going was a nightmare; none of the traditional options for creating a standalone Windows executable actually worked, and I ended up resorting to installing MSYS2 on every machine, then packaging the app for MSYS2 (and pulling in all of Qt5 as a dependency, meaning that it takes up multiple gigabytes of space for what should be a pretty simple desktop app).
I didn't know about fbs. I'm gonna try it out tonight. The fact that it seems to require resulting apps to be under the GPL is unfortunate, but that's already the case for PyQt5, so whatever.
How is the experience of other folks here? I have found QT as true nightmare. The UX created with QT just doesn’t scale with 4K displays and framework is just pain to maintain on OS like Windows. I rather prefer UX frameworks that uses web technologies any day.
Still using tkinter here which is python's default GUI, what's the license for PyQt5? For me learning Qt in general is another big investment of limited time, so far I have been using tkinter with python and it works well.
I've been using a lot of Python GTK via gobject introspection lately. It works fine, or at least a well as GTK ever works. Why would I want to switch to Qt?
1) I like how GTK and Python object lifetime tracking are compatible (both are simply reference counted), where as Qt has this hierarchical model that feels weird in Python and that led to random segfaults when I tried using PyQt for a serious project last year.
2) gobject introspection works with a variety of different bindings and libraries and provides an object model extensible in any language. Last time I looked at Qt bindings, they looked more like pre-gobject-introspection Python GTK bindings, meaning they were fixed-function and frequently left out some functionality. With gobject, all language bindings are first-class citizens.
How does the reference counting work in the presence of reference cycles involving both the GTK side and the Python side, e.g. an event handler having a reference to an object that has a reference to the object the handler is attached to?
Do they get collected properly, like they would with pure Python objects, or would you have to break up the cycle?
> If you use the Windows style instead, then it looks as follows:
note that this theme is generally not used anymore, being superseded by the WindowsVista one which uses native theming info from windows to render the widgets.
Also see PyOtherSide, a QML plugin that gives asynchronous access to a Python3 interpreter. It let's you use the Qt deployment tools and deploy it like any other Qt app.
I like the tutorial, but I don't know why you would use PyQt these days. Tkinter is more permissive and has wrappers like appJar which make it disgustingly easy to put together a quick, ugly GUI. If you're building a desktop app that needs to really look good and be fast, why are you using Python?
> If you're building a desktop app that needs to really look good and be fast, why are you using Python?
Why not? For an app to feel fast, you need to make it responsive and non-blocking. You can easily make apps with Python and Qt or Gtk that start instantly and never seem to hang. Discipline when it comes to not running things on the main thread, using proper async techniques etc. is more important than the number crunching ability of your programming language.
And when you need raw speed, you can easily drop in some C++ code with SWIG for example. For example, I made a GUI for controlling an experimental sensor system. The GUI could look boring, but should be rock solid and always responsive, it should be easy to add new features, and it had to read data from PCIe at hundreds of MB/s or even faster. So I wrote the GUI in PyQt, the PCIe part in C++. Python allowed me to mock the hardware code out easily so I could test the GUI separately, and made it really easy to read configuration files etc. which is unneccessary painful in C++.
Why not use python? It’s fast enough for most uses, and with PyQT it looks good enough on top of that it solves most cases rather fast. Sure I can make a solution that runs faster with a smaller memory footprint in Cpp, but my client doesn’t gain any value from me deciding to delay delivery to hit functional requirements they didn’t ask for and don’t need.
I suppose if you are familiar with Tkinter and are happy with how it looks have at it! But there are a ton of things that can be leveraged from Python and Qt separately going this route.
PyQt uses compiled Qt C++ code so isn't really that slow, comparable to how NumPy does it's number crunching. Even if you do find it is slow, you can always come back and branch down to the C++ level when needed, although there are ton of steps you could take to optimize in Python first. There are also all the Qt tools from UI editor and Designer to QML and way more if you really wanna go down the rabbit hole...
What are you suggesting as a really good looking and fast cross platform alternative??
I think the better appearance of Qt cross-platform is the main drawing point (at least it would be for me). If I were to make a cross-platform application, or even just a Linux one, I'd likely use Qt (with Python bindings because that's what I know). I tried using Tkinter on Linux for a simple utility, but I could not figure out the theming or find any matching themes for Ubuntu.
The combination of an interpreted shell with a statically-typed, AOT-compiled core is a time-tested architecture that leads to quick development times and lots of power. Python is a good choice for the former component of this mix, and if you use it, you want to be able to interact with the GUI.
I've only been a Python dev, and have ended up becoming entrenched in Tkinter. I want to be able to just use another GUI framework for when I finally switch to something else. So, I can see the use.
[+] [-] DanFeldman|7 years ago|reply
For our use case, relative speed of the GUI isn't a factor. We've considered moving to electron just for ease of development, but python is winning out.
[1] http://wiki.ros.org/rqt
[+] [-] morenoh149|7 years ago|reply
[+] [-] Waterluvian|7 years ago|reply
Felt exactly like making a RQT plugin.
[+] [-] solarkraft|7 years ago|reply
[+] [-] minimaxir|7 years ago|reply
[+] [-] ehsankia|7 years ago|reply
Does anyone know if there's any good shim/wrapper around PyQt that has a better API?
[+] [-] chaz6|7 years ago|reply
[1] https://www.qt.io/qt-for-python
[+] [-] omaranto|7 years ago|reply
[+] [-] gusmd|7 years ago|reply
If possible, I would rather get behind the "official" one since we also already pay for commercial Qt licenses.
[+] [-] cpburns2009|7 years ago|reply
[+] [-] nofunsir|7 years ago|reply
[+] [-] kodablah|7 years ago|reply
That I have to choose between C++ or Python makes it very difficult for many use cases in other languages. What essentially ends up happening is you create the UI in C++ then build a communication/bridge layer with your Go/Rust/JVM/etc app via C and the respective language's FFI features.
[+] [-] pknopf|7 years ago|reply
https://github.com/qmlnet/qmlnet
It worked out nicely.
[+] [-] rhodysurf|7 years ago|reply
[+] [-] sandGorgon|7 years ago|reply
Even Dropbox had to rewrite their packaging to ensure maximum system compatibility (https://news.ycombinator.com/item?id=18067784)
[+] [-] mherrmann|7 years ago|reply
[+] [-] voltagex_|7 years ago|reply
[+] [-] kelvin0|7 years ago|reply
[+] [-] kbumsik|7 years ago|reply
2. QML is an amazing language. It is modern, declarative and reactive but still very simple to use. Personally I don't want to go back to the traditional GUI coding styles after experienced QML.
3. Qt Designer is a great GUI tool that you can quickly prototype a GUI app.
4. Qt has the best documentation among cross-platform GUI frameworks.
5. Qt is a much bigger framework having more features. For example, you can easily embed WebKit or Chromium very easily.
[+] [-] mherrmann|7 years ago|reply
1: https://fman.io/blog/picking-technologies-for-a-desktop-app-...
[+] [-] nofunsir|7 years ago|reply
[+] [-] acidburnNSA|7 years ago|reply
"In the Python world, the process of turning source code into a self-contained executable is called freezing. Although there are many libraries that address this issue – such as PyInstaller, py2exe, cx_Freeze, bbfreze, py2app, ... – freezing PyQt apps has traditionally been a surprisingly hard problem.
We will use a new library called fbs..."
click to fbs...
"You can use fbs for free in open source projects that are licensed under the GPL. If you don't want to open your code up to the public, you can purchase a commercial license for EUR 249 per developer"
I'd happily pay the 250 euros but I somehow doubt fbs will also convert my code to C and compile it.
[+] [-] cjauvin|7 years ago|reply
[+] [-] pknopf|7 years ago|reply
https://github.com/qmlnet/qmlnet
It is a perfect balance between QML and .NET. The tech stack splits along the perfect line. QML for UI, .NET for business logic.
I'd be glad to answer any questions.
[+] [-] oblio|7 years ago|reply
[+] [-] raphinou|7 years ago|reply
[+] [-] toyg|7 years ago|reply
If you need some help with PyQt development, call me up, I'm cheap ;)
[+] [-] yellowapple|7 years ago|reply
The Linux side was surprisingly painless, but getting the Windows side going was a nightmare; none of the traditional options for creating a standalone Windows executable actually worked, and I ended up resorting to installing MSYS2 on every machine, then packaging the app for MSYS2 (and pulling in all of Qt5 as a dependency, meaning that it takes up multiple gigabytes of space for what should be a pretty simple desktop app).
I didn't know about fbs. I'm gonna try it out tonight. The fact that it seems to require resulting apps to be under the GPL is unfortunate, but that's already the case for PyQt5, so whatever.
[+] [-] sytelus|7 years ago|reply
[+] [-] ausjke|7 years ago|reply
[+] [-] gandreani|7 years ago|reply
[+] [-] mherrmann|7 years ago|reply
[+] [-] quotemstr|7 years ago|reply
1) I like how GTK and Python object lifetime tracking are compatible (both are simply reference counted), where as Qt has this hierarchical model that feels weird in Python and that led to random segfaults when I tried using PyQt for a serious project last year.
2) gobject introspection works with a variety of different bindings and libraries and provides an object model extensible in any language. Last time I looked at Qt bindings, they looked more like pre-gobject-introspection Python GTK bindings, meaning they were fixed-function and frequently left out some functionality. With gobject, all language bindings are first-class citizens.
[+] [-] ptx|7 years ago|reply
Do they get collected properly, like they would with pure Python objects, or would you have to break up the cycle?
[+] [-] rapsey|7 years ago|reply
Because GTK is awful outside of Linux.
[+] [-] jcelerier|7 years ago|reply
note that this theme is generally not used anymore, being superseded by the WindowsVista one which uses native theming info from windows to render the widgets.
[+] [-] throwwwafgk|7 years ago|reply
https://thp.io/2011/pyotherside/
[+] [-] paulcarroty|7 years ago|reply
[+] [-] Sileni|7 years ago|reply
[+] [-] captainmuon|7 years ago|reply
Why not? For an app to feel fast, you need to make it responsive and non-blocking. You can easily make apps with Python and Qt or Gtk that start instantly and never seem to hang. Discipline when it comes to not running things on the main thread, using proper async techniques etc. is more important than the number crunching ability of your programming language.
And when you need raw speed, you can easily drop in some C++ code with SWIG for example. For example, I made a GUI for controlling an experimental sensor system. The GUI could look boring, but should be rock solid and always responsive, it should be easy to add new features, and it had to read data from PCIe at hundreds of MB/s or even faster. So I wrote the GUI in PyQt, the PCIe part in C++. Python allowed me to mock the hardware code out easily so I could test the GUI separately, and made it really easy to read configuration files etc. which is unneccessary painful in C++.
[+] [-] int_19h|7 years ago|reply
https://thonny.org/
[+] [-] talltimtom|7 years ago|reply
[+] [-] radix07|7 years ago|reply
PyQt uses compiled Qt C++ code so isn't really that slow, comparable to how NumPy does it's number crunching. Even if you do find it is slow, you can always come back and branch down to the C++ level when needed, although there are ton of steps you could take to optimize in Python first. There are also all the Qt tools from UI editor and Designer to QML and way more if you really wanna go down the rabbit hole...
What are you suggesting as a really good looking and fast cross platform alternative??
[+] [-] cpburns2009|7 years ago|reply
[+] [-] quotemstr|7 years ago|reply
[+] [-] mherrmann|7 years ago|reply
1: https://stackoverflow.com/a/1094530/1839209
2: https://www.reddit.com/r/learnpython/comments/108zfq/tk_or_q...
3: https://www.quora.com/Should-I-use-PyQt-GTK3-or-tkinter-for-...
[+] [-] HoppyHaus|7 years ago|reply
[+] [-] ajuc|7 years ago|reply
[+] [-] liveoneggs|7 years ago|reply
[+] [-] tudelo|7 years ago|reply