[rgui-dev] Re: [rgui-user] project proposal

[Thorsten Roggendorf]

Hi,

I sent this mail to transami (is your name really Tom Sawyer?) and the
gutopia-dev since transami was the only one to respond on the
guitopia-user list.

> please explain the 
> following in more detail and common denominator terms as possible.
> 
> > [...]

Program code has interfaces. These interfaces come in six major forms:
- Execution Parameters
- Command Line Interfaces
- Parameter Files
- Grafical User Interfaces
- Application Programmer Interfaces
- Component Definitions (CORBA ...)

Three of these look very similar: parameter files (XML), component
definitions (e.g. CORBA) and (object oriented) APIs.
All these interfaces can be implemented in an object oriented fashion
... and usually are in modern applications. GUIs are actually pretty
similarly structured. Execution parameters and CLIs are usually pretty
flat. That's due to these applications usually being pretty old
fashioned and procedural. But there is no reason these could not be
organized in a similar fashion.
When all these interfaces look so similar, why then has a programmer to
decide in advance what's the best solution for a program? Why not let
him define the interface in an abstract manner and let the user decide
how to use it? That would not only give more choice to users, it would
also give them more power. It makes a lot of sense for many programs to
depend on parameter files. But for users learning all the parameter file
syntaxes is a pain in the ass. And adding GUIs to common configuration
tasks is also a lot of work. A project written with an abstract
interface definition would automatically feature a GUI-editor for its
parameter files.
I think the most important part are the APIs and Components though.
Components (or DLL APIs) are manifest UNIX philosophy for modern
systems. They are the next generation pipes. They enable the open source
community to approach projects which huge scopes. Being able to embed
every program as a component opens immense perspectives for future open
source projects. I think if everything is (also) a component, projects
will start to automatically break down into resuable sub projects.


> 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.

Ugh no, obviously I haven't. Well ...


> 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.

Meanwhile I've spend some more thoughts on the issue. I think the GUI
metaphor is probably indeed the best, because GUIs require more
information then other interfaces (the visual layout). I think it is a
good idea to take as much of the layout work from the user. But if the
user wants to do it himself, one has to let him. And it's probably for
now impossible to abstract the power of the canvas into some meta
language. Thus it remains to force good (nested) design on users through
the API. A closer look at GUItopia might reveal, that it already does
this.


> there is presently a "debate" though with the "low-end" of things. Wise is 
> just another backend. but we need a Prime Target Backend to be the standard. 

I agree completely. I do think that ultimately the target backends
should be gtk2, QT and MFC, but one needs to be realistic for now ;-)
I also think full look&feel integration with a given environment is of
minor concern than full functional integration. Thus Wise sounds like a
reasonable choice. Supporting specific component models and parameter
files has a higher priority than supporting various widget sets.


> 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?

I think CLIs are not all that important. If they turn out to be a
problem, I'd suggest to simply deprecate them. If one has parameter
files, GUIs and component interfaces all at the tips of one's fingers,
that would be a worthwhile achievement. I would focus on these. If it
turns out that CLIs can be brought in with just minor design changes,
fine. Bring them in. But don't adapt everything to an obsolete
technology. The other types of interfaces should have a higher priority.
As I wrote above, I am currently tending more toward the GUI-metaphor
because it contains everything needed for other interfaces, plus
everything needed for GUIs. It might still be necessary though, to
reorganize the API, to allow better integration with other forms of
interface (parameter file, component, API ...).


> 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 

Well, this does also sound very promising ... I have think more into
that direction, before I can comment.

  Cheers

    Thorsten