Live data from Hacker News

Python GUIs

pythonguis.com

31–40 of 98 posts

Re: Python GUIs

#31

I sometimes miss the good old days of visual basic and delphi when I could create a gui that just worked in seconds, help pages via F1 and quick access to all events possible through simple gui clicks. A few days ago I tried getting a simple PyQtWebengine example working using pyqt6 and failed miserably. It was a frustrating experience for sure

Tcl/Tk was fairly amazing for getting a simple UI going.

Back in the dialup days, my modem was plugged into a homebrew Linux firewall/router so that I could use the Internet from multiple machines at once. Which outside of a large business or college campus, was considered pretty much advanced wizardry back then. The problem was that I had one phone line and couldn't tie it up all the time. I wanted to be able to open a program on the desktop of another computer, click a button marked "connect to internet" and have that talk to the server to start the dialup process. And then also a "disconnect" button to hang up later. With a little text box to show any errors and whatnot. There were some half-solutions to this in existence at the time, but nothing that fit my exact use case.

I had been beating my head against various Perl experiments which weren't getting me anywhere until finally someone on IRC said, "oh, have you tried Tcl/Tk?"

Tcl was so easy to learn that I had a working proof of concept by the end of the day. Another couple of days to tidy it up. Used it daily for a few years until DSL came to my area.

Re: Python GUIs

#32

I sometimes miss the good old days of visual basic and delphi when I could create a gui that just worked in seconds, help pages via F1 and quick access to all events possible through simple gui clicks. A few days ago I tried getting a simple PyQtWebengine example working using pyqt6 and failed miserably. It was a frustrating experience for sure

I used to use Delphi over 20 years ago and changed career since.

I'm looking to dabble again. Is there anything similar to RAD these days? It really did make building simple GUIs very easy.

Re: Python GUIs

#33

Many of the Python GUIs here are GPLv3, which unfortunately makes them a nonstarter in a lot of projects.

Why should anyone care about that? 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.

Because I want to write open-source software that isn't required to also be GPLv3 as a result of using GPLv3 software.

Re: Python GUIs

#34
I think that tkinter is "good enough" for most cases that need a GUI in pythonb these days (for more complex stuff you'd better go with either a web app or a compiled language that creates normal desktop apps).

As a showcase I've built two simple utils with python and tk (and pyinstaller):

- https://github.com/spapas/pdfmerger a simple tool to merge pdfs into one

- https://github.com/spapas/pomo ; a simple pomodoro timer

Re: Python GUIs

#35
post #31

I sometimes miss the good old days of visual basic and delphi when I could create a gui that just worked in seconds, help pages via F1 and quick access to all events possible through simple gui clicks. A few days ago I tried getting a simple PyQtWebengine example working using pyqt6 and failed miserably. It was a frustrating experience for sure

Tcl/Tk was fairly amazing for getting a simple UI going. Back in the dialup days, my modem was plugged into a homebrew Linux firewall/router so that I could use the Internet from multiple machines at once. Which outside of a large business or college campus, was considered pretty much advanced wizardry back then. The problem was that I had one phone line and couldn't tie it up all the time. I wanted to be able to ope…

Ttk exists :)

Re: Python GUIs

#37
post #16

Earlier quoted context omitted.

I have tried wxWidgets and wxPython, and while there are many nice features, my issue with it has always been that its behavior is inconsistent across platforms. I have found Qt to be much better at delivering the same experience across platforms. Using PySide 2 with the previous version of Qt (Qt 5 instead of the current Qt 6) avoids any licensing issues since PySide 2 uses the LGPL version of Qt 5.

> my issue with it has always been that its behavior is inconsistent across platforms Isn't that because different platforms are different? This should be a feature. "Cross-platform that feels native", because each platform has a different definition of "native". IME wxWidgets was always better than Qt or any other of the high-level piles of bloat. For example, its layout system would actually use the platform-native…

> Isn't that because different platforms are different?

To some extent they are; I don't mind having Windows-native-looking widgets on Windows and Linux-native-looking widgets on Linux.

But programmatically, code that is designed to do a particular function should do it the same on all platforms. That's the point of having a cross-platform toolkit. If I end up having to write a lot of platform-specific code to handle quirks, I might as well just ship separate apps for each platform. It's been a while so I don't have specific examples, but that's generally what I remember running into.

Of course a lot of this will depend on what specific things you are trying to do. One item that I do remember having particular issues with was multiplexing network I/O with the GUI--which is inherently difficult because both of those things want to run their own event loop. Qt has a built-in "widget", QSocketNotifier, to bring network I/O events into its GUI event loop, but wx does not, so I had to roll my own, and it took different tricks on different platforms to make it work (and it was still clunky even then). But many GUI applications don't have to do that.

Re: Python GUIs

#38
post #14

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…

PyInstaller always seems to tick off our org's MalwareBytes, causing it to break in new and interesting ways but only after a good amount of development hours have been sunk into the project. Recently I've been using Nuitka to package python apps. It would be nice if PSF would adopt/develop an official way to do this.

Re: Python GUIs

#39

I sometimes miss the good old days of visual basic and delphi when I could create a gui that just worked in seconds, help pages via F1 and quick access to all events possible through simple gui clicks. A few days ago I tried getting a simple PyQtWebengine example working using pyqt6 and failed miserably. It was a frustrating experience for sure

I used to use Delphi over 20 years ago and changed career since. I'm looking to dabble again. Is there anything similar to RAD these days? It really did make building simple GUIs very easy.

Lazarus on FreePascal

Re: Python GUIs

#40
I love gooey: https://github.com/chriskiehl/Gooey

It allows me to quickly slap a GUI on an existing script that accepts command-line-arguments. In the end, I get the best of both world: Discoverability from the GUI, automation through the script, and automatic feature parity between the two.

Downside: Control over the GUI layout is basic, and only "standard" GUI features work, but I never felt limited when using it.

Post reply on HN