Re: [Gnumed-devel] switchable layout managers

[Horst Herb]

On Tue, 20 Jul 2004 13:28, Ian Haywood wrote:
> Nevertheless, I would like to rework the plugin loading code somewhat.
> Currently we call gmPlugin.register () to load plugins
> This forced the layout managers to expose a lot of their internal objects
> via gmGuiBroker (). Back in '02 I thought this was rather clever
> (but I was still a medical student then of course), now IMHO
> this interaction should be internal to the layout manager,
> plugin objects just publish their attributes (to wit, name, widget and
> toolbar) which  the layout manager uses as it loads them.

The way mini-gnumed does it:
the main screen is divided into a toprow (to area of screen), a notebookarea 
(left side of screen), an upper and lower toolarea (right side of screen, on 
top of each other.
These areas are separated by resizable borders ("sashes"), the GUI remembers 
the position of the sashes in it's configuration registry.

----------------------------------
|                                                |
|--------------------------------|
|                                 |             |
|                                 |             |
|                                 |-------- |
|                                 |             |
|                                 |             | 
|--------------------------------|

The plugin manager looks forregistry sections "plugins.notebook", 
"plugins.toprow" etc.

In the order plugins are listed in the configuration, they are stacked into 
the corresponding area's sizers (in the case of the notebook, they are added 
as notebook pages).

Plugins KNOW NOTHING about the program itself. The only common denominator 
they have is gmDispatcher through which they can register callback functions 
for events, and gmConnection through which they can get cached authenticated 
backend connections. It is irrelevant whether other modules have hooked up to 
the dispatcher, and irrelevant whether connections already exist (or 
authentication details already entered) - gmDispatcher and gmConnection take 
care of this and KNOW NOTHING about the rest of the application or plugins.

Even the logging module is completely "black boxed"; all it does is receive 
messages from the dispatcher and display/record them as configured.

If Richard's layout is implemented as single notebook page, it can have as 
complex management as it needs to have - as long as it does not directly 
interact with the main framework or other plugins other than via messages 
sent through the dispatcher.

That design is very simple, robust, and I believe even elegant. It s certainly 
versatile enough to do anything I want. And, most importantly, it makes 
writing plugins not only very easy, but also very safe.

Horst