Plugin support

[sezanzeb]

It would be interesting to have support for plugins that:

• run when the injection starts/stops via the daemon
• or run when the injection starts/stops via the gui/cli to have knowledge of the session #33 #110
• run during the injection to map keys in a new way in a sandboxed python process #49 #30 #79
• support a new syntax in the gui, but with a distinct prefix to make sure it is recognizable as external feature, for example [plugin_1234] foo, or, if the macro-editor becomes reality, add tabs to configure plugins
• store their settings in the preset.json files (which also indicates that they should be loaded for this preset)
• are simple to write because key-mapper provides all the needed information and handy interfaces to them
• are running inside a process that keeps running in the background and receives relevant key events via a pipe
• send their injections back to the root daemon

Open questions are

• how to install plugins
• how to enable and load plugins
• how to tell the root daemon which keys the plugin needs to know about
• how to avoid privilege escalation vulnerabilities when the daemon runs a plugin. Running plugins as separate process via an unprivileged user with ipc stuff happening to make it work? How does that affect latency, would shared memory be faster?
• how to avoid that any user can inject keys into the daemon via ipc. Should the plugin run as a special user and only root and that one can write into the pipe?

Because some niche features are hard to integrate into the existing architecture in a clean way

[matt-vdv]

Just some ideas regarding plugin installation/distribution. I can think of three ways of doing this:

• Use the system package manager (eg AUR)
• Get the user to copy plugin files to a plugins directory
• Make a 'mini package manager' style install system

As for enabling the plugins, an interface similar to the gnome extensions app (previously in gnome tweaks) may work well?

[sezanzeb]

There is a Consumer base class and ConsumerControl now, making it probably rather easy to add new ways of mapping events.

A "Plugin" consumer class could exist to load all plugins sandboxed (maybe from ~/.config/key-mapper/plugins/*.py and provide events to them via a pipe.

maybe pip3 install --user ... could copy a single plugin .py file to ~/.config/key-mapper/plugins/ via data_files of the plugins setup.py

The root daemon is already aware of the current users home directory and can therefore look the plugins up (via the set_config_dir dbus endpoint)

[sezanzeb]

Maybe the macro system could be moved into a plugin, so that different versions of the macro language can be enabled or disabled. Might be useful in the future to keep compatibility with old mappings if the macro system was to be overhauled.

Or to provide third party implementations of different macro systems