Hm, neat idea.

I think a way of doing it that would be more flexible is allow to send input. And now that I'm typing it I realise that this is already possible with seats.

So in this case you would do:

for_window [class="discord"] bindsym F24 seat - mmmhh, oops, nope, keyboards don't work yet. #1779

I prefer this solution over adding a redundant command.

While I understand your argument, and I would accept it as a solution when it is implement, I have two small concerns:

• The forward keyword avoid duplicating the key and is easy to understand
• bindsym XX .... syntax instead of for_window... bindsym XX provides easier grouping of global hotkey in the config

I think the config file must be as expressive, concise and easy to organize as possible.

* `bindsym XX ....` syntax instead of `for_window... bindsym XX` provides easier grouping of global hotkey in the config

I'm not sure I understand what you mean here. I would say it's actually the opposite:

for_window [class="discord"] bindsym {
	F21 .......
	F22 .......
	F23 .......
	F24 .......
}

Well, that's a matter of taste, for me:

bindsym XX ...
bindsym YY ...

is clearer than:

for_window ... bindsym..., other rules
... a bunch of lines
for_window ... bindsym..., other rules

Because I group my for_window directives not in the same way I would group my bindsym global hostkey. With a list of bindsym it's also easier to ensure you did not override a key.

But this is a matter of taste.

Anyway, there is another problem, the for_window wouldn't bind the key if there is no window, and the whole point of global hotkeys is for them to be always bound, regardless of context, if there is no window matching criteria to forward the key to, then the key is a noop.

My syntax would make that clear and would also permit forwarding to multiple apps:

bindsym F24 forward [app_id=A...], forward [app_id=B...]

This would swallow the key if neither A and B are running, if either A or B is running it would forward the key to it, and if both are running, it would forward the key to both.

forward would require keeping metadata about the key event around and pass it to the command executed by bindsym. Not a fan of this.

forward would require keeping metadata about the key event around and pass it to the command executed by bindsym. Not a fan of this.

Well, I guess creating a new event with the same keycode would work, like bindsym F24 emit [app_id...] which would emit the same key, and bindsym F24 emit F12 ... which would remap the key.

The idea is to provide an easy way to bind global hotkeys for app that cannot be scripted. I'm sure we can come up with a nice solution.

If syntax sugar is what you want you could use variables:

set $emit seat - keyboard press

(Ignoring the fact keyboards haven't been implemented yet)

Reread the original comment (#4937 (comment)) and realised I misread it. It won't be as easy as using seats. But regardless I still believe it can be done with seats. Especially with if "virtual seats" become a thing.

A workaround for this issue is to write a script that:

• Move the focus to the target application.
• Use wtype to send the key events.
• Move the focus back to the original workspace.

Below is an example with OBS as the target application:

#!/bin/sh

WRKSPC1=`swaymsg -t get_workspaces | jq -r '.[] | select(.focused==true).name'`

swaymsg [app_id="obs"] focus
if [ "$?" = "0" ]
then
    wtype $*

    WRKSPC2=`swaymsg -t get_workspaces | jq -r '.[] | select(.focused==true).name'`
    if [ ! "$WRKSPC1" = "$WRKSPC2" ]
    then
        swaymsg workspace number $WRKSPC1
    fi
fi

With the above script saved as send_keys_to_obs and the file turned executable, we could, for instance, press Super+n to send Ctrl+n to OBS:

bindsym $mod+n exec /path/to/send_keys_to_obs -M ctrl -k n -m ctrl

Notes: we can't use the same key combination in both OBS and Sway because it would result in an infinite loop.

More generalized approach from what @jalvesaq does:

#!/bin/sh
set -x

PID=$(swaymsg -t get_tree | jq '.. | select(.type?) | select(.focused==true) | .pid')

matcher=$1
shift
type=$@

swaymsg [$matcher] focus
    if [ "$?" = "0" ]
then
    wtype $type
    swaymsg "[pid=$PID] focus"
fi

This way you get your window focus back afterwards.

Using it like this:

type-to-app.sh "class=\"VencordDesktop\"" -M ctrl -M shift -k m -m ctrl -m shift

It is quite annoying that the window flashes into focus briefly tho and am still searching for a solution that doesn't do that...