Bind modifiers as keys without confusing them as modifiers

[butter-radish]

Can sxhkd let us execute commands on the press-and-release of a key, which the program considers a modifier, while also allowing us to use it as a modifier?

Say I would like to map Super_L to a command while also being able to use it as a modifier (in say super + F). If both these examples are mapped together, then pressing super + F will always also trigger Super_L's command.

However there is a way to distinguish between these two keybindings, Super_L would be the press-and-release of the Left Super key (with no other keypresses or releases before it's released, meaning: not used as a modifier) while super + F will involve pressing the Super key, then f, and then releasing both.

Can't sxhkd, then, allow us to write command that are only bound to the press-and-release of a key? This would allow what're outlined as modifiers keys to be bound by themselves and not be confused with modifier + key combos. Key + key is illegal anyways, Super_L + F is illegal—so why not have the program distinguish between the modifier keys being used as regular keys and as modifiers.

Would open up a lot for me if I could bind just the press-and-release of my Super key to something, while being able to use it as a modifier like usual.

[godalming123]

You can get this functionality with @Super_L with the @ telling sxhkd to wait for the release of the keybind before executing the specified command. BUT: theres a huge asterisk with this approach which is that when your super + f keybind is released the @Super_L keybind is activated.

[butter-radish]

Yes, that's my point, the program doesn't distinguish between modifier keys being used as modifiers and used as keys when to my novice brain there should be a way to tell both of them apart, like I explained earlier:

Super_L would be the press-and-release of the Left Super key (with no other keypresses or releases before it's released, meaning: not used as a modifier) while super + F will involve pressing the Super key, then f, and then releasing both.

Presently, if I map something to execute upon releasing Super_L then it would also run it following every use of super as a modifier that I've configured in my sxhkdrc.

To clarify what I mean by being able to tell the Super as a modifier apart from the Super key as a key, the latter is always pressed after and released alongside another modifier: in alt + Super_L, the Left Super key is pressed after the Alt key and then both are released; meanwhile, in super + Alt_L, where it's the modifier, Super is pressed first and then released with/or after the Alt key. We can tell without ambiguity whether a modifier key (Super, Alt, Control, etc.) is being used as a modifier or a key in a hotkey combination based on its order.

[ruzito]

I would also like this addition. It just makes sense to run rofi on Super_L just like any other DE would open app launcher on Super_L and then have other keybindings that use Super_L as modifier like moving windows around.

Looks like a very reasonable usecase to me.

I would also generalize this:

Just use anything before \n or ; as key press. And use anything before that and + as modifiers.

Then add some kind of way to resolve conflicts. Like integer priority to commands or something. If the priority is the same, run all of them, if different, run the one with higher priority.

[godalming123]

I would also like this addition. It just makes sense to run rofi on Super_L just like any other DE would open app launcher on Super_L and then have other keybindings that use Super_L as modifier like moving windows around.

Looks like a very reasonable usecase to me.

I would also generalize this:

Just use anything before \n or ; as key press. And use anything before that and + as modifiers.

Then add some kind of way to resolve conflicts. Like integer priority to commands or something. If the priority is the same, run all of them, if different, run the one with higher priority.

do you have a snippet of code as to what this would look like

[ruzito]

At the very least it would be nice if it worked like this

when i set the Super_L on key release

@Super_L
      rofi-stuff

super + enter
     terminal

When I press super it should open rofi and when i press super + enter it should launch terminal

nothing more, nothing less

to preserve backwards compatibility, I present a priority feature

all keybindings have implicit priority e.g. 5

you can change the priority like so (could be something else so that it doesn't interfere with any other keybinding syntax)

10) @Super_L
    rofi-stuff

super + enter
   terminal

super + enter
   notify "terminal launched"

1) super + enter
    never-used

This would split keybinds into distinct groups. Each group would evaluate keybinds independently just like they work now, but when one group accepts any keybinding, resolution doesn't continue in other groups (only the current group is "evaluated" completely just like it does now)

It would work something like this:

Key binds will be seperated into groups according to the priority group:

Group 10:

@Super_L
    rofi-stuff

Group 5:

super + enter
   terminal

super + enter
   notify "terminal launched"

Group 1:

super + enter
    never-used

Then when a keybinding events happen:

• super is pressed down - group 10 doesn't match since it is on key release, group 5 don't match since it is requires enter, same wih group 1
• enter is pressed down - group 10 doesn't match (same as above and it doesn't have enter), group 5 matches and runs both commands terminal and notification, group 1 is not evaluated since higher group matched
• after a match do not evaluate on key up events (or somethig simillar, I assume something like that has to already work)
• enter key up - ignored
• super key up - ignored
• super key down - same as first line
• super key up - group 10 matches and rofi is launched, other groups ignored

[butter-radish]

nothing more, nothing less

I agree, @ruzito, but the priority system you mentioned sounds like way more.

Like a convoluted new syntax for our sxhkdrc, because the logic sxhkd would follow (if modifiers like Super could also be bound as keys) would still be the same without this priority system, yes?

@Super_L
    rofi-stuff

super + enter
   terminal

super + enter
   notify "terminal launched"

Taking a part of your example, assuming there is no priority system: if you press 'super + RET' here it would launch the terminal and execute that notification command; you pressed RET before you released Super, so you presumably wanted the keybinding where Super is a modifier (not a key) and RET is the key.

As for the other group 1 keybinding for 'super + enter' which is never used, what is the point of that? Just illustrating what the lowest priority would be like? What function would having a duplicate command be a lower priority—guaranteeing it's never executed—serve?

[ruzito]

shadowing super + enter multiple times would serve no purpose, that was just to illustrate the functionality, where it would make sense would be, where the higher priority commands are the prefix of lower priority commands, in such case you would want to set the high priority as on release and wait for the full keybinding to see if some lower priority command isn't better match. If the higher priority on release command is better match (like pressing only super instead) run only the keybinding of such command AND when the lower priority is better match (super + enter) do not run the higher priority group commands, therefore when pressing super + enter it would only launch terminal and would not open rofi

[Ingvix]

Okay, so I think for many of you Super_L;@Super_L chain would give you the functionality you desire. I think it might actually solve this particular issue.