reidprichard / window_tools

Some simple tools to add lots of functionality to Kanata (and potentially other hotkey tools). This project is on hold for now, but after some life changes are complete I will pick this back up (est. June 2024).
GNU General Public License v3.0
12 stars 0 forks source link

Feature request - send a fake key when switching layers #3

Closed bogorad closed 7 months ago

bogorad commented 7 months ago

Now that I can assign layers to apps, some apps may require language switching. E.g., a chat app should always stay in one specific language. So when switching to it I need to make sure the OS language is switched.

reidprichard commented 7 months ago

If I'm understanding correctly, you want to be able to associate a fake key name with a layer name such that the fake key press is sent when the layer is activated? For example:

  1. Windows Terminal is focused by the user
  2. WindowsTerminal layer is activated
  3. fake-key-associated-with-windows-terminal is pressed?

Kanata has just recently committed (not yet released) the ability to tap fake keys via TCP, so this is technically possible. However, I'm not sure of an elegant way to accomplish it. I can think of a few options:

  1. Add a config file that defines fake key names corresponding to layer names. I want to keep kanata_helper_daemon as minimal as possible, so adding a config file is not preferred.
  2. Add command line arguments to associate layer names with fake key names. This feels clunky and would make the run command quite complex for larger layer counts.
  3. Embed the configuration for this into the Kanata config file. For example, (deflayer example_layer ;; fk:example-layer-fake-key .... Since we're moving to getting layer names from Kanata's TCP server rather than directly from the config file, this is not a long-term option.
  4. Encode fake key names into layer names. For example: (deflayer WindowsTerminal-fk_windows-terminal-fk ...) would activate the WindowsTerminal layer and send windows-terminal-fk when Windows Terminal is focused. This is still a bit clunky, but I think it would be my preferred method.

After more thought, though, I think this will best be integrated into a different feature I had in mind which I have just now described in #4. Hopefully Kanata adds more TCP fake key functionality soon so I can put that through.

bogorad commented 7 months ago

Indeed, that is what I meant. IMO config (separate or hijacked Kanata's) makes the most sense. It could hold the associations between process names, layers, and fake-keys. Using your example, I'd say:

(deflayer U_CHAT ;; proc:signal/zoom/jan fk:sw_malay
  XX XX XX
)
reidprichard commented 7 months ago

It would be nice to be able to use Kanata's config, but per #1 (include ...) in Kanata becomes a problem. Perhaps someday I will refactor to Rust and be able to use Kanata's config parsing code, but for now adding comprehensive config parsing is off the table.

I think #4 will provide the functionality that you need. I'll leave this open until that has been implemented.