QGIS » QGIS Application

I think a searchable tree with groups would be pretty easy and user friendly for this. At least with a tree there is no real limit and you can show just want is needed vs nested menus which never feel good to me.

Yes, good idea.

What do you think about implementing this into the plugin manager, rather than having a fifth list of plugins (1=installer, 2=manager, 3=menu, 4=toolbar)?

I think it would be very workable and powerful to have them all in one tree. The installer, manager, and current installed. The installed ones just look like normal tree items in groups, the ones disabled but installed can be grayed out and the ones to be installed could be grayed out and have a little down arrow (or some kind of arrow to show it as a download).

A one stop shop for plugins basically.

Thoughts?

Yes, I was going to suggest combining the installer and the manager, but I decided it was OK keeping them separate, since the installer isn't something that is run frequently (say multiple times a day), and it is reasonably complicated.

Someone would need to think hard about how to organise all the features.

e.g. where would you put all the information that is shown in different columns in the installer? Maybe the author, version and repository could go in a plugin "properties" dialogue (or even a tab).

The options and properties tabs from the installer could possibly be combined into one.

I guess even if the installer and the manager were kept separate, either they should both use a treeview or neither of them should.

The disadvantage of a treeview with groups is that you don't have column sorting ability like in the plugin installer, which is quite handy. In a way I think adding a "category" column would be better.

Another thing that might be useful is an overlay in the corner of the plugin icon to indicate its status e.g. out of date (maybe an exclamation mark) or only available locally (maybe a question mark).

This is a problem very cloese to that in GRASS plugin modules. I would encourage having solutions common to both (at least at GUI level), for consistency of the user experience.

Yes, maybe there should be a discussion on the developer list about this in relation to the processing framework.

In a way it might make sense for individual Grass/Saga/OTB/OSSIM modules to be treated as if they were separate plugins. Or for some (or most?) standard plugins to be rewritten as modules for the processing framework.

There is also the issue of how much grouping there should be e.g. see the processing framework screenshots at http://underdark.wordpress.com/2011/06/04/a-first-glimps-at-the-qgis-processing-framework/
Should it just be Vector/Raster/Database/etc, or should it be more specific?

BTW, does anybody have the processing framework manager with some modules actually installed? I don't have any modules installed as the Python bindings available for Saga don't work with the OSGeo4W Python version. I'm guessing that thing above the treeview is for actually launching a module - it isn't a filter, is it?

Alister,
Regarding the sorting: TreeViews in Qt are able to have columns and are sortable.

So what happens to the groups when the sort splits them up? I don't think I've ever seen that.

Or does it sort within each group? That wouldn't quite be the same.

Just some random thoughts:

• QGIS does not keep information which plugin creates what menus / menu items and toolbars / toolbar buttons, so it is not possible to say to QGIS "run this plugin!" - it does not know what to run
• It is possible (also for a plugin) to enumerate menus and toolbars and create a tree widget that would be searchable and could trigger the actions. See customization dialog for inspiration
• combining plugin manager and plugin installer is something we (Borys and me) talk about every hackfest :-) it is doable, but needs some effort
• most of the plugins seem to be processing plugins, so in future they should be rewritten to use processing framework. That would lower the amount of bloat in toolbars and plugin menu.
• organization of plugins: there is no clear way how to organize hundreds of inhomogenous tools (together with some more or less homogenous libraries like saga). Categorization would be nice, but it is extremely hard to provide a set of categories that would fit everyone. Some modules fit well into multiple categories. IIRC we have decided for tags in processing framework. Each plugin can introduce zero or more processing modules, each module might have some tags. Tags can be hierarchical so they can be shown in a tree.

Also see #4395

Regarding Martin's explanation that QGIS does not know how to run a plugin, and the idea of enumerating menus and toolbars to create a searchable widget. This would be nice, but I guess it might be overkill, especially if a lot of plugins are rewritten to use the processing framework. What do you think about this alternative idea:

- A lot of plugins have an "about" page. The plugin system could be changed so that instead of plugin authors implementing their own "about" pages (as many do currently), there is a standard "about" page, build from the plugin metadata, and accessible from the plugin installer/manager.

- There could be a policy that plugin authors should explain on the "about" page where to find the plugin in the QGIS gui.
e.g. "XYZplugin provides the ability to do xyz in QGIS, and can be accessed from the Vector menu".
Or "WXYplugin adds a WXY tool to the standard digitizing toolbar".

This would mean the search capability in the plugin manager/installer would be sufficient to find out how to run a plugin, even though it wouldn't provide the ability to search for a plugin and run it directly.
It would also reduce gui clutter caused by plugins being put in submenus just so that they can also provide an "about" page in the submenu.
The "about" page should also provide any needed links to a plugin's website, tracker etc.

Sorry - I referred to #4394, but it should be #4395

With regard to having an improved, combined plugin manager and installer:

On Windows I've encountered "dependency hell" with several plugins, worked around by reverting to older plugin versions. It might be good to make it work more like the OSGeo4W installer - allowing the user to revert to an older plugin version, and instead of having a button to "update all", having a button to select all updatable plugins to be updated, after which the user can unselect a particular plugin they don't want to update (before clicking a button to actually do the updates).

If plugins are ported to sextante where appropriate this will probably no longer be necessary.

Borys Jurgiel wrote:

I guess this ticket is (and will be) only applicable to Processing plugins.

No, it is specifically about plugins, not processing algorithms or scripts.

As now Processing is implemented, is the ticket still valid?

If everybody was writing processing algorithms instead of plugins then it wouldn't be necessary. I think the only plugin I've seen that also add tools to the processing toolbox is Crayfish, and if I use "Get scripts from on-line scripts collection" from the Processing toolbox there are only 47 available (I had to count them as it doesn't tell you the total).
There are currently 754 (non deprecated) plugins available in the official repository!

Got it.

Alister, Doesn't the new locator bar (on the status bar) help find them?