Very happy to hear this as the author of a PyQt-based file manager [1] and an open source library for solving the many headaches that come with developing desktop apps [2]. Once Qt for Python is stable enough, I'll be happy to switch to it from PyQt.
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?
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.
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).
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.
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.
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.
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.
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.
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.
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.
How do I provide end users the ability to swap out LGPL3 shared objects (as required by the license) on an embedded platform with no access, or inside a py2exe bundle?
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.
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?
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.)
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.
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.
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.
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.
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.
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.
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?
"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.
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.
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.
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.
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.
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.
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.
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.
`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.
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.
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.
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.
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.
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]
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?)
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.
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.
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.
:-) 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.
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.
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.
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.
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.
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.
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
> 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.
This seems easily googleable. Are you really completely oblivious as to controversy surrounding the GPL, especially as opposed to LGPL and ASL/MIT/BSD?
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.
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
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.
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?
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.
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.
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
and instead I find the GUI hanging while the function is running, then the alert box flash up and exit, or something equally unintuitive.
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.
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?
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.
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.
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.
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.
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
If within do_my_stuff you can periodically call update() to process events, it'll give the appearance of being more responsive.
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
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.
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.
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.
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?
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.
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.
[1]: https://fman.io
[2]: https://github.com/mherrmann/fbs