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
(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
For instance, a typical project-based software is made up of two of gui-blocks:
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
These are the three things the core must be able to do.
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:
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.
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:
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
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 :-)