mirror of
https://github.com/LGUG2Z/komorebi.git
synced 2026-11-14 12:53:43 +01:00
LGUG2Z
a2e7f12bd3
What a static shortcut file cannot be (modes, chord chains, release bindings, per-application bindings, a blacklist, a pause binding) komorebi realizes itself, with keys it registers in kglobalacceld. The engine is the logic of that, with no I/O and no clock: it takes the press and the release of an active combo, a change of the focused window and the time, and returns effects: combos to activate or deactivate, and commands to run (komorebic's to dispatch in-process, the others through `sh -c`). After every event it computes the set of combos it wants from its state (the mode, the chord chain being typed, the focused application, whether it is paused) and returns the difference with the active set, so that a key it does not want reaches the application. That is how everything works, because of what KWin 6.8.1 was measured to do: KDE's own multi-key sequences never fire, while a single combo can be grabbed and given back (`setShortcutKeys`, `setInactive`) in well under a millisecond each. A chain's first combo is an active key, and pressing it leaves only the next combos and Escape active until one is pressed or the chord timeout (3 s by default) passes. A scoped key is active only while the focused application, matched without regard to case on its executable, app_id or desktop entry and on the configured aliases, has an action for it. Autorepeat arrives as a separate signal the engine has no input for, so a held key runs its binding once. The D-Bus side (registering the component, carrying out the effects, feeding the signals in) belongs to the daemon and is not here. The crate documentation now ends with what is emulated and what is not, across the readers, the plan and the engine.