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<QString, QgsPluginMetadata> 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 [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
