[RFC] Shorcut overlays

Software darktable
1

DT has a very powerful shortcut system. However, there are only so many keys that it is convenient to operate without moving the hand too much, which is one of the main reasons why until now I have only embraced shortcuts to a certain extent.

This got me thinking that it would be nice to have a way to quickly remap a bunch of keys so that I can reuse the same set of keys for different parts of the workflow.

Enter: shortcut overlays.

It is actually pretty simple: a thin layer of overrides applied on top of your standard shortcuts that allow you to create “contexts” in which new shortcuts are assigned, or the shortcuts perform different actions. A bunch of new actions make it easy to create, delete and switch between overlays.

As an example, take a look at the video below. In this example, my default shortcuts use zxcvb with scroll to control the main AgX settings. I then hit Tab, which I mapped to the cycle shortcut overlays action, which loads my AgX primaries overlays. This is reflected in the title of the window, so that you always know if you are using an overlay, and which one. In this overlay, the same set of shortcuts is used to control the primaries sliders. When I am done, I hit Tab again and I go back to default mode (i.e., no overlay), where the keys are, again, controlling the main AgX settings.

The whole thing is completely optional, and you can keep using your shortcuts with no change to your workflow whatsoever.

If you create an overlay, after switching to it all the shortcuts that you registered will automatically be stored in the overlay. As soon as you go back to the default, i.e., no overlay, the new shortcuts disappear (if they were new additions), or go back to whatever function they already had before (if they were overrides). The current implementation adds a section for each overlay in the shortcutsrc file, e.g.:

[agx primaries]
b;scroll=iop/agx/blue attenuation
b;long=iop/agx/blue attenuation
c;scroll=iop/agx/green attenuation
c;long=iop/agx/green attenuation
n;scroll=iop/agx/blue rotation
n;pan=iop/agx/blue rotation
v;scroll=iop/agx/green rotation
x;scroll=iop/agx/red rotation
z;scroll=iop/agx/red attenuation

Note that, while in the example I am only using AgX to avoid too much UI fiddling during the screencast, there is no limit to what shortcuts an overlay can override. So, for example, you could have an overlay for your lightroom operations, one for the main technical edits in the darkroom, one for a specific module, one for color grading, whatever. The granularity is completely arbitrary and up to you.

The code footprint is 600 insertions and 100 deletions, so it’s a pretty tiny change.

Any thoughts? @Pascal_Obry, I always loop you in to understand whether it’s worth spending more time refining the idea or not.

Thanks, cheers

2

It sounds interesting…

Would you have some sort of visual reminder that you were in “overlay” mode ??

Would they be organized to be module specific, view specific and global, ie sets of overlays assigned to those categories…

Just a couple of first thoughts without much thought :slight_smile:

3

I believe that the answers to those questions are in the OP already :slight_smile:

Currently, the title of the main window changes based on the overlay that you are in. If needed, more can be done.

That is completely up to you, there is no rule. An overlay has access to all defined actions. It can assign new shortcuts or override existing ones, so you can decide what you want to use them for.

1 Like
4

I understand it is a bit like exchanging shortcutsrc, or parts of it, on the fly (probably implemented differently, of course), right?
I like the idea, as it allows to free up some shortcuts I only use in lighttable to be redefined in darkroom.

5

Not quite.

If you make a copy of shortcutsrc you are branching it, you are creating two independent sets of shortcuts.

The overlay is more like a live diff. It inherits all the default shortcuts that you do not explicitly create/override within the overlay.

If you remap a default shortcut (i.e., when there is no active override) then the overlay will also see the new shortcut, unless it overrides it explicitly.

Overlays allow you to reuse all the keyboard shortcuts that you have in your default, and to selectively change a few of them to carry out specific parts of your workflow more efficiently, without having to worry to keep all the shortcuts in sync.

So, for example, you have e for exposure in the default shortcuts. If you use e in an overlay where you did not explicitly remap it, it will change exposure there too. Now you go back to the default shortcuts, and you remap e to, say, contrast. If you switch to the overlay, now e controls contrast there as well. But if you override e while the overlay is active, then e in the overlay becomes independent from what e does when there is no active overlay.

1 Like
6

A few months ago, I asked how many people actually use shortcuts. The number was surprisingly low.

One of the main hurdles is remembering the shortcuts. That’s why, for the past few weeks, we’ve had themes to help with this.

Screenshot_20260324_154900
Screenshot_20260324_1549002560Ă—1537 2.86 MB

So the idea is to use something similar for your system – not via a theme, as that isn’t flexible – but perhaps you could have the shortcut displayed accordingly in each case?

7

I did say without much thought :)… sorry I missed the first point…

8

I am not sure what you mean. If you activate an overlay, H will show you all the shortcuts that are currently defined, i.e., all the default shortcuts + new additions/overrides specific to the overlay. If you disable the overlay, H will show you all the default shortcuts.

9

If you look at the screenshot, you’ll see that every module that is on the following keys:

qwert
asdf
yxcvb

displays a coloured letter corresponding to the keys above.

With H, you get a very long list of different shortcuts, which takes a lot of searching.

10

I understand that, what I do not understand is what you man with the following:

You mean, to hardcode the letter on the module header? That is not very generic, as one may use multiple keys to activate shortcuts within a module.

Or maybe you mean something else?

11

Not hardcoded, exactly. More like [A] AgX, [F] exposure. Depending on the chosen keyboard shortcut. The same then in “overlay” mode, so that you can see the shortcuts to the module or parameter at a glance. All of this is optional; if you have your shortcuts committed to muscle memory, you can simply leave them out.

Your idea is good, but it has the problem of accessibility to shortcuts

12

Sorry, hardcoded was the wrong word. I meant, display a letter on the module header, depending on the current overlay. That would be possible, but I don’t think it’s desirable. As I said above, shortcuts can be mapped to individual widgets, so each module may be controlled by a variety of keys, with single, double, triple presses, each with different kinds of movement associated with them. Hence, the idea of associating a letter with a module does not generalize well.

2 Likes
13

I think this could be useful.

I think this could be dangerous in the hands of users :smile:

I think this could be very confusing if you forget what overlay you do or do not have active.

Keeping the overlay notification in the title bar probably isn’t good because the title bar disappears when you go full screen

I could see where it could be harder to troubleshoot issues since there is another layer between the user and the code

1 Like
14

There are ways around that. Some ideas that come to mind:

  • Always toast the current overlay
  • Add a persistent decorator somewhere in the UI

These are implementation details. A proof of concept will necessarily have rough edges, otherwise it would be called a ready-to-merge PR :stuck_out_tongue_winking_eye:

I think this is what matters :slight_smile:

Not more dangerous than the quick shortcut button, it is so easy to assign random shortcuts to random actions by mistake :slight_smile:

15

This would solve half of a problem i have. I’d like to be able to assign shortcuts for tagging people on my pictures, which i currently do not do because of (1) the lua module that implements this has a limited, static, capacity of tags which is tedious to edit and (2) because there are not too many keys available which i don’t want to have a different function in other contexts than tagging.

This approach would solve (2). Why do i write this? Because maybe you have an idea how to solve (1) with this approach as well :smiley:.

16

I have a lua script that makes every tag in your tags into a shortcut

Here it is…

tag_shortcuts.zip (2.3 KB)

Create a folder in your lua directory and unzip it and drop it in. Start it and it will go through your tags and create a shortcut for each one.

1 Like
17

Does it do a random assignment? I am still trying to figure out what would be best, using the initial letters of the names or keeping families together on neighboring keys. Maybe even a key sequence would be beneficial, something like the initials of the people’s names. I also wondered if it would be better to have pictures of the people on a MIDI controller and use this. Do you have some experience with this?

18

It doesn’t assign keystrokes, just creates shortcuts. When I look in the shortcuts preference the tags are in alphabetical order. They show up under Lua scripts as apply tag <name of tag>

19

Not really, though I probably need to. I mostly shoot sports and it would be good to tag the players, but I haven’t managed to figure out a workflow that would work for me (or I’m too lazy :smile: )

20

When i get this done, it helps tremendously for my family calendars. With the tagged photos, it is much easier to balance family members such that there is nobody unhappy with the result. And if i would be able to manage to be earlier with my calendar efforts, i could also do some for friends with whom we were e.g. on vacation together. But

holds for me as well, and tagging 10000 photographs or more each year is a lot of work. Therefore i am still searching for better ways or workflows to tag …