FAQ
I am looking for some input on GUI libraries. I want to build a
Python-driven GUI, but don't really understand the playing field very well.
I have generally heard good things about wxPython. I happen to already own
John Grayson's book about Tkinter programming, so that is rather handy if I
decide to use Tkinter. I have done some things slightly more involved than
"Hello World" in Tkinter - I have never used wxPython. So, basically the
points I am looking to have illuminated are:

o What features does wxPython offer that Tkinter cannot (and vice
versa)?
o Is the general programming methodology pretty much the same between
the two (e.g., the general program structure - using callbacks & Frames,
etc. is the same, it's just a question of calling different widgets with
their own arguments)?
o Do you have a strong preference for one over the other (or some other
toolkit)? Why?
o Are there any platform and/or performance issues I should be aware of?
o Is animation and graphics particularly better suited to one over the
other?
o Other important contrasts/similarities I should be aware of?

So... I know this question must come up fairly often. I did do a search
for "wxPython" and "Tkinter" - of the articles I currently have visibility
of, I saw one bug in wxPython discussed and nothing about Tkinter. Anything
else than can contribute to a "bird's eye view" understanding of the two (or
other) toolkits would be appreciated.

Thanks for taking the time to read my post.

Sincerely,
-ej

Search Discussions

  • Mike Meyer at Dec 11, 2004 at 6:55 am

    "Erik Johnson" <spam at nospam.org> writes:

    I am looking for some input on GUI libraries.
    Since you said others, I'll recommend PyQt. Major downside with it is
    that it costs money on Windows.
    o What features does wxPython offer that Tkinter cannot (and vice
    versa)?
    I don't know about wxPython, but PyQt includes it's own threading
    facility, plus hooks to talk to databases. It also has a widget for
    creating Windows "wizards" for walking through a set of options.
    o Is the general programming methodology pretty much the same between
    the two (e.g., the general program structure - using callbacks & Frames,
    etc. is the same, it's just a question of calling different widgets with
    their own arguments)?
    Not for Qt. It has the notion of SLOTs and SIGNALs. You connect a
    signal from an object to a slot or signal on another (or the same)
    object. You can, for example, connect a signal from a slider widget to
    a slot on a digital display widget, thus causing the display to change
    as you move the slider.

    At the python level, slots are just callable objects. At the
    C++ level, slots are magic methods of objects. Signals are usually
    associated with GUI events, but Python can emit them for whatever
    reason it wants. It's possible to connect C++ signals to C++
    slots/signals in Python, meaning that Python won't be involved when
    that signal is emitted.
    o Do you have a strong preference for one over the other (or some other
    toolkit)? Why?
    I strongly prefer PyQt TkInter. PyQt provides a higher level of
    abstraction.
    o Is animation and graphics particularly better suited to one over the
    other?
    I've never tried doing animation in TkInter. Qt provides timer devices
    that you can use to drive animations. I suspect that doing the same in
    TkInter would be noticably more difficult.

    <mike
    --
    Mike Meyer <mwm at mired.org> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
  • Fredrik Lundh at Dec 11, 2004 at 9:38 am

    Mike Meyer wrote:

    I don't know about wxPython, but PyQt includes it's own threading
    facility, plus hooks to talk to databases.
    That would of course be a great argument if Python didn't already have
    a threading facility, and a standard API for talking to databases with
    implementations for all major players.
    It also has a widget for creating Windows "wizards" for walking
    through a set of options.
    Besides the fact that wizards isn't really that great (read Cooper), if your
    toolkit doesn't let you create a dialogue with a couple of buttons and a
    swappable frame, it's not a very good toolkit. (that's very easy, in both
    Tkinter and wxPython. You can probably find ready-made modules on
    the net if you look around a little)
    o Is the general programming methodology pretty much the same between
    the two (e.g., the general program structure - using callbacks & Frames,
    etc. is the same, it's just a question of calling different widgets with
    their own arguments)?
    Not for Qt. It has the notion of SLOTs and SIGNALs. You connect a
    signal from an object to a slot or signal on another (or the same)
    object. You can, for example, connect a signal from a slider widget to
    a slot on a digital display widget, thus causing the display to change
    as you move the slider.

    At the python level, slots are just callable objects. At the
    C++ level, slots are magic methods of objects. Signals are usually
    associated with GUI events, but Python can emit them for whatever
    reason it wants. It's possible to connect C++ signals to C++
    slots/signals in Python, meaning that Python won't be involved when
    that signal is emitted.
    That's would of course be a great argument if you didn't have Python.
    (even if Python's slower than C++, it's a lot faster than a user).

    If you want bind an event source (signal) to a slot (method) in one line,
    use a lambda. If you need to add more behaviour (you usually do), use
    a function.
    PyQt provides a higher level of abstraction.
    Whan what? C++ plus a low level UI API, sure. But Tkinter+Python?
    wxPython+Python? You gotta be kidding.

    (or you're borrowing it from Trolltech's marketing material; I notice that
    the phrase "higher level of abstraction" is very popular amont Qt fans, but
    Trolltech themselves only seem to use it when they talk about lower-level
    libraries like X/Xt/Motif and the native Win32 API)
    I've never tried doing animation in TkInter. Qt provides timer devices
    that you can use to drive animations. I suspect that doing the same in
    TkInter would be noticably more difficult.
    Eh? You don't know how to do a loop in Python? Or register a callback?
    wxPython contains both timers and a low-level graphics API; for Tkinter,
    you the "after" facility and the Canvas; if you need lower-level drawing
    with tighter Python intergration, use the WCK.

    (for more advanced drawing, I'd recommend OpenGL, which is available
    for them all)

    </F>
  • Jarek Zgoda at Dec 11, 2004 at 10:05 am

    Fredrik Lundh wrote:

    I don't know about wxPython, but PyQt includes it's own threading
    facility, plus hooks to talk to databases.
    That would of course be a great argument if Python didn't already have
    a threading facility, and a standard API for talking to databases with
    implementations for all major players.
    Python threading is not perfect in many cases in GUI programming -- you
    have to implement your own notification mechanism (eg. using queue
    polling), as usually you can communicate with GUI only from main
    application's thread. While this is the case also for Qt, QThread
    instances have ability to post events to any arbitrary Qt objects, thus
    making life a bit easier.

    Anyway, all of above mentioned toolkits have its own pros and cons and
    in most of cases choice is a matter of personal taste.
  • Peter Hansen at Dec 11, 2004 at 6:35 pm

    Jarek Zgoda wrote:
    Fredrik Lundh wrote:
    I don't know about wxPython, but PyQt includes it's own threading
    facility, plus hooks to talk to databases.
    That would of course be a great argument if Python didn't already have
    a threading facility, and a standard API for talking to databases with
    implementations for all major players.
    Python threading is not perfect in many cases in GUI programming -- you
    have to implement your own notification mechanism (eg. using queue
    polling), as usually you can communicate with GUI only from main
    application's thread.
    With wxPython, PostEvent (which is what CallAfter also uses) is
    threadsafe and can be used from any thread, allowing you to
    communicate (in this direction, at least) with the GUI thread
    from any regular Python thread. No need for special threads
    provided by the framework and, in fact, even though wxWidgets
    (on which wxPython is built) provides a wxThread class, it
    is not exposed in wxPython because it is redundant there.

    -Peter


    From d.lapasset Sat Dec 11 19:45:15 2004
    From: d.lapasset (houbahop)
    Date: Sat, 11 Dec 2004 18:45:15 GMT
    Subject: newbie questions
    References: <Gtrud.86530$ha.44167@news.chello.at> <41ba6511$1@nntp.zianet.com>
    <mailman.7510.1102738381.5135.python-list@python.org>
    <x76539z6oh.fsf@guru.mired.org>
    <pXBud.87963$ha.26614@news.chello.at>
    <bvCud.743222$8_6.73414@attbi_s04>
    Message-ID: <%eHud.90239$ha.15906@news.chello.at>

    Hi,

    "Steven Bethard" <steven.bethard at gmail.com> a ?crit dans le message de news:
    bvCud.743222$8_6.73414 at attbi_s04...
    houbahop wrote:
    Thank you everyone, but I still not understand why such a comon feature
    like passing parameters byref that is present in most serious programming
    languages is not possible in a clean way,here in python.
    I understand from this statement that Java is not a serious programming
    language? ;)
    ;) I didn't want to say that.
    In fact, python is the first language I use that is like java 100% oriented
    object.
    I didn't realise that the main function, was an object too ! (and I don't
    really knew that self.something was meaning that it was a class attribute..
    just grabed this in a code found on the net :) )
    My habit in VB was to start a new project with a module (that is not an
    object and doesn't have class functions) and then calling object functions
    and passing them local to the main objects.

    like this :

    class a()
    blabla
    class b()
    blabla

    main()
    create a instance
    create b instance
    b()
    a(b)
    end main

    But in the very small script that I'm coding, I don't really need OOP and I
    will not use it even if I really like that.


    I don't see why lack of pass-by-reference would force you to use
    globals...
    Or by globals do you mean instance variables? If you don't want any
    instance variables (which means you don't really want OO), you can still
    clear your list as long as you have any name bound to the list object:
    You're right.
    def clear(lst):
    ... while lst:
    ... lst.pop()
    ...
    x = [pow(x, 7, 19) for x in range(10)]
    x
    [0, 1, 14, 2, 6, 16, 9, 7, 8, 4]
    clear(x)
    x
    []

    or alternatively:
    def clear(lst):
    ... lst[:] = []
    ...
    x = [pow(x, 7, 19) for x in range(10)]
    x
    [0, 1, 14, 2, 6, 16, 9, 7, 8, 4]
    clear(x)
    x
    []

    Note that neither of these functions requires pass-by-reference; the lst
    local in the function is not the same name as the x local outside the
    function. But since you're basically just passing a "pointer" by value,
    both "variables" still "point" to the same object
    Passing a pointer by value appears to me as passing a var by reference.

    (or in Python terms,
    both "names" are "bound" to the same object). To apply an affect that is
    visible to all names bound to an object, you simply need to mutate the
    object. In the cases above, this is just a matter of using the
    appropriate object method (list.pop or list.__setslice__ respectively
    above).
    Thanks I will try all of that, but what does really means mutating in
    python? It's the first time I hear this word in programming :))
    Dominique
  • Mike Meyer at Dec 12, 2004 at 4:49 am

    "Fredrik Lundh" <fredrik at pythonware.com> writes:

    Mike Meyer wrote:
    It also has a widget for creating Windows "wizards" for walking
    through a set of options.
    Besides the fact that wizards isn't really that great (read Cooper), if your
    toolkit doesn't let you create a dialogue with a couple of buttons and a
    swappable frame, it's not a very good toolkit. (that's very easy, in both
    Tkinter and wxPython. You can probably find ready-made modules on
    the net if you look around a little)
    While I'm not a big fan of wizards, for some applications they are
    just the ticket, as you're walking down a tree of options. Presenting
    the user the options at each node is exactly the way to go. Sure, it
    may be easy to roll your own in TkInter, but in PyQt you don't have to.
    At the python level, slots are just callable objects. At the
    C++ level, slots are magic methods of objects. Signals are usually
    associated with GUI events, but Python can emit them for whatever
    reason it wants. It's possible to connect C++ signals to C++
    slots/signals in Python, meaning that Python won't be involved when
    that signal is emitted.
    That's would of course be a great argument if you didn't have Python.
    (even if Python's slower than C++, it's a lot faster than a user).
    It's still nice to be able to let the C++ code handle it all. After
    all, having the compiled layer do things for you is what makes for
    fast python code.
    PyQt provides a higher level of abstraction.
    Whan what? C++ plus a low level UI API, sure. But Tkinter+Python?
    wxPython+Python? You gotta be kidding.
    No, I'm not kidding. I'm stating my general impression after having
    done programming with both TkInter and PyQt. Note, that's *Py*Qt, not
    Qt.
    I've never tried doing animation in TkInter. Qt provides timer devices
    that you can use to drive animations. I suspect that doing the same in
    TkInter would be noticably more difficult.
    Eh? You don't know how to do a loop in Python? Or register a callback?
    wxPython contains both timers and a low-level graphics API; for Tkinter,
    you the "after" facility and the Canvas; if you need lower-level drawing
    with tighter Python intergration, use the WCK.
    Sure, you can roll a loop together with a sleep and do animation. You
    can throw in threading and queues so you can keep the GUI active while
    you're doing it. With Qt, you tie the timer's signal to the
    object-moving function, and you're done. Since you have to use the
    threaded version to get the same functionality, I'd say noticably more
    difficult isn't an overstatement.

    <mike
    --
    Mike Meyer <mwm at mired.org> http://www.mired.org/home/mwm/
    Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
  • Info at Dec 12, 2004 at 9:52 am
    Hi, I had very bad experience with Tkinter when using input servers(for
    CJK languages like scim, xcin...) on Linux (doesn't work), so you might
    consider this.



    From http Sun Dec 12 10:54:28 2004
    From: http (Paul Rubin)
    Date: 12 Dec 2004 01:54:28 -0800
    Subject: Persistent objects
    Message-ID: <7xis77q1t7.fsf_-_@ruckus.brouhaha.com>

    I've had this recurring half-baked desire for long enough that I
    thought I'd post about it, even though I don't have any concrete
    proposals and the whole idea is fraught with hazards.

    Basically I wish there was a way to have persistent in-memory objects
    in a Python app, maybe a multi-process one. So you could have a
    persistent dictionary d, and if you say
    d[x] = Frob(foo=9, bar#)
    that creates a Frob instance and stores it in d[x]. Then if you
    exit the app and restart it later, there'd be a way to bring d back
    into the process and have that Frob instance be there.

    Please don't suggest using a pickle or shelve; I know about those
    already. I'm after something higher-performance. Basically d would
    live in a region of memory that could be mmap'd to a disk file as well
    as shared with other processes. One d was rooted into that region,
    any entries created in it would also be in that region, and any
    objects assigned to the entries would also get moved to that region.

    There'd probably have to be a way to lock the region for update, using
    semaphores. Ordinary subscript assignments would lock automatically,
    but there might be times when you want to update several structures in
    a single transaction.

    A thing like this could save a heck of a lot of SQL traffic in a busy
    server app. There are all kinds of bogus limitations you see on web
    sites, where you can't see more than 10 items per html page or
    whatever, because they didn't want loading a page to cause too many
    database hits. With the in-memory approach, all that data could be
    right there in the process, no TCP messages needed and no context
    switches needed, just ordinary in-memory dictionary references. Lots
    of machines now have multi-GB of physical memory which is enough to
    hold all the stuff from all but the largest sites. A site like
    Slashdot, for example, might get 100,000 logins and 10,000 message
    posts per day. At a 1k bytes per login (way too much) and 10k bytes
    per message post (also way too much), that's still just 200 megabytes
    for a full day of activity. Even a low-end laptop these days comes
    with more ram than that, and multi-GB workstations are no big deal any
    more. Occasionally someone might look at a several-day-old thread and
    that might cause some disk traffic, but even that can be left in
    memory (the paging system can handle it).

    On the other hand, there'd either have to be interpreter hair to
    separate the persistent objects from the non-persistent ones, or else
    make everything persistent and then have some way to keep processes
    sharing memory from stepping on each other. Maybe the abstraction
    machinery in PyPy can make this easy.

    Well, as you can see, this idea leaves a lot of details not yet
    thought out. But it's alluring enough that I thought I'd ask if
    anyone else sees something to pursue here.
  • Eric Brunel at Dec 13, 2004 at 9:03 am

    info at klubko.net wrote:
    Hi, I had very bad experience with Tkinter when using input servers(for
    CJK languages like scim, xcin...) on Linux (doesn't work), so you might
    consider this.
    Eh? I use (not frequently, I admit...) kinput2 with canna and wnn servers with
    Tkinter on Linux and it works quite smoothly. Can you describe what happens to
    you exactly?
    --
    - Eric Brunel <eric (underscore) brunel (at) despammed (dot) com> -
    PragmaDev : Real Time Software Development Tools - http://www.pragmadev.com

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedDec 11, '04 at 1:08a
activeDec 13, '04 at 9:03a
posts8
users7
websitepython.org

People

Translate

site design / logo © 2022 Grokbase