Re: Notebooks in Gtk+ v1.2.x

[Carlos Pereira <carlos pehoe civil ist utl pt>]

> Please tell me more of your architecture.  I can think of several
> instances where my drawing areas need to be independent ( plug-ins,
> design details, seperate models).  As such a master-master architecture
> might work well for my purposes.

I will try (sorry if I couldn't reply earlier) ;-)

First two examples:

- i) when I launch the app, window A is created
ii) from window A, I create window B
iii) I remove window A, the result is, window B keeps 
working exactly as if it was the first window to be launched.

- B windows A and B (for example created from window A)
are working simultaneously. The progress bar in the
status_bar might be moving forward in window A while
is moving backward in window B, (and this is just
out of the box, without threads, etc.)

windows A and B are exactly the same and truely
independent, the only think that they have in common
are the OpenGL pre-compiled lists, which are shared
among the various OpenGL drawing areas, and the app
general resources, that are common to all the app
and are stored elsewhere. Windows A and B are as 
independent as, say, molecules A and B, or lights
A and B.

Local tasks occur in the window where they were
required, Global tasks, to occur in all windows
(or in a different specific window) can be required
from a single window.

-----------------------------------
About the architecture:

I have one object, which has the name of the program,
which contains global data (how many rgb bits per
pixel? what is the scren width and height? what
are the default atomic masses? etc.etc.) and
start and end pointers to dlists listing separately
each class of objects, separately (so, it has window_start
and window_end, layer_start and layer_end, etc...)
Of course there is only one instance of this object.

All the other objects can have as many instances
as required (most OpenGL implementations put a
limit for the number of lights used simultaneously,
but as the number of transparent layers is unlimited,
in practice an image can be drawn with unlimited
lights). Each object contains data that it
needs for itself and start and end pointers to
dlists listing all its direct child, which
in turn, will contain its own data and pointers
to its child, etc. Some classes of objects are
recursive, so for example a text object can
own another text object.

Window objects, only have one possible child,
which is layers, so we have window->layer_start
and window->layer_end.
A window object must store its own data, for example
the address of its gtk window, when it goes full
screen it needs to save its origin and size, to
restore the initial conditions, etc. (if different
windows could have different gtk themes, this
would be the place to save this information).
Each window must also keep track of the dialog
windows that were opened fom it, to remove them
if necessary, among other things.

Each layer in turn must have its own data
(what is the background color for this
layer? is it visible to outside and to inside
or not? what are the projection and viewing
(camera) parameters?), plus pointers to each
class of child objects that are owned by this
particular layer, for example layer->light_start
and layer->light_end, layer->graph_start
and layer->graph_end

etc. for all the objects

Almost everywhere, connecting signals with
the data gpointer pointing to the window object
is a safe, clean, easy, way to handle information,
because actions will take place automatically in 
the right window and you know exactly the window 
where you are, from where you can in turn get all
the information you need for that window (including
dialogs opened from that window, which in turn might
have data attached with the set_data/get_data gtk mechanism), 
and down the hierarchy, for all its child.

Everytime you need information that is above the windows
in the hierarchy (say, the user wants angles printed with
how many decimal figures? this kind of information, for
example to print in a dialog, must be saved only once, 
therefore above windows in the hierarchy), then you need 
to access the singleton global object, either saying that 
this object is the direct parent of the windows (an elegant 
and simple solution) and pointing to it everytime 
a new window is created, or through a global variable, the 
only global variable that in these circunstances the program 
might have (in this case I strongly suggest to call this 
global variable the name of the package itself, is elegant 
and very easy to maintain), that is available everytime 
a given header is included, for example.

Carlos