Tkinter: The good, the bad, and the ugly!

[Michael Torrie]

The problem with QT is the license.

PyQT indeed is licensed poorly for anything that's not GPL. But Qt
itself is dual-licensed under GPL and the LGPL, as of version 4.6 I
think. The LGPL license would seem to be quite acceptable even for
commercial, closed-source programs. Is this not so? The license is at
parity with GTK+.

Eventually PySide will be stable and fast, and so the licensing issues
involving PyQt won't matter.

 

[Gregory Ewing]

[Sorry to revive an old thread, but I was away when it occurred
and I'd like to make a comment...]

This library isn't much different from other Python GUI toolkits--it's
dependent on underlying, rather large, platform-specific
implementations--but it provides an even higher level of abstraction. On
the Mac, it is dependent on PyObjC; on Windows, pywin32; and on X11,
pygtk. In short, it's a wrapper over other wrappers.

PyGUI differs from the likes of wxPython and PyQT in that the
things it depends on are mainly just Python bindings for native
facilities already present on the platform.

This is an issue because of the number of API translations
involved. WxWidgets and Qt are themselves cross-platform libraries
that present quite a different API from the platform. The Python
bindings for them just expose that API to Python, resulting in
something that is not very Pythonic. To fix that, you would need
another layer on top, resulting in *two* API translations.

Each time such a translation occurs, something gets lost. PyGUI
is designed to minimise the loss by building a Pythonic API
directly on the platform API.

To me, this is the most important thing. Minimising the size of
third-party dependencies is also a goal, but it's secondary, and
can be addressed in various ways later, such as by using ctypes
or custom extension modules. Getting the API right, and proving
that it can be implemented with acceptable quality on all the
target platforms, are the first priorities.