11–20 of 98 posts
for Python GUIs (or "TUIs", or "a screen with colorful buttons and controls I can use with the mouse or keyboard but NOT a "GUI" " if that helps some of the responders to get through the day) I recommend considering a console-based GUI using the excellent Textual: https://textual.textualize.io/ this is the most modern GUI (in a console or not) framework you'll find for Python right now.
Unless picking a solution from the start and testing it throughout, I find that the most challenging.
The guide lists four different GUI frameworks and the comments (so far!) have listed two more.* None of them really have claim to being the good "default" (except maaaaaaaaybe tkinter) and all of the "GUI-knowledge" is fragmented across them. I like Python but whenever I have to make a GUI, I shy away. * Between starting and finishing this comment, someone brought up a third. Now we're up to seven!
It seems the author push for PyQt a bit, even though PySide has the same basic capabilities with the benefit of LGPL license (PyQt is GPL or Commercial).
The problem remains delivering the app to the customer in my experience, unless something like flatpak can be used cross platform. Unless picking a solution from the start and testing it throughout, I find that the most challenging.
I tried to use GTK for a little project at work and I couldn't figure out how to make it look decent. I ended up making a flask app and launching a browser. It seemed to be 100x easier. I would prefer to make native GUI apps but it's just so much more difficult.
I'm a big fan of using wxPython instead of Qt or the other recommendations in OP. https://www.wxpython.org/ wxWidgets is mostly licensed under an LGPL analog with linking exceptions intended to permit distributing binaries under any license you choose. No part of wxWidgets, including wxPython, has a license more restrictive than the LGPL.
But as always, I turn to PEP 20, in particular "There should be one-- and preferably only one --obvious way to do it." Batteries ought to be included. I'm hardly a language designer, but more and more I care less about things like syntax and such, and more about having as much as possible already built out, so I can focus on the particulars of a problem, rather than having to endure a "evaluate a bunch of alternatives" phase for each little thing.
It's a tall order, and a growing one, but I think whatever the next big language is, it will have that kind of focus.
The problem remains delivering the app to the customer in my experience, unless something like flatpak can be used cross platform. Unless picking a solution from the start and testing it throughout, I find that the most challenging.
I have found PyInstaller [1] to work well for packaging everything into a single ZIP file that unzips to a folder with an executable binary and all accompanying files (or even a single EXE file that self-extracts when run, but that increases startup time). It knows how to package PyQt and its associated Qt libraries (or PySide, which I actually prefer) so that they can be shipped with your application. [1 https://pyi…
But it's still considered challenging when you compare with any other compiled language, where you can get an executable out of the box. I ship Python desktop apps at work and it's remarkable how much code we accumulated over the years just to deal with the "interpreter in bundled/exe mode".
Ideally, I can build that with Python. I was thinking of DRF and React (since things like Retool are out of the question) but I'm open to any framework/stack. What is the most simple way to accomplish and maintain this?
Many of the Python GUIs here are GPLv3, which unfortunately makes them a nonstarter in a lot of projects.
If you want to sell something and keep it all to yourself, then go buy something. Qt will happily sell you a quite nice resellable component. If you want to reshare that which you got for free yourself, great, no problem there either.
Say what exactly is the problem that isn't either of those two situations out loud.