Feature: Integration with other synergistic tools

[reidprichard]

As you know, there are several cool tools to allow Kanata to provide application-specific keybinds. In no particular order 😉:

• kanata_helper_daemon in window_tools for Windows
• kanawin for Windows
• qanata for Linux
• komokana for komorebi

It would be super convenient to be able to open kanata-tray and have kanata_helper_daemon launch with it. I would love to be able to send a friend or coworker a zip with a few files and say "yeah just double click kanata-tray.exe and you can give it a try."

Perhaps this could be implemented in config.toml like:

extra_commands = [
    "./bin/kanata_helper_daemon -p 1337 -c ./kanata.kbd",
]

Of course, someone could also do:

extra_commands = [
    "powershell rmdir -Recurse -Force ~",
]

so perhaps a whitelist of allowed binary names could be implemented. Then again, if someone were running a Kanata config without looking at it there's the equal and unavoidable (in kanata-tray at least) risk of something like (macro M-r p o w e r s h e l l ret r m d i r spc - R e c u r s e - F o r c e spc ~ ret).

[rszyma]

I would love to be able to send a friend or coworker a zip with a few files and say "yeah just double click kanata-tray.exe and you can give it a try."

To make this happen, additionally config.toml would need to be able to be read from the curent directory (i.e. where kanata-tray binary is located).

Of course, someone could also do:

extra_commands = [
    "powershell rmdir -Recurse -Force ~",
]

so perhaps a whitelist of allowed binary names could be implemented. Then again, if someone were running a Kanata config without looking at it there's the equal and unavoidable (in kanata-tray at least) risk of something like (macro M-r p o w e r s h e l l ret r m d i r spc - R e c u r s e - F o r c e spc ~ ret).

I don't think anything can be done to prevent potentially malicious configs, besides adding a warning to README to not use random ones from the internet. But that should be obvious anyway. Adding filters is a wasted effort; if someone malicious wanted to, they would eventually find a their way around them.

[reidprichard]

Good point about the config location. Perhaps kanata-tray could first look in the current directory before checking AppData?

That would be useful behavior for me even outside this one issue, as I like being able to keep all hotkey-related binaries and settings files in a single folder for portability across computers.

I agree with your assessment re: malicious configs.

Wish I could submit a PR but I don't know Go and my free time is going to learning Rust to contribute to Kanata itself :)

[rszyma]

Back to the main request of this PR - extra_commands, when exactly would these commands would be ran? Maybe instead a single hook, a better idea is to add a couple of them that could be run when specified event happens: e.g. before starting kanata, after kanata is ready, after kanata exits

Another thing, is array of commands needed or a single command would suffice? For running multiple commands, a link to a bash/powershell script could be provided

[reidprichard]

Good question - I hadn't considered that. It's been awhile since I've had time to work on this stuff, but I'm pretty sure _kanata_helperdaemon needs Kanata to be running before it starts (though I could always make it reattempt the TCP connection for some period). I like the idea of having separate event hooks like you describe. Being able to handle multiple commands per event would be nice so you could avoid having to deal with spawning threads in PowerShell, but that's more of a future-proofing scenario than any present need I can think of.

[rszyma]

Another thing, there should be a control passed to the called script/program to let kanata-tray know when the hook is done so kanata-tray can continue. We need this to ensure no race condition appear between called programs and kanata-tray operations.

Simplest way to implement this would be to block until the provided script/executable exits (with a short max time the hook is allowed to block - let's say around 10 seconds). So unless the called programs are somehow daemonizing themselves to run indefinitely in background, most long-running programs I guess would require to be called from a bash/powershell script to run them in background.

[rszyma]

Notes to self:

add default.hooks and preset.<key>.hooks

add following hooks: pre-start post-start post-start-async post-stop

Logic:

• non-async hooks should have maximum allowed runtime 3 seconds, and will block main loop until the process exits or timeout is exceeded.
• async hooks are ran in background without blocking kanata-tray and can run indefinitely. When stopping preset, first send interrupt (ctrl+c) signal, and if the process doesn't respond to it after 3 seconds, send force kill signal (kill -9)

[rszyma]

Let me know if this covers your use case.

[reidprichard]

Thanks, will do! I've had zero time for any of this in the last few months (finishing up PhD) but I'll spend some time on this once I have my head on straight (probably June-ish).