UI toolkits for Python

[Kenneth McDonald]

Is there any emerging consensus on the "best" UI for toolkit. Tk
never quite made it but from what I can see, both qt and wxWin are
both doing fairly well in general. I'm already aware of the licensing
issues surrounding qt (fwiw, I think their license fee for commercial
use is eminently reasonable), so aside from that, I was wondering if
there was any feedback readers could provide on the following:

1) Which plays best with Python? Ideally, it would already have some
higher-level python libraries to hide the grotty stuff that is almost
never needed when actually implementing apps.

2) Reliability of each?

3) Useful external libraries for each?

4) Ease of installation/use on OS X?

Something with a genuinely useful text widget would be nice, but I
know that's too much to expect...ah, TkText widget, where are you
when I need you.


Thanks,
Ken

 

[Paul Rubin]

1) Which plays best with Python? Ideally, it would already have some
higher-level python libraries to hide the grotty stuff that is almost
never needed when actually implementing apps.

2) Reliability of each?

3) Useful external libraries for each?

4) Ease of installation/use on OS X?

The answer to each of those questions points to Tkinter. It comes
with Python by default (the least installation hassles of any
toolkit), is pretty reliable, has a reasonably Pythonic interface, and
I don't understand the question about external libraries.

However, Tkinter not most people's favorite, because the widgets look
crude, they don't resemble the native widgets of any popular platform,
and the widget set is somewhat limited.

That suggests you're not asking the right questions.

I use Tkinter because the Python gui's I've built so far have been for
straightforward functionality purposes without being fancy. However,
if I were doing something for wide distribution and wanted it to look
sharp, at this point I think I'd go for PyGtk despite the preference
of many for wxpython.

Finally, don't overlook the possibility of embedding a basic web
server in your app, and having the user communicate with it through a
web browser. That turns HTML into your gui, which is very easy to
program. It also lets you easily handle remote clients, multiple
concurrent clients, etc, and gives users a familiar and intuitive
interface.

 

[Kenneth McDonald]

Thanks for reminding me of Gtk. OK, add that to the list.

The Web Browser interface is good for simple things, and will get better
with CSS2's adoption, but they still don't have a good way for important
things like interactive styled text, key bindings, etc. Good for
simple things
(for which I use them), not for more complex stuff.

As for Tkinter, well, sigh, I have to go into a semi-rant, semi-
eulogy right now.

Tk was, IMHO, the hands-down award winner for UI toolkit farthest
ahead of
its time. I used it for years and years and years.

Tcl, on the other had, wasn't the _worst_ scripting language of all
time, but it
was sure down in the bottom ten percent. How John Ousterhout could
come up
with Tk on one hand and the other at the same Tcl boggles my mind.

Unfortunately, while Tkinter did provide in theory full access to Tk,
it was in
practice never finished. I wrote quite a bit of code to try to add a
true pythonic
interface to Tk via Tkinter (I'm happy to give it away if anyone
wants--some of
it is actually in pretty good shape). But it's a big job, and it
became clear to me
that Tk is going the way of the dinosaurs, so I abandoned it.

Ddevelopment on the advanced features of Tk--what really made it worth
using--has languished. Both marks and tags in the Text widget have been
fundamentally broken forever (not buggy, I mean broken in the sense that
their semantics destroys a great deal of their real potential), and I
don't see
they'll ever be fixed. Same thing with tags in the Canvas widget.
Plus the
lack of well-thought-out new widgets, and various other sins of omission
and comission, and I decided that Tkinter was clearly in the last of
its days.

That said, if I was one of the founders of Google, Tk would be one of
the
projects I'd hire a lot of people to get on to and actually realize
its potential.
But I don't even buy lottery tickets

Now I'm just waiting until one of the other kits becomes mature enough
(if ever) to start using it. So this is a query about that

 

[Mark Roseman]

However, Tkinter not most people's favorite, because the widgets look
crude, they don't resemble the native widgets of any popular platform,
and the widget set is somewhat limited.

People should probably be more aware of work that has been going on with
Tk recently (after a fairly long hiatus) in terms of greatly improving
its appearance, adding theming, and more. It's worth checking out, and
of course, if there's a way to help get some of these changes into
Tkinter, the Tk folks would I'm sure be helpful.

Here's a portion of a note that Jeff Hobbs posted to the Ruby group
recently, on a similar topic:

 

[Grant Edwards]

The answer to each of those questions points to Tkinter. It comes
with Python by default (the least installation hassles of any
toolkit), is pretty reliable, has a reasonably Pythonic interface, and
I don't understand the question about external libraries.

However, Tkinter not most people's favorite, because the widgets look
crude, they don't resemble the native widgets of any popular platform,
and the widget set is somewhat limited.

Aside from the look & feel issue with Tk, the other objection
sometimes heard is that Tk is integrated into Python by
including Tcl as well (as opposed to doing an actual Tk binding
the way some other languages have done). It's an eminently
practical approach, but it sure makes you feel dirty.

 

[gsteff]

I've used wxpython and pygtk, and have a strong preference for pygtk.
wxpython has some advantages: it has better OSX support (widgets look
native, and it doesn't require the installation of the Fink x server),
and better win32 support (a few gtk widgets, such as menus, don't look
quite native on gtk, and multithreading with pygtk on win32 is
problematic). But pygtk has better documentation, a MUCH cleaner api,
integration with the Glade GUI designer (wxpython has wxglade, but its
not in the same league), and a richer widget set. In addition, top
itself is in the top tier of free software projects; wxwidgets is not
as mature, and its development is not as active.

So, if you're trying to choose between those two, go with wxpython if
you need OSX support, or have specific issues with pygtk's win32
support. In all other cases, I'd reccomend pygtk.

Greg

 

[gsteff]

Er, meant to say "In addition GTK itself is in the top tier of free
software projects"

 

[Fredrik Lundh]

However, Tkinter not most people's favorite, because the widgets look
(given that the web interface is the new black, that's not much of
an argument. tkinter with the right stylesheet can look anyway you
want)

People should probably be more aware of work that has been going on with
Tk recently (after a fairly long hiatus) in terms of greatly improving
its appearance, adding theming, and more. It's worth checking out, and
of course, if there's a way to help get some of these changes into
Tkinter, the Tk folks would I'm sure be helpful.

maybe this should be reposted to tkinter-discuss ?

fwiw, I still use Tkinter for all UI:s I build, but these days, 80-90%
of the visible widgets are based on this module:

http://effbot.org/zone/wck.htm

sometimes combined with:

http://effbot.org/zone/draw-agg.htm

</F>

 

[Ville Voipio]

4) Ease of installation/use on OS X?

There are two questions which may restrict your choice
rather a lot:

#1 Should the UI look the same on each platform or should it
look the same as all other apps on the platform?

#2 Are you trying to make a simple installation package which
includes everything needed?

With OS X compatibility you tend to come across with the
fact that many "OS X compatible" things are actually X11
things. X11 certainly looks different from Aqua (the native
interface). Also, X11 is not always installed, and some
unixish things require using Fink to install them. Not
something Joe A. User usually has on his Mac.

GTK is an example of this. There is an Aqua version of
GTK, but it seems to be rather outdated. The newer versions
run on X11 but installing them may be just laborious or
then plain pain depending on your luck. And you still need
the X11 installed.

So, if you are looking for something that looks like Mac
and works like Mac, do not touch anything with X11. OTOH,
if you just need to get something working on your own
OS X computer, then X11 is fine.

---

I have tried using wxPython for Mac/Windows cross-platform
GUIs. This far it seems to work fine, but I have not tried
anything very fancy. Mac applications have the OS X looks,
and Windows applications look Windowsish. Without having
a single line of platform-dependent code.

Making simple installation files (exe for Windows and dmg
for OS X) seems to work, as well. So, the installation should
be easy for the user.

- Ville

 

[dberlin]

I find wxPython to pro fill my GUI needs from python in a pretty good
way.
To show off it's capabilities - I am building a GUI editor and it
currently converts from windows forms (visual studio c# forms) to
wxPython code.
When I started programming this editor I thought I'd have major
incompatibility problems, thinking wxPython is extremely weaker than
the windows forms.
However, coding the conversion between the two proved wxPython to be
highly capable.
BTW, this GUI editor can be found here:
http://farpy.holev.com

I believe this also provides an answer to gsteff's post about not
having a normal GUI editor.

 

[Claudio Grondi]

Thanks for reminding me of Gtk. OK, add that to the list.

The Web Browser interface is good for simple things, and will get better
with CSS2's adoption, but they still don't have a good way for important
things like interactive styled text, key bindings, etc. Good for
simple things
(for which I use them), not for more complex stuff.

I don't fully understand your attitude here. The Web Browser interface has
all I can imagine is required for a GUI, so what is missing when you
consider, that you can generate custom images on the fly on the server and
let the user shape the page without requesting CPU power from the server
using JavaScript.
I don't even name here the not really beeing itegral part of Internet
Browsers JavaApplets and any other kind of plugin stuff.
The only issue I can see with this approach is the speed of responding to
user interactions, but for really optimize this one needs a compiled
language anyway.
What is that complex, that it can't be solved using an Internet Browser as a
GUI?
Do I miss here something?

Claudio

 

[Malte Clasen]

What is that complex, that it can't be solved using an Internet Browser as a
GUI?

Nothing, but session management isn't trivial with http interfaces. You
have to deal with the back button of the browsers, bookmarks to pages
that result from posted forms, users leaving the application without
notice, etc.. And if you want to implement dialogs like the Photoshop
image resizing with automatic calculation of some widget data based on
other widgets (e.g. interlocked width and height), you have to rely on
JavaScript which isn't as platform independent as it should be and
sometimes deactivated due to security issues.

But if that doesn't bother you, you might want to have a look at
http://qooxdoo.sourceforge.net/ , "an advanced open-source javascript
based toolkit."

Malte

 

[Stefan Behnel]

Is there any emerging consensus on the "best" UI for toolkit. Tk never
quite made it but from what I can see, both qt and wxWin are both doing
fairly well in general. I'm already aware of the licensing issues
surrounding qt (fwiw, I think their license fee for commercial use is
eminently reasonable), so aside from that, I was wondering if there was
any feedback readers could provide on the following:

[snip]

As for my experience with Python-integrated GUI toolkits: I tried
wxWidgets/Boa and had it crashing on me all over the place. I switched to
GTK/glade2 and fought with it for a couple of days until I ran away screaming.
Next, I tried Qt/Designer and the more I learned, the more I knew I'd keep
loving it. Its Python bindings are not perfect, especially QStrings will annoy
you. You will notice that it was originally designed for C++ and had to try
hard to reimplement a lot of the batteries that Python has included, so it
often uses its own concepts where Python concepts would feel a bit nicer. But
once you accept that, you will really like its clean design that helps you
with your work.

A friend of mine switched to Mac-OS X recently and I told him to use Qt for
one of his projects. He is a Debian developer and did all of his previous GUIs
with GTK. It took him only a couple of hours to fall in love with it. He was
especially mad about the fact that it looks completely like a Mac application
on Mac-OS and like a Windows application on Windows. It even felt like a
native app.

Just try it, you'll see.

Stefan

 

[Stefan Behnel]

Is there any emerging consensus on the "best" UI for toolkit. Tk never
quite made it but from what I can see, both qt and wxWin are both doing
fairly well in general. I'm already aware of the licensing issues
surrounding qt (fwiw, I think their license fee for commercial use is
eminently reasonable), so aside from that, I was wondering if there was
any feedback readers could provide on the following

Oh, one more thing with respect to web apps: There was the nufox announcement
recently, which seems to support XUL driven interfaces in Python.

http://trac.nunatak.com.au/projects/nufox

Stefan

 

[Steve Holden]

I don't fully understand your attitude here. The Web Browser interface has
all I can imagine is required for a GUI, so what is missing when you
consider, that you can generate custom images on the fly on the server and
let the user shape the page without requesting CPU power from the server
using JavaScript.

In this case then, I'm afraid the failure is in your imagination

I don't even name here the not really beeing itegral part of Internet
Browsers JavaApplets and any other kind of plugin stuff.
The only issue I can see with this approach is the speed of responding to
user interactions, but for really optimize this one needs a compiled
language anyway.
What is that complex, that it can't be solved using an Internet Browser as a
GUI?
Do I miss here something?

While you are correct in saying (I paraphrase) that HTML interfaces
nowadays can offer a rich graphical interface, it can be quite difficult
to manage state maintenance between the two components (web server, web
client) in the system.

A "proper" GUI runs all functionality inside a single process, and
allows much easier control over complex interactions, creation of
dynamic dialogues, and so on.

regards
Steve

 

[Mike Meyer]

Nothing, but session management isn't trivial with http
interfaces. You have to deal with the back button of the browsers,
bookmarks to pages that result from posted forms, users leaving the
application without notice, etc..

This fact seems to have escaped the notice of most developers of web
applications. They just fail and/or misbehave under all those
conditions.

<mike

 

[Claudio Grondi]

In this case then, I'm afraid the failure is in your imagination

Any useful hints towards enlightenment except criticism?

While you are correct in saying (I paraphrase) that HTML interfaces
nowadays can offer a rich graphical interface, it can be quite difficult
to manage state maintenance between the two components (web server, web
client) in the system.

The cause of confusion here is, that HTML interfaces don't necessary need a
web server and HTTP to work. I mean, that Internet Browsers
have an API which allow access to them directly, so they can be used without
a server as a kind of GUI library supporting widgets programmed
in HTML and JavaScript (I haven't used them yet in this form, but I think
it should be no problem - right or not?).

A "proper" GUI runs all functionality inside a single process, and
allows much easier control over complex interactions, creation of
dynamic dialogues, and so on.

Complex and dynamic is in my eyes possible with HTML and JavaScript, so I
still don't see where is a problem with this approach. I have programmed
already a HTML and JavaScript driven server platform and know about (the
solvable) problems with the back-button and sessions (it is sure not the
easiest way of programming a GUI).
The only disadvantage of not using plugins or Java is, that real time
interactions are not possible, but this is in my eyes usually not the
requirement for a standard kind of GUI with no gaming, no Virtual Reality
and no timing of user response down to milliseconds (but consider, that with
a good speed of connection it is even possible to play blitz chess over the
Internet).

Claudio

 

[Robert Hicks]

Grant Edwards wrote:

Aside from the look & feel issue with Tk, the other objection
sometimes heard is that Tk is integrated into Python by
including Tcl as well (as opposed to doing an actual Tk binding
the way some other languages have done). It's an eminently
practical approach, but it sure makes you feel dirty.

Dirty or not, it allows Python to utilitze any new features of Tk much
faster than an actual Tk binding would. That is Perl/Tk's problem...it
is slow to adopt new Tk features.

Robert

 

[Steve Holden]

[Claudio]

has

and


In this case then, I'm afraid the failure is in your imagination

Any useful hints towards enlightenment except criticism?

Perhpas the mistake I made was bearing in mind the title of the thread,
and the fact that this is a Python newsgroup.

as a



The cause of confusion here is, that HTML interfaces don't necessary need a
web server and HTTP to work. I mean, that Internet Browsers
have an API which allow access to them directly, so they can be used without
a server as a kind of GUI library supporting widgets programmed
in HTML and JavaScript (I haven't used them yet in this form, but I think
it should be no problem - right or not?).

You are perfectly correct that interfaces can be programmed in the
browser. As has already been said, with the adoption of standards like
CSS2, it's even possible to make such stuff run across multiple browser
platforms (at the moment, though, just try writing an interface that
makes table rows appear and disappear in a cross-browser fashion: you'll
find the stylesheet techniques you need to use for Mozilla and IE are
very different). But this doesn't help you at all if you are trying to
interface to Python logic.

Complex and dynamic is in my eyes possible with HTML and JavaScript, so I
still don't see where is a problem with this approach. I have programmed
already a HTML and JavaScript driven server platform and know about (the
solvable) problems with the back-button and sessions (it is sure not the
easiest way of programming a GUI).
The only disadvantage of not using plugins or Java is, that real time
interactions are not possible, but this is in my eyes usually not the
requirement for a standard kind of GUI with no gaming, no Virtual Reality
and no timing of user response down to milliseconds (but consider, that with
a good speed of connection it is even possible to play blitz chess over the
Internet).

So, back to the subject: with an HTML/Javascript interface, how do you
propose to bolt Python logic into the same process? Or do you admit that
the application that interacts with such an interface either has to be
all JavaScript or in a separate process?

regards
Steve

 

[Wolfgang Keller]

With OS X compatibility you tend to come across with the

fact that many "OS X compatible" things are actually X11
things. X11 certainly looks different from Aqua (the native
interface).

But imho, Gnome _does_ "look and feel" quite Mac-ish in the sense that
its ergonomics has certain things in common with the Mac, even more
with the old MacOS classic than with the pretty "gadget-ish" Aqua
interface.

For example, with its hierarchical multi-column listview, Nautilus
"looks" and "feels" perfectly like the old MacOS classic Finder,
something that lots of long-time Mac users miss a lot on MacOS X.

Another example is MDI (or "windows inside windows"), which is a no-no
on the Mac (and afaik not supported by GTK), or multi-pains (sic!). As
a long-time Mac user (since system 6.0.x), I did like a lot the GUI of
WingIDE (which uses GTK) because it allows me to switch from a
multi-pain layout to a multi-window layout.

GTK is an example of this. There is an Aqua version of
GTK, but it seems to be rather outdated.

There's a new effort for a "aqua-native" implementation:

http://micke.hallendal.net/archives/2005/10/gtk-macosx.html

The newer versions
run on X11 but installing them may be just laborious or
then plain pain depending on your luck. And you still need
the X11 installed.

One advantage of an X11 application is, obviously, the possibility to
use it from a different computer without the requirement to install it
there.

"Hey, my Mac can do that for free, while your Windows needs an
expensive "Server" license.!" >;-> Shhh, don't tell them about
Cygwin...

So, if you are looking for something that looks like Mac
and works like Mac, do not touch anything with X11.

As a long-time Mac user, I somewhat disagree, see above.

To me, a GTK application with a really well-thought ergonomic user
interface is a lot more Mac-ish than a pile of "aqua-native" visual
gadgetry.

Sincerely,

Wolfgang Keller