Print Story Python GUI frameworks
By ucblockhead (Sat Dec 05, 2009 at 03:35:29 PM EST) (all tags)
In which I whine about Python UI Toolkits

Last week I expressed my dissatisfaction with the flash card programs I've been able to find.  My reaction, as someone with some knowledge of programming, was to write my own.  In theory, this shouldn't be too difficult as the programming involved with what I want to do is fairly straightforward.  I need a simple GUI that can take text input, show multiple choice buttons and time user input.  This is the sort of stuff that could have been done with the Windows 1.0 dev kit.  Hardly rocket science.  Yet a few hours after I'd started the project, I hadn't even been able to select a tool, much less start.

I've moved to the Mac, and want something portable, so the obvious choice for this sort of thing is a scripting language.  My first thought was Python and TkInter.  I know Python well, and it is hard to get simpler than TkInter which, when combined with the fact that both come, by default, on OSX, seemed to have made it a no-brainer.  So I spent five minutes putting up a test app and got this:

TkInter text controls apparently don't allow Japanese input.  It's actually a bit sillier than that.  I can paste non-roman text just just won't let me type it directly, making it all useless for the app I am trying to write.  I found this immensely puzzling because every other application I've ever used works perfectly with the OSX IME.  I had assumed this was all built into the OS, and so wonder how they could have even made this fail in this way on purpose.

And so yet another project descends into where every project seems to go about an hour after it is started.  Googling for "why won't $X work".  After an hour of research, I find a number of buried forum posts implying that this is a known problem.  (Buried in other links to forum posts asking about the failure, which are, of course, left unanswered.)  These forum posts are all years old, so from what I understand, this is a bug, and since TKInter is a mostly dead project (in that no one is working on it) it isn't going to be fixed.

Bloody typical.

Here we have something that is important enough to include with the OS, but not important enough to actually finish.  It's another instance of the more generic problems with GUI frameworks.  None of them are ever finished.  They are always 85-95% done.  The reasons why depends on whether the project is Open Source or proprietary.

Open Source projects as a whole are rarely ever completely finished as the developers generally get bored and wander away when things mostly work.  In theory, whoever has a problem is supposed to swoop in and fix it.  In practice, this rarely happens, as projects either become orphans, or become the province of a small set of owners who have to be talked into any change.

Proprietary software suffers from much the same problem, though it is caused by entirely different motivations.  No one makes money on that last 10%, so libraries tend to be "good enough".  It is often more profitable for them to create an entirely new replacement library than to put the final polish on the old one.  Microsoft is absolutely the worst offender here.  There are significant failings in the original Win32 API which weren't fixed...instead MFC was created, and then partially replaced with ATL, then everything was replaced with .NET.  In every case, the failings of the old library are never fixed, and so you end up with multiple libraries with overlapping uses and unfixed issues.

The next most popular GUI toolkit for Python appears to be wxPython.  I've used wxWidgets before, but I have not been particularly impressed with it.  What happened this time was exactly what happened last time, when I tried with C++.  I spent hours wrestling with panels and boxes and sizers trying to get buttons where I wanted.  This is perhaps understandable...there always an a learning curve.  More annoying is this:

Portable toolkits never seem to really work.  Some take the "look like ass everywhere" approach of having the exact same look and feel everywhere.  Others, like wxPython, try to use the native OS's look and feel.  This is good, but it magnifies the workload, and so it ends up looking like ass on the platforms the developers don't care as much about.  The clipping problem above seems to be a least, all the panels have enough of a border, etc.

The third OSX way to get a GUI on Python appears to be PyObjC.  Unfortunately, this seems to involve doing the GUI in ObjectiveC and connecting to it with Python.  This seems to involve a whole level of complication beyond what I was hoping to avoid by using Python in the first place.

There's also QT, but I've used it in C, and don't like it's model at all.  In the end, I will probably just stick with wxPython.  It looks like ass, but I it appears that it will work, and who cares if it looks like ass anyway.  It just bothers me that here we sit in 2009 and no one has yet made a GUI toolset that's as clear and easy as writing a command-line program.

...or maybe I'll just make an AJAX app instead.

(cross-posted here.)

< Ting tang, wallawalla bing bang | Night out, with friends >
Python GUI frameworks | 7 comments (7 topical, 0 hidden)
PyObjC probably isn't that big a deal by fluffy (2.00 / 0) #1 Sat Dec 05, 2009 at 07:05:06 PM EST
You'd use Interface Builder to build the UI, Python to write your model code, and have a tiny tiny amount of ObjC to glue it all together.

i.e. I'd recommend you try PyObjC before you assume it sucks.

Or just do it as a web app, yeah.

busy bees buzz | sockpuppet revolution
In some ways I'm kind of heartened to see that ... by lm (2.00 / 0) #3 Sat Dec 05, 2009 at 09:47:55 PM EST
... things haven't changed much on the ground since I was looking at tool kits some 10 years ago.

Kindness is an act of rebellion.
Smalltalk!? (nt) by ucblockhead (2.00 / 0) #4 Sun Dec 06, 2009 at 12:20:55 PM EST

[ucblockhead is] useless and subhuman
Well by ucblockhead (2.00 / 0) #6 Sun Dec 06, 2009 at 10:21:07 PM EST
I think I'll stick to languages people actually use.
[ucblockhead is] useless and subhuman
[ Parent ]
everything was replaced with .NET. by wiredog (2.00 / 0) #7 Mon Dec 07, 2009 at 08:20:24 AM EST
No. Everything was wrapped with dotNet. Good in the case of COM, tolerable otherwise.

Earth First!
(We can strip mine the rest later.)

objustuseperl [nt] by debacle (2.00 / 0) #8 Mon Dec 07, 2009 at 12:29:17 PM EST


s/per/java/ by Dr H0ffm4n (2.00 / 0) #10 Thu Dec 10, 2009 at 09:57:49 AM EST

[ Parent ]
Python GUI frameworks | 7 comments (7 topical, 0 hidden)