[rgui-user] project proposal

[Thorsten Roggendorf]

Hi, 

I'd like to propose thinking about a project, that is somehow related to
GUItopia. This Email consists of six parts: 
- Where did I get the idea? 
- What does it have to do with GUItopia? 
- What's the idea now? What's the potential? 
- First ideas on how to approach the problem
- Pitfalls, Gotchas and other Maladies
- closing remarks 


Where did I get the idea? 
^^^^^^^^^^^^^^^^^^^^^^^^^ 
I am working on a simulation of six legged walking machine in a
university. The simulation is parameter file driven. For some time now
(about two years) I am thinking about adding a GUI to the app. I did not
really have the time or the motivation to start coding on it though.
About two weeks ago, I started coding. The thing that got me started was
the first release of the ruby bindings for the gnome2 stuff which
intrigued me. My gui will heavily depend on the gnome2-canvas. 
I started digging through the heavily loaded api and started creating my
own meta-api for common tasks that I would face, especially regarding
the canvas: making canvas-items interactively movable and furnishing
them with popup-menues and mouse over tooltips. 
My design goal was maximal simplicity of usage. I wanted all that
overhead flexibility taken from me and put in useful defaults. The
ultimate aim for something like that would be to preserve all the
flexibility but don't show it to client programmers if they don't need
it. 
When I had some usable code I asked on the ruby-gnome2 list if they had
a place where such wrappers could be thrown - a kind of toolbox for
beginners or RAD. They pointed me to GUItopia and locana. 


What does it have to do with GUItopia? 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
I looked at GUItopia and was stunned. The interface design is of amazing
beauty and functionality. The use of mixin modules "reminded" me of how
I add popup, tooltip and movable functionality to my canvas-items.
GUItopia shines by having a couple of interface-concepts unified and put
into the big picture in a consistent manner. I think the potential of
wrappers like this is enormous. You got the interface right and that's
why I'm writing to you. I think, that idea might be yet extendable,
though. 


What's the idea now? What's the potential? 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
Today every bozo can code a gui when he brings some persistence and
chooses the right toolkit for his skills. A couple of years ago this was
quite different. Gui programming was in the arcane realm of advanced
programmers. GUItopia tries to bring gui programming to yet more people,
which in itself is a great feat. 
But todays coding problems have moved on from guis. All major desktop
environments that are here to last feature a couple of things: gui
toolkits, registry like fascilities for parameter storage *and*
components (COM, bonobo ...). Successful projects on all Desktop
environments usually use the whole power of these features. But
especially the components still remain arcane arts. I don't think that
has to be this way. 
Ruby does have the potential of bringing that power to less skilled
hobbyist programmers. The GUItopia interface design points in the right
direction. 
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. 
If such power could be brought to unskilled hobbyist programmers, the
impact on free software could be very significant. That, I assume, was
the original intention of the people who developed free component models
(e.g. Gnome and KDE). The problem with these projects is, that the
C-APIs are far beyond the grip of unskilled programmers. Ruby has the
potential to change that and GUItopia points out the direction to go.
.NET (MONO) tries to achieve something a bit similar, but it's still in
its infancy and I doubt it will bring salvation to free software. Even
today many, many Gnome projects spring up that don't use C but Python -
for obvious reasons. We know ruby can do a better job. 


First ideas on how to approach the problem 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 
The proposed paradigm requires substantial effort to implement. I don't
think everything required could be achieved by a single person or a
small developer team. Some important tasks are already started or even
partly complete in GUItopia though: 

- usage of simple yet extremely powerful programming language that can 
  be easily learned by unskilled programmers and is fun to provide 
  motivation for hobbyists 
- complete seperation of API-frontend and implementation backends 
- implemention of some backends (for GUIs) 
- definition of a clean and simple API that's accessible to unskilled 
  programmers 

What remains to be done: 

The API might have to be changed. The API needs to use an abstract
metaphor that can be used to describe any kind of interface. GUItopia
currently uses the GUI-metaphor. Maybe that is no bad choice. I don't
see yet how the GUI metaphor can be translated into a command line
interface, but I think it can already be easily translated into a CORBA
(or COM or ...) interface: A checkbutton is a setter method for a bool,
an entry is a setter for anything, a scale is a setter for numeric
values. Buttons are method calls that make the app perform some action
and so on. 
But maybe the GUI-metaphor produces too much overhead. One idea is to
assume that every interface can be represented in a tree like fashion: 
- class inheritance trees for CORBA/COM/(...) and APIS 
- packing hirarchy trees (packing stuff into nested containers) in GUIs 
- commonly known command line interfaces usually represent very shallow 
  trees since they come from procedural programmers - I don't think that
  has to necessarily be that way, though. 
The task of e.g. a gui backend would be, to do the right thing for the
right tasks. Think LaTex for gui layout. The task of creating the actual
gui (or any other interface) is taken completely out of the hand of
client programmers, which is a good thing (tm). Let programmers express
their ideas and let "professionals" care about gui layout. There are
layout guidelines for Gnome, KDE and Windows. One could even imagine
different layout backends for different environments that makes the app
fit in seamlessly everywhere. 
But if that is possible, then what is all that "overhead" in common gui
APIs meant for? I think much or most of that "overhead" is necessary to
provide flexible interfaces that adapt to the needs of users. 
Thus the whole trick would be to provide a general, abstract (treelike?)
interface definition that can dynamically change (!). What GUIs do is
just show that part of the interface to the user that he currently needs
and to hide stuff that could potentially harm the application in the
current context. These dynamics are useful in complex applications but
they should be optional for simple ones. That would also be a very
useful paradigm for all other interfaces (think error mesages for CLIs
and exceptions for Component models and APIs), and can in principle be
expressed in an abstract fashion that does not rely on the GUI metaphor.
Maybe the best Metapher would be ruby itself. Any common interface
structure (treelike or otherwise) can be expressed in ruby. Ruby also
includes all major higher abstraction mechanisms in modern programming
languages (except for dedicated functional programming, but even that
can be achieved). And Ruby presents them in a coherent fashion. The job
of the meta-API would then be to force good design on the client
programmer, without taking too much flexibility from or imposing him to
learn too much new stuff for using the API. The API could provide a
collection of base classes from which to derive interface elements, plus
modules to provide common functionalities. The interface definition
would start with one instance of some class (the toplevel window or the
"main" class of the CORBA/COM/API/... interface. That instance would
nest other Elements (accessible data and methods). The job of the client
would be to order the interface in a treelike fashion. He can use the
provided functionality from the API-provided base classes and modules to
bind callbacks to events in the interface. The API must also provide
infrastructure to seperate the interface from the program core.
This would allow programmers to express interfaces in the most natural
fashion possible (at least natural for programmers).
 I think it can be done in Ruby, but in few other languages ... if at
all. 


Pitfalls, Gotchas and other Maladies
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The task of implementing such an idea can be broken down into three
mission critical parts:
- designing a useful API
- implementing the interfaces
- bringing the implementation to a usable performance
The whole thing stands or falls with the API. If the API is good, the
project can succee - otherwise not. The implementation is a huge task
and the performance issue makes it huger yet. I think the only sensible
way to cope with a task of such dimensions is, to implement everything
in ruby until there is a working system. The system must then be
profiled and performance critical parts ported back to C/C++. When
designing the original ruby implementation, one should stick with
conservative design and always keep in mind that the thing one is
currently coding might have to be backported. The system should be
broken down into as many independent parts (components?) as possible.
Achieving complete unification of interfaces is probably not possible. I
think object oriented (treelike) command line interfaces might not be a
bad idea at all. But it's probably difficult to interpret the whole
power of e.g. CORBA interfaces as a GUI. How do you pass three arguments
to a method (= button) on execution?
And yet again: The presumable effort of implementing such a huge system
makes the project look broken right from the start.


closing remarks 
^^^^^^^^^^^^^^^ 
I am not a professional in any IT stuff. My programming skills and my
experience are pretty limited. Something like the proposal above may
have been proposed before. If so, what became of it? I know the scope
and effort of implementing something like this is huge. I doubt that it
can be done. I am not sure if the potential is as great as I assume it
to be. The thing just came to my mind and I wanted to hear other
people's opinions. You are here because you feel a need for something
like GUItopia. My proposal takes GUItopia to another level. The new
reading would be "Grand Unified Interface topia". That's why I'm asking
you of all people to express your opinions. 


  Cheers 

    Thorsten