[Qgis-developer] New Manager - consultation for the best solution

Borys Jurgiel lists at borysjurgiel.pl
Mon May 6 03:52:08 PDT 2013


> Not sure how far you got with the implementation, but for the record I
> would surely choose the solution 2. It is generally a good idea to
> keep core structures separated from Qt model - ideally the model
> should be acting just as an adapter to the core data structure. If we
> decide to change the plugin manager dialog and model, it will not
> affect the way how other parts of QGIS deal with plugins.

Actually there was a concord (well, only a few folks discussed it) we should 
keep the metadata inside manager, as there is no use for it outside, so I'm 
implementing a mixed solution: replacing the messy QgsPluginMetadata and 
QgsPluginItem classes with one robust QgsPluginMetadata, but wih no external 
QgsPluginMetadataRegistry.

It's not very likely other part of QGIS could be interested in plugin metadata 
(except Python plugins, but it's already implemented in PyQGIS).

I leave all the stuff in the src/app directory, what isn't available by API, so 
all communication with Python (eg. adding metadata of available plugins) is 
done by QgsInterface::doSomethingWithManager(). What shhould I do in your 
approac h? Move QgsPluginMetadata, QgsPluginMetadataRegistry to the src/core 
directory? Is it worth the effort? I guess it's the only problem for me to 
adapt your solution. 

Anyway, I'll work on it from Wednesday, so in first step I'll evaluate time 
needed for your suggestion. Considering extremely limited time (both: 
available for me and the delay in QGIS schedule) and the fact I'm not very 
fast in c++ we will see... In the worst case I can go a mixed way to allow 
further improvements without backward API breaks.

Dnia poniedziałek, 6 maja 2013 o 09:54:04 Martin Dobias napisał(a):
> Hi Borys
> 
> (sorry for the lag - I have been on holiday last week)
> 
> 
> Martin


More information about the Qgis-developer mailing list