Feature request #4069
Enhancement: ability to search for a plugin to run
|Pull Request or Patch supplied:||No||Resolution:|
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
- Add to the plugin manager the ability to start a plugin.
- 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.
- Combine 1 and 2, i.e. modify the plugin manager to be a dockable modeless window with the ability to launch plugins.
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.
#3 Updated by Nathan Woodrow over 6 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.
#4 Updated by Alister Hood over 6 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.
#8 Updated by Alister Hood over 6 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?
#12 Updated by Martin Dobias over 6 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.
#13 Updated by Alister Hood about 6 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.
#15 Updated by Alister Hood almost 6 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.
#17 Updated by Alister Hood almost 6 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).