Marco, I can merge the new plugin installer tonight if your happy with that. I'm not sure I will merge the SIP stuff in just yet but I will review and see where to go from there.
Regards, Nathan On Wed, Jun 5, 2013 at 5:09 PM, Marco Hugentobler < [email protected]> wrote: > Hi Nathan > > I'm away today and can merge earliest late evening or probably in the > morning. > Alternatively, to not block your progress with the new API, you could do > the plugin manager merge / SIP update / python part update and the const > things can be easily added later. > > Regards, > Marco > > On 05.06.2013 08:53, Nathan Woodrow wrote: > > Marco, > > As Borys is away would you be able to merge it tonight. I can then > merge the SIP update once that is done, just need to check the status. > I'll take care of updating the python part of the installer to the new API > once it's merged into master. > > Regards, > Nathan > > > On Wed, Jun 5, 2013 at 4:48 PM, Marco Hugentobler < > [email protected]> wrote: > >> Hi Borys >> >> I tested the newpluginmanager branch and I must say the new plugin >> manager / installer is really a great user experience. And it is good that >> the plugin manager also works without the python bindings (handy e.g. in >> the server case). >> Codewise, I have few suggestion on detail level: >> >> QgsPluginRegistry: isLoaded(), isPythonPlugin(), isPluginCompatible() can >> be const >> >> QgsPluginManager: pluginMetadata() returns a pointer to the map. This >> function should be const and return either const pointer or a copy (kind of >> similar issue like recently with the layer registry) >> >> It might be worth thinking if QgsPluginRegistry should be in core and >> accessible by third party apps / plugins. Like that it would e.g. be >> possible to use functions from one plugin in another and load the required >> plugin if not already there. The plugin registry could also emit an unload >> signal to notify the dependent plugin. I'm not 100% sure it is a good idea, >> but maybe it would be handy for sextante (e.g. WPS plugin requires a loaded >> sextante)? >> >> All in all great work. I'm proposing that you merge the branch to master. >> >> Regards, >> Marco >> >> >> On 27.05.2013 14:23, Borys Jurgiel wrote: >> >>> Hi All, >>> >>> The new manager is ready. Here is a screenshot for impatient ones :) >>> http://tmp.borysjurgiel.pl/manager4.png >>> >>> The code is in a branch "newmanager": >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771 >>> >>> As it affects a number of classes, please review the architecture summary >>> below and if there is no veto, it's ready to be merged to master. >>> Otherewise I'll >>> make requested changes before merging. >>> >>> >>> *QgsPluginItem* >>> ========== >>> Removed. It only used in the old manager and wasn't usefull anymore. >>> >>> >>> >>> *QgsDetailedItemData, QgsDetailedItemDelegate and QgsDetailedItemWidget* >>> ========== >>> Untouched. It was used in the old manager and Grass Plugin, now it's used >>> exclusively by Grass Plugin. >>> >>> >>> >>> *QgsPluginMedatadata* >>> ========== >>> Untouched, however I propose to rename it to QgsPluginItem or >>> QgsPluginRegistryItem >>> for consistency. It's only used in QgsPluginRegistry and it mainly >>> conatains >>> pointers to loaded plugins instances, while its name may imply a rich >>> metadata >>> map. If some day during QGIS 2.x lifetime the Manager will need a >>> separate class >>> for storing rich metadata (now QMap is enough), and it would be nice to >>> use this name. >>> >>> >>> >>> *QgsPluginRegistry* >>> ========== >>> Info: This class is a registry for instances of lodaded plugins. It has >>> nothing to to >>> with metadata and it works independently from the manager, just by >>> restoring >>> session plugins from QSettings. Manager only calls its method to load >>> and unload plugins. >>> >>> Small change: as it already had methods loadCppPlugin() and >>> loadPythonPlugin(), >>> I've added also unloadCppPlugin() and unloadPythonPlugin() too keep the >>> loading/unloading stuff in one place. >>> >>> Diff: >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/diff/src/app/qgspluginregistry.h >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/diff/src/app/qgspluginregistry.cpp >>> >>> >>> >>> *QgsPluginManager* >>> ========== >>> Completely rewritten and moved to src/app/pluginmanager/ subdirectory >>> class for the dialog window. Important facts: >>> >>> 1) It keeps plugin metadata registry just in nested QMap: >>> QMap< QString, QMap<QString,QString> > mPlugins; >>> >>> where the first key is library/module basename, and the second one is >>> attribute >>> name. There was no need to create a separate class for storing metadata, >>> however, some day it may become convinient to create a class called >>> QgsPluginMedatadata. >>> For this reason I propose to rename the current QgsPluginMedatadata >>> (what actually has nothing to do with metadata) before releasing QGIS >>> 2.0. >>> The list of used attributes is provided in the "metadata" file and it's >>> an unification >>> of existing fields from repository xml, metadata.txt, the old installer >>> and c++ plugins. >>> QgsPluginManager populates this field (let's call it metadata registry) >>> with >>> c++ plugins when the window is opened. On the contrary, Python plugins >>> are handled on Python's side and they are appended to mPlugins by API. >>> >>> 2) The plugin list view uses QStandardItemModel populated from mPlugins >>> and also QgsPluginSortFilterProxyModel for filtering and sorting. >>> >>> 3) The html metadata browser is quite simple, and we can extend it in >>> QGIS 2.1. >>> For example, some tags can be clickable and set a new filter (filter by >>> clicked >>> author/tag/status). Also the separate buttons Install/Uninstall can be >>> implemented by html "buttonsm", and the popup dialog with installation >>> progress >>> can be replaced by animated image (this way we don't freeze the gui when >>> installing). >>> >>> Code: >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/entry/src/app/pluginmanager/qgspluginmanager.h >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/entry/src/app/pluginmanager/qgspluginmanager.cpp >>> >>> >>> >>> *QgsPluginSortFilterProxyModel* >>> ========== >>> New class: just a sort-filter proxy for the metadata. Filtering is done >>> by status >>> in the left list as well as name/description/tags/author in the filter >>> input line. >>> Sorting is done by rightclicking on the list. Foltering and sorting is >>> based >>> on a few user data roles. I tried to read necessary data from mPlugins >>> everytime, >>> but it affected the performance too much. >>> >>> Code: >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/entry/src/app/pluginmanager/qgspluginsortfilterproxymodel.h >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/entry/src/app/pluginmanager/qgspluginsortfilterproxymodel.cpp >>> >>> >>> >>> *QgsAppPluginManagerInterface, QgsPluginManagerInterface and SIP binding* >>> ========== >>> New classes: just the interface to QgsPluginManager. Is's exactly based >>> on the existing Qgs(App)LegendInterface >>> >>> Code: >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/entry/python/gui/qgspluginmanagerinterface.sip >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/entry/src/gui/qgspluginmanagerinterface.h >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/entry/src/gui/qgspluginmanagerinterface.cpp >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/entry/src/app/pluginmanager/qgsapppluginmanagerinterface.h >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/entry/src/app/pluginmanager/qgsapppluginmanagerinterface.cpp >>> >>> >>> >>> QgisApp >>> ========== >>> Small change: initialize the QgsPluginManager and Python module >>> pyplugin_installer in the constructor. Only open the QgsPluginManager >>> window >>> when called from the main menu. >>> >>> Diff: >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/diff/src/app/qgisapp.h >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/diff/src/app/qgisapp.cpp >>> >>> >>> QgisAppInterface and QgisInterface and SIP binding >>> ========== >>> Small change: instantiate Qgs(App)PluginManagerInterface >>> exactly the same way as Qgs(App)LegendInterface >>> >>> Diff: >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/diff/src/app/qgisappinterface.h >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/diff/src/app/qgisappinterface.cpp >>> >>> >>> >>> pyplugin_installer Python module >>> ========== >>> New python module in python/pyplugin_installer. It contains just >>> slightly refactored >>> code of the old plugin_installer plugin and provides backend for >>> handling Python >>> plugis, e.g.: fetching remote repositories, loading installed plugin >>> metadata, finding >>> upgradeable plugins, (un)installing python plugins etc. It's methods are >>> called from >>> QgsPluginManager and it calls QgsPluginManager methods via >>> QgsPluginManagerInterface. >>> >>> Code: >>> >>> http://hub.qgis.org/projects/quantum-gis/repository/revisions/5ee09d362148c411047a0fc7bc22679d9989f771/show/python/pyplugin_installer >>> >>> >>> _______________________________________________ >>> Qgis-developer mailing list >>> [email protected] >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >> >> >> -- >> Dr. Marco Hugentobler >> Sourcepole - Linux & Open Source Solutions >> Weberstrasse 5, CH-8004 Zürich, Switzerland >> [email protected] http://www.sourcepole.ch >> Technical Advisor QGIS Project Steering Committee >> >> >> _______________________________________________ >> Qgis-developer mailing list >> [email protected] >> http://lists.osgeo.org/mailman/listinfo/qgis-developer >> > > > > -- > Dr. Marco Hugentobler > Sourcepole - Linux & Open Source Solutions > Weberstrasse 5, CH-8004 Zürich, [email protected] > http://www.sourcepole.ch > Technical Advisor QGIS Project Steering Committee > >
_______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
