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

Martin Dobias wonder.sk at gmail.com
Wed Feb 28 06:36:18 EST 2007


On 2/28/07, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch> wrote:
> Hi Martin,
>
> I thought about gui/core plugins again. Although I like the idea from a
> conceptual point of view, I found a problem with it. If we have separation of
> gui/non-gui plugins, then a typical plugin is split into core parts and gui
> parts (in a way similar to e.g. wfsplugin/wfsprovider). But then the gui
> plugin has to know about the corresponding core plugin, and this seems to be
> a problem for portability (see
> http://lists.qgis.org/pipermail/qgis-developer/2006-October/000896.html). It
> works for provider plugins because qgis core does everything related to data
> providers, so the plugin is not directly linked to the provider.

Hi Marco,

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

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

Martin



More information about the Qgis-developer mailing list