To add filters (or sources or extractors), one can use the dedicated menu. But it is also possible to use the “Quick Launch” window (ctr+space). Then typing some text will display the matching filter labels.
Pressing enter on the desired one create it in the pipeline.
We see different possible improvements to this window, here is a post to discuss them before starting implementation.
Using filter (short) help
Proxy definition includes some help, including a short_help.
We propose to display the short_help of the selected filter.
Also, a shortcut to open the complete help may be useful here.
To improve discoverability, we may extend the research to list proxies with matching help,
and not only matching label.
Display unmet requirements
It can be useful to know why a filter is disabled in the list.
When using the Filters menu, a status is updated with the reason (see bottom left of the application).
We suggest to put this line in the quicklaunch window too.
Interactions
As a prerequisite to display unmet requirements, the disabled filters (currently greyed out in the list) should be selectable, while keeping the ability of quick navigation among enabled-only filters.
Mouse double click will allow to create the targeted filter (if available)
I use the quick launch a lot when using ParaView, so I’m interested in improvements. I like a lot of these.
Adding the ability to create a filter with a double click is a good idea. I’ve seen new users stymied by not being able to do this.
I really like the idea of expanding the search into the short help. Sometimes I cannot remember what words are used in the name (e.g. is it “external surface” or “extract surface”?) and searching extra words will help. Searching into the long help might not be too bad either. Heck, how about searching the full documentation string? I’m not a big fan of keywords, but a keyword parameter could be added to the XML to add words that are related but don’t quite match.
I’m a little worried about making the disabled filters selectable. I sometimes type a search that has lots of matches, and it is really helpful for the scroll to skip pass disabled filters. If this changes, how do you feel about resorting the list so that selectable filters are on top and disabled are on the bottom? That would give us the best of both worlds.
Speaking of ordering the list, maybe we should give some thought about what order matches are shown. Currently, it looks like matches are given in arbitrary order. But maybe there can be a match score used to order matches. Perfect matches of the name would be first. Followed by perfect matches of keywords, short help, and long help. All this followed by partial matches.
For now only Enter can be used to create the selected filter. Be able to double click on it will be nice.
Of course it should be an available filter (post updated).
Yes I fully agree. But in order to display information about disabled filter, we should be able to select them. But I advocate to keep a “quick navigation”. Not sure of the actual impl for now, but it may be something like a “ctrl+arrow” vs “arrow” ? Or as you suggest, putting them at the bottom of the list…
Agreed again: searching in help string will of course increase the number of matches so be able to present most pertinent at top should be considered.
Concerning this point, we had some internal discussion and stated that pertinent keyword should probably be part of the help text, so we want to start without adding XML element. Also we thought about long_help and full help, but as a first implementation we prefer to see what happen with only short version. And then may be prototype with more.
One more wish: it would be nice to include other actions besides creating filters/sources/extracts. For example, I would love to type Ctrl+Space Screenshot to take a screenshot. Same for standard camera orientation. We could get a long way by indexing QAction text.
I prefer the solution of putting matches together on top. I will forget anything about the modifiers and ignore any tips at the bottom of the window trying to remind me of it.
extended name match (e.g. Extract Surface will be here when typing surf ext )
help match
Available and disabled filters are split so if you have an exact match that is disabled, you quickly see it while keeping shortest access to available filters only.
In fact this quick launch dialog is not hard linked to filters or proxies, but to any “list of actions”, so it should be easily doable (but outside of the scope of my current work).
However, I’m not sure that we should put misc actions like Screenshot in the same Quick Launch than filters. So I advocate for another instance of the window, triggered by another shortcut.
