Add support for plasma5 which uses a marginally different dbus and scripting
API (ugh). We also use the window class instead of the app id, which appears
to yield a more consistent result).
Add support for Gnome 45, which breaks backward extension
compatibility. We now ship and maintain two extensions :/.
The main change in Gnome seems to be the switch from a custom
import implementation to 'standard' ES6 style imports.
The init method also seems to have inexplicably
been swapped out in favour of extending a magic
class.
This patch takes the opportunity to clean up some residual cruft
and move the extension code out of the mapper script.
Specifically:
- Ship distinct extensions for Gnome 42-44 and Gnome 45 in /usr/local/share/keyd
- Move the named pipe to XDG_RUNTIME_DIR
- Initialize the pipe inside the extension instead of the script
to avoid potential race conditions during initialization.
Replace hacky Sway and Hypr application detection logic with a generic
wayland implementation that works for wlroots based compositors.
This also provides the scaffolding for adding Gnome/KDE support
in the future should they decide to implement the requisite
protocols.
This patch reduces the compose sequence size by making use of keysyms a-z.
This is mainly done to improve support for programs with broken XCompose logic
(i.e chrome). A consequence of this is that the user will need to be using
the standard US layout on their display server to make use of unicode support.
Sometimes in Sway, when an application goes from fullscreen to
windowed mode, there is neither a "app_id" or "window_properties"
attribute. Avoid throwing an exception for this case.
A potential race condition exists on systems where keyd-application-mapper
is started before keyd (ideally this shouldn't happen, but exotic
setups exist). To allow initialization order to be reversed, we simply
eliminate the ping check on script initialization.
Removing this is mostly harmless since keyd -e will silently
fail until the daemon is started anyway, and any errors will show up
in the log file.
The stock XCompose file which ships with most distros isn't exhaustive
and uses a number of layout specific keysyms intended to be easy to
memorize (rather than globally accessible). To circumvent this problem
we ship our own set of simplified compose definitions.
If we encounter a utf8 sequence corresponding to a glyph for which a
known XKB compose sequence exists, we replace the glyph with the
corresponding sequence. This allows non-english users to easilly specify
alternate glyphs without having to memorize the appropriate macros.