CZ-NIC/run-or-raise

Feature request: Layered shortcuts

Closed this issue · 9 comments

humanplayer2 commented

Run or raise is amazing, and it makes my day, every day. I think it would be a great addition if it supported layered shortcuts.

Beyond the type of use cases described next, with layered shortcuts Run or raise would add a new dimension of shortcut customizability to GNOME.

A use case and how I hack it with a remapper

With the remapper keyd, I use Super + f, a to run-or-raise a Dolphin tab in one directory, Super + f, b to run-or-raise a tab in another, etc.

As Run or raise does not support such layered shortcuts, with keyd, I map Super+f to activate a second layer, where a triggers the key combination <Super><Control><Alt>a, etc. In my Run or raise config, I then have lines such as

<Super><Control><Alt>a:move-window-to-active-workspace:minimize-when-unfocused,dolphin /home/user/,dolphin, Home
<Super><Control><Alt>b:move-window-to-active-workspace:minimize-when-unfocused,dolphin /home/user/Downloads/,dolphin, Downloads
...

Idea

The shortcut syntax allows a break character (e.g., ,), so shortcuts may be specified as <Super>f,a, meaning that Super + f waits for additional input, and if a is given, then it executes the matching command.

An example of a config for the above use case could then be

<Super>f,a:move-window-to-active-workspace:minimize-when-unfocused,dolphin /home/user/,dolphin, Home
<Super>f,b:move-window-to-active-workspace:minimize-when-unfocused,dolphin /home/user/Downloads/,dolphin, Downloads
...
e3rd commented

Thanks and thanks for the idea! First of all, I there any feature advantage of using run-or-raise over keyd?

humanplayer2 commented

Yes, I think there would be a feature advantage to having layered shortcuts in run-or-raise over implementing them through keyd.

A big plus with having them implemented in run-or-raise directly would be the number of shortcuts one can define.
To not mess up with my lousy combinatorics, say we have a keyboard with with one modifier mod and two keys, a and b. With run-or-raise + keyd, you get four possible key combinations: mod+a, a, mod+a, b, mod+b, a, mod+b, b. But you can only define two shortcuts with run-or-raise: mod+a and mod+b. Hence the layer that keyd allows becomes obsolete because run-or-raise does not allow as many key combinations to be mapped to shortcuts.
If run-or-raise had layered shortcuts, all four options mod+a, a, mod+a, b, mod+b, a, mod+b, b could be mapped to shortcuts.
I know there are a lot of key combinations on a keyboard already, so wanting more may seem useless, but with more also comes freedom. To not elaborate too much, I'll just mention that I'm in a situation where I can't easily define the shortcuts I'd like used keyd+run-or-raise: I use super+e to launch a "editor" layer, where e.g. d opens an editor on my dotfiles. In run-or-raise, this is <Super><Control><Alt><Shift>d. I also use super+f to launch a "file manager" layer, where e.g. d opens my downloads. I'd like to use super+f, shift+d to open my dropbox folder. But I can't: That'd be <Super><Control><Alt><Shift>d, already used in run-or-raise.

Beyond that, I think it would just be super nice to just be able to define my shortcuts in the run-or-raise config, instead of having to design them half using a key remapper, half in run-or-raise, and translating between the two.

e3rd commented

There is a chance I've found a way to do the layered shortcuts (but I cannot promise anything yet).

  1. But instead of , to be the delimit character, I think space would be better (the same is used in the multikey/compose config file and does not interfere with the current delimiting character.

The old syntax:
shortcut[:mode],[command],[wm_class],[title]

  1. Should the mode be adjacent to the main shortcut or the the layered

Proposed syntax this:
shortcut[:mode][ layered][ layered],[command],[wm_class],[title]

Or this?
shortcut[ layered][ layered][:mode],[command],[wm_class],[title]

humanplayer2 commented

It would be awesome! Thank you for looking into it!

  1. I think a space is as good as a comma =)

  2. Personally, I think your second option for syntax is more intuitive, since [ layered] is part of the key combination to be pressed.

  • 👍1
e3rd commented

Could you try current master? Everything should work.

<Super>q a,notify-send Launched a

for typing a after the shortcut.

humanplayer2 commented

This is awesome! Thank you!

It works very smoothly. The syntax is really nice, I think.

I notice that if the config holds both a non-layered and a layered shortcut for the same "prefix" (e.g., <Super>q a, ... and <Super>q, ...), then the non-layered will take precedence. I think that's a good choice.

Given the syntax suggestions you made, I tried a shortcut with several layers (<Super>q d e f g h i j k l,notify-send Launched long). That worked brilliantly!

I tried adding modifiers in [ layered], e.g. <Super>q <Super>w, ..., but it didn't work with any mods. Would that be possible, too?

  • 🎉1
e3rd commented

I did not want to implement layered modifiers before, that's why I've originally marked this as char and not as a shortcut in the README but as you've directly tried this, you convinced me to finish the work :D

Please try the current version, huge refactoring took place and you should be able to use <Super>q <Super>w, ... really smoothly too. Thanks!

humanplayer2 commented

Super nice! This is extremely cool! It works super well.

I've tried breaking it a bit:

  1. Nicely, layers with <Control>c, <Control>v, f11, <Shift>f11, work for me, also in apps where the latter are defined as shortcuts for fullscreen. So that indicates that Run-or-raise layered shortcuts takes precedence over applications' shortcuts. Nice =)

  2. For some bindings that are already taken by GNOME shell, I'm notified that Run-or-raise cannot grab the layered accelerator. This happens e.g. for my shortcut to switch workspace up <Super>w and for maximizing windows <Super>m.

So, having run

gsettings set org.gnome.desktop.wm.keybindings switch-to-workspace-up "['<Super>w']"
gsettings set org.gnome.desktop.wm.keybindings toggle-maximized "['<Super>m']"

the following do not take effect:

<Super>q <Super>w,notify-send Launched =)
<Super>q <Super>m,notify-send Launched =)
  1. Nicely, point 2. does not apply to the Run-or-raise shortcuts. I.e., the following works:
<Super>q,notify-send Launched =)
<Super>e <Super>q,notify-send Launched =D

For me personally, 2. is definitely a minor issue, but I thought I'd mention it. And then I'd really like thank you for and congratulate you on having made a great extensions even greater!

e3rd commented

Thanks for those supportive words and the testing! I am well aware of the 2. but there is little I can do in the moment. Have a nice day!

  • 👍1