Tkinter vs. wxPython?

[SeeBelow]

Do many people think that wxPython should replace Tkinter? Is this
likely to happen?

I ask because I have just started learning Tkinter, and I wonder if I
should abandon it in favor of wxPython.

Mitchell Timin

--
"Many are stubborn in pursuit of the path they have chosen, few in
pursuit of the goal." - Friedrich Nietzsche

http://annevolve.sourceforge.net is what I'm into nowadays.
Humans may write to me at this address: zenguy at shaw dot ca

 

[Doug Holton]

Do many people think that wxPython should replace Tkinter? Is this
likely to happen?

I ask because I have just started learning Tkinter, and I wonder if I
should abandon it in favor of wxPython.

Could you share a little more info, like are you new to GUI programming,
what platform do you develop on (windows, mac, linux), and what features
do you need for your application.

If you this is your first time using a GUI toolkit I'd recommend
sticking with Tkinter. It is simpler to use and there is much more and
better documentation since it has been a standard part of Python for a
long time.

But myself I use wxPython because it has more features.

 

[Andrei]

Do many people think that wxPython should replace Tkinter? Is this
likely to happen?

From my POV it would be a good idea since I don't use Tkinter/Tkinter apps
but I do use wxPython. However, I don't think it will happen because things
out of the standard distro don't get phased out that easily; programs count
on Tkinter being there. Plus Idle would have to be removed as well, which
is not very likely to happen since it's the standard Python IDE .

I ask because I have just started learning Tkinter, and I wonder if I
should abandon it in favor of wxPython.

If you like Tkinter, use it. If you like wxPython, use that - neither of
them shows any signs of going away in the near or not so near future. BTW,
there are several nice GUI builders for wxPython available which might be
of assistance in using wxPython. Personally I prefer wxPython and I avoid
Tk-based apps whenever I have an alternative, which is basically always .

--
Yours,

Andrei

=====
Real contact info (decode with rot13):
(e-mail address removed). Fcnz-serr! Cyrnfr qb abg hfr va choyvp cbfgf. V ernq
gur yvfg, fb gurer'f ab arrq gb PP.

 

[Peter Milliken]

wxPython will not "replace" Tkinter (IMO ) if you mean that Tkinter will
become a dead letter. Tkinter was first, has much support through add-ons
such as Pmw and is still the most extensively documented Python GUI. It
builds on the broadbase available through the Tcl/Tk community and provides
many more resources than I could find for wxPython.

I originally wrote a small app using Tkinter, then attempted a rewrite in
wxPython ("lunch time" exercise in both cases so this activity literally
spanned years! ) . I don't claim to be a GUI programmer BTW

The main reason I started down the wxPython conversion path was I wanted to
be able print on a Windoze platform and wxPython seemed to offer an
interface that would achieve that. I can't really remember what "went wrong"
but I abandoned the wxPython conversion and went back to using Tkinter -
however, I did keep the print code that I developed and actually communicate
via TCP/IP to that "app" from my Tkinter app with print instructions and the
stream of text to print. I think the sticking point with wxPython was I was
unable to achieve the same key binding flexibility that I had achieved
through Tkinter - I'm sorry, I really can't remember what exactly it was. I
remember some extreme frustration though getting my head around the
different model that wxPython offered

Having said all that, I have a background in Tcl/Tk (probably 7 years ago
now, I wrote a small GUI app in Tcl/Tk and then re-wrote it in Ada/Tk). I
have a GUI book for the Tcl/Tk and then purchased Grayson's Tkinter GUI book
when I moved across to Python - I find reading a much simpler way of
learning . I was unable to find an published work on wxPython and whilst
the mailing list is helpful it just wasn't the same as solving a problem by
using one of more books as reference I haven't remained in touch with
the wxPython community, but last I heard, that book on wxPython was still in
the "real soon now" category

I find the Tkinter/Pmw combination very powerful - much of my later
additions to my small GUI app have used Pmw and inheritance extremely
heavily and I am exceptionally pleased at how re-usable some of my GUI
classes worked out - I saved some significent work on at least one GUI page
by small class modification and re-use. Tkinter builds on the efforts of
another large group of individuals - the Tcl/Tk people. Whereas, dare I say
it?, the wxPython effort is based on the efforts of a much smaller group of
individuals, leaving you often to puzzle through wx reference
documentation - and it ain't easy to learn something from reference
documentation!

So my personal recommendation would be to stick with the Tkinter approach,
there is more documentation available (you can even read books based on
using Tk with Tcl that will help you to learn and "solve" those GUI problems
if you can't find a solution from a Tkinter book ) and I believe there
are more Python users of Tkinter from which you can request help if you find
a sticking point.

Just my thoughts on the topic

Peter

 

[Roger Binns]

Do many people think that wxPython should replace Tkinter? Is this
likely to happen?

I ask because I have just started learning Tkinter, and I wonder if I
should abandon it in favor of wxPython.

wxPython comes with a demo which includes sample code for almost all
the different controls. I would recommend looking at the demo (and
sample code) to see the scope of wxPython. The sample code will
give you an idea of how readable the code is.

In the end I used wxPython because I wanted things like printer
support.

Roger

 

[Heiko Wundram]

Am Dienstag, 27. April 2004 23:06 schrieb Peter Milliken:

I haven't remained in touch with
the wxPython community, but last I heard, that book on wxPython was still
in the "real soon now" category

There's a german book on GUI Programming with Python, which covers Tkinter,
wxPython, PyQT and PyGTK+ 2... I actually liked the read, the author creates
a lightweight contact management program in each of the four, and discusses
step by step how the functionality is implemented, showing the differences
between the event handling code in each of the four, etc.

You might wonder how he achieves to go through all four different programming
environments in a single book, but I think he manages quite well to keep it
simple and short, and showing relevant links to the available documentation
where it is needed as a starting-point for further projects.

Anyway, if anybody's interested:

Name: Python und GUI-Toolkits
Author: Michael Lauer
ISBN: 3-8266-0844-5
Publisher: mitp-Verlag
First published in 2002 (I have the first edition, IIRC there's a second
edition out already)

I can only recommend to have a look at this book if you speak german,learn
easily from example, and would like to get insight knowledge on
GUI-Programming with Python...

Heiko.

 

[SeeBelow]

Could you share a little more info, like are you new to GUI programming,
what platform do you develop on (windows, mac, linux), and what features
do you need for your application.

If you this is your first time using a GUI toolkit I'd recommend
sticking with Tkinter. It is simpler to use and there is much more and
better documentation since it has been a standard part of Python for a
long time.

But myself I use wxPython because it has more features.

I'm mostly a C programmer, with a little Python experience. I have only
basic needs for GUI and graphics. The Tkinter set of widgets seems
adequate for my needs, although one never knows for sure what ones needs
might be.

Portability is important. My audience is 50/50 linux and Windows
people. I myself use Win 2000.

Ease of learning is important to me. I have only a little experience
with GUI and graphics programming. I keep using the phrase "GUI and
graphics" because I need graphical output from my programs, not just a
GUI to control them.

Mitchell Timin

--
"Many are stubborn in pursuit of the path they have chosen, few in
pursuit of the goal." - Friedrich Nietzsche

http://annevolve.sourceforge.net is what I'm into nowadays.
Humans may write to me at this address: zenguy at shaw dot ca

 

[Mark 'Kamikaze' Hughes]

I'm mostly a C programmer, with a little Python experience. I have only
basic needs for GUI and graphics. The Tkinter set of widgets seems
adequate for my needs, although one never knows for sure what ones needs
might be.
Portability is important. My audience is 50/50 linux and Windows
people. I myself use Win 2000.
Ease of learning is important to me. I have only a little experience
with GUI and graphics programming. I keep using the phrase "GUI and
graphics" because I need graphical output from my programs, not just a
GUI to control them.

For ease of learning and portability, and if you don't need 60fps
videogame speed, Tkinter blows anything else for Python away. Pick up
John Grayson's _Python and Tkinter Programming_
<http://www.manning.com/grayson/>, and don't look back.

I wrote Umbra, a pseudo-3D computer RPG, in Python with Tkinter.
While it has problems, it works. Two years ago, I attempted to rewrite
it in PyQT, which was a total failure. Last year, I attempted to
rewrite it in PyGame, which works and is faster, but requires an immense
amount of extra code to accomplish the same tasks.

However, Tkinter works well enough that it's not a big issue for
applications other than games. Drawing on a Tkinter canvas is not as
slow as you'd expect, though it's fairly limited. The image support is
terrible (especially since the cropping function from Tk has never been
implemented in Tkinter, and the maintainers don't seem to give a damn),
but PIL sort of fills the gap, if you don't mind learning yet another
API and converting back and forth (which is slow).

I've written a few toy apps in wxWindows^WwxWidgets, and it's really a
pain in the butt, on par with PyQT for doing things its own way instead
of the Python way, and of course there's bugger-all in the way of
documentation.

Distribution of any of the alternative GUI toolkits with Python apps
is a pain. It can be done, but it's extra work in packaging, and more
potential problems for end-users, that you don't have with Tkinter.

The GUI experience on Python is inadequate. I love Python for
server-side tasks, but I will never write another serious GUI app in it
until/unless it gets a better standard GUI, preferably something built
on top of PyGame.

 

[Josiah Carlson]

For ease of learning and portability, and if you don't need 60fps

videogame speed, Tkinter blows anything else for Python away. Pick up
John Grayson's _Python and Tkinter Programming_
<http://www.manning.com/grayson/>, and don't look back.

Generally, people do best with the GUI toolkit that fits their mind. I
tried learning Tkinter and failed miserably. On the other hand, in a
few hours with wxPython, I had developed something I found useful.
Since then, I've developed 10-15 useful (to me anyways) apps using
wxPython in a very short amount of time.

In terms of the Tk vs. PyQt vs. PyGTK vs. wxPython vs. etc., I urge
everyone to give Tk 3 hours, wxPython 3 hours and perhaps PyQt or PyGTK
(if they are available on your platform) 3 hours. After getting a taste
for them all, it should be relatively easy to decide which fits your
mind better. All of this "mine is better than yours" bullshit isn't
even worth the few kbytes they are stored in.

- Josiah

 

[Jason Harper]

The image support is
terrible (especially since the cropping function from Tk has never been
implemented in Tkinter, and the maintainers don't seem to give a damn),

Easily fixable from the Python side:

def subimage(src, l, t, r, b):
dst = PhotoImage()
dst.tk.call(dst, 'copy', src, '-from', l, t, r, b, '-to', 0, 0)
return dst

Jason Harper