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

[Martin Dobias]

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 <lists at borysjurgiel.pl> 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<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.