[New actions] [Builds available] Cycle groups, modules, instances and widgets

Software darktable
,
1

Hi all,

During the WE I had a bit of time and I implemented a way to navigate through the visible modules using the arrow keys.

Paired with the option miscellaneous > shortcuts with multiple instances > prefer focused instance, this allows me to target any instance of any module without having to define multiple shortcuts.

I added new key bindings to the search box so that, when it is focused, you can press Up/Down to cycle through all visible modules. If the search box is not empty, this will only cycle through the search results.

As you cycle, a toast displays which instance of which module is selected.

As the search bar is still focused, if you keep typing you will just keep editing the text in the search box, so your shortcuts (if you are using the keyboard) will not fire. To address this issue, I added a special handling for Enter, which will remove the focus from the search box and allow you to control the currently focused module with whatever shortcuts you defined for it.

The video below shows it in action. I have set up / to focus the search bar and E + scroll to control the exposure level.

So, I can type / to focus the search bar, expo to find the exposure instances, Up/Down to select a certain instance, Enter to defocus the search bar and use the same shortcut E + scroll to control the level of the different exposure instances.

If folks find this interesting and the devs have no objection I am happy to prepare a PR. Personally, I find it very useful, it’s a small change but it greatly improves my ability to operate multiple instances with a smaller set of key bindings.

Tagging @dterrahe who I believe may be interested.

11 Likes
2

Uhh I like that. I find searching for modules clumsy and switching out of the search field with this fix might help. For me there is also a slight delay when entering the search-bar with STRG+f which makes it slightly unwieldy. (/ doesnt really work on QUERTZ).

3

As long as it doesn’t break the existing shortcut system, it should be fine.

I would say hold it until after 5.4 because feature freeze is soon and there wouldn’t be enough time to thoroughly test before 5.4 is released.

4

Will do, thanks :+1:

1 Like
5

If you want to reach developers to discuss actual code, github might be a better platform. I don’t check here as often and don’t get notified by email when I’m @ed.

This sounds like useful functionality, but it makes sense to think about next steps. If you are able to change the focused module by keyboard, it would be useful to change the focused widget within those modules by keyboard as well. Then you can manipulate any slider, even those without shortcuts already set up. But that won’t work with an approach where the search box needs to be focused for keys (up/down) to get a special meaning (to change module focus). Because the search box and a slider cannot have focus at the same time. To me that suggests that you want to have real shortcuts (that can be used at all times and don’t require the search box to be focused) to change modules. I would suggest PgUp/PgDown. Look at darkroom/move/vertical how a shortcut is defined so you can also assign a key+mouse move(scroll) to it or allow going to the last/first in one move.

For changing the focused slider/combo, we could then use Up/Down. Those currently are already captured by bauhaus but do the same as left/right. So the question is if it is likely that people prefer them like that or if they are happy to have them change focus instead. Maybe for combos it is preferable to have up/down act the same as when the dropdown is open. In that case we’d need to look for other keys (and might make them real shortcuts instead of special bauhaus keys). I think it would be preferable to wrap around the focused widget within the focused module (from the last go back to the first), rather than progressing to adjacent modules (since an Up/Down via the above shortcut would do that). You could keep the “same” widget within a module focused if you change to the next module of the same type. With that I mean if you are in exposure module and you have the exposure widget active, then PgDown would go to the next exposure module instance and again focus on its exposure widget.

Enter to de-focus/leave the search box is not necessary as Tab already does this (for any Entry; if there are multiple Entries chained, like in the metadata module, it will cycle through them).

1 Like
6

Yes, actually that was my first implementation. I added two actions to move up and down. The Up/Down when search is focused seemed like a nice way to introduce the functionality with as little code changes as possible.

Yes, totally. I did not look into it yet, but it’s on my todo list :slight_smile: This is somewhat already achievable via <focused>/slider etc., but I agree that a generic way to achieve that would be more convenient.

What tamed my enthusiasm is that currently there is no vidual clue (that I am aware of) to show visually which widget has focus. Though maybe this can be addressed via theming.

Thanks for all the useful insights!

7

In the spirit of <focused>, I would probably go for a different shortcut to cycle each type of widget (i.e., slider, button, combo, curve node), which would make it easier to access all widgets with fewer keystrokes.

1 Like
8

There is! It is just very very (very!) subtle. But if you know its there you’ll see it (and not just think there’s a slight bug).

Power vs complexity. I would just do all Bauhaus (slider+combo mixed) and ignore everything else because they can’t currently focus (and it makes sense to keep it that way; should pressing a button give it focus, which redirects some keys?) and don’t generally have keyboard handling). We may need to add a keyboard way to press the Bauhaus “quad” button. Space?

9

I had some more time to work on this, and thanks to @dterrahe’s indications it’s getting better and better.

So, I implemented three new actions:

  • Cycle modules, to cycle all the currently visible processing modules.
  • Cycle widgets, to cycle all the (bauhaus, for now) widgets in the currently selected module
  • Edit focused value, to edit the value of the selected widget

I added Z+scroll as a shortcut to control the first, X+scroll for the second and C+scroll for the third.

Now, with just three keys (and / to search and TAB to remove focus from the search box), I can basically navigate the whole darkroom :smiley:

See the video below for a quick demo:

Naturally one can also use just the keyboard to do the same, but with the scroll navigating through all the controls of complex modules, also with multiple pages (e.g., color balance RGB), is a breeze.

[I also did some theme hacking to make the focused widget more prominent]

Hope you like it :slight_smile:

3 Likes
10

Think I start to like what you are doing here :grinning:!

Maybe I missed it but I see you are working top to bottom, I - and I guess more of us - often work bottom to top. Is that easily possible? And I guess this functionality is applicable in all module-tabs?

Kind regards, Jetze

11

It’s bi-directional and circular, for both modules and widgets. You can start top or bottom and when you reach the end it continues from the other side.
Scrolling widgets only works within the focused module, so you cannot switch module without wanting it.

And by the way, you can also do random access. With a shortcut to focus the search box you can then type three letters to show your module, Tab to leave search and scroll (up or down) to the instance that you want to change.

1 Like
12

Are you already in a stadium that we might test?

13

Almost, I still need to implement editing of combo boxes and a couple other little details. If all is well I may publish the branch in a day or two.

2 Likes
14

I’d really prefer to have this discussion on github at this point. If not as a PR then as an RFC issue. That way I’m better able to provide suggestions before you spend time implementing something in a possibly suboptimal way.

When implementing a shortcut that could target either a slider or a combo, remember that fallbacks depend on the type of the action. So if you want C+shift+scroll and C+ctrl+scroll to change the speed consistent with “normal” slider shortcuts, you can’t just create a separate type that in its implementation dispatches to the slider or combo handler. Without having dug into it now, you’d probably need to “fix” this in the actual accelerator.c shortcut matching code. <focused> is already treated as a special case there, so it would make sense to have this “shape-shifting” action sit underneath it.

Logically, focus could be an element of that type, with next/previous effects.

Just like the instance of the module type could be special cased for <focused> to refer to all modules visible in the panel, and relative to the focused one, rather being disabled (as now) or referring only to modules of the same type as the current action. This would serve the need of your z+scroll. But it would allow you to not just focus modules next to the currently focused one, but also to switch them on/off, whatever. Which might be handy in a script (“disable all except the focused one” if you’ve search for “expo” might make it clearer what you are currently doing).

Does the line along the right side of the focused module work well if there’s a color picker (or other) button there?

Using the mouse scroll would not be ideal for users who really want to be able to work keyboard-only. As default shortcuts I think PgUp/PgDown makes more sense. Don’t know for changing focused widget.

Anyway, I’ll look closer at it when I see a draft PR.

1 Like
15

Agreed, I am just gauging interest in a proof of concept here.

Keyboard is fully supported. There is no default shortcut, but for myself I am using PgUp/Down for modules and Shift + PgUp/Down for widgets. Then, when the widget is focused you can use the normal shortcuts (i.e., up/down, left/right).

This is not a code change, it’s just done via css. No, it covers it partially. I could make some space in the parent container via CSS but I did not spend time on it.

16

I think this should be default. Ideally tab would cycle widgets as well, since that’s customary across platforms, but that would mean changing current defaults.

ctrl + PgUp/Down could be used to cycle through module groups.

17

Dt standardizes on ctrl for smaller changes and shift for larger changes, so it would be “more intuitive” to have shift+PgUp/Down do module groups and ctrl+PgUp/PgDown switch widget focus.

But I’m also in favor of changing the meaning of Tab, if we can agree what other key to use for that (I’d be happy to move it one key up, to `). It’s not a “destructive” change (accidentally changing widget focus when you meant to hide the side panels is “not a big deal”) although for people who have +10 years of muscle memory it can be very annoying. So let’s at least do a poll before changing.

18

I am tentatively using Home/End to cycle module groups. Again, nothing is hardcoded so it can be customized.

I am not in love with PageUp/Down and Home/End for a default because on most laptops you do not have those keys (or you need an extra modifier, e.g., Fn, to simulate them, which makes it cumbersome). But if you have those they are very convenient.

I like @dterrahe’s idea of using whatever pair of keys for cycle modules (e.g., < and >), and adding Shift for larger (i.e., module group) and Ctrl for smaller (i.e., widget). However, num_widget >> num_modules >> num_groups, so I would prefer the shortcut for widgets to be the simplest.

In the end, my current setup (on a Tenkeyless keyboard… I just learned this term) is

  • PageUp/Down: cycle widgets
  • Shift + PageUp/Down: cycle modules
  • Home/End: cycle groups

As for Tab, I hardly ever use it to hide all panels, but I wouldn’t want to mess with people muscle memory. Then Tab is only one, so it does not convey direction.

19

It seems to me that ctrl + W already does the same thing. But ` would work for me.

Can’t make omelette without breaking a few eggs :wink:

Yes, most laptop keyboards are form over function shit these days, but using something like < and >, or any other symbol, isn’t ideal either, since the placement and modifiers needed depend a lot on the keyboard layout.

I would suggest this:

  • PageUp/Down: cycle widgets
  • ctrl + PageUp/Down: cycle modules
  • shift + PageUp/Down: cycle groups

or this:

  • (shift +) Tab: cycle widgets
  • PageUp/Down: cycle modules
  • shift + PageUp/Down: cycle groups

The benefit of using Tab, other than it still being available on a Macbook, is that the right hand can be on the arrow keys, while the left goes through widgets. Should be a lot more efficient.

Tab is forward, Shift + Tab is backwards.

By the way, how does this work with graphs like in Tone EQ? And what about buttons, such as pickers, can they be triggered with space?

1 Like
20

Ok, so I implemented the following actions:

  1. view/darkroom/cycle module groups
  2. view/darkroom/cycle modules
  3. view/darkroom/cycle widgets
  4. view/darkroom/edit focused value
  5. view/darkroom/toggle focused picker

The first three are self-explanatory.

(4) Is what allows one to edit the value of a slider/combobox. If you assign it to a shortcut with movement, it will do up/down. You can assign individual keys to each direction, as well as to the edit (which will open the input box) and reset effects.

(5) Is used to trigger the quad (e.g., picker) associated to a certain slider/combo. This works well if the button does not steal focus. If it does, as in the case of a picker, you will have to click manually on the picker again to close it and restore the focus to the widget when you are done. I didn’t spend too much time refining it, an action to close the picker and return focus to the widget may exist already, if not it will have to be implemented.

As suggested by @dterrahe, for the moment this works only with sliders and comboboxes. Support for graph nodes, checkboxes and other widgets (are there?) may be added if (1) this ever gets pulled into master and (2) there is interest for it.

Everything can be controlled only with the keyboard, or with keyboard mouse if you prefer. Here is a demo in which I am doing everything only with the keyboard:

If you want to try it out, you can clone this branch:

As for the shortcuts, this is what I am using. You can copy/paste this in your shortcutsrc if you want to try with the same setup:

c;scroll=views/darkroom/cycle widgets
v=views/darkroom/edit focused value
v;scroll=views/darkroom/edit focused value
v;long=views/darkroom/toggle focused picker
v;double=views/darkroom/edit focused value;reset
x;scroll=views/darkroom/cycle modules
z;scroll=views/darkroom/cycle module groups
Home=views/darkroom/cycle module groups;up
Page_Up=views/darkroom/cycle widgets;up
Page_Up;shift=views/darkroom/cycle modules;up
Page_Down=views/darkroom/cycle widgets;down
Page_Down;shift=views/darkroom/cycle modules;down
End=views/darkroom/cycle module groups;down

That is:

  • KBD only: Home/End to cycle groups. With mouse: z + scroll
  • KBD only: Shift+PageUp/Down to cycle modules. With mouse: x + scroll
  • KBD only: PageUp/Down to cycle widgets. With mouse: c + scroll
  • KBD only: Up/Down/Left/Right to change the value of the focus widget (this is the default in DT already). With mouse: v + scroll
  • v: open input field (or, the default Enter)
  • v (double): reset value
  • v (long): toggle picker, if present

The layout makes sense with a QWERTY keyboard, so that the four bottom-left keys are used for navigation (z, x, c) and value manipulation (v). If you are using a different layout you may want to replace z with whatever you have at the very bottom left (or make something completely different altogether, of course).

Looking forward to early testing reports :slight_smile:

EDIT: In order to be able to see which widget is focused, you may want to edit your user.css with something like this:

@define-color focus_color #9FE2BF;

#bauhaus-slider:focus,
#bauhaus-combobox:focus {
  color: @focus_color;
  border-right: 2px solid @focus_color;
}
4 Likes