Abstracted GUI APIs (was: RANT: Ruby GUI API)

I'd like to follow up on a thread, and attempt to consolidate some thoughts 
on the topic of abstracted GUI APIs.  When I say "toolkti" below, I'm 
talking specifically about GUI toolkits.

A few months ago, there was a vigorous discussion about the relative merits 
of native toolkits and abstract toolkits.  It sort of petered out, and I 
haven't seen any activity in that area since.

One thing that *n?x users tend to be blind to is the importance of 
cooperation between an application and the desktop.  In my mind, 
look-and-feel is a minor issue compared to how well an application 
integrates with the environment in which it is running.

Consider: StarOffice and KWord.  My wife is an author, and is not what you 
would call a computer afficianado.  StarOffice is a much better word 
processor than KWord (at the moment).  It is more feature complete, and it 
doesn't suffer from the printing problems that plague KWord.  KWord is 
currently WYSI*not*WYG.  Despite this, she uses KWord.  Why?  Because the 
current version of StarOffice/OpenOffice doesn't support copy/paste from 
the X clipboard.  This means she can't copy from Netscape, or Konqueror, 
into StarOffice, and this is unacceptable.

Also consider NeXTSTEP.  Still, in my mind, the best windowing environment 
on the planet.  You could drag and drop from practically any application to 
any other.  It supported complex data types in the clipboard the likes of 
which I haven't seen on any other OS, to this day.  It was /integrated/, 
and it worked fabulously well.  The GUI wasn't complex; the widgets weren't 
multi-hued animated superbuttons, but it was a joy to use.

*n*x users don't see this, because they traditionally haven't had it.  KDE 
and Qt are bringing this to the Linux community, slowly, and I ask you KDE 
users to consider: don't you find yourself trying to find KDE versions of 
your applications, not because they look the same as your other KDE apps, 
but because they integrate better?  They dock, they answer to the window 
manager requests (a-la smart-starting when you log out and in again), and 
so on.  Windows users are more used to it, but they generally tend to think 
of it as an appearance issue.

I propose that the strongest argument for using native toolkits is to gain 
this integration with the user's desktop.  You can emulate look-and-feel, 
but you can't emulate integration.

So the goal becomes one of getting a toolkit through which applications can 
integrate into the native environment, while providing a maximally portable 
API.  This is what SWT attempts to do; it tries to use native widgets, when 
they are available, and provide abstract widgets when they aren't.  In this 
way it provides an API which is portable, but is reasonably lightweight, 
fast, and integrated.  We hope.  As Chris said, SWT hasn't proven the 
concept yet, but as far as I can see, it is the only real hope of getting 
the portable native API.

Any ideal API for Ruby is going to be designed for Ruby, together with Ruby 
method naming scheme, using Ruby iterators, POLS, the whole nine yards.  
SWT may be a good model to look at.  As I've mentioned, a project like this 
is going to be a lot of work, but I believe that it should start with 
defining the API; stubbing out the API, as it were, from a viewpoint of how 
we'd like to use it.

I'd like to start a mailing list specifically for discussing this topic, or 
a separate newsgroup.  I'd be happy to host that, but I'd like to know how 
many people would be interested in contributing to the discussion.  
Ideally, I'd like to see the authors of the existing GUI toolkits for Ruby 
be involved, because they'll know more about the issues and will be able to 
point out things that need to exist for such an API to function.

-- 
--- SER