Making Dynamic Guis

I'll rewrite this more clearly when the api is more clear in my mind... ;-)

We saw before how to design a static gui.
When your gui is static, it means that you can't modify the contents of a list, that you can't add a window (eg a project window, after a click on a 'new' button), and so on.

In other words, we can already do cool things with a static gui, but we'd like to do more

gui blocks

(I took the first word that popped into my mind)

If you think a bit at that problem, you will see that, although a gui can be dynamic, you can always find a finite (and fixed) set of sub-guis so that, at any time, the graphical user interface of your program is made up of a several of these sub-guis, some being present more than once, and some others not at all.

Note that such a gui-block does not need to be in one single window or to be visible. When there is an instance of a gui block, it means that all components of it do exist.

For instance, a typical project-based software is made up of two of gui-blocks:

A gui-block is a static gui and a static gui is one gui-block

Everything that was described in previous chapter can be directely applied as the definition of a gui-block:
A gui-block contains some hard-coded stuff, and some added gadgets, and some notifications between them.

I'll come back on connections between different gui-blocks later

Creating, deleting and addressing a gui block

These are the three things the core must be able to do.

Gui-block hierarchy

Now, we must be able to say that some gui-block is a child of another, e.g. if you have a program where the user can create projects, and where he can create objects inside projects, then the program's gui-block will be at the root of the hierarchy, the project gui-block is a child of the root gui-block, and the object gui-block is a child of the project gui-block.

This implies several things:

With the above example, this means:

Designing the model

When you know what communications the program must be able to do with the user, you look which parts can be duplicated, and decide that way how many gui-blocks you need.
Then, you decide, for each of these gui-blocks, what in, out and inout communications you need. These will be the invisible objects of your gui.
And finally, for each of these objects, you decide what kind of data it must hold. You can be as vague as "just some character string", and as specific as "this very custom class".

Now you've done the job on paper, you will make an Amool class defining that model, i.e. containing the "abstract" definitions of the gui-blocks. This class will ultimately be subclassed to define the final gui.

Designing the core side

This is the tricky part, as it's the only one that mixes Amool and the other programming language.

the main program will have, as childclass, a class describing that model. The superclass of the model will be a gui-system description, which will add to the main program the necessary code for handling that gui (if the gui is hardcoded) or for communicating with the library (if it is external)... I'll explain this in more details after I tell you about the actual Amool api structure...

Here I have two possibilities:

Both solutions look interesting to me, so I'll not make the choice right now (I might keep both; so if the programmer is doing a program that does lots of calculations, then he shall take the first choice, and if he's doing something that responds quickly, then he can keep the second solution.

This means that the programmer, after having designed the model, will code his program like always, but, when communicating with the gui, will only access invisible objects. It might be a good thing to force these communications to go through the library, so that the gui can be really separated (that way we can let the choice of the gui system (mui, gadtools, ...) to the gui-designer)
This will depend on the gui-system the programmer chooses to subclass. If he really requires for instance MUI, then he will set MUI as superclass. If he does not care, then he will take a higher class as superclass

Designing the gui side

This is the funny part :-)

When you are designing the gui of your application, you are making a subclass of the model, simply adding the visible gadgets, making fun with the placements, putting fancy pictures in the gui, making cool notifications between all that stuff...
With the AlMuist's wysiwyg interface, this part should really be a pleasure :-)


Maxime Gamboni
Last modified: Sat Jun 30 20:57:54 MET DST 2001