GUI for Python?

[bd139]

Qt is why Electron is so popular…

[MK14]

Maybe just the framework itself, QT.  Can be downloaded.

Not "maybe", for sure. But you are right about the installers and probably also Qt Designer and Qt creator (the IDE).
But you don't need them. I write software with grafical interfaces using Qt for 10 years and the only thing I need is the
Qt framework (the libraries), a good editor (Kate) and a compiler (GCC).

On Linux, programming with Qt is easy. When I want to release a windows version, I fire up a virtual machine and recompile
it for windows. No installer, no IDE. I simply download the Qt source and compile the libraries with MinGW-64.
Then I compile my program static. That way I don't need to install a gazillion of dll's when deploying my program
and I don't risk any version conflicts. The result is an executable with everything needed inside it.

That makes sense.  Maybe using the framework that way, is also more programming language agnostic (yes it would need to change, but not by that much), but you are NOT committed to the actual programming language.

Many people say, staying with text based solutions (which is exactly what you just said), is the best way, anyway.

[Karel]

Many people say, staying with text based solutions (which is exactly what you just said), is the best way, anyway.

When I started to program with Qt, I used Qt Designer, but I didn't like the generated code.
For sure it's easier for starters but as with everything, the risk is that you never learn Qt well enough.

By te way, the documentation of Qt is the best:

https://doc.qt.io/qt-5/reference-overview.html

When I'm programming, I usually have this page open so that I can easily jump to any class/widget:

https://doc.qt.io/qt-5/classes.html

And no, I haven't touched Qt6 yet, I stay with Qt5 untill Qt6 is complete and ready for production and when it's
the default Qt version Linux.

[Karel]

Qt is why Electron is so popular…

You are kidding, aren't you?

Which software uses electron:

https://en.wikipedia.org/wiki/List_of_software_using_Electron

Now let's have a look at Qt:

https://en.wikipedia.org/wiki/Category:Software_that_uses_Qt

https://en.wikipedia.org/wiki/Category:Proprietary_software_that_uses_Qt

Also, electron is slower and uses more memory than Qt but I guess that's not a problem for hobbyists.

[bd139]

The market is larger than that. There are an order of magnitude more applications behind closed doors. And they’re pushing towards web and electron over native GUI. One thing I have heard is that Qt is complicated to license and expensive to build. Plus there aren’t enough people who can actually do it out there.

I’m no fan of electron myself but it’s s viable tech for a good chunk of cases where Qt sat.

The largest thing I’ve seen recently was a fintech numerical analysis tool built in Electron and React. The processing was done with an external process which was C++.

[Karel]

The market is larger than that. There are an order of magnitude more applications behind closed doors. And they’re pushing towards web and electron over native GUI. One thing I have heard is that Qt is complicated to license and expensive to build. Plus there aren’t enough people who can actually do it out there.

I’m no fan of electron myself but it’s s viable tech for a good chunk of cases where Qt sat.

The largest thing I’ve seen recently was a fintech numerical analysis tool built in Electron and React. The processing was done with an external process which was C++.

That's your opinion only, you don't provide any info.
By the way, electron is slower and consumes more memory than Qt.

[Nominal Animal]

However, there is one or two Qt packages that are not licensed under FOSS licenses, and not available in standard Linux distributions.  The main one is Qt for MCUs, which is only available under a commercial or an evaluation license.

This thread is about a GUI for Python. So, I was clearly speaking about the Qt GUI framework which is FOSS.

I was agreeing with you, not arguing with you.

It is important to be precise about licensing, as there is too much FUD flying around Qt licensing.  Describing the Qt package (unrelated to this thread) that is not FOSS, shows the whole picture.  As in "the border lies there, and it is miles away; thus, the claim is quite correct."

[MK14]

Many people say, staying with text based solutions (which is exactly what you just said), is the best way, anyway.

When I started to program with Qt, I used Qt Designer, but I didn't like the generated code.
For sure it's easier for starters but as with everything, the risk is that you never learn Qt well enough.

By te way, the documentation of Qt is the best:

https://doc.qt.io/qt-5/reference-overview.html

When I'm programming, I usually have this page open so that I can easily jump to any class/widget:

https://doc.qt.io/qt-5/classes.html

And no, I haven't touched Qt6 yet, I stay with Qt5 untill Qt6 is complete and ready for production and when it's
the default Qt version Linux.

Thanks, that's interesting and good to know.  Apparently, there is a similar situation (of sorts) between GTK3(+) and GTK4.  GTK4 is the latest one, but many things are still GTK3(+).

I also find it annoying with systems (but still might use them), which automatically write some of the code for you.  On the one hand it makes it fast and easy, but it can adversely affect the source code.

So, it is preferable, to be in charge of the source code, and not have some automatic system, make changes to bits of it.

Excellent point about the QT's documentation.  Many, GUIs, are rather powerful and useful.  But are significantly deficient on the documentation side, which can be a real pain in the neck.  Especially when starting out with a new (to the programmer/developer), GUI system, or coming back to it, after a long period of doing other things.
But also, exactly as you said.  While developing with a particular GUI, the quality of the documentation, can easily affect your workflow speed and aggravation factor.

TL;DR
It is sad.  But GUIs which lack quality/useful/extensive documentation, are (possibly, opinions might vary) best avoided.  Certainly the ones which have almost zero documentation and/or what there is, is of rather poor quality, are best avoided.  Even GTK, (or so I've heard), suffers from that, because of issues, related to automatically generating the documentation, from the source code.  Brought about, especially because of the numerous multiple, language bindings, for GTK (I've read about this, rather than had it as first hand experience).

[Nominal Animal]

When I started to program with Qt, I used Qt Designer, but I didn't like the generated code.

I don't like using code generators at all.

I recommend against using uic to generate the code for the UI, and instead save the designed UI as an .ui file, instantiating it at runtime via PySide2.QtUiTools.QUiLoader (PySide2) or PyQt5.uic.loadUi (PyQt5).

For those interested in this, see e.g this example I posted in another thread a couple of years back.

Apparently, there is a similar situation (of sorts) between GTK3(+) and GTK4.  GTK4 is the latest one, but many things are still GTK3(+).

Definitely.  There are those who do (use Qt 6 and/or Gtk+4), but since Qt 5 and Gtk+3 work very well for now, there really isn't any reason to "upgrade" yet.

I also find it annoying with systems (but still might use them), which automatically write some of the code for you.  On the one hand it makes it fast and easy, but it can adversely affect the source code.

I don't like those either.  I just wanted to point out that although Qt Designer supports that, it does not require one to generate the source code for the UI.  Both Glade (Gtk+) and Qt Designer (Qt) support XML-based user interface descriptions as .ui files, that can be instantiated at run time.

The syntax is sufficiently simple that one can actually write those .ui files from scratch, too; it isn't much different to writing HTML by hand.  More repetitive and verbose, perhaps, especially the <property ...>...</property> stuff needed to set widget properties.

Many, GUIs, are rather powerful and useful.  But are significantly deficient on the documentation side, which can be a real pain in the neck.

Very true.  For Qt, I use the same doc.qt.io/qt-5/classes.html as Karel mentioned.  For Gtk+, I'm still using developer-old.gnome.org/gtk3/stable/ and not the new developer.gnome.org/gtk3/stable/ site, as I find the old pages faster to navigate; fewer clicks to find whatever I'm looking at.

(I always keep a terminal window open for man -s 2,3 function or pydoc3 module.class, or a browser tab open at man7.org/linux/man-pages/ or docs.python.org/3/library/, too.  There is no reason to memorise function signatures and other insignificant details, when you can check in a couple of seconds, and avoid bugs like memset(pointer, length, value) – it's memset(pointer, value, length) –; these kinds of typos are too common already.)

[Karel]

However, there is one or two Qt packages that are not licensed under FOSS licenses, and not available in standard Linux distributions.  The main one is Qt for MCUs, which is only available under a commercial or an evaluation license.

This thread is about a GUI for Python. So, I was clearly speaking about the Qt GUI framework which is FOSS.

I was agreeing with you, not arguing with you.

It is important to be precise about licensing, as there is too much FUD flying around Qt licensing.  Describing the Qt package (unrelated to this thread) that is not FOSS, shows the whole picture.  As in "the border lies there, and it is miles away; thus, the claim is quite correct."

No offence. I like your contributions here.

[spostma]

anybody interested in FreePascal and Lazarus should visit the Ultibo website.
Ultibo compiles for (and can run on a) Raspberry Pi, and gives you a full Lazarus IDE with debugging.
The compiled output can go on an SD card, and you are ready to run!

This is a monolithic system, so all the OS-specific and all rPi-specific functions are written in Lazarus.

You can use most USB devices out-of-the-box, and use wired or wireless ethernet.
Also CAN drivers are available, and support for many popular peripheral chips.

A great project for people loving the beauty of Pascal!

Just take a look at this CAN dashboard with 2x HDMI output for a TVR sports car:
https://ultibo.org/forum/viewtopic.php?f=9&t=1450

[eugene]

For Tkinter there is this standalone WYSIWYG editor called PAGE (should work to generate Tcl/Tk, too), but I've tried it only for Python, and it worked.  A little too basic, from sourceforge, seems straight from the 90s and not very intuitive for these days, but it kind of works. 

To be fair, in your opening post you asked for something that works like VB5, which was released in 1991. 

Anyway, I gave PAGE a try and found that it suits my needs well. Like RoGeorge, I sometimes wish for something as simple and easy as early VB. You could put together a good looking interface in just a few minutes, then flesh out the event handlers. Not suitable for sophisticated programs, but often I just want to interface with some instrument or microcontroller, maybe plot a graph, and save some data to a file. VB5 was great for that.

I use Python for similar things today, but writing code to define tkinter widgets and use pack... it's simple, but not RAD enough. PAGE makes it RAD enough for me.

[RoGeorge]

About PAGE, on my desktop the Ctrl+Z does strange things, not really undo-ing, sometimes the graphic WYSIWYG is not synchronized with the tree view of the same elements, selecting more than one element (middle mouse) is not very intuitive (click and drag around elements doesn't select all the enclosed elements, things like Shift or Ctrl alterators behaves unexpected when used for selection, etc.), doesn't do multi-edit of the same property, things like that.

I'm not sure if those are bugs, or if it's the expected behavior, but certainly PAGE is not as intuitive as VB5 was.  PAGE works, but not very smooth, even if it were to judge it by the 90's standards.

[Ed.Kloonk]

I'm not sure if those are bugs, or if it's the expected behavior, but certainly PAGE is not as intuitive as VB5 was.  PAGE works, but not very smooth, even if it were to judge it by the 90's standards.

Do you mean in the app design/widget placement stage or running the generated code?

[RoGeorge]

Talking about the WYSIWYG editor, the quirks while you edit how your Python GUI will look like.  PAGE has a Drag&Drop editor, and when you are happy with your future GUI look, it can generate Python code to be edited later for adding functionality to the designed GUI.

Also it was not possible to move an element in the tree, for example to just drag a button from outside to inside of a labelframe.  Such a change can still be done by copy/paste then deleting the original, but only with one element at a time.  So if you want to add later a labelframe around a group of GUI objects you have to copy/paste them one by one inside the new labelframe.

Also the alignment appears missaligned sometimes, even when the snap to grid is enabled, things like that 

[bd139]

Ugh I'd rather use WPF than deal with that sort of stuff 

[Karel]

Ncurses! 

[Ed.Kloonk]

+1

[eugene]

About PAGE, on my desktop the Ctrl+Z does strange things, not really undo-ing, sometimes the graphic WYSIWYG is not synchronized with the tree view of the same elements, selecting more than one element (middle mouse) is not very intuitive (click and drag around elements doesn't select all the enclosed elements, things like Shift or Ctrl alterators behaves unexpected when used for selection, etc.), doesn't do multi-edit of the same property, things like that.

I'm not sure if those are bugs, or if it's the expected behavior, but certainly PAGE is not as intuitive as VB5 was.  PAGE works, but not very smooth, even if it were to judge it by the 90's standards.

Ah, okay. I didn't run into those things, but likely because I didn't try to do the things you did. I ran through the first tutorial without incident, then put together an interface for a simple file sync program using almost the same process.

You're right, behavior like that is hard to tolerate. I'll still be on the lookout for something better, but may continue to use PAGE to build interfaces initially. That's the usual workflow anyway, isn't it? Design/create a GUI then fill in the functionality. With VB5 (and VB.NET and C# in VisualStudio) you can make changes to the interface as you discover the need. With PAGE (even without the intolerable quirks) it's not that simple, but I did find it useful for the first step of building the GUI. Maybe if I'd experienced the same frustration that you did then my attitude would be different.

[Nominal Animal]

It would be interesting to create a simple example Python 3 program using the various toolkits (Tkinter, Qt, Gtk+ at least), comparing the implementations and especially the maintainability, written with long-term maintainability and customisation in mind.  That would be very informative, I think, for everyone interested in the subject.

I personally am most interested in the ways an external (XML-based text) file is used to define the user interface, as opposed to implementing it in code.  For tkinter, one can use pygubu and pygubu-designer; Glade for Gtk+, and Qt Designer for Qt.

Serial port access and serial device enumeration is a "problem", because the various existing libraries used for this are, uh, "deficient".  So, it'd have to be something more local.  Python does have built-in support for CSV files, JSON data, various configuration file formats (including .INI-type files), network sockets and TLS encryption, and even WAV files.  Numpy and Scipy have all kinds of FFT and such support, so maybe something to do with those would be useful?  I've already done a simple Finite Impulse Filter response analysis tool as an example of completely standalone single-file HTML+CSS+JavaScript browser tool.

It'd have to be something actually useful, as to properly "stress" the toolkits/frameworks, and see what working with the codebase and resource files is like.  I just cannot think of a suitable example.  Even better if someone designs a suitable UI in pygubu-designer/Glade/Qt Designer, or even just e.g. Inkscape as a picture, to start with.

[Bud]

Given Python's shitty backwards compatibilty, this may be a useless exersize. This may work for a specific version but become broken once a new version is out.

[Nominal Animal]

Given Python's shitty backwards compatibilty, this may be a useless exersize. This may work for a specific version but become broken once a new version is out.

Aside from Python 2 to 3, which was annoying as all hell but carefully controlled and not a surprise to anyone, I haven't been bitten by that at all.  Exactly what are you referring to?

And do note, I am not particularly fond of Python.  I use it only because it currently fits my use case – portable interpreted language suitable for user interface implementation, with an easy interface to native libraries – better than the alternatives.  It is just a tool for me, and I use it as such.  Thing is, I want others to have multiple tools in their kit, and choose the one they use based on the problem/task at hand; and Python only where it is appropriate.  Thus, an actual real life example is much more useful than this kind of discussion, in my opinion.

[Bud]

Carefully controlled?

"Python version incompatibilty is intentional" - When such statements come out right from the horse's mouth (Guido van Rossum, the creator of Python), that makes you think.

[bd139]

I’ve had about 15 million lines of it in production before. Not one issue. Even the python 2 to 3 port was smooth.

[Nominal Animal]

Carefully controlled?

"Python version incompatibilty is intentional" - When such statements come out right from the horse's mouth (Guido van Rossum, the creator of Python), that makes you think.

It applied to the 2-to-3 thing.  I'd rather have a rewrite/redesign/refactoring, than live with a sub-par design.  Now that they know how painful it is, how likely do you think it is they repeat it?

Even Perl 7 intends to fix defaults that are no longer applicable, somewhat "breaking" backwards compatibility.  Although I do realize first-hand how painful all backward compatibility breaking changes are, I still think they are good/important/preferable in the long term.

Programming languages are just tools, after all.

In any case, if someone comes up with a good idea for a basic but useful GUI example program, especially if they bother to design/sketch out the UI, I do promise to try to write at least Qt (PySide2 + PyQt5) and Gtk+ (gi) implementations (on Linux, as I cannot currently test on Windows), perhaps also a tkinter/pygubu one.  (The "try" is there, because I'm still struggling with productivity/responsibility/stress management failures, and cannot promise I don't stumble on those personal pitfalls I tend to stumble on. )