[DotGNU]The Abstract GUI

[Peter Minten]

Hi folks,

mdupont and I talked on IRC today about a way to get rid of the toolkit
incompatibility problem (you can't run a Qt app with GTK) for DotGNU. Mdupont
devised a scheme to place a toolkit independant GUI description in a file and
send it to the client that displays the GUI using it's preferred toolkit. The
following is my implementation of that idea.

First a little terminology:
AGS: Abstract GUI Specification: the spec (for now this email).
AGD: Abstract GUI Description: the file that is send to the client.
AGC: Abstract GUI Converter: the program/lib that converts the GUI description
into a real GUI.

The Abstract GUI system is based on the idea that all popular GUI's share common
elements like textboxes and buttons. Another similarity is that all popular
GUI's are event based. A third similarity is that all popular GUI's use
containers for layout. That's enough similarity for a pretty decent abstract GUI
that will work well on all toolkits.

Now an example of the AGD, simple hello world:
1  <gui>
2    <widget type="vbox"> <!-- Vertical container -->
3      <children>
4        <widget type="label" value="Push the button to quit"/>
5        <widget type="button" name="Button1" value="Hello world">
6          <events>
7            <event name="Clicked">
8          </events>
9        </widget>
10     </children>
11   </widget>
12 </gui>

Line 1 and 10 should be clear, a simple XML root. In line 2 an anonymous vbox is
created to contain the label and buttons. In line 4 a simple anonymous label is
created. In line 5 a button named Button1 is created (a name is needed for
widgets that have events). In line 7 it is declared that when the event Clicked
occurs a message should be send to the server. The rest should explain itself.

When this is send to a client the AGC reads the file, and calls constructors and
other methods to make it show on the client (or it converts to a native GUI file
like .glade first and then calls constructors and other methods). The AGC
however is not responsible for communication between the constructed GUI and the
server, that's done using the normal mechanisms for data transfer between server
and client. That means using the DotGNU client webservice library.

Note that there are only 3 basic containers that can carry multiple widgets (aka
multi-containers), vbox, hbox and tabbook. All other multiwidget containers
(like table) simply use these. There are however many single-containers (widgets
that can only contain one other widget) such as frame.

Note that menu's are supported as part of a widget
(<widget><menu><menuitem>...</menuitem></menu></widget>), but they are displayed
at the top if the widget is top-level (non-contained) or if the right mouse
button is clicked on the widget. In the last case the menu of the parent
(container) of the widget is displayed when the widget does not have one (this
is recursive, it could go up multiple levels).

Note that not all features or widgets in normal toolkits will be supported. The
ground rule for a widget to be included in the AGS is that it should be in all
of the following toolkits: GTK, Qt, FOX, Tk. The ground rule for a feature to be
included in the AGS is that it should be in at least 3 of the aforementioned
toolkits.

The AGS does not know the concept of windows. Everything is a widget and if a
widget does not have a parent, well then it does not have a parent. The AGC
creates a window if needed (running embedded in a window (like in Forum) is also
possible).

And now a short and non-exhaustive list of what widgets will be in the AGS:
* Button
* Checkbox
* Radiobutton
* Label
* Editbox
* HScrollbar
* VScrollbar
* Picture
* DrawArea
* Progressbar
* Statusbar
* Toolbar
* Hbox
* Vbox
* Notebook
* Listbox
* Combobox

Greetings,

Peter