Re: Python GUI toolkit

Discussion in 'Python' started by Thomas Dybdahl Ahle, Feb 3, 2008.

  1. On Sun, 2008-02-03 at 15:18 +0000, ult 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.
    Thomas Dybdahl Ahle, Feb 3, 2008
    #1
    1. Advertising

  2. Thomas Dybdahl Ahle

    Eric Brunel Guest

    On Sun, 03 Feb 2008 20:38:41 +0100, Thomas Dybdahl Ahle <>
    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+-'])"
    Eric Brunel, Feb 4, 2008
    #2
    1. Advertising

  3. Thomas Dybdahl Ahle

    Guest


    >
    > 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
    , Feb 4, 2008
    #3
  4. Thomas Dybdahl Ahle

    Chris Mellon Guest

    On Feb 4, 2008 9:19 AM, <> 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.
    Chris Mellon, Feb 4, 2008
    #4
  5. Thomas Dybdahl Ahle

    Kevin Walzer Guest

    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.codebykevin.com
    Kevin Walzer, Feb 4, 2008
    #5
  6. Thomas Dybdahl Ahle

    Chris Mellon Guest

    On Feb 4, 2008 9:57 AM, Kevin Walzer <> 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).
    Chris Mellon, Feb 4, 2008
    #6
  7. Thomas Dybdahl Ahle

    Kevin Walzer Guest

    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/document..._1.html#//apple_ref/doc/uid/10000060i-CH7-SW1

    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.codebykevin.com
    Kevin Walzer, Feb 4, 2008
    #7
  8. Thomas Dybdahl Ahle

    Kevin Walzer Guest

    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/document..._1.html#//apple_ref/doc/uid/10000060i-CH7-SW1

    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.codebykevin.com
    Kevin Walzer, Feb 4, 2008
    #8
  9. Thomas Dybdahl Ahle

    Chris Mellon Guest

    On Feb 4, 2008 10:46 AM, Kevin Walzer <> 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/document..._1.html#//apple_ref/doc/uid/10000060i-CH7-SW1
    >
    > 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.
    Chris Mellon, Feb 4, 2008
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Leo
    Replies:
    12
    Views:
    813
    Frithiof Andreas Jensen
    Nov 5, 2003
  2. Orr, Steve
    Replies:
    1
    Views:
    698
    Daniel Dittmar
    Oct 30, 2003
  3. Tim Ronning
    Replies:
    16
    Views:
    802
  4. Oren Tirosh
    Replies:
    6
    Views:
    1,722
    Oren Tirosh
    Dec 18, 2003
  5. Andre Brightway
    Replies:
    4
    Views:
    2,829
    Michael 'Mickey' Lauer
    Dec 17, 2003
Loading...

Share This Page