[Qgis-developer] New Manager - consultation for the best solution
I need your advice which direction should we take to store plugin metadata in QGIS 2.x. I started to work on Solution 2, but now I think maybe the first is better? It looks much simpler anyway. I'd be happy to see some response asap, as I'm going to implement it until lunch and go further today... :) SOLUTION 1: The QgsPluginManager is created as soon as application starts and it persists all the application life time. Once it's created, it reads installed plugins to the QListView model (like it used to do now), and then Python (if available) uses QgsPluginManager API to add extra metadata (of available plugins) directly to the model. So QgisApp::showPluginManager() only calls exec() of existing QgsPluginManager instance. SOLUTION 2: The QgsPluginManager only exists within QgisApp::showPluginManager() (like now), so I create a new global C++ data structure for all plugin metadata: QgsPluginMetadataRegistry. When application starts, C++ pushes metadata of installed plugins (both C++ and Py) there, then Python (if available) adds an extra metadata for available plugins. Finally, when an user opens the PluginManager, it has an access to the joined metadata. All filtering is done by QSortFilterProxyModel. In addition, this QgsPluginMetadataRegistry class provides transmitting slots- signals for communication from C++ to Python. For example: because the install procedure stays in Python and the "Install" button is ported to C++, we need a way to connect signal from the C++ button to Python. But in this solution QgsPluginManager is created on user's click, while the Python is already loaded on startup. So first Python (on startup) connects to signal from QgsPluginMetadataRegistry, then the manager (when created) can ping this transmitting slot. I guess it's the simplest way (within solution 2). == Regardless the solution 1 or 2, I'd like to extend QgsPluginMetadata class to make it more multipurpose. Now it's only used internally in QgsPluginRegistry and only contains two fields. I'd add the complete field set (what won't bother QgsPluginRegistry) and use it also as a main metadata item everywhere. Everywhere means: In solution 1 - QgsPluginMetadata as a PLUGIN_DATA_ROLE data in QListView item In solution 2 - QgsPluginMetadata as a base for QgsPluginMetadataRegistry I'd also remove QgsPluginItem class and include its fields into QgsPluginMetadata. So the present state is: 1. QgsPluginRegistry - the registry of loaded plugins. Data are stored in QMap 2. QgsPluginMetadata - a simple class for the map above. It's only used internally within QgsPluginRegistry. It only contains thee fields: name, library and a pointer to the living plugin object. 3. QgsPluginItem - seems it's obsolete and could be easily merged with QgsPluginMetadata. More details: it's similar to QgsPluginMetadata, just contains another fields and is used in one place only: in QgisApp::showPluginManager() to get data from QgsPluginManager::getSelectedPlugins(). The proposed solution: 1. QgsPluginRegistry - leave it as is 2. QgsPluginMetadataRegistry (only solution 2): parallel to QgsPluginRegistry 3. QgsPluginItem - remove it and include its two fields to QgsPluginMetadata 4. QgsPluginMetadata - make it an universal plugin metadata object == In all cases, all the QgsDetailed... classes are not used anymore, and they only stay for GRASS Plugin. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New Manager - consultation for the best solution
Hi Borys (sorry for the lag - I have been on holiday last week) 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. Martin On Tue, Apr 30, 2013 at 12:11 PM, Borys Jurgiel wrote: > I need your advice which direction should we take to store plugin metadata in > QGIS 2.x. I started to work on Solution 2, but now I think maybe the first is > better? It looks much simpler anyway. I'd be happy to see some response asap, > as I'm going to implement it until lunch and go further today... :) > > SOLUTION 1: > The QgsPluginManager is created as soon as application starts and it persists > all the application life time. Once it's created, it reads installed plugins > to the QListView model (like it used to do now), and then Python (if > available) uses QgsPluginManager API to add extra metadata (of available > plugins) directly to the model. So QgisApp::showPluginManager() only calls > exec() of existing QgsPluginManager instance. > > SOLUTION 2: > The QgsPluginManager only exists within QgisApp::showPluginManager() (like > now), so I create a new global C++ data structure for all plugin metadata: > QgsPluginMetadataRegistry. When application starts, C++ pushes metadata of > installed plugins (both C++ and Py) there, then Python (if available) adds an > extra metadata for available plugins. Finally, when an user opens the > PluginManager, it has an access to the joined metadata. All filtering is done > by QSortFilterProxyModel. > > In addition, this QgsPluginMetadataRegistry class provides transmitting slots- > signals for communication from C++ to Python. For example: because the install > procedure stays in Python and the "Install" button is ported to C++, we need a > way to connect signal from the C++ button to Python. But in this solution > QgsPluginManager is created on user's click, while the Python is already > loaded on startup. So first Python (on startup) connects to signal from > QgsPluginMetadataRegistry, then the manager (when created) can ping this > transmitting slot. I guess it's the simplest way (within solution 2). > > > == > > Regardless the solution 1 or 2, I'd like to extend QgsPluginMetadata class to > make it more multipurpose. Now it's only used internally in QgsPluginRegistry > and only contains two fields. I'd add the complete field set (what won't > bother > QgsPluginRegistry) and use it also as a main metadata item everywhere. > Everywhere means: > In solution 1 - QgsPluginMetadata as a PLUGIN_DATA_ROLE data in QListView item > In solution 2 - QgsPluginMetadata as a base for QgsPluginMetadataRegistry > > I'd also remove QgsPluginItem class and include its fields into > QgsPluginMetadata. > > So the present state is: > > 1. QgsPluginRegistry - the registry of loaded plugins. Data are stored in > QMap > > 2. QgsPluginMetadata - a simple class for the map above. It's only used > internally within QgsPluginRegistry. It only contains thee fields: > name, library and a pointer to the living plugin object. > > 3. QgsPluginItem - seems it's obsolete and could be easily merged with > QgsPluginMetadata. More details: it's similar to QgsPluginMetadata, just > contains another fields and is used in one place only: in > QgisApp::showPluginManager() to get data from > QgsPluginManager::getSelectedPlugins(). > > > The proposed solution: > > 1. QgsPluginRegistry - leave it as is > > 2. QgsPluginMetadataRegistry (only solution 2): parallel to QgsPluginRegistry > > 3. QgsPluginItem - remove it and include its two fields to QgsPluginMetadata > > 4. QgsPluginMetadata - make it an universal plugin metadata object > > > == > > In all cases, all the QgsDetailed... classes are not used anymore, and they > only stay for GRASS Plugin. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] New Manager - consultation for the best solution
> 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 Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
