In [[Feature demo] Scroll through module groups, modules and widgets], I demoed a way to navigate hierarchically through all module groups, modules and widgets. This complements DT’s excellent shortcut system by making those widgets for which you did not set explicit shortcuts (e.g., arbitrary multiple instances) more accessible.
Now I built another small feature on top of that, which is different enough to justify its own post.
I extended the search box in the darkroom with the ability to also filter widgets. A configurable special character (|, by default) is used to separate module search from widget search. So, for example, you can type exp|lightness to search for widgets labeled lightness within exp(osure) modules.
As soon as you type | in the search box, all modules currently in the search results are expanded, so that you can see the labels of the widgets. As you start typing after the |, the widgets whose label does not match the query string are removed from the UI. When you clean the search string, all the widgets reappear.
Combined with the ability to navigate arbitrary modules/widgets introduced in my previous post, this makes it super easy to navigate quickly to the slider that you need.
See it in action below (only using the keyboard, PgUp/Down to cycle widgets and arrows to change values):
If there is enough interest and no objections from the devs I will start polishing the code and prepare a PR after the release of 5.4.
If you want to try it out, the branch is published here:
It is really nice to see someone working on such UI improvements.
My wishlist would be:
Fuzzy finding, i.e. ignoring missing letters like fzf
Activating the search box with a standard shortcut. Ctrl-p does something similar in VS Code. This may already be possible, haven’t checked.
I use the keyboard a lot in Darktable and I have been playing around with editors like Neovim and Helix that often use a very search-based workflow. This is why I like this direction a lot.
I am a DT user who doesn’t currently use many shortcuts, however, if this got implemented in DT5.5 I would look forward to trying it out with the hope that it would be a further improvement to DT. Thanks for your contribution to DT.
This looks interesting and potentially useful. I’m mostly away from my dev machine this week so haven’t been able to test, but a few thoughts after glancing at the code.
The shortcut system depends on visibility of widgets to determine if shortcuts should do anything, so presumably all shortcuts to widgets not included in the search, and therefore hidden, stop working. I’m guessing is not what you want or maybe you’ve worked around that?
You seem to be storing the visibility of each widget before searching. If shortcuts do work, you could have a situation where the visibility of a widget is adjusted based on a change in the value of a related setting which makes it applicable or not. When then restoring to “previous visibility”, after search is cleared, that might not reflect the current status anymore? This could all become somewhat finicky (unless, obviously, I’m overlooking simple solutions to all possible issues that could arise).
Having most of a module hidden when you make changes to one widget in it has the general drawback that you don’t get visual feedback of the impact your change has. There might be a warning popping up that you’ll now miss.
I’m wondering if a better approach might be to make this a special case of the QAP. After all, that is also about showing a subset of all widgets. Currently that doesn’t show multiple instances, but presumably you could ignore that here. And anyway, it could be good to look again at supporting multiple instances for QAP as well; it is often mentioned as a reason why people don’t use it. But of course there must be a way to select which instance (or all) to include, in a way that survives reordering/creating/deleting/renaming instances and that isn’t too complex/user unfriendly…
I’m also thinking that part of the reason for this feature would be to be able to easily cycle through the same widget (say, exposure) in multiple instances of the same module. I mentioned before that I think this could/should be the default for module cycling; if currently the 3rd widget of a module is active, then cycling to the next module should again focus the 3rd widget there. For me that might be a better way to approach this. Rather than typing “|exp” after searching for the exposure module, it might be faster to press tab-tab-tab to get to the exposure slider and then pgup/pgdn to cycle around each of the exposure sliders of the several instances of the exposure module.
Just some ideas/doubts/suggestions. Thanks for thinking about and working on all these improvements.
Thanks @dterrahe, your remarks are always very insightful.
Re: Interaction with shortcuts, I haven’t considered that. I will need to look at it more closely to get a better idea of what is happening and what can be done.
I would say that this is a matter of ensuring that all the relevant widgets are included in the trimmed down module. For example, I am already including all the labels that precede a visible widget so that widgets with the same name can be disambiguated (e.g., the various “chroma” in CB-rgb).
That was actually my first implementation, but it had a couple of drawbacks (in addition to the multiple instances, which is a major one). The implementation is a bit more complicated, and the overall UX is less fluid. Filtering in the current view seems very natural, as opposed to creating a whole new view with a different L&F and slightly different functionality.
This would be a nice addition indeed. Note that there are cases in which this wouldn’t be possible, or the widget with the same index may be a different one in a different instance (e.g., multiple instances of exposure with different mode settings, so that effectively the two instances have a different set of controls).
True for modules with 2 or 3 widgets, not true for, say, CB-rgb which has ~30.
As a first attempt to address the problem, this one line change makes it possible to control a widget also while it is hidden by widget search.
See the video below, in which I am hiding the exposure level widgets and then I am controlling its value in two different exposure instances with E + scroll:
