[Qgis-developer] Re: question about location of providerregistry and pluginregistry

[Marco Hugentobler]

Am Mittwoch, 28. Februar 2007 16:28 schrieb Martin Dobias:
> You're right that usage of signals/slots make the code flow harder to
> track. And probably the best would be to avoid them completely in core
> library. I hope we could find some nice design patterns which are
> well-suited for this situation.

The observer pattern seems to be a perfect replacement for signal/slot (see 
below)

> One thing that comes to my mind is the usage of some of hooks. Let's
> say we have a set of actions that might happen - loading a project
> file or rendering progress notification might be one of them. When
> plugin gets initialized, it might register itself to some actions.
> Once an action happens, it goes through the list of hooked plugins and
> calls them. Implementation could be done as a hooks registry which
> will register and deregister the plugins for different actions. The
> hook would be an interface, that would be implemented by the plugins
> e.g.:
> class QgsHookProjectRead
> {
>   void hookProjectRead( params ) = 0;
> };
>
> I don't have much knowledge in design patterns but if the amount of
> hooks won't get big, this might be good solution.

This is a good idea. It reminds me of the 'observer' pattern in the design 
patterns book. Observer classes (in QGIS the plugins) may register at a 
subject class and they get notified by the subject when something happens. 
The book discusses several variations and it will be interesting to see what 
suits best for plugin notification.


Regards,
Marco