GUI Frameworks in Python?

[Hugh Macdonald]

I've recently been trying out various different GUI frameworks in Python and
was wondering if I could get your input on the pros and cons of the
different ones...

wxPython: I love the programming side of wxPython, but I find it's just so
slow to initialise in the first place.

Tkinter: While it's fast to load up, the syntax has never really appealed to
me

GTK: Unknown - I'm looking into it today

Qt: I have yet to manage to install it on my system

Anything else?
Hugh Macdonald

[Corey Coughlin]

One I've always meant to look into more is PyUI, a gui framework built
on the pygame library. Always looked kind of cool. Anyone have any
experience with it?

"Hugh Macdonald" <Hu***********@brokenpipefilms.com> wrote in message news:<ma**************************************@pyt hon.org>...

I've recently been trying out various different GUI frameworks in Python and
was wondering if I could get your input on the pros and cons of the
different ones...

wxPython: I love the programming side of wxPython, but I find it's just so
slow to initialise in the first place.

Tkinter: While it's fast to load up, the syntax has never really appealed to
me

GTK: Unknown - I'm looking into it today

Qt: I have yet to manage to install it on my system

Anything else?
Hugh Macdonald

[Greg Ewing]

Hung Jung Lu wrote:

Can someone outline some differences/advantages of PyGTK vs. wxPython?
Having had an intensive experience with both recently, I
can give you some of my impressions.

I started a project using wxPython, having heard good things
about it. At first it seemed all right, but as things progressed
I found myself becoming more and more frustrated with it.
Everything seemed to be just a little more complicated than
it needed to be, and I kept on running into bugs, limitations and
strange behaviours that I had to work around.

As an experiment, I tried re-writing it to use PyGtk, to find
out what it would be like. It turned out to be a much more
pleasant experience. The wrapping is very straightforward and
Pythonic, and everything Just Works the way I expect. I've
yet to encounter a single bug or unreasonable limitation.
A first look at PyGTK shows me a more Unix-like look-and-feel. On the
other hand, wxPython on Windows does look very much like any other
Windows applications.
It doesn't look quite the same as native apps on Windows, but
for my purposes it's close enough. If precise Windows authenticity
is important to you, you might have to use wxPython or something else
that uses native Windows widgets.
Is the event handling in PyGTK cleaner/better than wxPython?
The basic idea is fairly similar in both, but event handlers
("signal handlers" in Gtk terminology) seem more straightforward
to set up in PyGtk. In wxPython, for example, you have to get the
ID number of the widget and pass that to an event-binding function;
in PyGtk, you just pass the widget itself.

That's just one example of how the PyGtk API is simpler. It might
not sound like much, but lots of little things like that add up
to make me like PyGtk much better.
Does PyGTK have more widgets?
They seem to be more or less equal in this area, although the
PyGtk text and table/tree widgets may provide more functionality
than their counterparts in wxPython. I'm not sure, since I
haven't had to use much more than the basic functionality of
these widgets. It did seem to be easier to get the PyGtk table
widget to do exactly what I wanted in some cases.
Given the lack of comparison, I
would guess that GTK is unix-friendly, since Unix people usually would
mention little or nothing about Windows. :)

I would say that PyGtk is more Python-programmer-friendly,
regardless of what platform you're using. The only disadvantage
I can see for Windows is possibly slightly less authentic
appearance.

--
Greg Ewing, Computer Science Dept,
University of Canterbury,
Christchurch, New Zealand
http://www.cosc.canterbury.ac.nz/~greg

[Sridhar R]

hu********@yahoo.com (Hung Jung Lu) wrote in message news:<8e**************************@posting.google. com>...

sr*************@yahoo.com (Sridhar R) wrote in message news:<93**************************@posting.google. com>...

Man, you better use PyGTK (http://pygtk.org). It's portable (See pygtk
faq for windows port). It's neet (API).
Try also `glade`, `libglade`.
http://glade.gnome.org , I think?
Can someone outline some differences/advantages of PyGTK vs. wxPython?

Sure.

A first look at PyGTK shows me a more Unix-like look-and-feel. On the
other hand, wxPython on Windows does look very much like any other
Windows applications.
Wrong. GTK apps do look with native look and feel. For Windows,
look at the screenshots from the wimp project

http://gtk-wimp.sourceforge.net

I am sure about Mac too, as I have seen screenshots before (probably
linked from GTK homepage)

[You may better download download pygtk from windows from the link
given the pygtk faq page]

Is the event handling in PyGTK cleaner/better than wxPython? Does
Of course. Have looked at libglade ( is availble as glade module in
pygtk). You can even write a small function to autoconnect functions
to events. Say you can write function in a format like
def on_button1__clicked(self,button):
"This function is called when button1 emits 'clicked' signal"

... stilll many more functions like this ...

and you can even write your own function that autoconnects functions
with their object/events.

Instrospection in Event Handling!
PyGTK have more widgets?
Sure. Also have a look at the GtkExtra (also pygtkextra) project.
Writing new widgets is also pretty neat in PyGTK.
e FAQ of PyGTK does not have a comparison
section regarding other GUI toolkits, I think it would be useful if
If not, you can try them yourself
one were included. (If you go to wxPython's mainpage, you read "Why
the hell hasn't wxPython become the standard GUI for Python yet?", and
also "BTW, great work! I've definitively switched from Tk. I work on
Win32, anybody who works on Win32 should switch!". Comments like that.
Readers can immediately know the relationship to Tk, and wxPython's
platform friendliness for Win32.)
But, those people wouldn't have used PyGTK (or GTK) before. Don't
get a mind-shift just bcoz of some famous personality has said it.
Usually I will try out the possiblities and then choose from the
domain.
Given the lack of comparison, I
would guess that GTK is unix-friendly, since Unix people usually would
mention little or nothing about Windows. :)
As I said before, look at the screenshots. Or see this,
http://gtk-wimp.sourceforge.net/screenshots/

Gimp in WinXP
http://gtk-wimp.sourceforge.net/scre...gimp-winxp.png
Continuing with my guess:
are there any caveats for using PyGTK for Windows programmers?
PyGTK apps were little slow in Windows. But since the Wimp theme
(http://gtk-wimp.sourceforge.net) uses native win32 api calls to draw
widgets it should be pretty fair when compared to normal win32 apps.

Also try the tutorial at pygtk site

Also see http://developer.gnome.org
And very important try Glade, the GUI builder which generates XML
files which can be given to the `glade` module of pygtk to build GUI
dynamically.

---------------------------

Given my observations, is it fair to say:

(a) wxPython is widely used for Windows Python programmers, and
May be. But you can't say that as the best, without looking at
other toolkits. I found PyGTK great.
(b) PyGTK is widely used for Unix Python programmers?
GTK is widely used in the UNIX world! That's true.
regards,

Hung Jung

Happy programming.

[Thomas Heller]

> Hung Jung Lu wrote:

Can someone outline some differences/advantages of PyGTK vs. wxPython?

Greg Ewing <gr**@cosc.canterbury.ac.nz>: Having had an intensive experience with both recently, I
can give you some of my impressions.

I started a project using wxPython, having heard good things
about it. At first it seemed all right, but as things progressed
I found myself becoming more and more frustrated with it.
Everything seemed to be just a little more complicated than
it needed to be, and I kept on running into bugs, limitations and
strange behaviours that I had to work around.

As an experiment, I tried re-writing it to use PyGtk, to find
out what it would be like. It turned out to be a much more
pleasant experience. The wrapping is very straightforward and
Pythonic, and everything Just Works the way I expect. I've
yet to encounter a single bug or unreasonable limitation.

A first look at PyGTK shows me a more Unix-like look-and-feel. On the
other hand, wxPython on Windows does look very much like any other
Windows applications.

It doesn't look quite the same as native apps on Windows, but
for my purposes it's close enough. If precise Windows authenticity
is important to you, you might have to use wxPython or something else
that uses native Windows widgets.

I still think that a native windows toolkit written in pure Python,
based on venster, maybe, with a 'pythonic' api on top would be a killer.

Thomas

[DH]

Greg Ewing wrote:

Is the event handling in PyGTK cleaner/better than wxPython?

The basic idea is fairly similar in both, but event handlers
("signal handlers" in Gtk terminology) seem more straightforward
to set up in PyGtk. In wxPython, for example, you have to get the
ID number of the widget and pass that to an event-binding function;
in PyGtk, you just pass the widget itself.

That's just one example of how the PyGtk API is simpler. It might
not sound like much, but lots of little things like that add up
to make me like PyGtk much better.

I know, I can't believe wxPython doesn't use a simpler API for things
like event binding rather than just sticking to the C++ api so closely.
That's why people are creating their own wrappers to wxPython now.
It's ridiculous. And yes, I know event binding was made slightly
simpler for 2.5. 2.5 also takes some steps backwards, in the name of
being more like the C++ api.

[Hung Jung Lu]

sr*************@yahoo.com (Sridhar R) wrote in message news:<93*************************@posting.google.c om>...

Wrong. GTK apps do look with native look and feel. For Windows,
look at the screenshots from the wimp project
First of all, thanks for all the pointers. But from GTK-Wimp I read:

News:
GTK-Wimp 0.5.4 released (Thursday, 11 March 2004)
GTK-Wimp 0.5.3 released (Sunday, 25 January 2004)
GTK-Wimp 0.5.2 released (Wednesday, 19 November 2003)
But, those people wouldn't have used PyGTK (or GTK) before. Don't
get a mind-shift just bcoz of some famous personality has said it.
Usually I will try out the possiblities and then choose from the
domain.

If you have time, sure. Being guinea pig is a great way to learn. :) I
did that with Java. After that, I swore I would never be another
guinea pig again. :) I've done my share.

Jokes aside. The easiest way of being taller than giants is to stand
on their shoulders. The problem nowadays is there are all too many
things to learn in life, and life unfortunately is short. Who you
spend time talking to, and whose opinion you rely on, makes a big
difference. Nowadays I realize I must relying on words of expert
friends that have been there, done that. It's much more effective.
Anyway, these are lessons that people learn, sooner or later.

See also:

http://groups.google.com/groups?hl=e...entral.cox.net

"I have to concur with Cameron on the immaturity of Gtk under
win32..."
"Unless running on win32 is of secondary importance, I don't think Gtk
would
is a good choice until some of the Gtk/win32 bugs and other issues are
worked out..."

Your opinion, and opinions like the above, are the types of comments
that I take into account. So, I have nothing against GTK in Windows
per se, but it just seems to need a bit more time. Python did not
start this good either.

regards,

Hung Jung

[simo]

I've found that on 3 PC's (1.6GHz/7200rpm/XP Pro, 500MHz/4200rpm/2K
Pro, dual 400MHz/5400rpm/2K Pro) it always takes 3 seconds to get to
the demo splash screen, on Python 2.3.3 and wxPython 2.4.2.4/2.5.1.5

On the dual PII/400, Hugh's script takes repeatedly about 1.125s,
unless you run it from within IDLE, whereby the first run takes about
1.7s and then it takes 0.03s, so I guess IDLE caches the compiled
version (I've see this before).

It doesn't seem to be wxPython specific either, I've got similar
wx/Qt/Tk apps that seem to take the same time to start.

This leads me to believe it's the Python interpreter starting up that
takes a specific amount of time (does it wait or something odd?).
Unless it's so heavily optimised that a processor 3x as fast makes no
speed difference! ;o)

[Josiah Carlson]

>> The basic idea is fairly similar in both, but event handlers

("signal handlers" in Gtk terminology) seem more straightforward
to set up in PyGtk. In wxPython, for example, you have to get the
ID number of the widget and pass that to an event-binding function;
in PyGtk, you just pass the widget itself.

That's just one example of how the PyGtk API is simpler. It might
not sound like much, but lots of little things like that add up
to make me like PyGtk much better.

I know, I can't believe wxPython doesn't use a simpler API for things
like event binding rather than just sticking to the C++ api so closely.
That's why people are creating their own wrappers to wxPython now. It's
ridiculous. And yes, I know event binding was made slightly simpler for
2.5. 2.5 also takes some steps backwards, in the name of being more
like the C++ api.

Simpler? According to Greg, passing ids of the widget was a
pain...well, in 2.5 you can pass the widget. Apparently that is
significant enough to warrant Greg complaining about it, and Robin Dunn
to fix it.

What parts of the 2.4 to 2.5 conversion are steps backward?

- Josiah

[DH]

Josiah Carlson wrote:

That's just one example of how the PyGtk API is simpler. It might
not sound like much, but lots of little things like that add up
to make me like PyGtk much better.

....
What parts of the 2.4 to 2.5 conversion are steps backward?

Here's one example of unneeded extra typing, compared to virtually every
other GUI API, to further illustrate Josiah's point:

Java drawline: (AWT & Swing)
graphics.drawline(x1,y1,x2,y2)

Visual Basic drawline:
graphics.drawline(pen,x1,y1,x2,y2)

pyqt drawline:
painter.drawline(x1,y1,x2,y2)

anygui drawline: (wraps wxpython and other guis)
canvas.drawLine(x1,y1,x2,y2)

piddle drawline: (wraps wxpython and other guis)
canvas.drawline(x1,y1,x2,y2)

pythoncard drawline (wraps wxpython)
drawline(x1,y1,x2,y2)

pygtk drawline:
draw_line(drawable, gc, x1, y1, x2, y2)

tkinter drawline:
canvas.create_line(x1,y1,x2,y2)

pygame drawline:
pygame.draw.line(surface,(r,g,b),(x1,y1),(x2,y2))

wxPython 2.4 drawline:
wxdc.drawline(x1,y1,x2,y2)

wxPython 2.5 drawline:
wxdc.drawline (wxPoint(x1,y1),wxPoint(x2,y2))
or the much simpler ((x1,y1),(x2,y2))
or you can do drawlineXY(x1,y1,x2,y2)

Admittedly, wxPython is still simpler than OpenGL:
def drawline(x1,y1,x2,y2):
glBegin (GL_LINES)
glVertex2f (x1,y1)
glVertex2f (x2,y2)
glEnd ()

[greg]

Josiah Carlson wrote:

Simpler? According to Greg, passing ids of the widget was a
pain...well, in 2.5 you can pass the widget. Apparently that is
significant enough to warrant Greg complaining about it, and Robin Dunn
to fix it.

Like I said, it's not a big deal on its own, just something
that seemed needlessly awkward, among many others. Some
other examples: You can't create a widget until there's a
parent for it, forcing you to create widgets in a certain
order. When you create a widget, you have to either specify
an ID number, or -1 to say you don't care what its ID number
is (I didn't, mostly), instead of just letting it default.
Most widget constructors seem to take about half a dozen
parameters that you have to get in the right order because
you can't specify them using keywords. And so on.

All these small things added up to an experience that I
didn't enjoy much overall.

--
Greg