I am fed up with Python GUI toolkits...

[Kevin Walzer]

On 7/20/11 9:05 AM, rantingrick wrote:
> On Jul 19, 9:44 pm, Kevin Walzer<k... at codebykevin.com>  wrote:
>
>>> 2. Bloatware. Qt and wxWidgets are C++ application frameworks. (Python
>>> has a standard library!)
>>
>> Again, so? This isn't applicable to Tk, by the way. It's a GUI toolkit
>> specifically designed for scripting languages.
>
> Tk is SPECIFICALLY designed for TCL. Tkinter works ONLY by embedding a
> TCL interpreter. You statements are misleading.

Of course I know this--I'm one of the core Tcl/Tk developers on my 
platform. :-) My statement was actually based on Mark Lutz's 
characterization in "Programming Python," when he defends Tk's inclusion 
in the stdlib (and his own book's extensive focus on it) by observing 
that the toolkit was specifically designed for use with scripting 
languages--Tcl at the start, but also Python, Perl, Ruby...he seemed to 
want to downplay Tk's Tcl-ish roots, as if he were embarassed by them. I 
guess it's a Tcl-ish subject.


>>> 3. Unpythonic memory management: Python references to deleted C++
>>> objects (PyQt). Manual dialog destruction (wxPython). Parent-child
>>> ownership might be smart in C++, but in Python we have a garbage
>>> collector.
>>
>> Again, so? Again, this isn't applicable to Tk.
>
> He did not even mention Tk in that block, do you have a TK persecution
> complex?

No, but it's an advantage that Tk has over the other ones, and an 
argument that reinventing the wheel is unncessary.

>
>>> 4. They might look bad (Tkinter, Swing with Jython).
>>
>> Then again, they might not.  A lot depends on the skill of the
>> developer. I write highly polished commercial apps with Tk GUI's. I'm
>> sick of developers blaming their ugly apps on the toolkit rather than
>> their own lack of design training and/or skills.
>
> This is true. Lots of people lack the skill to create professional
> quality GUI applications however lots of GUI devs lack the skill to
> create clean and intuitive API's also. Tkinter/TclTk and WxPython
> \WxWidgets has lots of warts in this respect.

I think what constitutes a "clean API" is partly a matter of taste.

>
>>> 5. All projects to write a Python GUI toolkit die before they are
>>> finished. (General lack of interest, bindings for Qt or wxWidgets
>>> bloatware are mature, momentum for web development etc.)
>>
>> That's right. People issue a clarion call for a new GUI toolkit, then
>> discover that even a so-called "ugly, limited, minimalist" toolkit like
>> Tk has twenty years of development behind it. And people think they can
>> duplicate this effort in a few months by starting a flame war on
>> comp.lang.python?
>
> Just because someone wants to entertain ideas for a new GUI does mean
> they are starting flame wars. I would say out all the responses so far
> YOURS is the most emotional.

*shrug*

Maybe it is. I prefaced this by saying, "OK, I'll bite," which suggests 
that perhaps I shouldn't, because complaints and hand-wringing are 
really a waste of time. In the future, I think my response (if I make 
one at all) will more likely be something like this:

"An interesting idea. Please post back when you have a source code repo, 
build instructions so we can play with your code, a mailing list, and a 
license that is suitable for both open-source and proprietary development."

The most substantial effort at developing a new GUI API for Python did 
just this--PySide (alternative bindings to Qt). No hand-wringing, no 
flame wars, just an announcement of the project, an invitation to 
contribute, and so on. Whether you think it's a misguided project or an 
attempt to reinvent the wheel is beside the point--it's a substantial 
project, with both leadership and a growing community that support 
ongoing development and rapid maturation.

In my own experience, this is the only way to move things forward or 
bring about any useful change--roll up my sleeves and do it myself. I've 
done this a bit with Tkinter (maintaining bindings/wrappers to a popular 
Tk widget, tablelist), but I've done this extensively with Tk itself on 
the Mac. I complained on mailing lists for years that Tk didn't do this 
or that on the Mac, and these complaints fell on deaf ears; finally, I 
decided to dive into the deep end, learn the low-level API's to do what 
I wanted, and bingo! Suddenly Tk did what I wanted.

That's the essence of open-source development--scratching your own itch. 
Sometimes you get lucky and a large corporate entity has an itch to 
scratch, and this can bring large-scale projects with large-scale 
benefits. I believe Nokia is funding PySide. While Tk's port to the 
Mac's Cocoa API was done by a single developer, the project was funded 
by Apple. Creating a new GUI toolkit may require this scale of effort 
and investment. But even without it, if a developer can get something 
started and make enough progress to be of interest to others, then a 
larger community may move the project forward.

Code trumps everything.

>
>>> 1. Lean and mean -- do nothing but GUI. No database API, networking
>>> API, threading API, etc.
>>
>> Presenting...Tk.
>
> True Tkinter does no Database, networking, threading, etc. However i
> would not call an embedded TCl interpreter "lean and mean".

Perhaps not. Creating a pure-Python GUI toolkit that provides native 
integration with X11, Windows, and OS X windowing systems would be "lean 
and mean"--but it would also be a lot of work. And, assuming the project 
went forth to completion, I bet that other scripting languages would 
piggyback on top of it (Lua or Ruby bindings for Python's GUI toolkit, 
anyone?) because doing that is less work than writing your own toolkit 
from scratch.

>
>>> 2. Do as much processing in Python as possible. No more native code
>>> (C, C++, Cython) than needed.
>>
>> And what's wrong with native (ie. compiled) code? Python is written in
>> native code, isn't it? To extend Python in significant ways, it is often
>> necessary to drop down into native code.
>
> I will agree with Kevin here. Hey, he's not ALWAYS wrong you know;
> just most of the time! ;-)

Meh.

>
>>> 6. Expose the event loop to Python.
>>
>> Presenting...Tk.
>
> Tk's event binding (whist quite powerful) is also quite overwhelming
> in the sheer number of event sequences alone and leads to spaghetti
> code. See my recent thread about the subject.

This is a matter of taste.
>
>>> 8. Written for Python in Python -- not bindings for a C++ or tcl
>>> toolkit.
>>
>> Well, that's the holy grail, but given the history of other toolkits,
>> you'll reach a comparable level of maturity in 2031.
>
> I think it could happen much sooner if people got serious. However it
> won't happen tomorrow for sure.

Certainly not.


>>> Is it worth the hassle to start a new GUI toolkit project?
>>
>> Not unless you want to reinvent the wheel yet again.
>
> The old "reinvent the wheel" argument is only valid when wheels
> already exists. Currently we have triangles (or maybe pentagons) but
> no wheels.

Well, I have two closing responses:

"Let's see your code, repo, mailing list, and license."

and:

"I'm bowing out now."

--Kevin

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com