mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-11-14 21:04:04 +01:00
LGUG2Z
2f61b62276
kglobalaccel keeps the actions of a client that died, and their keys: a daemon that is killed leaves its keys swallowed and running nothing until they are unregistered. And kglobalaccel runs inside KWin, so a KWin that restarts forgets every key komorebi registered. Neither should leave a user without keys. kwin::hotkeys::release unregisters every action of the component, whatever registered it, and komorebic hotkeys release runs it, with or without a daemon. The NixOS module's unit runs it after the daemon stops (ExecStopPost), however it stops, and a start already takes over what is left. The KWin backend's NameOwnerChanged watch now also follows org.kde.kglobalaccel: when it has an owner again, kwin::hotkeys::rebind loads the key bindings into the new one, trying for 15 seconds. Loading moves from the daemon's main into kwin::hotkeys::load, which keeps its settings (Keybindings: file, format, plan mode, engine options), so that reload can read the file again: the message ReloadHotkeys, komorebic hotkeys reload. A new engine replaces the running one without unregistering its keys, and takes them over as a start does, so the keys both files have stay grabbed. The message HotkeysState answers with the engine's mode, the combos it holds and whether a chain is pending (null without an engine); komorebic hotkeys state prints it with the actions kglobalaccel has for the component. komorebic now depends on komorebi for the two calls to kglobalaccel, and on serde_json for the state. Tests: the socket messages without key bindings, state and release without a session bus, reload without a daemon, and a nixos-module-eval check of ExecStopPost. The VM test vm-restart-survival runs the module's unit in a Plasma session: a key works, hotkeys state shows it; with the daemon stopped by SIGSTOP the key runs nothing until hotkeys release gives it back; after SIGKILL the unit's journal shows the release and the restarted daemon has the key; after the KWin process is killed, the daemon registers the key with the new KWin; and a reload of a changed file swaps the key. vm-keys-engine asks the engine and does not sleep. A key that is not grabbed yet reaches the focused window, which showed as a binding that does not run, so the suite presses one once komorebic hotkeys state answers, which it does when the engine has made the calls of its last event: for a mode, for a chord chain beginning and ending, and for the keys of the application that takes the focus. It waits for the old daemon to exit before it starts the next (a daemon started meanwhile failed to load its KWin script), and activates a window until KWin has it (KWin lists a window before it can have the focus). The last check reloads the key bindings with komorebic hotkeys reload while wev has the focus and every binding is for the terminal, a start with no key to grab.
162 B
162 B
Show the keys komorebi has registered with KDE, and what the engine of the daemon is doing
Usage: state
Options:
-h, --help
Print help