From 670c9845129fc0c4b6e0192d657eea05e1a64b49 Mon Sep 17 00:00:00 2001 From: srdusr <99972264+srdusr@users.noreply.github.com> Date: Wed, 13 May 2026 19:47:00 +0200 Subject: Expose key bindings over IPC so a launcher can list them Asked whether srdwm's bindings show in the AGS launcher. They could not: srd.bind lives entirely in the Lua engine, and nothing published a binding anywhere a client could read it. There was no IPC command, no field in any response, and bound_keys() was used only by main.rs to register grabs. srd.bind now takes an optional third argument, a description, and the loaded set is copied into the WindowManager after the initial load and after every reload. Core neither owns nor interprets them - it has no Lua state and never dispatches a key - it holds them so the IPC layer, which is handed a WindowManager and nothing else, can serve them. New `srd keybindings` returns combo and description pairs, sorted so a UI listing them does not reshuffle on every refresh. Every binding in the shipped config now carries a description, so the feature is useful without the user writing any. Verified live in a nested instance: 46 bindings published, 0 without a description, and editing the config file updated the list without a restart (which also exercised reload-on-write again). Also verified, for the separate report that windows cannot be moved to another workspace from the AGS workspace pills: the compositor side works. `srd dispatch move workspace 2` moved a window from workspace 1 to 2 and correctly hid it, since workspace 1 was active. Nothing to fix here; the missing piece is on the shell side. 515 tests pass, clippy clean. --- docs/DEFAULTS.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) (limited to 'docs') diff --git a/docs/DEFAULTS.md b/docs/DEFAULTS.md index 2cc1614..abcdad1 100644 --- a/docs/DEFAULTS.md +++ b/docs/DEFAULTS.md @@ -935,3 +935,30 @@ make an app forget where it lives. Dialogs are centred instead, and take neither a remembered position nor a remembered size - window memory is keyed by `app_id`, which a dialog shares with the window that spawned it. + +## Listing key bindings + +`srd keybindings` returns every binding the loaded config registered, with a +description if it gave one: + +``` +{"keybindings":[{"combo":"Mod4+Return","description":"Open a terminal"}, ...]} +``` + +`srd.bind` takes an optional third argument for that description: + +```lua +srd.bind("Mod4+Return", function() srd.spawn("alacritty") end, "Open a terminal") +``` + +Bindings live entirely inside the Lua engine, so before this nothing outside +the compositor could see that a binding existed at all - a launcher or +cheat-sheet had no way to show the user their own keys. The list is +republished after every config reload, so a rebound key appears without a +restart. Note that a brand new *combination* still needs a restart before the +compositor grabs that key at all; an existing combination picks up its new +action immediately. + +Combos are reported in canonical order (`Ctrl+Mod4+l`), which is what the +compositor matches a real keypress against - not necessarily how the combo +was written in the config. -- cgit v1.2.3