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

[Marco Hugentobler]

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.

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?

Regards,
Marco 



Am Mittwoch, 21. Februar 2007 14:27 schrieb Martin Dobias:
> On 2/20/07, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch> wrote:
> > > Moreover plugins are connected also with gui library - they
> > > might need to access map canvas etc.
> >
> > I agree with this. Maybe we should have GUI plugins and non-GUI plugins
> > somewhen in future? But for the diagram plugin now, your suggestion below
> > seems to be the best way.
>
> This makes sense. Providers are also an example of non-gui (or 'core'
> ) plugins. That way, also core library should get some kind of plugin
> registry, but it's important to differentiate between the two types of
> plugins (first ones would depend only on core library, second ones on
> both core and gui libs).
>
> Now, when I'm thinking about this again, I see you were right - to
> avoid bad design we probably can't avoid using registry of 'core'
> plugins (it would be good to find a name for them) that would be
> initialized the same way as providers are and once metadata are to be
> read QGIS willl look at plugins registry that will provide read/write
> and some other functions.
>
> This opens the question how to modify plugin registry handling to work
> well with core/gui plugins or core-only plugins, make no difference
> between C++ and Python plugins etc.
>
> Martin
>
> > Thanks a lot,
> > Marco
> >
> > > Martin
> > >
> > > On 2/19/07, Marco Hugentobler <marco.hugentobler at karto.baug.ethz.ch> 
wrote:
> > > > Hi,
> > > >
> > > > In svn head, qgsproviderregistry.h is in core/ directory and
> > > > qgspluginregistry.h in app/ directory. I wanted to ask what the
> > > > reason for this is.
> > > > Backgournd of my question is that I'm trying to restore the diagram
> > > > overlay from project file. For this, QgsVectorLayer needs to have a
> > > > pointer to the diagram plugin (in case it is loaded). From a pure
> > > > technical point of view this is similar to QgsVectorLayer using
> > > > QgsProviderRegistry to restore a data provider from project file. But
> > > > because plugin registry is in app, vector layer is not allowed to use
> > > > it, as code in core should not depend on code in app.
> > > > Is it possible that QgsPluginRegistry could be in core? Or is there a
> > > > more intelligent way of getting the plugin pointer?
> > > >
> > > > Thanks,
> > > > Marco