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 fine...it 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 bug...at 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.)