[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