> 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 _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
