Tkinter or wxpython?

Chris Mellon arkanes at gmail.com
Mon Aug 6 10:58:34 EDT 2007


On 06 Aug 2007 07:39:12 -0700, Paul Rubin
<"http://phr.cx"@nospam.invalid> wrote:
> kyosohma at gmail.com writes:
> >  I've read that Tkinter doesn't scale well if you're writing complex
> > GUIs. I haven't been able to test this hypothesis though. However,
> > since I had to rewrite VBA apps into Python, to get the right "look
> > and feel" I needed the widgets that wxPython provided. Since I started
> > out with C++, I find wxPython better than Tkinter, but it's all pretty
> > subjective. Try them both!
>
> Tkinteger (dang, I always end up typing it that way, I won't even
> bother fixing the error) is easy to use for simple gui's, and it's
> part of the standard python distro which for me is a big advantage (no
> extra crap to download).  However, the widget set is rather ugly and
> doesn't blend in well with anyone's native widgets; the widget
> selection itself is rather narrow, and I think kyosohma may be right
> that it doesn't scale well to complex gui's.  I've looked at the code
> for IDLE's gui and it's terrifying.
>
> At this point I think nobody should write desktop gui apps without a
> good reason.  There is a fairly flexible and easy to program gui
> already running on almost every desktop, namely the web browser.
> Before you write a gui using some client side toolkit, ask yourself
> whether you can instead embed a web server in your application and
> write an HTML gui.  That approach is not always the answer, but it has
> considerable advantages when you can do it that way.

Some disadvantages of the web based platform:

No native look and feel - constrained by the browser.
No control over browser UI idioms. I had to write this post twice
because the text control lost focus and I hit backspace, going back in
the history and losing my work.
No native integration - no "open file", no "browse the filesystem", no
rich drag and drop, no copy/paste.
No or poor dialogs. Poor multiple window support.
More platforms to develop on and test with.
Limited to CSS box model for layout.


You can mitigate some of these constraints if you *require* the local
web browser technique, rather than supporting local or remote access.
You can mitigate more if you write your own browser host (along the
lines of the dashboard in OS X), but then you get to write 3
applications instead of one.

The web is a terrible application platform. There is not a single web
application in existence which has even half the UI functionality of a
rich client application. There are some (even many) applications for
which the benefit of global access and easy deployment makes up for
the lack in functionality, but statements like "At this point I think
nobody should write desktop gui apps without a good reason" are simply
ludicrously misguided.



More information about the Python-list mailing list