Asp Forum - Re: Python GUI toolkit

lobais@gmail.com

2/3/2008 7:39:00 PM

On Sun, 2008-02-03 at 15:18 +0000, default@defaulted.default wrote:
> what would be the best python GUI toolkit, it must be cross platform.
>
> i have tried gtk, but it interface are real bad and its coding was
difficult
> so i dropped it,

I came from Sving to Gtk, so for me also it was a real brainbreak.
However I must say I got used to it.
I have a good list of links if you still have some corruage.

> the only remaining are qt4 and wx, i would like to know if one of
these or
> any other toolkit is capable of creating good-looking GUI's, like in
other
> apps, for e.g, .net apps.

Well, I've always hated wx apps. It might be a good toolkit for writing,
but I've never seen a good-looking app written in it.

For Qt there is also distance between the good looking apps. However
with qt4 I've started to see some. They still don't fit good into gnome
of cource, but it's not as bad as it used to. I also think the toolkit
is nice for writing.

Another toolkit you might look into is Tkinter. I think it is something
like the "official" toolkit for python. I also think it is an adapter
for other toolkits, so it will use gtk widgets on gnome, qt widgets on
kde and some other strange widgets on windows.

> i m a noob, and willing to learn, so difficulty is no problem

In that case I think you should give gtk another try. The way it is
build is very much based on GObject, which is also used in a number of
other gnome libraries + stuff like Clutter.

8 Answers

Eric Brunel

2/4/2008 1:00:00 PM

On Sun, 03 Feb 2008 20:38:41 +0100, Thomas Dybdahl Ahle <lobais@gmail.com>
wrote:
[snip]
> Another toolkit you might look into is Tkinter. I think it is something
> like the "official" toolkit for python. I also think it is an adapter
> for other toolkits, so it will use gtk widgets on gnome, qt widgets on
> kde and some other strange widgets on windows.

No. Tkinter doesn't use any other library and draws its own widgets, which
until now look like very old-style Motif widgets on Unix. There's a new
version of tcl/tk (on which Tkinter is based) that has a new look for
widgets, basically looking like gtk's default theme, but it doesn't use
gtk at all.

This can be seen as an advantage or a drawback depending on what you're
looking for:
- this keeps the toolkit very small and independent (no dependency hell)
- this basically ensures that the look won't be "native"

And BTW, the new version of tcl/tk is supposed to look native on Windows &
MacOS too. Unfortunately, this version is very new and the Tkinter module
has not been adapted for it yet.

HTH
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"

Francesco Bochicchio

2/4/2008 3:19:00 PM

>
> Another toolkit you might look into is Tkinter. I think it is something
> like the "official" toolkit for python. I also think it is an adapter
> for other toolkits, so it will use gtk widgets on gnome, qt widgets on
> kde and some other strange widgets on windows.
>

Not t so, AFAIK. Tkinter is the python adapter for Tk, the toolkit
originally developed for Tcl language.

The latest version of Tk (not yet integrated in Python, maybe in 2.6)
has themes, which emulates
the look-and-feel of native toolkit at list for XP and OS X. For unix,
the last time I checked, there was only a theme that looked like a
plainer version of Gtk default theme. No Gnome or Kde themes yet.

The latest version of Tk also increased the set of available widgets,
which now is similar to the set of widgets offered by Qt/Gtk..
However, how much of these widgets will be available through Tkinter
will depend on people stepping in and upgrading Tkinter beyond simpy
ensuring that the old widgets still works. Given that many GUI-
developing python programmers have moved to other toolkits, I'm not
sure this will ever happen.

Ciao
--------
FB

Chris Mellon

2/4/2008 3:25:00 PM

On Feb 4, 2008 9:19 AM, <bockman@virgilio.it> wrote:
>
> >
> > Another toolkit you might look into is Tkinter. I think it is something
> > like the "official" toolkit for python. I also think it is an adapter
> > for other toolkits, so it will use gtk widgets on gnome, qt widgets on
> > kde and some other strange widgets on windows.
> >
>
> Not t so, AFAIK. Tkinter is the python adapter for Tk, the toolkit
> originally developed for Tcl language.
>
> The latest version of Tk (not yet integrated in Python, maybe in 2.6)
> has themes, which emulates
> the look-and-feel of native toolkit at list for XP and OS X. For unix,
> the last time I checked, there was only a theme that looked like a
> plainer version of Gtk default theme. No Gnome or Kde themes yet.
>
Nitpick, but an important one. It emulates *look*. Not feel. Native
look is easy and totally insufficient for a "native" app - it's the
feel that's important.

Kevin Walzer

2/4/2008 3:57:00 PM

Chris Mellon wrote:

> Nitpick, but an important one. It emulates *look*. Not feel. Native
> look is easy and totally insufficient for a "native" app - it's the
> feel that's important.

Is this opinion based on firsthand experience with use of the Tile/ttk
widgets on any of the relevant platforms?

I'm not a Windows user, so I can't speak about that platform, but I have
worked very hard to make my Python-Tile-Tk app consistent with both the
look and feel of OS X: keyboard shortcuts, menu behavior, and so on.
It's mainly a matter of attention to detail, and listening to user
feedback. I've gotten good feedback on my applications in recent months
as I've implemented more and more platform native behavior, and sales of
these applications (I'm a shareware developer) reflect that.

I'd be interested to hear how, in your experience, Tk/Tile is inherently
unable to deliver native platform "feel," in a way that reflects on the
toolkit rather than the developer. It's fine to focus on Windows if
that's your area of expertise.

--
Kevin Walzer
Code by Kevin
http://www.codeb...

Chris Mellon

2/4/2008 4:23:00 PM

On Feb 4, 2008 9:57 AM, Kevin Walzer <kw@codebykevin.com> wrote:
> Chris Mellon wrote:
>
> > Nitpick, but an important one. It emulates *look*. Not feel. Native
> > look is easy and totally insufficient for a "native" app - it's the
> > feel that's important.
>
> Is this opinion based on firsthand experience with use of the Tile/ttk
> widgets on any of the relevant platforms?
>
> I'm not a Windows user, so I can't speak about that platform, but I have
> worked very hard to make my Python-Tile-Tk app consistent with both the
> look and feel of OS X: keyboard shortcuts, menu behavior, and so on.
> It's mainly a matter of attention to detail, and listening to user
> feedback. I've gotten good feedback on my applications in recent months
> as I've implemented more and more platform native behavior, and sales of
> these applications (I'm a shareware developer) reflect that.
>
> I'd be interested to hear how, in your experience, Tk/Tile is inherently
> unable to deliver native platform "feel," in a way that reflects on the
> toolkit rather than the developer. It's fine to focus on Windows if
> that's your area of expertise.

I didn't say inherently unable, I said the toolkit doesn't provide it.
Note that you said that you did a lot of work to follow OS X
conventions and implement behavior. The toolkit doesn't help you with
any of this. A mac-native toolkit (or one that strives for native
behavior, like wxPython) eliminates a lot of this work (although, of
course, not all).

Kevin Walzer

2/4/2008 4:47:00 PM

Chris Mellon wrote:

>
> I didn't say inherently unable, I said the toolkit doesn't provide it.
> Note that you said that you did a lot of work to follow OS X
> conventions and implement behavior. The toolkit doesn't help you with
> any of this. A mac-native toolkit (or one that strives for native
> behavior, like wxPython) eliminates a lot of this work (although, of
> course, not all).

If the toolkit doesn't provide it, then I think that means "inherently
unable."

On the Mac, Tk provides a mechanism that allows hooking up arbitrary
events to arbitrary keyboard. Something like:

self.bind('<Command-Key-N>', lambda event:
self.authorizeCommand(self.installPackage))

I have to specify the key-combination--that's all. One line of code. No
implementing of keyboard bindings in C or at the Tcl/Tk or even
Python-Tkinter level--it's all already defined by the toolkit.

By contrast, Cocoa/Objective-C has a rather complex system for defining
keyboard events:

http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/chapter_6_section_1.html#//apple_ref/doc/uid/1000006...

PyObjC is a thin wrapper over Objective-C, so you'd have to do the
equivalent calls in Python to implement custom keyboard behavior.

It is true that Cocoa some convenience methods in Interface Builder,
i.e. common menu commands don't require any extra code: if you are
developing a document-based application, "Command-C" is implemented in
the menu and in the frameworks as "copy (text, image, whatever) to
clipboard." But "Command-C" also works identically in the Tk console.

Tk does lack some things. It doesn't support drag-and-drop on the Mac.
It doesn't hook into some of the newer Mac visual styles. Getting access
to this would require an extension or patching Tk's core. In those
events, I emulate the behavior or appeareance, which Tk makes very easy.

--
Kevin Walzer
Code by Kevin
http://www.codeb...

Kevin Walzer

2/4/2008 4:47:00 PM

Chris Mellon

2/4/2008 5:46:00 PM

On Feb 4, 2008 10:46 AM, Kevin Walzer <kw@codebykevin.com> wrote:
> Chris Mellon wrote:
>
> >
> > I didn't say inherently unable, I said the toolkit doesn't provide it.
> > Note that you said that you did a lot of work to follow OS X
> > conventions and implement behavior. The toolkit doesn't help you with
> > any of this. A mac-native toolkit (or one that strives for native
> > behavior, like wxPython) eliminates a lot of this work (although, of
> > course, not all).
>
>
> If the toolkit doesn't provide it, then I think that means "inherently
> unable."
>

Of course it doesn't, because you can implement it yourself. Which is
what you do. Tile itself is inherently unable to provide this because
it's a theming mechanism.

> On the Mac, Tk provides a mechanism that allows hooking up arbitrary
> events to arbitrary keyboard. Something like:
>
> self.bind('<Command-Key-N>', lambda event:
> self.authorizeCommand(self.installPackage))
>
> I have to specify the key-combination--that's all. One line of code. No
> implementing of keyboard bindings in C or at the Tcl/Tk or even
> Python-Tkinter level--it's all already defined by the toolkit.
>

I know how toolkits work.

> By contrast, Cocoa/Objective-C has a rather complex system for defining
> keyboard events:
>
> http://developer.apple.com/documentation/Cocoa/Conceptual/EventOverview/HandlingKeyEvents/chapter_6_section_1.html#//apple_ref/doc/uid/1000006...
>
> PyObjC is a thin wrapper over Objective-C, so you'd have to do the
> equivalent calls in Python to implement custom keyboard behavior.
>
> It is true that Cocoa some convenience methods in Interface Builder,
> i.e. common menu commands don't require any extra code: if you are
> developing a document-based application, "Command-C" is implemented in
> the menu and in the frameworks as "copy (text, image, whatever) to
> clipboard." But "Command-C" also works identically in the Tk console.
>
> Tk does lack some things. It doesn't support drag-and-drop on the Mac.
> It doesn't hook into some of the newer Mac visual styles. Getting access
> to this would require an extension or patching Tk's core. In those
> events, I emulate the behavior or appeareance, which Tk makes very easy.
>

I'm not sure how you keep referring to things you implement yourself
as something that the toolkit supports. As a brief example, some
features that wxPython provides to aid in native "feel" and not just
look:

Stock button support allows you to have native button location, order
and labelling.
Sizer support allows for differently sized controls to be positioned
with the same layout.
Stock menu IDs (like preferences and "About this application...") will
be labelled and placed correctly.
Accelerators will automatically map between Command and Control.
Standard path support to find appropriate user directories.

All of these are things that you can do yourself, of course. You could
have implemented Tile yourself, too, to get the (mostly) native look.
The point is what the toolkit provides, and Tk+Tile, while it mostly
provides native look, does *not* provide native feel. If you want
native feel, you need to implement it yourself.

comp.lang.python

Re: Python GUI toolkit

lobais@gmail.com

Eric Brunel

Francesco Bochicchio

Chris Mellon

Kevin Walzer

Chris Mellon

Kevin Walzer

Kevin Walzer

Chris Mellon

x Login to ForumsZone