Enhancement: ability to search for a plugin to run

[qgib]

Author Name: Alister Hood (@AlisterH)
Original Redmine Issue: 4069

Redmine category:gui

---

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 Use a dockable tabbed window for plugins #11794: "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 #11662: "Grouping plugins in the menu" was implemented, i.e. if all plugin developers put their plugins into category submenus.

[qgib]

Author Name: Nathan Woodrow (@NathanW2)

---

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.

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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

[qgib]

Author Name: Nathan Woodrow (@NathanW2)

---

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?

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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.

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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.

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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

[qgib]

Author Name: Paolo Cavallini (@pcav)

---

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.

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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?

[qgib]

Author Name: Nathan Woodrow (@NathanW2)

---

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

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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

[qgib]

Author Name: Martin Dobias (@wonder-sk)

---

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.

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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.

---

• pull_request_patch_supplied was configured as 0

[qgib]

Author Name: Alister Hood (@AlisterH)

---

Also see #14327

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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.

[qgib]

Author Name: Alister Hood (@AlisterH)

---

Sorry - I referred to #14326, but it should be #14327

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• fixed_version_id was configured as Version 1.7.4

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• fixed_version_id was changed from Version 1.7.4 to Version 2.0.0

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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

[qgib]

Author Name: Pirmin Kalberer (Pirmin Kalberer)

---

• fixed_version_id was changed from Version 2.0.0 to Future Release - Nice to have

[qgib]

Author Name: Giovanni Manghi (@gioman)

---

• easy_fix was configured as 0

[qgib]

Author Name: Borys Jurgiel (@borysiasty)

---

I guess this ticket is (and will be) only applicable to Processing plugins.
As now Processing is implemented, is the ticket still valid?

---

• description was changed from 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

Add to the plugin manager the ability to start a plugin.

Implement something like #11794: "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 #11662: "Grouping plugins in the menu" was implemented, i.e. if all plugin developers put their plugins into category submenus. to 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

Add to the plugin manager the ability to start a plugin.

Implement something like #11794: "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 #11662: "Grouping plugins in the menu" was implemented, i.e. if all plugin developers put their plugins into category submenus.

[qgib]

Author Name: Alister Hood (@AlisterH)

---

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!

[qgib]

Author Name: Borys Jurgiel (@borysiasty)

---

Got it.

[qgib]

Author Name: Harrissou Santanna (@DelazJ)

---

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

[qgib]

Author Name: Harrissou Santanna (@DelazJ)

---

Closing as I can find plugins with the locator bar.
Feel free to reopen if you feel it does not fix the issue you reported.

---

• status_id was changed from Open to Closed
• resolution was changed from to fixed/implemented

[qgib]

Author Name: Alister Hood (@AlisterH)

---

Sorry, I thought had had replied to your question previously. I think you must have misunderstood the ticket:

As described in the ticket, there is a locator bar in the plugin manager which searches plugins for installing them etc, but not for running them.

As described in the comments, there is now a locator bar in the main window which has filters for Project Layers, Project Layouts, Actions, Active Layer Features, Calculator, Spatial bookmarks, and Processing Algorithms. As far as I can see there is no way to use it to run a plugin, except if the plugin has provided a processing algorithm.

---

• status_id was changed from Closed to Reopened
• resolution was changed from fixed/implemented to

[m-kuhn]

What exactly is the definition of running a plugin (sometimes in here also refered to as starting a plugin?

There are a lot of different things a plugin can do:

• Adding processing algorithms (https://plugins.qgis.org/plugins/processing_r/)
• Adding locator filers (https://plugins.qgis.org/plugins/swiss_locator/)
• Adding expression functions (https://plugins.qgis.org/plugins/refFunctions/)
• Adding toolbar buttons, menu entries, other UI elements that
  • open a modal dialog
  • open dock widgets
  • start map tools
• ... or they do all sort of other crazy stuff

from what I can see, extracting a common "start" concept from this is (maybe not even) close to impossible.

That's probably the reason that after all this time this ticket isn't gaining much traction.

I think that it's not something that QGIS itself needs to solve, but that instead plugins should improve their description.
What could help here is

1. to make it possible/easier to add screenshots to the plugin description that help people to get started
2. to go over plugins with poor description and add more information

I would propose that one or more of the following steps happen

• a new issue is opened for 1. above
• interested parties start working on 2.
• use cases are listed in here that would benefit from a new unified run plugin concept with detailed GUI and workflow descriptions
• the guides to write plugins are reworked so people don't add new menu items to the plugin menu
• this issue is closed

[borysiasty]

@AlisterH wrote:

As far as I can see there is no way to use it to run a plugin,
except if the plugin has provided a processing algorithm.

From the Locator you can also trigger menu actions (including show/hide docks created by plugins). Isn't it all you can "run" from the plugin?

[AlisterH]

Ah, right, thanks for the keyword - "actions".

When I saw "Actions" I thought it meant "layer actions", but actually if I type ". " and then part of the label for a menu item or a panel or toolbar, then it is listed. So "Actions" really means "gui actions".

I guess this won't be so obscure when there is some documentation, but surely there is a better way of describing it? How about ". menu entries and panels/toolbars" (even though that is a bit redundant because the panels and toolbars are actually listed in the menu)? Does it provide access to anything else that isn't a menu entry?

[AlisterH]

I guess the main thing that was tripping me up is that you actually need to type ". " to search menu entries, when you don't need to type e.g. "a " to search processing algorithms. Is there a reason menu entries aren't searched by default?

[borysiasty]

When I saw "Actions" I thought it meant "layer actions"

Ah, now I see. I fully agree it's misleading, so in Polish translation I translated it more descriptively (just as a fast fix before a release), and forgot that the problem still remains in the source! I think it deserves a separate ticket.

Does it provide access to anything else that isn't a menu entry?

Well, if I create a QAction and add it to a toolbar but not to the main menu, it seems it's not accessible. It could be improved.

Is there a reason menu entries aren't searched by default?

Maybe they are too many, so the results list would be cluttered? I guess it was a fast decision which filters are active by default (without the prefix), and it can be re-discussed.

Anyway, you can still configure it (in the main settings window, btw. accessible from the Locator). From my experience, in various user profiles I'd use different settings. In some projects I have 50+ layers and all I need from Locator is to easily seek the desired layer - so I don't want the list cluttered by any other kinds of results.

[AlisterH]

Oh, I can't edit my tickets that have been migrated from redmine; annoying.

Well, if I create a QAction and add it to a toolbar but not to the main menu, it seems it's not accessible.

Confirmed - that means this ticket is something like 75% complete, I guess :)
This was actually one of the situations that prompted me to file this ticket. After you install a plugin you have to go on a treasure hunt, because you have no way of knowing whether it will add things in the menus, or in the toolbars, or both (or even neither, I guess).

I think it deserves a separate ticket.

#30186, although a "bug" tag seems harsh.

[borysiasty]

Thanks! I see you also mentioned the toolbar-only actions there, so maybe we can close this ticket now?

[AlisterH]

I thought you wanted a separate ticket because you thought the two changes might be implemented separately...

Feel free to manage the tickets how you like, but I am unable to edit or close this one.

[borysiasty]

1. Yes, I guess they can be implemented separately
2. I guess this topic became so long and outdated there is very little chance anyone will ever find its conclusion among all the 3000 tickets.
3. I'm not able to manage any tickets because of complete lack of time. I just wanted to say "From the Locator you can also trigger menu actions" and not take over maintenance of this ticket ;-)

[AlisterH]

As Borys suggested, it would probably be good if someone with the necessary superpowers could close this ticket, unless they want to update the description with the current status, which is:

• menu entries can be searched in the locator bar, using . by default (discoverability is a minor issue as per locator bar "Actions" filter is badly named #30186).
• toolbar buttons that aren't also menu entries can't be searched.