[Python-3000] Requirements for a standard GUI library

[Talin]

I'm afraid I'm going to have to blow the dust off of one of my pet 
rants, this one concerning the design and implementation of GUI toolkits.

As someone who is familiar with about 20 different GUI toolkits (not 
including the half dozen or so that I've created for various projects), 
I've formed a number of fairly strong opinions about them.

The first think you notice about GUI APIs is that, well, there's a lot 
of them. It seems that this is one of those areas that programmers just 
like to play in.

(I like to say that "whenever a programmer gets the urge to create their 
own programming language, the first thing they should do is lie down on 
the couch until the feeling passes." [Sadly, I don't remember the source 
of this quote.] The same advice could be given to writers of user 
interface systems.)

Another thing that I notice is that a lot of the APIs out seem to have 
been created using the following process:

   1) Start with a programmer who has never used a really good GUI API,
      but who has lots of experience with one or more of the really bad
      APIs such as Motif, Win32, xtk, and so on.

   2) Working within that paradigm, make heroic attempts to clean up
      and improve the API, without actually ever questioning the
      whole architectural approach of what they learned.

The result is a design that appears to its designer (and anyone else 
familiar with the original, badly-designed API) as a fantastic leap 
forward, but doesn't look so great when compared against a really 
top-notch API.

To avoid starting a potential flamewar, I will refrain from stating my 
own personal opinions as to the quality of specific GUI toolkits out 
there. I will, however, list what I believe are the qualities that make 
an API great:

  - It should follow the UI conventions of the specific platform that 
it is running on. Ideally, the user should not be able to tell that this 
is not a native-written application. This includes not only widget 
appearance, but subtle details of spacing, focus, selection, tab 
navigation, and so on.

  - If there are platform-specific features that are not available on
all platforms, it should attempt to fill the gaps with custom code
that brings the various platforms up to the same standard.

  - It should leverage the standard modal dialogs for that platform - 
color picker, font picker, file open dialog, etc. If, for some reason, 
the platform's implementation is deemed inadequate, the replacement 
should be a superset. (For example, when using the file open dialog in 
OS X, I rely a lot on the ability to be able to type the first couple 
letters of a file name to scroll down to that file in the list; having a 
program which creates its own file open dialog, but doesn't support this 
feature, annoys me greatly.)

  - It should support the accessibility features of the host platform, 
including things like mouse wheel scrolling, special keyboard modes, and 
so on. Most times this can be supported fairly easily by using native 
widgets wrapped in a platform-neutral API.

  - It should support a rich set of widget types. The standard set of 
GUI widgets (including more exotic types such as combo boxes, tree 
views, grids, etc.) is essentially a visual language which has evolved 
over time. Users expect certain kinds of data to be presented in certain 
ways; To say that elements such as combo boxes are unecessary is like 
saying that keyboards don't really need a 'q' key.

  Of course, one can claim that the purpose of the toolkit is to 
intentionally diverge from the standard, so as to faciliate evolution of 
the visual language; This is a laudable goal, but such a toolkit should 
be labeled "experimental", and should not claim to be part of a standard 
library.

  - The toolkit should support tooltips (if that is standard for the 
platform), drag and drop (ditto), and the system clipboard. For extra 
credit, floating tool palettes and dockable toolbars are very handy to have.

  - The toolkit must have a clean system for distributing and handling 
event notifications. This is an area where many toolkits fail to measure 
up. Event notification should be simple, yet there should be a powerful 
delegation model (I believe the terms "capture" and "bubble" to describe 
various strategies of message delegation are coming into vogue) that 
allows for notifications to be inherited, messages distributed based on 
the current focus state, and so on.

  Remember that every UI (including the web) is essentially an event 
sieve hooked to a display system; At least 50% of the job of the UI is 
to classify incoming user events and transform them into higher-level 
application events.

  It is also a plus if the event system is debugger-transparent, which 
is to say that it should be possible to display events in the debugger 
and make some sense out of them. Being able to add a generic event 
tracing function, either on a per-widget basis or globally, is also 
quite useful.

  Also, it should be possible to separate the UI from the application, 
in a classic "Model View Controller" architecture. Ideally, you should 
be able to drive the underlying application from a variety of 
interfaces, ranging from a GUI to a command shell.

  - It should support one or more forms of dynamic layout. The simplest 
type of layout is the AWT style "top-down" layout, in which each parent 
determines the size and shape of its children, subject to the childrens' 
minimum size constraints. A more sophisticated, two-pass "bottom-up" 
layout system (I think that XUL supports something like this) allows the 
children to influence the size and shape of the parent.

  Ideally, the dynamic layout should be user-extensible, so that new 
layout policies can be added.

  - It should support data-driven creation of UIs. Personally, I am in 
favor of XML-based formats, simply because I like to be able to tweak 
the files by hand occasionally. I'm also into machine-generated UIs, but 
that's another story. However, there are many other viable alternatives
besides XML.

  Conversely, it should also support purely procedural creation of UIs. 
I've seen some toolkits that only allowed UIs to be loaded from a file.

Finally, I would say that anyone attempting to create a GUI toolkit
should be familiar with a variety of the standard GUI APIs out there.
I would suggest that familiarity with Qt, XUL, and either Java/Swing
or .Net/Windows.Forms (I prefer the latter, but it's a matter of
taste) would give enough breadth of experience to begin to approach
the problem.

-- Talin