Feature request #4069

Enhancement: ability to search for a plugin to run

Added by Alister Hood over 5 years ago. Updated over 4 years ago.

Status:Open Start Date:07/10/2011
Priority:Normal Due date:
Assigned to:- % Done:


Target version:Future Release - Nice to have
Platform:All Resolution:
Platform version: Pull Request or Patch supplied:No
Status info: Tag:


Problem description
Quoting from an old ticket: "With the explosion of QGIS plugins, people will eventually have so many plugins that it would get hard to find them in the Plugin menu or Plugin toolbar."

"eventually" is now!

This is particularly a problem when a plugin is not grouped into one of the categories (e.g. "analysis" or "vector"), and its name is different from the label of its menu entry e.g. "shaded relief" vs "DEM relief shader".

In the plugin manager and the plugin installer there is a "filter", which allows the user to search for a plugin to install/uninstall or enable/disable it. It would be good if there was also somewhere where the user could search for a plugin to run it.

Possible Solutions
  1. Add to the plugin manager the ability to start a plugin.
  2. Implement something like #1734: "Use a dockable tabbed window for plugins", and include a filter. Personally I don't like the idea of an array of buttons (a list like the plugin manager would be better), and rather than category tabs it may be better to have a single list of plugins, with the ability to filter by category.
  3. Combine 1 and 2, i.e. modify the plugin manager to be a dockable modeless window with the ability to launch plugins.
  4. ?

The need for this would probably be reduced significantly if #1602: "Grouping plugins in the menu" was implemented, i.e. if all plugin developers put their plugins into category submenus.


Updated by Nathan Woodrow over 5 years ago

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.

Updated by Alister Hood over 5 years ago

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)?

Updated by Nathan Woodrow over 5 years ago

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.


Updated by Alister Hood over 5 years ago

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.

Updated by Alister Hood over 5 years ago

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.

Updated by Alister Hood over 5 years ago

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).

Updated by Paolo Cavallini over 5 years ago

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.

Updated by Alister Hood over 5 years ago

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?

Updated by Nathan Woodrow over 5 years ago

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

Updated by Alister Hood over 5 years ago

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

Updated by Alister Hood over 5 years ago

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

Updated by Martin Dobias over 5 years ago

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.

Updated by Alister Hood over 5 years ago

  • Pull Request or Patch supplied set to No

Alister Hood wrote:

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

Oh I see. What you would probably do is something like the "Rule grouping" radio buttons in the rule-based renderer - "No grouping", "Group by filter" and "Group by scale".
In this case it could be a drop-down box or something, which allows you to group by any of the columns.

Updated by Alister Hood over 5 years ago

Also see #4395

Updated by Alister Hood over 5 years ago

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.

Updated by Alister Hood over 5 years ago

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

Updated by Alister Hood over 5 years ago

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).

Updated by Giovanni Manghi over 5 years ago

  • Target version set to Version 1.7.4

Updated by Giovanni Manghi almost 5 years ago

  • Target version changed from Version 1.7.4 to Version 2.0.0

Updated by Alister Hood almost 5 years ago

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

Updated by Pirmin Kalberer over 4 years ago

  • Target version changed from Version 2.0.0 to Future Release - Nice to have

Also available in: Atom