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

[Borys Jurgiel]

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.