From: Sean Russell <ser@...>
Date: 2002-01-23T09:32:56+09:00
Subject: Re: Abstracted GUI APIs (was: RANT: Ruby GUI API)

Horacio L�pez wrote:

> I am not sure I am following you.
> Is the idea to create a discussion space towards tighter integration
> of existing toolkits ?

No, I'd like to see the discussion result in an API discription which all 
(or most) of the toolkit maintainers can agree on, that satisfy their 
requirements.  Any Ruby binding to a lower-level toolkit is basically an 
artifical API layer on top of a library.  The actual API used is more or 
less arbitrary, with certain restrictions based on the widgets available 
and (usually) driven by the underlying library's native API.  For example, 
you'll find a lot of toolkits adopt the naming scheme of the original 
toolkit's language, so you get things like:

  addButton()

rather than the more Ruby-esque:

  add_button()

My assumption is that, given an arbitrary GUI library, you can design the 
Ruby API that uses it with a fair amount of freedom.  Based on this 
assumption, I'd like to design the API *first*, and then write the binding 
to the underlying libraries later.

To put it another way: the Ruby API becomes the standard GUI API, the 
contract between with the authors who use the GUI toolkit and the 
underlying libraries.  If someone wants to add wxWindows library support to 
Ruby, they would craft their binding so that it follows the Standard Ruby 
GUI API.  Ideally, then anybody could dynamically bind any application 
written with the Standard Ruby GUI API to the new toolkit, without 
rewriting the app.  It would mean that if you wrote a GUI app, the User 
would be able to choose the toolkit it runs on, as per their preference.

This is the goal, whether it is attainable or not is to be seen.  There is, 
obviously, a number of people who believe that even attempting this is 
folly, and a waste of time.  I believe that the possibility that it *is* 
possible is large enough, and the benefits of such a resulting system are 
great enough, that it is worth a shot.

> Are you thinking of integration of future applications, or
> bringing tight integration to legacy applications ?

I don't care about legacy applications.  There aren't that many legacy Ruby 
applications that use a GUI anyway.

> Are you thinking of a common GUI API for Ruby, sort
> of  Java's Swing ?

More like SWT, or a cross between Swing and AWT.

First and foremost, I want the API itself to be clean and like Ruby: fun to 
work with, intuitive, easy.  Secondly, I'd like it to be detatched from any 
particular library, so that if I use KDE, you use Gnome, and Albert uses 
Windows, that you could choose the GTK backend, I could choose the Qt 
backend, and Albert could choose the Windows backend, and we'd all get nice 
integration with our desktops.

> I am interested on all these ideas, and discussing them,
> it's just I don't see clear goals.

I can only talk about my own goals, but you are right.  It would be useful 
to define a charter for such a discussion.  Primarily, I'm afraid of 
swamping the people in this NG who Don't Give A Damn about this issue, or 
people like Albert who think it is a waste of time.

--- SER