Re: [rgui-user] project proposal

[Tom Sawyer]

On Thursday 12 December 2002 06:06 am, Thorsten Roggendorf wrote:

hi, thanks for writing. i am interested in your idea. though i haven't fully 
grasped it. i'm starting to see what you getting at. please explain the 
following in more detail and common denominator terms as possible.

> I'd like to propose a new paradigm for a hypothetical toolkit project:
> The client programmer has to provide one interface definition. The
> meta-API backends then automatically generate the interface required in
> the current context: parameter file (or registry) evaluation,
> commandline parameters passed on execution start, a full fledged command
> line interface, a GUI *or* a CORBA/COM/(what does KDE use?) interface,
> or an (language binding?) API.
> Usage of these interfaces can be combined: Another application can start
> the program as a component (e.g. using CORBA) and ask it to start
> another interface (e.g. the gui) which the calling application then
> embeds somewhere.

going on what i beleive you to be saying...i wonder, have you read the GUtopIa 
mailing list archives? they haven't been active for a few months b/c i have 
been "out" so to speak. but i have returned to the project just recently and 
am starting to work on it again. anyway, the archives contain some 
interesting dialog on "meta" interface definitions. some thoughts were shared 
on the idea of allowing the meta-API (GUtopIa) to generate interfaces kind of 
like you're suggesting and in such a way that one dosen't have to specify 
specifically what gui widgets to use but rather more general definitions, 
like Mutliple-Selection-List, or On/Off-Switch, etc. and the meta-API could 
determine exactly which widget to use based on some other general parameters, 
like screen real estate, etc.

you've taken the notion a bit further. i like that. what you are mostly 
talking about is the "high-end" side of what GUtopIa is all about. i'm glad 
to hear you're interested in it. you should chat with Massimiliano. he too 
was very interested in that side of things.

there is presently a "debate" though with the "low-end" of things. the 
question remains on where to focus our energies in this regard. one of the 
things i would like to see is a pure ruby gui. the closest thing we have at 
this point is Wise. but Wise is not cross-platform b/c it depends on XLib. i 
have asked Kero, the developer of Wise, to port Wise to GGI and FreeType but 
he isn't really concerned with doing so. but i'd really like to see that 
happen, and have started playing with doing it myself. of course, Wise is 
just another backend. but we need a Prime Target Backend to be the standard. 
all other backend developers reference this one. this primary backend we can 
be sure works 100%. other backends might only work 98%, 95%, etc. b/c of 
feature differences. know what i mean?

currently GUtopIa's meta-API is the "mid-point" between the "high-end" and the 
"low-end". we haven't defined the "high-end" yet and have only expiemented 
with the "low-end". you are right though, it does use the GUI methaphor which 
could be tricky for CLI implementations. perhaps then this middle ground 
should be done away with? we would elevate the API definition to a much 
higher-level like you say. instead of defining widgets, like a DropdownList, 
or ListBox, we'd define higher-order "things" like Single_Selection_Set. from 
there our "super-meta-api" would generate a backend-neutral implementation 
that the backends tap into to. and we would create a reference specification 
for the backends to implement. as for the low-end, i could move the GGI-Wise 
project to a seperate sub-project of GUtopIa as the target platform. i.e. the 
backend that we develop internally. it will be left to other developers to 
create other backends, using Gnome, KDE, CLI, COM+, or whatever.

so what do you think?

thanks for you input, by the way. you have really stirred some interesting 
thoughts for me. and you are giving GUtopIa some better direction. i'm 
excited about your idea!!!

-transami (tom)