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

[Marco Hugentobler]

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.

> - 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.

> > 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.

Regards,
Marco