Custom OSC for xdg-activation #2201

silversquirl commented 2025年10月18日 16:53:17 +02:00

Describe your feature request

Some terminal applications, for example Kakoune, use a client-server model and may wish to switch focus from one terminal window to another. There is currently no way to do this without resorting to compositor-specific hacks.

I would like to request a custom OSC sequence for this, looking something like the following:
(code is a placeholder since I don't really know what OSCs are available - is there a resource anywhere that lists all known escape sequences across all terminals?)

• Request an activation token with OSC code ; ? ST
  Response from the terminal is in the form OSC code ; token ST
  The seat and serial of the token should be set to the last keyboard, mouse button, or focus event that was sent (via escape codes) to the application running inside the terminal. The surface should be set to the terminal's surface, and the app id should be left unset.
• Activate the current terminal with OSC code ; token ST

The spec for xdg-activation-v1 doesn't appear to place any restrictions on what the token string actually is, but in practice I think it's safe to assume it won't contain any control characters, and won't be just a single question mark.

### Describe your feature request Some terminal applications, for example Kakoune, use a client-server model and may wish to switch focus from one terminal window to another. There is currently no way to do this without resorting to compositor-specific hacks. I would like to request a custom OSC sequence for this, looking something like the following: (`code` is a placeholder since I don't really know what OSCs are available - is there a resource anywhere that lists all known escape sequences across all terminals?) - Request an activation token with `OSC` `code` `;` `?` `ST` Response from the terminal is in the form `OSC` `code` `;` `token` `ST` The seat and serial of the token should be set to the last keyboard, mouse button, or focus event that was sent (via escape codes) to the application running inside the terminal. The surface should be set to the terminal's surface, and the app id should be left unset. - Activate the current terminal with `OSC` `code` `;` `token` `ST` The spec for xdg-activation-v1 doesn't appear to place any restrictions on what the token string actually *is*, but in practice I think it's safe to assume it won't contain any control characters, and won't be just a single question mark.

krobelus commented 2025年10月19日 10:18:28 +02:00

FWIW I have a hacky script for a related use case: it creates a new terminal window with a new Kakoune client connecting to the same Kakoune server as the currently focused window.
I do this by putting hostname and Kakoune's session-name into my OSC 0 window title,
and have my script extract them from swaymsg -t get_tree | jq -r '.. | select(.focused? == true) | .name'

This means that I don't use Kakoune's :terminal,:new or :focus commands, as they don't work across SSH.

Compositor-independent solution sounds nice.

I don't know much about Wayland; do you want the Kakoune server to store each client's activation token as it connects?
I wonder if this is really needed; the Kakoune client's TTY might be enough.
I don't think the Kakoune server can access that directly, but it can be added (like it already writes OSC 0).

FWIW I have a hacky script for a related use case: it creates a new terminal window with a new Kakoune client connecting to the same Kakoune server as the currently focused window. I do this by putting hostname and Kakoune's session-name into my OSC 0 window title, and have my script extract them from `swaymsg -t get_tree | jq -r '.. | select(.focused? == true) | .name'` This means that I don't use Kakoune's `:terminal`,`:new` or `:focus` commands, as they don't work across SSH. Compositor-independent solution sounds nice. I don't know much about Wayland; do you want the Kakoune server to store each client's activation token as it connects? I wonder if this is really needed; the Kakoune client's TTY might be enough. I don't think the Kakoune server can access that directly, but it can be added (like it already writes OSC 0).

silversquirl commented 2025年10月19日 18:16:28 +02:00

In the context of Kakoune specifically, the wayland implementation of :focus would need to do the following:

1. track which client currently has focus, using a FocusIn hook
2. when :focus is run, request an activation token by sending the proposed OSC to the terminal of the currently focused client
3. when the activation token is received, send it to the terminal of the client that is requesting to be focused

Kakoune doesn't currently have a way for plugins to reliably send and receive escape codes, but either the support for this OSC could be implemented natively within Kakoune's terminal UI, or functionality could be added to allow plugins to do this :)

In the context of Kakoune specifically, the wayland implementation of `:focus` would need to do the following: 1. track which client currently has focus, using a `FocusIn` hook 2. when `:focus` is run, request an activation token by sending the proposed OSC to the terminal of the currently focused client 3. when the activation token is received, send it to the terminal of the client that is requesting to be focused Kakoune doesn't currently have a way for plugins to reliably send and receive escape codes, but either the support for this OSC could be implemented natively within Kakoune's terminal UI, or functionality could be added to allow plugins to do this :)

raiguard commented 2025年11月05日 19:29:48 +01:00

I daily drive kakoune, and its focus capabilities currently fall apart when you use foot -s and footclient. It will focus a seemingly random window instead of the one it wants. Would this OSC fix this issue?

I daily drive kakoune, and its focus capabilities currently fall apart when you use `foot -s` and `footclient`. It will focus a seemingly random window instead of the one it wants. Would this OSC fix this issue?

silversquirl commented 2025年11月05日 21:59:30 +01:00

@raiguard yes

@raiguard yes