Hello Qt for Python(blog.qt.io)
blog.qt.io
Hello Qt for Python
http://blog.qt.io/blog/2018/05/04/hello-qt-for-python/
175 comments
What would you recommend to someone who wants to write Python desktop applications today? I've used wxWindows way back when, and I'd hate to use Electron. Would you go with Qt for Python, or PyQT?
Also, what's PySide/PySide2?
Also, what's PySide/PySide2?
As you can see, Qt for Python is not yet stable release. So you will want to use PyQt5 first. I remcommand PyQt5 because there are more resouces available on the internet now.
PyQt5 and Qt for Python is a 1-to-1 binding to the original Qt and their APIs are almost identical, so you should be able to switch to Qt for Python quite easily when it is stable.
By the way, Qt for Python is re-branded from PySide2. They are the same.
PyQt5 and Qt for Python is a 1-to-1 binding to the original Qt and their APIs are almost identical, so you should be able to switch to Qt for Python quite easily when it is stable.
By the way, Qt for Python is re-branded from PySide2. They are the same.
PySide2 (Qt for Python) has been in production where I work (and in the visual effects industry) since 2016.
Since then, bugs have been smashed, modules have been added and improvements have been made. I would recommend almost anyone to start developing with this right away and, like always, report bugs [0] and contribute improvements back to the project [1] (not on github).
[0]: https://bugreports.qt.io/projects/PYSIDE/issues
[1]: http://code.qt.io/cgit/pyside/pyside-setup.git/
Since then, bugs have been smashed, modules have been added and improvements have been made. I would recommend almost anyone to start developing with this right away and, like always, report bugs [0] and contribute improvements back to the project [1] (not on github).
[0]: https://bugreports.qt.io/projects/PYSIDE/issues
[1]: http://code.qt.io/cgit/pyside/pyside-setup.git/
Would it be as simple as a global change of all "from PyQt5" to "from PySide" in all import statements?
Almost, when switching from PyQt4 to PySide 1. It was roughly equivalent with some minor differences. It was much less work than switching Python 2.7 syntax to 3. There are some bindings as well [1].
I don't know much detail about PyQt5 vs PySide 2 but at least the overall logic should be the same.
[1]: https://github.com/epage/PythonUtils/blob/master/util/qt_com...
I don't know much detail about PyQt5 vs PySide 2 but at least the overall logic should be the same.
[1]: https://github.com/epage/PythonUtils/blob/master/util/qt_com...
That's very helpful, thank you!
Wxwindows was a dream to work with. Electron needs to die a fiery death. preferably the corpse is then mauled by bears and tigers
PySide is Qt4. PySide2 is Qt5. I would suggest using PySide2 but using https://github.com/mottosso/Qt.py in case you need to switch to PyQt5 for any reason.
Not OP, I've been very impressed with some enlightenment apps written using python.
In particular: https://github.com/DaveMDS/egitu
https://phab.enlightenment.org/w/projects/python_bindings_fo...
Scroll down to "python projects using EFL".
In particular: https://github.com/DaveMDS/egitu
https://phab.enlightenment.org/w/projects/python_bindings_fo...
Scroll down to "python projects using EFL".
I wouldn't use enlightenment/EFL for a new project today. If you've got the opportunity to greenfield, Qt is a much nicer framework.
EFL has a number of questionable design choices, covered a little bit here: https://what.thedailywtf.com/topic/15001/enlightened .
EFL has a number of questionable design choices, covered a little bit here: https://what.thedailywtf.com/topic/15001/enlightened .
I feel so grateful that my first GUI toolkit is Cocoa touch which is mature in design. At least the typing just works and object ownership is well defined.
I had not heard of enlightenment, so took a peek but as far as I could make out from the docs, it is linux/unix project? I saw nothing about MacOS or Windows... did I miss it?
[Py]Qt of course is cross-platform with the local look/feel.
[Py]Qt of course is cross-platform with the local look/feel.
Thank you, that looks very interesting. I'm not sure if it's cross-platform, but I'll play with it a bit and see.
Tkinter, it comes packed with python and is actually really good and really fast.
In fact, when I tried variations of Qt for py, I just quit out of frustration with how things either didn’t work or didn’t work very fast, now I just stick with Tkinter.
In fact, when I tried variations of Qt for py, I just quit out of frustration with how things either didn’t work or didn’t work very fast, now I just stick with Tkinter.
Unfortunately, Tk isn't accessible with screen readers (for blind people) or other assistive technologies, at least on Windows. Of course, if you're just developing utilities for yourself, that's fine. Otherwise, I'd recommend wxWidgets or Qt instead.
Do you know of good tutorials on ttk? I keep on reading that the look and feel provided by ttk is much more native than tk, but I can hardly find a good relevant tutorial.
Check out tkdocs.com
One thing to keep in mind is licensing. PyQt is GPL and commercial licensed. PySide is LGPL.
wxPython is a thing that exists, and I believe it has a similar mental model to wxWidgets.
To be honest most of the QT solutions for Python are pretty fidgety . The recent wxPython releases (4.x) work out of the box direct from PyPI, not too much to worry about licensing.
For Qt, it's... the licensing is usually just fine for people but it's complex enough to where things like maintaining your own fork (pretty easy in Python compared to C++) is not super easy. But there's decent Python support, so it's more "do you want to use Qt or wx". Both systems have good enough support.
To be honest most of the QT solutions for Python are pretty fidgety . The recent wxPython releases (4.x) work out of the box direct from PyPI, not too much to worry about licensing.
For Qt, it's... the licensing is usually just fine for people but it's complex enough to where things like maintaining your own fork (pretty easy in Python compared to C++) is not super easy. But there's decent Python support, so it's more "do you want to use Qt or wx". Both systems have good enough support.
Qt license is pretty ok, it is just complicated for the typical crowd that wants to sell stuff built with free (beer) tools.
I guess the proper rephrasing is that it doesn't match the licensing terms of most projects in the Python world.
It's most definitely not the most complicated thing, but when your processes are based off of BSD'd libraries, you gotta think a bit harder about Qt usage, if only for it falling outside the normal scope of things.
It's most definitely not the most complicated thing, but when your processes are based off of BSD'd libraries, you gotta think a bit harder about Qt usage, if only for it falling outside the normal scope of things.
[deleted]
FWIW I use PyQt5 in a code editor project I maintain. While all GUI frameworks have hiccups and smells to various degrees, Qt and PyQt5 has been, relatively speaking, the strongest UI framework I've encountered for Python. Why? Ease of development, cross-platform reach, "batteries included" (e.g. accessibility features, important for my project), friendliness of the API and breadth of features immediately spring to mind.
Perhaps PySide's return will encourage some competition in the Qt space for Python. For example, I wish it was simple to create a cross-platform installer for stand-alone Python apps that use Qt. Current solutions suffer from the 80/20 rule where the 20 usually contains something essential.
Perhaps PySide's return will encourage some competition in the Qt space for Python. For example, I wish it was simple to create a cross-platform installer for stand-alone Python apps that use Qt. Current solutions suffer from the 80/20 rule where the 20 usually contains something essential.
Has the python qt installation story improved much recently? A few years ago it was a pain to set up, especially within a virtualenv, which was one of my only complaints with it. Everything else was wonderful.
You can just do `pip install PyQt5` now. That is possible without a virtual environment, but in practice I think you still want to use one: python3 -m venv venv && source venv/bin/activate && pip install PyQt5.
How well does that work on OSX? I’ve tried many times over many years, but never got a satisfactory working Python + Qt development environment working on the Mac.
With Python3 and PyQt5 it is literally as simple as "pip install pyqt5". I speak from having built and maintained multiple PyQt-based apps on MacOS.
Edit: I should say, there are MacOS-unique difficulties if you want to bundle your nice PyQt5 script into a standalone MacOS app bundle using PyInstaller. But that's a separate issue.
Edit: I should say, there are MacOS-unique difficulties if you want to bundle your nice PyQt5 script into a standalone MacOS app bundle using PyInstaller. But that's a separate issue.
conda install pyqt
Why was this downvoted?
It will setup exactly what was asked for. Specifically qt 5.9.5 with PyQt.
It will setup exactly what was asked for. Specifically qt 5.9.5 with PyQt.
>>> You can just do `pip install PyQt5` now.
>> How well does that work on OSX?
> conda install pyqt
Your comment, while presenting a potential solution to the original problem, did not make sense in context and went off in another direction entirely.
>> How well does that work on OSX?
> conda install pyqt
Your comment, while presenting a potential solution to the original problem, did not make sense in context and went off in another direction entirely.
Did you miss that I was replying to
simonh, and to be specific, to this part?
> I’ve tried many times over many years, but never got a satisfactory working Python + Qt development environment working on the Mac.
> I’ve tried many times over many years, but never got a satisfactory working Python + Qt development environment working on the Mac.
pip installing binary dependencies! What could go wrong?
With the new binary wheels, this actually works now - at least on Windows 10 and misc Linux distros (and according to other comments here, on Mac OS too).
On Linux you might want to get the distros qt/qt-dev packages, as usual. But as far as I can recall, you generally don't have to.
On Linux you might want to get the distros qt/qt-dev packages, as usual. But as far as I can recall, you generally don't have to.
Great - installing random (huge) binaries that have been compiled god-knows-how by god-knows-whom expecting god-knows-what other libraries to be on the target system.
Sorry to be spamming here but check out my https://github.com/mherrmann/fbs. It is literally the solution to your pain point.
No, interesting and useful. But a few questions. So basically you have automated the job of calling PyInstaller to make a standalone app, plus the step of wrapping the app in an installer. Yes?
In order to use this, if I read the tutorial[1] code correctly, I must modify my app to wrap everything -- or at any rate, all PyQt-related things? -- inside an AppContext, and modify the outermost level to create this.
If so, this is easy enough for the tutorial but what if my app opens multiple windows and has code to create them spread over multiple modules (as one of mine does). Is there a simple way to get all these bits into one "context"? Or have I read too hastily?
[1] https://github.com/mherrmann/fbs-tutorial
In order to use this, if I read the tutorial[1] code correctly, I must modify my app to wrap everything -- or at any rate, all PyQt-related things? -- inside an AppContext, and modify the outermost level to create this.
If so, this is easy enough for the tutorial but what if my app opens multiple windows and has code to create them spread over multiple modules (as one of mine does). Is there a simple way to get all these bits into one "context"? Or have I read too hastily?
[1] https://github.com/mherrmann/fbs-tutorial
It's more than just automating the calling of PyInstaller. It also fixes some edge cases with PyInstaller-built apps that lead to crashes on some users' systems and took me months to figure out. Further, it integrates the solutions nicely. You don't have to learn how PyInstaller works, fbs does it for you with very reasonable default settings. You don't have to figure out how you are going to ship resource files and access them from within your app, etc.
Yes you should use the AppContext. You don't have to convert your entire app to it. Only enough to "start" your app. (I highly recommend the app context approach where possible however, it's just so clear.)
Yes you should use the AppContext. You don't have to convert your entire app to it. Only enough to "start" your app. (I highly recommend the app context approach where possible however, it's just so clear.)
Man, when a project is this useful, spam away. Thanks for this.
Does it use Qt IFW? That's what I've been using for cross-platform installers.
Aha... thanks for the heads-up. :-)
I'll echo this.
I've maintained a production PyQt based app for 7-8 years (started on PyQt4/py2, moved to PyQt5/py3, but I evaluated PySide as well). It involved wrapping another Qt library for use from python. I found the bindings I created based on SIP (which is what PyQt is based on, both written by the same author) to be overall easier to create and smaller in size.
It's great that we're getting Qt backed bindings but Phil Thompson has done a wonderful job with PyQt over the years and I really would've liked to see it become the official library somehow.
I've maintained a production PyQt based app for 7-8 years (started on PyQt4/py2, moved to PyQt5/py3, but I evaluated PySide as well). It involved wrapping another Qt library for use from python. I found the bindings I created based on SIP (which is what PyQt is based on, both written by the same author) to be overall easier to create and smaller in size.
It's great that we're getting Qt backed bindings but Phil Thompson has done a wonderful job with PyQt over the years and I really would've liked to see it become the official library somehow.
I've always found Qt and Python (PyQt and PySide) to be a weird match. So many times did I end up with cryptic segfaults in the python VM due to some python object being collected "too early", creating a dangling pointer in the C++ world. This can happen if you forget to set the parent object, for instance.
I know that those are things you have to worry about when you write C++, but when in the python world, you kind of expect everything to be refcounted for you. If I ever have to write a GUI app in python again, I'll probably chose another framework.
I know that those are things you have to worry about when you write C++, but when in the python world, you kind of expect everything to be refcounted for you. If I ever have to write a GUI app in python again, I'll probably chose another framework.
This just means that wrapper around C(++) code doesn't handle resources correctly. As you said, once inside Python you shouldn't care about object collection process. Nothing should lead to segfaults, in worst case you should get an exception about missing parent ref.
more exactly “underlying C/C++ object has been deleted" error.
In my experience, those errors are easy to resolve: just assign the new object to something, so it isn't immediately deleted. A little awkward, maybe, and it shouldn't happen, but if that's the worst quirk of PyQT/PySide, I can deal.
Those errors are always related with a bad implementation where there is something holding a reference to the qt python object represented by the bidding therefore keeping it alive even when their c++ instance has been already deleted. The solution is to go back to the drawing board and improve the implementation :)
This seems to be the successor for PySide that supports Qt 5. The old PySide died some years ago and only PyQt was offering Qt 5 support. Due to some details PyQt was never officially supported by Qt. Is PySide2 now officially supported by Qt?
http://blog.qt.io/blog/2018/04/13/qt-for-python-is-coming-to...
"PySide2 – the bindings from Python to Qt – changes skin this spring. We have re-branded it as Qt for Python on a solution level, as we wanted the name to reflect the use of Qt in Python applications. Under the hood it is still PySide2 – just better."
"PySide2 – the bindings from Python to Qt – changes skin this spring. We have re-branded it as Qt for Python on a solution level, as we wanted the name to reflect the use of Qt in Python applications. Under the hood it is still PySide2 – just better."
Yes, but tbh even PySide was originally "officially supported" by Qt, when Nokia owned it; and then it was dropped. So the question is whether it will continue to be supported.
The owners of PyQt (Riverbank) depend on that product to survive; whereas Qt has bigger fish to fry most of the time. The incentives are very different.
The owners of PyQt (Riverbank) depend on that product to survive; whereas Qt has bigger fish to fry most of the time. The incentives are very different.
It wasn't so much that PySide was dropped, as the whole of Qt was dropped (by Nokia). PySide development was funded by Nokia, which owned Qt, and done mostly in a Nokia R&D institute in Brazil (INdT). Nokia sold Qt to Digia, and Microsoft bought Nokia, so there was no connection anymore between Qt and the people who developed PySide, and so it stalled.
Digia later spun off The Qt Company, which develops Qt and is now developing PySide2, so this is actually the first time the same organisation has developed both Qt and Python bindings for it.
For many purposes (including mine), PyQt is very expensive, so I'm really hoping PySide2 goes somewhere.
Digia later spun off The Qt Company, which develops Qt and is now developing PySide2, so this is actually the first time the same organisation has developed both Qt and Python bindings for it.
For many purposes (including mine), PyQt is very expensive, so I'm really hoping PySide2 goes somewhere.
PyQt is not affiliated with Qt the company. "Qt for Python" (formerly PySide2) is. So, yes.
This is like 10 years too late. This could have prevented electron.
Electron is the third wave, before we had MSHTML and XUL.
Just like its predecessors I give it one or two years more max, then it will fade away like they did.
Just like its predecessors I give it one or two years more max, then it will fade away like they did.
Most interfaces created through web technology would be incredibly hard and slow to do using pyside/pyqt. We take for granted the non-blocking aspect of javasript where in python in order to make a slick interface would require to deal with threads/GIL in a much slower interpreted language compared with javascript running on V8.
Qt (Qt Desktop) bindings for python are welcome. But, it's not a suitable for a viable replacement for electron. Maybe Qt Quick, but even qt quick has some decisions that can make incredibly uncomfortable to use in large applications.
Qt (Qt Desktop) bindings for python are welcome. But, it's not a suitable for a viable replacement for electron. Maybe Qt Quick, but even qt quick has some decisions that can make incredibly uncomfortable to use in large applications.
We have asyncio now to handle things in a non-blocking way with async/await. Someone just needs to write an implementation of asyncio.AbstractEventLoop that hooks into the Qt event loop.
And then they need to write an async version of everything you might want to use. And then they're done!
No, async versions of everything are already being written, based on asyncio. You just need the glue for using it with Qt.
but.... 10 years ago there was PySide 1 which was the exact equivalent of this except with the 10 years ago Qt version
The licensing was weird iirc.
People use Electron because of web technology and also the abstractions available there like React, not because any dynamically-typed language would've sufficed.
In fact, Python is at a disadvantage here anyways because it's not async by default.
In fact, Python is at a disadvantage here anyways because it's not async by default.
What's so important about being async by default to build desktop applications? Offloading slow tasks to a background thread is not at all harder and actually allows you to use more than one cpu core.
Threads avoid the need of callbacks/promises/async/await and they're also cheap and performant unless you need to spawn >10k of them, which seems very unlikely in a desktop applications.
Being async by default is an advantage when you need to handle hundreds of thousands of tasks, all of which are mostly waiting on I/O, which is something that can happen on server side applications, and almost never on the desktop.
Threads avoid the need of callbacks/promises/async/await and they're also cheap and performant unless you need to spawn >10k of them, which seems very unlikely in a desktop applications.
Being async by default is an advantage when you need to handle hundreds of thousands of tasks, all of which are mostly waiting on I/O, which is something that can happen on server side applications, and almost never on the desktop.
Python is really in the same category as JavaScript as far as being asynchronous is concerned.
Does anyone know of a Qt binding for Python that is actually pythonic (as in follows PEP 8)? Both PyQt and Pyside are just one-to-one wrappers that use C-style naming for everything.
I find that really strange. The same holds for most other GUI libraries, like WxPython.
It seems the only real pythonic GUI libraries are Tkinter and PyGobject.
I find that really strange. The same holds for most other GUI libraries, like WxPython.
It seems the only real pythonic GUI libraries are Tkinter and PyGobject.
It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time. At the end of the day, PEP8 is just a convention and we're free to break with it where it makes sense. Imho, this is such a case.
> It's so much better if it's one-to-one. You can use the same documentation. The same search terms. You don't have to translate back and forth in your head all the time.
Those are things that make it better for the library maintainers, sure, but presenting (and documenting) an API that is idiomatic, both in structure and behavior, for the host language is better for library consumers, as it doesn't force them to context switch between the idioms of the host language and the idioms of the foreign library.
Those are things that make it better for the library maintainers, sure, but presenting (and documenting) an API that is idiomatic, both in structure and behavior, for the host language is better for library consumers, as it doesn't force them to context switch between the idioms of the host language and the idioms of the foreign library.
Agree with having a pythonic API.
There are already examples in the "Hello Qt" which are easily solvable:
These small things make the difference.
There are already examples in the "Hello Qt" which are easily solvable:
app = QApplication([])
# should read instead:
app = QApplication()
app.exec_()
# should be instead
app.exec()
These small things make the difference.
`exec` is a python built-in (in py3, it was a keyword in py2). Variables that would clash names with keywords / built-is are conventionally followed by an _, so `exec_` is expected.
I agree on your first example.
I agree on your first example.
exec is a reserved keyword in Python. The _ is there because the code wouldn't "compile" otherwise.
[deleted]
[deleted]
Parent was taking about PEP8, which is purely syntactic. I would argue that has very little to do with structure and behaviour. It's completely superficial.
Syntax is an element of structure. But, yes, I was going beyond the upthread comment.
Well, if code readability is superficial to you, you are probably not the target group of Python I guess. For Python users, readability, however, is very important.
No it really is not. You are defending Qt's decision to keep their own lives simple. That's fine for Qt, but not so for their target Python audience.
Generating similar high quality docs for the Pythonic wrapper should not be a issue.
Isn't the point that you don't have to translate in your head all the time. For non-Pythonic, non pep8 code you are going to do that constantly, not only when you read the Qt docs.
pep8 is a subset of 'Pythonic', the current wrappers are not only not pep8 compliant, they are also un-Pythonic in other ways.
Don't get me wrong, I appreciate Qt trying to expand their user base, but I would consider this effort a early milestone on the road to something that really fits into the Python ecosystem.
Generating similar high quality docs for the Pythonic wrapper should not be a issue.
Isn't the point that you don't have to translate in your head all the time. For non-Pythonic, non pep8 code you are going to do that constantly, not only when you read the Qt docs.
pep8 is a subset of 'Pythonic', the current wrappers are not only not pep8 compliant, they are also un-Pythonic in other ways.
Don't get me wrong, I appreciate Qt trying to expand their user base, but I would consider this effort a early milestone on the road to something that really fits into the Python ecosystem.
The Python standard library itself also breaks the PEP8 naming convention in all the ways PyQt does so their decision really makes sense. If Python itself were consistent the trade-off would be different...
I find PyQt to be Pythonic in all the ways that count, e.g. replacing `self.setFoo(bar)` with `self.foo = bar`, decorators for signals/slots, etc.
I find PyQt to be Pythonic in all the ways that count, e.g. replacing `self.setFoo(bar)` with `self.foo = bar`, decorators for signals/slots, etc.
It does? Which library?
Unfortunately, a few library modules that predate PEP 8 and that never made the switch still use camel case, such as `unittest` and a few others. Bugs the hell out of me, as do libraries that have no excuse for their lack of compliance with PEP 8, such as PySide.
logging for instance.
import logging
logger = logging.getLogger()
logger.setLevel(logging.DEBUG)
logger.addHandler(...)[deleted]
Sadly, we still don't have the seamless UI building functionality Delphi had 15 years ago, allowing making a fairly advanced desktop app in a day. Jumping between Qt Designer and IDE back and forth is still an order of magnitude more complicated than it needs to be.
Delphi is still around, as is the open source clone Lazarus. It's certainly not as popular as it used to be but still actively developed with people using it.
Yes, though Pascal is now a fringe language. I was mostly ranting about best IDEs Python has such as PyCharm, where one has to go back and forth between Qt Designer, some command-line compilation stuff and PyCharm. It feels like some ancient way to waste time doing trivial stuff instead of getting app done quickly.
Ha! I feel your pain. That's what I ended up doing for an application a few years ago, wrote a Python script to compile the Qt Designer generated code to Python code [0]
[0] https://github.com/ssebastianj/ia2013-tpi-rl/blob/master/gui...
Going back and forth between Qt Designer and PyDev was (is?) ancient. Unfortunately I couldn't find a way to automate the compilation step (perhaps with a hook from Qt Designer?)
[0] https://github.com/ssebastianj/ia2013-tpi-rl/blob/master/gui...
Going back and forth between Qt Designer and PyDev was (is?) ancient. Unfortunately I couldn't find a way to automate the compilation step (perhaps with a hook from Qt Designer?)
> Jumping between Qt Designer and IDE back and forth is still an order of magnitude more complicated than it needs to be.
... uh ? the designer is part of the ide... nowadays you even have a code view synced with the UI editor in realtime (http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creat...)
... uh ? the designer is part of the ide... nowadays you even have a code view synced with the UI editor in realtime (http://blog.qt.io/blog/2017/05/24/qt-quick-designer-qt-creat...)
He was talking about writing Qt apps with Python. (This entire post is about writing Qt apps with Python.) Qt Creator is not a Python IDE.
Ie you have to use qt designer as you ide or switch between IntelliJ/pycharm. It’s not ideal as IntelliJ is miles ahead of qt designer as a general purpose ide for python. I’m pretty spoiled at this point by the excellent refactorings and type support.
I just took a look at delphi. What’s so unique about its ui builder?
Delphi's UI designer pioneered two-way tools, meaning that any changes to the contents of a form/window are reflected immediately in code.
The general design is this: there's a code unit (.pas) and declarative UI property file (.dfm) for every form in your application. When you modify any published properties for any controls/components on the form via the object inspector, these modifications are stored in the .dfm file. Any changes to the controls/components on the form (adding a control, removing a control, renaming a control) are immediately reflected in the .pas code for the form. And, the code is not just generated code that you can't touch, it is code that you are modifying along with the IDE. You can jump back and forth between the UI designer and code editor with a simple F12 key press.
When an application is compiled, the compiler automatically bundles the .dfm files as resources in the resultant binary and streams the properties in during form instantiation.
Where this all really shines is with event handling. You can, for example, double-click a button on the form and the designer will drop you into the code editor with a fully-defined OnClick event handler all ready to go. This is because Delphi has the concept of default events for controls/components. For non-default events, you can do the same by double-clicking on the event name in the object inspector.
The other thing is that the UI designer is running real code in the background for controls/components, so the design-time environment mirrors the run-time environment, and control/component designers can interrogate the RTL to find out which state they are in, and act accordingly. You can also write custom property editors that allow for complex property editing in a nice interface.
Our product, Elevate Web Builder, works exactly like this for building single-page web applications. It's extremely productive and a very good fit for web applications because, unlike desktop applications, there's not as much risk of mixing back-end code into your UI code and starting to makes things messy.
The key is that you need a strongly-typed language to make this all happen, so I'm not sure how applicable any of this is to Python.
The general design is this: there's a code unit (.pas) and declarative UI property file (.dfm) for every form in your application. When you modify any published properties for any controls/components on the form via the object inspector, these modifications are stored in the .dfm file. Any changes to the controls/components on the form (adding a control, removing a control, renaming a control) are immediately reflected in the .pas code for the form. And, the code is not just generated code that you can't touch, it is code that you are modifying along with the IDE. You can jump back and forth between the UI designer and code editor with a simple F12 key press.
When an application is compiled, the compiler automatically bundles the .dfm files as resources in the resultant binary and streams the properties in during form instantiation.
Where this all really shines is with event handling. You can, for example, double-click a button on the form and the designer will drop you into the code editor with a fully-defined OnClick event handler all ready to go. This is because Delphi has the concept of default events for controls/components. For non-default events, you can do the same by double-clicking on the event name in the object inspector.
The other thing is that the UI designer is running real code in the background for controls/components, so the design-time environment mirrors the run-time environment, and control/component designers can interrogate the RTL to find out which state they are in, and act accordingly. You can also write custom property editors that allow for complex property editing in a nice interface.
Our product, Elevate Web Builder, works exactly like this for building single-page web applications. It's extremely productive and a very good fit for web applications because, unlike desktop applications, there's not as much risk of mixing back-end code into your UI code and starting to makes things messy.
The key is that you need a strongly-typed language to make this all happen, so I'm not sure how applicable any of this is to Python.
Well hey now, python is strongly typed. Type declarations are just optional. :) just giving you grief.
That said, especially the custom property editors would make e.g. Xcode’s interface builder almost worth looking at. I’ve just given up on graphical designers at all—last I checked thy were all terrible with responsive design, which is ironic on an ide that claims to target a mobile platform.
That said, especially the custom property editors would make e.g. Xcode’s interface builder almost worth looking at. I’ve just given up on graphical designers at all—last I checked thy were all terrible with responsive design, which is ironic on an ide that claims to target a mobile platform.
:-) Yeah, you're correct, I should have written statically-typed, not strongly-typed.
As for responsive design in graphical editors: what part do you find that they are terrible at, or is it that they don't do it at all ? Our previously-mentioned Elevate Web Builder will allow the developer to design responsive layouts that flow and move as you resize the container in the designer so that you can see how the design will behave at run-time.
As for responsive design in graphical editors: what part do you find that they are terrible at, or is it that they don't do it at all ? Our previously-mentioned Elevate Web Builder will allow the developer to design responsive layouts that flow and move as you resize the container in the designer so that you can see how the design will behave at run-time.
You could build a comprehensible app with very natural handling of UI events, mostly by just clicking in designer and setting some properties visually, in like an hour, what in Visual Studio took weeks. It was such a time saver and productivity boost for UI and we still don't have anything mainstream that approaches these levels for e.g. web or Python.
Don't know if its UI builder is unique or not, but there are plenty of good things about it. Some bad, too.
Here is one post and a thread with many pros and con views about Delphi:
Delphi – why won't it die? (2013) (stevepeacocke.blogspot.com)
https://news.ycombinator.com/item?id=7613543
Here is one post and a thread with many pros and con views about Delphi:
Delphi – why won't it die? (2013) (stevepeacocke.blogspot.com)
https://news.ycombinator.com/item?id=7613543
It was (is?) very powerful and at the same time very easy to use. Not sure about alternatives nowadays...
For .NET, Eto is a good option. It's cross-platform and supports the native toolkits of the platforms it supports:
https://github.com/picoe/Eto
There's also Avalonia, but it's currently in beta:
http://avaloniaui.net/
https://github.com/picoe/Eto
There's also Avalonia, but it's currently in beta:
http://avaloniaui.net/
Mostly Java and .NET, if we let aside the AOT compilation part, although it is being improved.
Qt for Python == PySide2 == PySide for Qt 5.
I'm sure others here have far, far more experience with QT that I do, I wanted to give my 2 cents: QT has been great for the experimental control software we run to perform experiments in our lab (https://github.com/LISE-B26/PyLabControl --- note, the readme is unfortunately out of date, but it should be ready in a week or two). I tried a good number of other GUI libraries for python, but pyQT just worked far more quickly.
Anyone else getting Heroku application error?
https://archive.fo/DdJpj
https://archive.fo/DdJpj
If you click on "history", you can find a version that works, though:
https://archive.fo/y0YlA
https://archive.fo/y0YlA
Yep, website seems to be down.
I skimmed through the posts in the thread but no one seemed to mention the major pet peeve that (IMO) PyQt has, which is not the licensing, but the development model:
1. SIP files are generated and dropped into the tarball: no way to do that yourself (the tool is available, but completely undocumented). This is problematic when a new major Qt version is out, but PyQt hasn't updated yet (I had problems like this recently when building PyQt5 for Qt 5.11 for openSUSE)
2. There is absolutely no bug reporting: you have to join the mailing list, post about your issue, and hopefully get an answer or "fixed in next snapshot" (see below)
3. There's no source repository access, just frequently-released "snapshots". Backporting patches to stable releases (because perhaps fixes aren't in old versions) is a chore.
4. Submitting patches as well requires a ML post: not bad per se, but there's no real workflow for it (and hard to do anyway without having the current state of the code).
I don't have to use PyQt professionally (all my stuff is parsing/querying/stats, so a GUI isn't necessary), but for my free time projects I preferred to learn C++ and Qt than go through PyQt again. And it's a shame since the bindings are quite good in quality.
1. SIP files are generated and dropped into the tarball: no way to do that yourself (the tool is available, but completely undocumented). This is problematic when a new major Qt version is out, but PyQt hasn't updated yet (I had problems like this recently when building PyQt5 for Qt 5.11 for openSUSE)
2. There is absolutely no bug reporting: you have to join the mailing list, post about your issue, and hopefully get an answer or "fixed in next snapshot" (see below)
3. There's no source repository access, just frequently-released "snapshots". Backporting patches to stable releases (because perhaps fixes aren't in old versions) is a chore.
4. Submitting patches as well requires a ML post: not bad per se, but there's no real workflow for it (and hard to do anyway without having the current state of the code).
I don't have to use PyQt professionally (all my stuff is parsing/querying/stats, so a GUI isn't necessary), but for my free time projects I preferred to learn C++ and Qt than go through PyQt again. And it's a shame since the bindings are quite good in quality.
This isn't PyQt, but an update of PySide. However I find the PyQt developer very responsive to bug reports. It's a much better service vthan the usual post to a bug tracker and no response you get with many other projects.
I used PyQt5 quite successfully a while back. This looks very similar. What is actually new here?
PyQt is not PySide. Qt (the foundation) does not officially support PyQt. PySide (the old one) did not support Qt5. PySide2 does support Qt5.
> Qt (the foundation) does not officially support PyQt.
But the project owners (Riverbank) support PyQt just fine, and arguably much better than Qt ever supported PySide in any previous incarnation.
But the project owners (Riverbank) support PyQt just fine, and arguably much better than Qt ever supported PySide in any previous incarnation.
Permissive license.
So PyQt5 is GPL. Practically speaking what is the point of a new permissively licensed library?
Once upon a time, Qt was GPL + commercial. A separate project - PyQt - came and was GPL + commercial too.
Later, Qt became GPL + LGPL + commercial. However, PyQt, didn't want to add LGPL and stayed dual licensed. Qt thought "ok then, will have to do it by myself" and created an alternative to PyQt called PySide, which was GPL + LGPL + commercial.
That was in Qt4 time. Then Qt5 came, and PyQt5 appeared, while PySide was still in Qt4 land.
Then PySide2 happened, now known as Qt for Python.
Later, Qt became GPL + LGPL + commercial. However, PyQt, didn't want to add LGPL and stayed dual licensed. Qt thought "ok then, will have to do it by myself" and created an alternative to PyQt called PySide, which was GPL + LGPL + commercial.
That was in Qt4 time. Then Qt5 came, and PyQt5 appeared, while PySide was still in Qt4 land.
Then PySide2 happened, now known as Qt for Python.
PySide came to exist because Nokia failed to reach a commercial licensing agreement with Riverbank (the makers of PyQt). I guess one side or the other was asking for too much
https://wiki.qt.io/PySide_FAQ
> Initial research into Python bindings for Qt involved speaking with Riverbank Computing, the makers of PyQt. We had several discussions with them to see if it was possible to use PyQt to achieve our goals. Unfortunately, a common agreement could not be found , so in the end we decided to proceed with PySide.
https://wiki.qt.io/PySide_FAQ
> Initial research into Python bindings for Qt involved speaking with Riverbank Computing, the makers of PyQt. We had several discussions with them to see if it was possible to use PyQt to achieve our goals. Unfortunately, a common agreement could not be found , so in the end we decided to proceed with PySide.
And GPL isn't permissive.
Eg. that you can use it for free(?)
This seems easily googleable. Are you really completely oblivious as to controversy surrounding the GPL, especially as opposed to LGPL and ASL/MIT/BSD?
Took me a while to figure out the "pip install" command:
pip install --index-url=http://download.qt.io/snapshots/ci/pyside/5.9/latest/ pyside2 --trusted-host download.qt.io
I have been waiting for this my entire adult life. That's all I have to say about it.
What about pygobject? What does Qt have to offer over GTK?
I like pygobject too, but I've always wanted a QT library for python not written by a 3rd party. Most of the 3rd party libs will get you 90% there, but if QT commits to making the library, they won't leave me hanging. I've been wanting to build a python desktop app with the newest version of QT with lots of dynamic UI windows for a very long time, and this will allow me to do it.
Haven't used either, but people typically say that Qt's API is cleaner, that it's better suited for cross-platform applications (for example it has support for Android) and that it's more flexible (for example LXDE is being rewritten as LXQt, since the devs found GTK3 too heavyweight and too GNOME-centric).
Is is possible to use QML in a PyQt/PySide2 app? Using QML for interface and Python for logic would make perfect sense. But every PyQt article and tutorial I see is about QtWidgets.
We use PyOtherSide for exactly this. Works perfectly.
I'm also working on a similar solution for .NET Core: https://github.com/pauldotknopf/net-core-qml
I'm also working on a similar solution for .NET Core: https://github.com/pauldotknopf/net-core-qml
Yes, PyQt4/5 has supported this since it was first introduced, PySide2 just recently got some support for it although it is incomplete. Source: I maintain a Python/QML library https://github.com/pyblish/pyblish-qml
Do you need PySide2 to support QML in order to use the Qt Designer?
Archived page because site is really slow:
https://archive.is/y0YlA
https://archive.is/y0YlA
This is good ! I remember coding a GUI in PyQt5 when the first usables version of python 3 came out and it was incredibly painful.
Almost no documentation was avaible and I was learning how GUI works. It took me a while to get a basic app running and from there I mostly translated the official docs to python.
Almost no documentation was avaible and I was learning how GUI works. It took me a while to get a basic app running and from there I mostly translated the official docs to python.
Why though? Is there some useful benefit that python offers over C++, or is it just another language support so that people more comfortable with Python could use it?
If I were ever to write a desktop app, which one should I choose, given I'm equally comfortable with both languages?
If I were ever to write a desktop app, which one should I choose, given I'm equally comfortable with both languages?
It's like you say, and like the qt blog says, "opening to python world"
About your second question (c++ vs python), even I am curious
About your second question (c++ vs python), even I am curious
Python is a much higher level language than C++, with all the problems and benefits of that.
I would love to hear more about this from the sages of HN. I really don't enjoy GUI development in Python. I am not a good enough CS to have the language to describe what is wrong, but I find it really hard to get Python GUI stuff to do what I want.
Retained-mode GUIs like Qt , wxWidgets, gtk, etc aren't intuitive. Try an immediate mode GUI, like my python bindings to nuklear
https://github.com/billsix/pyNuklear
https://github.com/billsix/pyNuklear
For more context, immediate mode is much closer to the type of declarative UI popularized by libraries like React. The invariant is that what is displayed on screen is always a pure function of some state variable(s), and on any input/event, instead of needing to "reach into" some retained object that represents a certain piece of text in a certain pane in a certain window, you just change those state variables and re-render the entire UI from scratch. Sounds expensive, but for a 2D UI on hardware that's designed to do far more complicated things at 60FPS, it's far from the bottleneck.
For instance, https://github.com/billsix/pyNuklear/blob/master/demo/overvi... (this function is called repeatedly on each frame) is not significantly different from the example at https://reactjs.org/tutorial/tutorial.html#what-is-react ... but it is very different from something like `div = createDiv(); div2 = createDiv(parent=div)` etc. which would be a retained-mode API.
For instance, https://github.com/billsix/pyNuklear/blob/master/demo/overvi... (this function is called repeatedly on each frame) is not significantly different from the example at https://reactjs.org/tutorial/tutorial.html#what-is-react ... but it is very different from something like `div = createDiv(); div2 = createDiv(parent=div)` etc. which would be a retained-mode API.
Another option is pyImgui. Imgui is C++ based. pyimgui isn't on the latest imgui version, but it's coming along. https://github.com/swistakm/pyimgui
What is the difference between the two GUI modes?
If you can't express what's wrong it will be even harder to find a solution.
Sorry, I thought it was generally accepted that Python's relationship with the GUI was troubled?
Put in plain English it is like this. I write quite a lot of code that integrates various enterprise systems together. Things like EDI management, and 'brokers' between incompatible API's. It is usually a mixture of Python/Bash/SQL. It is not my full-time job to code, but I get things done. As complexity increased I learned about version-control, OOP, and unit-testing. I have some pretty complex stuff in production. So I can self-learn all of those things, but not Python GUI programming
The kind of thing I would happily launch from the command line, often needs a GUI when end users are involved. Even to have an app that takes an input>click OK>do some API stuff>return an answer seems absurdly complicated in Python and [insert whichever GUI framework]. In fact I find it simpler to add a web front end and a server than I do a desktop GUI. Qt was never on my list as I have enough battles to handle without negotiation with bosses for PyQt licensing costs. Hence my interest in this development.
I didn't have this trouble with VB6 or VB.NET. Draw a box>draw a button>double-click the button>add the code you want to run when the button is clicked.
When I do the same in Python I have dozens of lines of set-up code. I have a window with a text box and a button, surely that should be three lines of code (like in html)? Then I find that things are not running in the order I expected... Imagine for instance I want to put an alert box up that says "working", then call the function to do the work, then take the alert box away when the function exits...My Python head says this should look like this
There doesn't seem to be a Pythonic or indeed simple way to handle these super straight-forward use cases. I have no aspiration to be a UX person, or learn a new paradigm just to have a button that says "GO!". I'm guessing from the other comments that Qt for Python is not going to be my savior.
Put in plain English it is like this. I write quite a lot of code that integrates various enterprise systems together. Things like EDI management, and 'brokers' between incompatible API's. It is usually a mixture of Python/Bash/SQL. It is not my full-time job to code, but I get things done. As complexity increased I learned about version-control, OOP, and unit-testing. I have some pretty complex stuff in production. So I can self-learn all of those things, but not Python GUI programming
The kind of thing I would happily launch from the command line, often needs a GUI when end users are involved. Even to have an app that takes an input>click OK>do some API stuff>return an answer seems absurdly complicated in Python and [insert whichever GUI framework]. In fact I find it simpler to add a web front end and a server than I do a desktop GUI. Qt was never on my list as I have enough battles to handle without negotiation with bosses for PyQt licensing costs. Hence my interest in this development.
I didn't have this trouble with VB6 or VB.NET. Draw a box>draw a button>double-click the button>add the code you want to run when the button is clicked.
When I do the same in Python I have dozens of lines of set-up code. I have a window with a text box and a button, surely that should be three lines of code (like in html)? Then I find that things are not running in the order I expected... Imagine for instance I want to put an alert box up that says "working", then call the function to do the work, then take the alert box away when the function exits...My Python head says this should look like this
def on_ok_clicked(event):
alert=framework.alertbox(text="working...")
do_important_blocking_stuff()
alert.destroy()
There doesn't seem to be a Pythonic or indeed simple way to handle these super straight-forward use cases. I have no aspiration to be a UX person, or learn a new paradigm just to have a button that says "GO!". I'm guessing from the other comments that Qt for Python is not going to be my savior.
> My Python head says this should look like this
No, that's not "your python head", sorry, that's your "VB head" at best. That's lack of knowledge of how desktop GUI paradigms actually work and what an event loop is and how it interacts with threads.
I do not disagree that VB (and Delphi) did a better job at hiding these concepts from the "just getting it done" crowd, but don't blame it on Python if you don't have a grasp of how C++ GUI toolkits actually work.
No, that's not "your python head", sorry, that's your "VB head" at best. That's lack of knowledge of how desktop GUI paradigms actually work and what an event loop is and how it interacts with threads.
I do not disagree that VB (and Delphi) did a better job at hiding these concepts from the "just getting it done" crowd, but don't blame it on Python if you don't have a grasp of how C++ GUI toolkits actually work.
> but don't blame it on Python if you don't have a grasp of how C++ GUI toolkits actually work.
I'm not blaming it on Python, honestly. I'm just really surprised that there isn't a framework that will hide that stuff from me like VB did. You are a 100% correct in that I don't know anything about desktop GUI paradigms, or C++ GUI toolkits. I really don't have the bandwidth to find out either! I'm also surprised that I need to. I don't think that is even my VB head, I am a business systems person who has successful modeled a physical process in software. In a recent case I did all of the work negotiating with vendors/management/users, I found the bugs in the vendors API, and I did this to an absurd deadline (with almost zero budget) created by a a vendor withdrawing a product with no notice. That's the kind of absurd thing us plebs in the "just getting it done" crowd have to do all of the time. But I am finding that simple GUI launchers for my software are really complicated in Python with the frameworks I have found. I am shocked that this is the piece that is defeating me! As I said before, I could write a web front-end for this kind of thing relatively easily (in the above case it was a hardware requirement that lead me to try again at the desktop GUI). Perhaps this is why we see so many people looking at the web-app-on-the-desktop that is so derided on these pages?
I'm not blaming it on Python, honestly. I'm just really surprised that there isn't a framework that will hide that stuff from me like VB did. You are a 100% correct in that I don't know anything about desktop GUI paradigms, or C++ GUI toolkits. I really don't have the bandwidth to find out either! I'm also surprised that I need to. I don't think that is even my VB head, I am a business systems person who has successful modeled a physical process in software. In a recent case I did all of the work negotiating with vendors/management/users, I found the bugs in the vendors API, and I did this to an absurd deadline (with almost zero budget) created by a a vendor withdrawing a product with no notice. That's the kind of absurd thing us plebs in the "just getting it done" crowd have to do all of the time. But I am finding that simple GUI launchers for my software are really complicated in Python with the frameworks I have found. I am shocked that this is the piece that is defeating me! As I said before, I could write a web front-end for this kind of thing relatively easily (in the above case it was a hardware requirement that lead me to try again at the desktop GUI). Perhaps this is why we see so many people looking at the web-app-on-the-desktop that is so derided on these pages?
Yes, a shame that the FLOSS world never came up with a competitive integrated VB/Delphi clone in a better language like Python. Probably it would have been a huge undertaking, right when web dev was taking off.
Although I've heard good things about Lazarus IDE, probably your best bet for such projects. Pascal is not hard to learn, or re-learn.
https://en.wikipedia.org/wiki/Lazarus_(IDE)
http://www.lazarus-ide.org/
Although I've heard good things about Lazarus IDE, probably your best bet for such projects. Pascal is not hard to learn, or re-learn.
https://en.wikipedia.org/wiki/Lazarus_(IDE)
http://www.lazarus-ide.org/
As I said I am not qualified to judge how hard this is, but:
I don't really like working in an IDE, or need to. I am happy to design GUI components in a markup language, for the kind of use cases I am talking about.
However would it not be possible to hide the complexities of managing a GUI in the framework/bindings so that the Python user just has to deal with "Someone clicked OK>Run this function" in as easy a way as VB did?
I mean I don't know much about how to send a http request in C++, but I can do it in 'requests' without much problem!
Thanks for the advice on Lazarus. Not FOSS and not desktop, but I have been looking at Anvil recently, which makes it really easy to code web app front ends, allowing me to concentrate on backend stuff.
http://www.anvil.works
I don't really like working in an IDE, or need to. I am happy to design GUI components in a markup language, for the kind of use cases I am talking about.
However would it not be possible to hide the complexities of managing a GUI in the framework/bindings so that the Python user just has to deal with "Someone clicked OK>Run this function" in as easy a way as VB did?
I mean I don't know much about how to send a http request in C++, but I can do it in 'requests' without much problem!
Thanks for the advice on Lazarus. Not FOSS and not desktop, but I have been looking at Anvil recently, which makes it really easy to code web app front ends, allowing me to concentrate on backend stuff.
http://www.anvil.works
VB was easy because of shortcuts provided by the IDE.
If you don't want one, QML is what you are looking for.
Saw anvil and it looked interesting, aren't apps tied to its system however?
If you don't want one, QML is what you are looking for.
Saw anvil and it looked interesting, aren't apps tied to its system however?
Yes, that is the (major) downside. The trade-off is extreme productivity.
And doing your GUI with Tkinter, which has an API that fits incredibly well with Python is a problem because...?
One problem I have with Tkinter is scrolling.
In other frameworks I just say "this frame (containing lots of widgets) is scrollable" by setting one property to true and it just works. Including vertical and horizontal scrolling, mouse-wheel support, and standard keyboard shortcuts like page-down etc.
In Tkinter this seems almost impossible. It takes dozens of lines of code; many events must be implemented manually, including low-level things like calculation of scroll offsets; good mouse-wheel support is very difficult; etc. It feels more like I'm _implementing_ (rather than _using_) the scrolling widget. And in the end it the UI flickers like crazy during scrolling.
Is there something I overlooked?
In other frameworks I just say "this frame (containing lots of widgets) is scrollable" by setting one property to true and it just works. Including vertical and horizontal scrolling, mouse-wheel support, and standard keyboard shortcuts like page-down etc.
In Tkinter this seems almost impossible. It takes dozens of lines of code; many events must be implemented manually, including low-level things like calculation of scroll offsets; good mouse-wheel support is very difficult; etc. It feels more like I'm _implementing_ (rather than _using_) the scrolling widget. And in the end it the UI flickers like crazy during scrolling.
Is there something I overlooked?
I'm really pleased to hear you say that. Every time I have asked about Tkinter on here or SO I get "Tk is really old, you should be using Qt or blahblah". So I guess I start to doubt myself and think that the issues I am having are because I am such a noob I used this crappy old framework that no serious developer would.
However I still find similar issues with Tkinter as I discussed above, I really didn't expect to have to learn how Tk event loops or whatever worked just to get my code to execute in the order it is written in! I guess I was just naive.
However I still find similar issues with Tkinter as I discussed above, I really didn't expect to have to learn how Tk event loops or whatever worked just to get my code to execute in the order it is written in! I guess I was just naive.
Check out http://tkdocs.com to get started _properly_ with tkinter.
The blocking thing you can do in two ways. First, put your blocking stuff in another thread and do it there, and when it's done call back into the main thread to tear down the alert.
The other way, to play nice with the event loop, is to do something like:
After you get a bit more experience with doing some GUI stuff, and if you want to have a more long-running GUI, it will become more natural to think of initiating everything in response to event handlers, as opposed to the batch model of running your program linearly from top to bottom.
The blocking thing you can do in two ways. First, put your blocking stuff in another thread and do it there, and when it's done call back into the main thread to tear down the alert.
The other way, to play nice with the event loop, is to do something like:
makemydialog()
Tk.update_idletasks() # process events so that the dialog shows up
do_my_stuff
teardown
After you get a bit more experience with doing some GUI stuff, and if you want to have a more long-running GUI, it will become more natural to think of initiating everything in response to event handlers, as opposed to the batch model of running your program linearly from top to bottom.
You have told me more in that message than the whole book I read on Tkinter, and all of the experts who told me I was using the wrong framework. Thank you.
I guess looking at it, having a process that is going to take a few seconds and must block the user from progressing until it completes is perhaps not the scenario most tutorials envisage. Thanks again
I guess looking at it, having a process that is going to take a few seconds and must block the user from progressing until it completes is perhaps not the scenario most tutorials envisage. Thanks again
yuck, for the sake of everything, please don't use tk for new apps. They don't support hidpi (except for a global scaling of the app which sometimes does not even works - makes quite a bunch of tk apps unusable). For some reason they don't feel smooth either on > 60Hz screen.
Can't you use a designer GUI to develop the static GUIs?
You will have to understand how layouts actually work and how the designer translates your design into code/widgets/layouts. Then in Python you write your logic and event handlers.
Qt also offers QML, if you are a fan of how those components look you may enjoy using it.
Qt also offers QML, if you are a fan of how those components look you may enjoy using it.
What happened to PyQt?
Also, the API does not seem Pythonic at all.
Also, the API does not seem Pythonic at all.
I think PyQt is owned by a different company, so Nothing happened to it, I guess.
PySide is waaaay more Pythonic than PyQt ever was. Types are actually translated to Python native types and APIs are way more Pythonic and not just translated 1:1 like PyQt.
PySide is waaaay more Pythonic than PyQt ever was. Types are actually translated to Python native types and APIs are way more Pythonic and not just translated 1:1 like PyQt.
You've been able to automatically translate types going back to PyQt4 (it's the default for PyQt5, wasn't changed in PyQt4 due to backwards compatibility IIRC, but you could opt-in). As mentioned elsewhere PyQt offers properties, decorators for connecting signals and slots, etc. I found the APIs to be very similar overall.
In the visual effects industry, it's common practice to write GUIs using Python and Qt that are compatible with PySide, PySide, PyQt4 and PyQt5 all at once. I think that speaks for how similar these bindings really are. Source: I maintain the most widely used shim for such occasions https://github.com/mottosso/Qt.py
That's because Qt isn't a Python library. The API is made to be compatible with the actual Qt API, so you can write label->resize(800, 600); in C++ and label.resize(800, 600) in Python.
PyQt is still around. This seems to be an 'official' thing from the Qt folks.
... with a more permissive licence (Qt for Python is LGPL, PyQt is GPL or $550 per dev commercially).
And it's generally worth it. PyQt has been great, and I find the messaging from Pyside a little offputting -- "finally, Qt for Python." Pyside, you weren't there when I needed you, and now you're back and you want to pretend like we don't have history?
When did you need it? Because PySide is not new.
PySide didn't support Qt5. That's because the project was basically left for dead by Nokia and then Digia - for Qt proper, bindings will always be an afterthought.
Meanwhile, PyQt just chugged along just fine. Riverbank must keep focusing on it all the time or it will die. The incentives are very different.
Meanwhile, PyQt just chugged along just fine. Riverbank must keep focusing on it all the time or it will die. The incentives are very different.
PySide was stuck on Qt4 and basically stalled. PySide2 is practiaclly a new project. For Qt5 bindings, PyQt has been the only game in town for years, and Riverbank has done a damn good job of it.
Oh this is very convenient and cool. I'm go looking forward to developing gnuradio applications using this.
Will there be need of QT runtime for this?
[1]: https://fman.io
[2]: https://github.com/mherrmann/fbs