Are there (and if yes, where are they defined) general accessibility shortcuts for DT? Like, navigating through the interface with the keyboard, such as moving through panes, tabs and widgets.
I know that I can set a shortcut to focus, activate and set value for specific modules or widgets. What I am asking is something different.
How can I, say, cycle through all the modules in the right panel? Or cycle through all the widgets of a module?
Thanks 
This is from the manual, is that what you are looking for?
Much of the functionality in darktable can be controlled via keyboard shortcuts, which can be customised in preferences > shortcuts.
Press the H (shift+h) key (for help) in any darktable view to show a list of all shortcuts that are applicable to the current view.
Thanks, but no.
As I explained above, to the best of my understanding you can set shortcuts for specific actions (e.g., “increase exposure level”, or “activate agx”), but not for general ui navigation (e.g., focus prev/next pane, focus prev/next tab, focus prev/next widget, increase/decrease value of currently selected slider).
I am talking about the basic accessibility functionality that every web page or desktop application generally has, which allows one to navigate the whole ui only using the keyboard (as opposed to triggering specific actions).
Did you press h in your keyboard?
Yes, I did. Did you? It does not seem to answer my question.
I think what they are looking for its like using tab and page up and pagedown to jump through elements of the interface, ie navigate around and in that general sense I don’t think those standard OS navigation elements are in DT or universally applied…
Thanks, yes that is what I mean.
I don’t find these accessibility features documented anywhere, though maybe they are. Since modern toolkits like GTK+3 have native support for keyboard-based navigation I am wondering whether the functionality is actually there but maybe it’s not easily discoverable.
Darktable has a lot of custom widgets, so not sure keyboard nav is implemented like you’re asking for. At least, I haven’t heard of it.
Today i wrote down all default keyboard shortcuts. Found nothing that would help you. sorry.
In the shortcut system there are things called “fallbacks” which can be turned on and provide default behaviors for the currently focused module/widget. I don’t use them but I know they exist. You would probably have to play with them to figure them out.
That’s a nice visualization, thanks! Same info as the h overlay but more accessible.
Thanks, I have been trying to use them for a couple of days (after enabling them in the preferences) but with no success. In principle this is closer to what I am asking about, even though much more limited in scope.
Thinking about this keyboard navigation: why would you want this? (Other than that it’s a standard functionality in a lot of programs.) And what’s the usefulness of such functionality for darktable, as editing images is by definition a visual activity.
Also, why would you want to cycle through all panes/modules/settings? At least for me, the process (in editing) is: “what do I need to change?” “what module is that? and which setting?”. That’s more a usecase for short-cuts. I do not want to cycle through all modules just to pick the one I need…
It could also get rather resource intensive and visually “disturbing”. I have dt set to open the selected module and close the others in the column, so with keyboard navigation, either that should not happen, or you’l get every module in turn opened, and the previous one closed. Lots of flicker.
Accessibility is not just about people with visual problems but also about people with, for example, motor issues preventing them from using a mouse.
In my case, I just like to use the keyboard as much as possible.
I can set a shortcut to search for a module (which I did, it’s /), but then I cannot navigate to the module that I want, activate/deactivate it, focus/unfocus it, select and operate any of its controls without a pointing device.
For example, I could do something like (with the exception of / all keyboard shortcuts below are imaginary, just for exemplification purpose):
/ to focus the module search boxexp to start searching for exposureDown n times to find the right instance of exposure in the search resultsEnter to focus/expand the moduleTab to move to the first sliderEnter to open the manual input1.2 to set the desired exposure levelThis may seem cumbersome at first, but for me it is much more intuitive than having specific keys associated with specific widgets of specific modules. For two reasons:
More to the point of your reply:
The fact that is a visual task has nothing to do with it. Coding is also a visual task (in fact, code is indented and colored to make it more readable) but when I code I never have to take my hands off the keyboard. I can switch applications, select different files, move through files, run terminal commands, etc. and never use a pointing device. I can guarantee you it is a very efficient way of working.
Agreed. I want to cycle through some modules (e.g., search results) and through their controls. And even if the search results consisted of only one module, so no cycling at all, currently I do not know how to select it (without having a dedicated shortcut for that specific module).
I don’t see why. You have a highlighted border that shows you the currently focused element UI. When you cycle the highlighted border moves. A module would expand only when you decide to dive into its controls, just how, when using a pointing device, modules do not expand if you hover them, but only if you click on them.
Just to clarify, before people start worrying that I am proposing to change something that works well for a lot of users.
I am not suggesting anything. I started the thread just to understand if this is somehow already possible (as GTK supports this natively) and maybe the functionality is a bit hidden and not documented.
Short answer: no, dt has not implemented full accessibility access. I contemplated using the relative instance of the <focused> module shortcuts to allow focusing the next/previous module. That would be different meaning from the normal one where it only refers to instances of the same modules type. Maybe I even tried to get feedback on it, but in general people already seem to find the shortcut system too complex and would probably never find this unless it had a default assignment. Since Tab has already been taken for a long time, consensus on the “correct” key might not be easy. At some time i stopped having fun implementing stuff just for completeness if neither me nor apparently anyone else would use it. But i could revisit…
You could assign Enter as a shortcut to expand/collapse the focused module.
Utility modules would be a separate issue.
The standard Tab is supported to cycle between text entry fields. Try for example the metadata module.
The focused slider or dropdown do responds to arrow keys and enter opens the pop up (so you can easily repeatedly enter values). These are not shortcuts but hardcoded widget responses so not configurable.
BTW: I believe Ansel has more of a focus on conforming to standard UI practises; maybe you could investigate if it is a better option for keyboard users (so we don’t have to).
Thanks @dterrahe, this is very useful
Well, I for one would find it useful 
If you have the branches published something I would be curious to take a look, just to get an idea of what it entails.
I would still need to be able to navigate between modules.
That would probably be less important as most of the UI interactions happen in the darkroom already.
I guess that to make it cycle between the modules currently in scope one would need to add an action like /view/darktable/focus next module, correct?
My fun ran out before I implemented this. And it is not back yet. There are no magical branches anywhere.
That was understood, yes.
No. To be consistent with the rest of the shortcut system, one would define /views/darkroom/focused module and give it elements 1st-20th (just like <focused>) and then for each of those have a previous/next “effect” that does the cycling. The fallback for the shift modifier would reverse the direction. This would allow connecting the shortcut for example to a rotor on the x-touch mini and get feedback from the light ring around it indicating which module is currently focused, or to a range of buttons to be able to directly select between visible modules 1,2,3 etc. The first “effect” would basically just copy the default for <focused> which is to expand/collapse. But until I get some suggestions/consensus for the keys to assign to prev/next by default, I still believe there is little point in implementing this. So we need agreement on keys for switching modules and switching widgets (and shift+ each of those would reverse direction). If you intend to use Tab for the second function, please try to give me a feeling there is some support/consensus on this (maybe organise a poll?)
BTW a big motivator for me in the past to implement functionality correctly is to prevent the “wrong thing” from getting merged, so do feel free to submit a PR to prod me a little.
Thanks for the detailed explanation!
Not planning to do anything ATM but it may be a fun project to break my tooth on the codebase if and when I get the cycles (the kid is still 7, so don’t hold your breath…)