[FAQ] "Best" GUI toolkit for python

[Michael Torrie]

On 10/18/2016 02:33 AM, Mark Summerfield wrote:
> When I started out I used Qt Designer to produce .ui files (XML) and
> then used the Qt uic tool to convert this to C++ (although you can
> convert to Python using pyuic). I then studied the code and learnt
> from that. And it turns out that it isn't very hard. There is
> QVBoxLayout - widgets one above the other; QHBoxLayout; widgets side
> by side; QGridLayout - widgets in a grid. The only complication is
> when you nest these, say a QVBoxLayout inside a QHBoxLayout inside a
> QGridLayout; but in practice, once you've done it a few times it
> isn't hard to picture. However, I know highly skilled people who
> prefer to use Qt Designer, so it is no big deal either way.

I am certainly not highly skilled. But I definitely do use the Designer
for everything related to the GUI.  I don't, however, use uic or pyuic.
What I recommend these days is to use the xml .ui file directly in your
program to create the objects for you.  In C++ with an EXE, you can
incorporate the .ui file into the executable as a resource.  In Python,
I would just bundle it with all the other resources I might be using.
For custom widgets I either build a simple plugin for Designer that lets
me use the widgets as any other in the visual layout.  Alternatively,
I'll just change the class type in properties.

The way you use the .ui file loader is to create a class in Python,
usually for each window or dialog, and subclass it from the appropriate
Qt type such as QDialog.  Then in the __init__() method, you call
PyQt.uic.loadUi and it brings all the widgets in and initializes them
and adds them to the QDialog you are defining. And if you follow the
naming scheme for your callbacks of on_widgetname_signalName(), it will
auto connect them. For example, if my button was called "myButton", I
could name a slot to be on_myButton_clicked() and it would connect
automatically.  PySides allows something similar with QUiLoader. I use a
wrapper class that Sebastion Wiesner wrote to make it closer to a
one-liner wrapper function like PyQt offers.

I agree with you about making GUIs programmatically being not hard,
especially when one is learning.  When I first started using Qt, coming
from GTK, I had to get used to a similar but different boxing model.  In
GTK, when packing widgets you specify both the expansion and spacing
while packing.  In Qt, you have explicit spacers to insert into the
boxes.  I'm not sure which method is better.

> If you use many modern Gtk applications they no longer have a menu
> bar but instead a menu button. This is due to the influence of
> mobile. But for desktop users with big screens it now means that to
> say, open a file, instead of clicking File, then Open, you now have
> to click Menu button, then File, then Open. So you need an extra
> click for *everything* you want to do. Thankfully, Firefox allows you
> to get the menu bar back; but I can't get Evince to do that so I had
> to switch to Okular (these are PDF viewers). I have no problem with
> making things nice for mobile users, but at least either detect a big
> screen and act accordingly, or give the user the choice (as Firefox
> does although the default of no scrollbar on the desktop version
> still seems wrong to me).

Correction. You are talking about Gnome applications that follow the
Gnome UI guidelines, not necessarily GTK applications.  And you as a
programmer are not forced to use the HeaderBar and make your application
look like a Gnome application.  And don't confuse Firefox's
Chromification with anything that has to do with GTK.  GTK is used very
little in Firefox; Firefox does its own widgets, event-handling, etc.

GTK still very much offers the foundation for traditional applications,
thank goodness.  The Mate Desktop is porting many of the traditional
Gnome 2 apps to GTK 3 and the look and feel about the same as they
always have.