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

[Martin Dobias]

On 2/28/07, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch> wrote:
> Hi Martin,
>
> > I think this has some possible solutions:
> > - implement shared stuff in a library and let core/gui plugins link to
> > it - this seems to work with GRASS provider and plugin
>
> This works, but it has the disadvantage that for each plugin there must be a
> piece of code in qgis core. This does not fit well with the idea of plugins.

Actually it doesn't have to have a piece of code in qgis core - that
shared library can be distributed separately. But I would also prefer
the second option.


> > - or another possibility is to develop an interface for core plugins
> > that would be versatile enough that it could be used by other parts of
> > QGIS (or other plugins) without the need to use directly the class
> > you're working with. As there's interface for providers which we can
> > consider as core plugins, there might be more interfaces for plugins
> > with different purposes.
>
> You mean to have e.g. a plugin interface for analysis plugins? I prefer this
> possibility over the first one.

Yes I mean there should be a different interface for every kind of
functionality that could be implemented by plugins. So plugin will
specify which interfaces does it implement and for every implemented
interace it will have a factory method which will create the object
and return the pointer to the interface. This means that also when one
plugin would want to use functionality of another plugin, it will ask
for the interface and will get it (or won't get it if the plugin is
not available).


> > > For the diagram plugin I found a solution how to read from xml without
> > > plugin registry. I used the signal QgisApp::projectRead(), which gives
> > > plugins the possibility to read plugin specific settings from project
> > > file. The plugin creates the diagram overlays and adds it to the
> > > corresponding vector layers (they can be accessed through
> > > QgsMapLayerRegistry). A problem with this approach is the notification of
> > > the legend that the layer symbology has changed. I created the method
> > > QgisInterface::refreshLayerSymbology(QString) for this. Maybe there is a
> > > more elegant solution for it?
> >
> > I think more elegant solution might be to let map layers emit a signal
> > when they think their symbology has changed. Legend can connect itself
> > to this signals and change itself appropriately when signal has been
> > emitted. Do you like this idea?
>
> Ok, this has the advantage of keeping the interface for plugins cleaner. On
> the other hand, too much signals and slots create dependencies which are not
> explicitly visible in the program code. And this makes a program harder to
> understand. In QGIS, I find myself often doing 'grep -r -n slotname * | grep
> connect' to find out what's going on. Or I have to place a debbuger
> breakpoint to see by which signal something has been triggered. In both
> cases, it would be easier to see a method call in the program code.

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.

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.

Martin