GUI Frameworks in Python?

[Shane Hathaway]

Re: GUI Frameworks in Python?

Chris Perkins wrote:[color=blue]
> I just upgraded from 2.4.2.4 to 2.5.1.5, and the start-up time for the
> demo app went from about 5 seconds to less than a second.[/color]

Wow! I'd really like to know how this was accomplished. Do you know?
(Robin?)

Shane

[Peter Hansen]

Re: GUI Frameworks in Python?

Peter Hansen wrote:
[color=blue]
> Hugh Macdonald wrote:
>[color=green]
>> I just wrote the following simple script:
>>
>> -------------------------------------------------
>> #!/software/python/python2.2.2/linux/bin/python
>> import time
>> startTime = time.time()
>> from wxPython.wx import *
>> print "Time:",time.ti me()-startTime
>> -------------------------------------------------
>>
>> On running multiple times, I get the following outputs:
>>
>> Time: 4.60863804817
>> Time: 3.26165890694
>> Time: 3.24744296074
>> Time: 3.26767706871
>> Time: 3.25304102898[/color]
>
> Running that repeatedly (sorry, can't reboot conveniently
> right now, so can't get the first time) it takes 0.125 s
> on my machine.[/color]

Just upgraded to the newly released (thank you so very much
for all your work Robin Dunn... now get back to that book! ;-)
2.5.1.5 to compare, sort of, with Chris Perkins' results.

Now it consistently takes 0.20 seconds to run the above on
my machine... how very odd.

-Peter

[Sridhar R]

Re: GUI Frameworks in Python?

"Hugh Macdonald" <HughMacdonald@ brokenpipefilms .com> wrote in message news:<mailman.1 02.1080629227.2 0120.python-list@python.org >...[color=blue]
> 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[/color]

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?

[Hung Jung Lu]

Re: GUI Frameworks in Python?

sridharinfinity @yahoo.com (Sridhar R) wrote in message news:<930ba99a. 0404030246.7864 55f5@posting.go ogle.com>...[color=blue]
>
> 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?[/color]

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

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.

Is the event handling in PyGTK cleaner/better than wxPython? Does
PyGTK have more widgets? The FAQ of PyGTK does not have a comparison
section regarding other GUI toolkits, I think it would be useful if
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.) Given the lack of comparison, I
would guess that GTK is unix-friendly, since Unix people usually would
mention little or nothing about Windows. :) Continuing with my guess:
are there any caveats for using PyGTK for Windows programmers?

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

Given my observations, is it fair to say:

(a) wxPython is widely used for Windows Python programmers, and
(b) PyGTK is widely used for Unix Python programmers?

regards,

Hung Jung

[Kenneth McDonald]

Re: GUI Frameworks in Python?

In article <mailman.102.10 80629227.20120. python-list@python.org >, Hugh Macdonald wrote:[color=blue]
> 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...
>[/color]
I would take a strong, close look at Tkinter again. In my opinion,
people have dismissed Tk as 'old technology', but I have seen
nothing else that remotely approaches the power of Tk.

First, a few points:
1) Tk at the moment looks ugly. There is a major
effort undergoing (tile--look on sourceforge) to
develop a themable Tk, and they already have
some very good-looking Windows-looking screenshots.
This won't be available in the immediate future,
but I think it won't be too too far off either.
The Tk community understands that the ugly,
nonstandard look is hurting Tk use.

2) Tkinter is a (relatively) thin layer over
Tk calls. The best way to use it is to build
some functions over it to do what you want
to do, and then reuse those functions.

3) Tkinter does make Tk into an object oriented
paradigm. So as you mention, you can subclass
a Tk widget and then pass in appropriate methods
of that class as functions. However, you often
don't even need to do this. A complex widget is
almost certainly going to be declared as a class
so just do:

class MyWidget(Frame) :
def __init__(self)
button1=Button( command=self.fo o1)
button2=Button( command=self.fo o2)

def foo1(event):...
def foo2(event):...

I can't remember if 'command' is the right option to Button,
but you get the idea.

3) People often complain about the Tk widget set not
being powerful enough. This is nonsense. First, read
through all of the man pages for the Text and Canvas
widgets--nothing else even comes close. (If something
does, please let me know). I've looked at QScintilla,
and it is far less flexible than Text. Then, download
the BLT addon package for Tcl/Tk and read through
its graph widget documentation. As for basic widget
sets, There may be a few widget types missing, but
it is very few, and what is missing can usually
be found in an Python extension (MegaWidgets) or
somewhere else, or coded fairly quickly using Tkinter.

4) The event-handling mechanism in Tk is awesome
It is very easy to specify not just single events,
but also "event sequences"; so, for example, you
can specify that ^X^S (the emacs save command)
saves your files.

5) As I mentioned above, it is often best to put
a nicer wrapper around some of the Tkinter stuff.
For example, here is the way I put things into a
gridded layout:

button = Button(...)
label = Label(...)
subframe = Frame(...)
mywidget = MyWidget(...)

grid([
[button, '-', label],
[subframe, 'x', '^'],
['^', mywidget, '-']
])

Which, using the captalized first letter of each
widget's variable, result in a layout like this:

BBL
S L
SMM
with the middle cell empty. The ^ and - characters
simply indicate that the cell in the previous
row/column should be carred into this cell. This
grid function (not method)
took me about 8 lines to write, and I've
put it up on the Tkinter mailing list hosted on
the Python web site.

Likewise, I'm in the process of writing something
to make event binding easier, and will put that
up when it's done. It will look something like:

bindevents(widg et,
ca_x_space_b1=f un1,
m_backspace=fun 2,
Y=fun3,
)

Which indicates that fun1 should be invoked on the
event sequence ctrl-alt-x ctrl-alt-space ctrl-mousebutton1;
fun2 on meta-backspace; and fun3 on the single key 'Y'.

There are a few problems with Tk. To use much of the
Tkinter stuff, you need to have the Tk man pages
handy, which is why writing more pythonic wrappers
is a good idea. There is a third-party table widget
available which is useful for relatively simple
applications, but which lacks the flexibility and
power of the Text and Canvas widgets. (Still, it's
better than a lot of other table implementations
I've seen.) However, once you've gotten over the
initial learning curve (which mostly has to do
with learning the Tk side, and isn't really that
bad--Brent Welch and a co-author have a brand new
book out which is just great), you can throw a
powerful UI together in an amzingly short time.

Cheers,
Ken

[Corey Coughlin]

Re: GUI Frameworks in Python?

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" <HughMacdonald@ brokenpipefilms .com> wrote in message news:<mailman.1 02.1080629227.2 0120.python-list@python.org >...[color=blue]
> 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[/color]

[Greg Ewing]

Re: GUI Frameworks in Python?

Hung Jung Lu wrote:[color=blue]
> Can someone outline some differences/advantages of PyGTK vs. wxPython?[/color]

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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> Is the event handling in PyGTK cleaner/better than wxPython?[/color]

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.
[color=blue]
> Does PyGTK have more widgets?[/color]

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.
[color=blue]
> Given the lack of comparison, I
> would guess that GTK is unix-friendly, since Unix people usually would
> mention little or nothing about Windows. :)[/color]

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]

Re: GUI Frameworks in Python?

hungjunglu@yaho o.com (Hung Jung Lu) wrote in message news:<8ef9bea6. 0404041009.26ae 2683@posting.go ogle.com>...[color=blue]
> sridharinfinity @yahoo.com (Sridhar R) wrote in message news:<930ba99a. 0404030246.7864 55f5@posting.go ogle.com>...[color=green]
> >
> > 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?[/color]
>
> Can someone outline some differences/advantages of PyGTK vs. wxPython?[/color]

Sure.
[color=blue]
>
> 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.[/color]

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]
[color=blue]
>
> Is the event handling in PyGTK cleaner/better than wxPython? Does[/color]

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__cli cked(self,butto n):
"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!
[color=blue]
> PyGTK have more widgets?[/color]

Sure. Also have a look at the GtkExtra (also pygtkextra) project.
Writing new widgets is also pretty neat in PyGTK.
[color=blue]
> e FAQ of PyGTK does not have a comparison
> section regarding other GUI toolkits, I think it would be useful if[/color]

If not, you can try them yourself
[color=blue]
> 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.)[/color]

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.
[color=blue]
> Given the lack of comparison, I
> would guess that GTK is unix-friendly, since Unix people usually would
> mention little or nothing about Windows. :)[/color]

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/screenshots/gfx/gimp-winxp.png

[color=blue]
> Continuing with my guess:
> are there any caveats for using PyGTK for Windows programmers?[/color]

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.
[color=blue]
>
> ---------------------------
>
> Given my observations, is it fair to say:
>
> (a) wxPython is widely used for Windows Python programmers, and[/color]

May be. But you can't say that as the best, without looking at
other toolkits. I found PyGTK great.
[color=blue]
> (b) PyGTK is widely used for Unix Python programmers?[/color]

GTK is widely used in the UNIX world! That's true.
[color=blue]
> regards,
>
> Hung Jung[/color]

Happy programming.

[Thomas Heller]

Re: GUI Frameworks in Python?

> Hung Jung Lu wrote:[color=blue][color=green]
>> Can someone outline some differences/advantages of PyGTK vs. wxPython?[/color]
>[/color]

Greg Ewing <greg@cosc.cant erbury.ac.nz>:[color=blue]
> 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.
>[color=green]
>> 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.[/color]
>
> 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.[/color]

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]

Re: GUI Frameworks in Python?

Greg Ewing wrote:[color=blue][color=green]
>> Is the event handling in PyGTK cleaner/better than wxPython?[/color]
>
>
> 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.[/color]

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]

Re: GUI Frameworks in Python?

sridharinfinity @yahoo.com (Sridhar R) wrote in message news:<930ba99a. 0404060104.fdf2 605@posting.goo gle.com>...[color=blue]
> Wrong. GTK apps do look with native look and feel. For Windows,
> look at the screenshots from the wimp project[/color]

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)
[color=blue]
> 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.[/color]

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=en&lr=&ie=UTF-8&oe=UTF-8&selm=axa6b.64498%240u4.46413%40news1.central.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]

Re: GUI Frameworks in Python?

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]

Re: GUI Frameworks in Python?

>> The basic idea is fairly similar in both, but event handlers[color=blue][color=green]
>> ("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.[/color]
>
>
> 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.[/color]

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]

Re: GUI Frameworks in Python?

Josiah Carlson wrote:[color=blue][color=green][color=darkred]
>>> 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.[/color][/color][/color]
....
[color=blue]
> What parts of the 2.4 to 2.5 conversion are steps backward?[/color]

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.drawli ne(x1,y1,x2,y2)

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

pyqt drawline:
painter.drawlin e(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(drawa ble, gc, x1, y1, x2, y2)

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

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

wxPython 2.4 drawline:
wxdc.drawline(x 1,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,y 1,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]

Re: GUI Frameworks in Python?

Josiah Carlson wrote:[color=blue]
> 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.[/color]

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