Application-aware layer switching

[jtroo]

For Linux, can use https://github.com/k0kubun/xremap for inspiration.

For Windows: https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getforegroundwindow

[13minutes-yt]

Is tcp server needed? In linux xdotool can get the activewindow
xdotool getactivewindow getwindowclassname
and xdotool can also simulate keystroke movements( based on result of getactivewindow)
xdotool keydown n (can be used to switch to layer)

[jtroo]

The TCP server is not necessary for this particular feature as you've shown. There can be workarounds that don't involve inter-process communication.

However, the TCP server is nice to have for software integrations.

[jtroo]

For ease of discovery:

• Windows has the komokana project that integrates with kanata's TCP server
• Linux has no fancy solution, but as 13minutes-yt said, xdotool could be one way to do this

[13minutes-yt]

Just a thought. I have been using Espanso as a text expander and noticed they have application aware triggers.
Can't a crate be used in kanata for that purpose?
https://github.com/espanso/espanso/search?q=Appinfo

[jtroo]

Yep, that's a good reference to use if one were to implement this in kanata.

https://github.com/espanso/espanso/tree/9f82b4e146e6090897c876a02f5eee697b85e979/espanso-info

[gerhard-h]

espanso offers similar features than autohotkey hotstrings, and similar to ahk hotstrings espanso won't work while kanata is running (at least on windows).

But if we could tell espanso to listen to the kanata ouput instead of the real keyboard it should work?
Is the kanata tcp server the right thing to use to make espanso listen to it?

[veyxov]

I quickly put together a rough draft.

It uses swaymsg for getting information about windows (wayland/sway) which also shows which windows is focused. I searched, but it seems there is no universal way to get this information in wayland, so this only works in sway.

Sends a request to change the layer to the current window name.

Needs significant improvements, for example switch to the default layer, if current window is not in the list of application-specific layers.

Here is the code: https://github.com/veyxov/qanata (sorry for the name 😅)

Updates:
Saw the xremap implementation for sway, it looks a lot cleaner. Maybe I can integrate some parts from that.
Now using swayipc to get the window name.

[Aqaao]

I use SetWinEventHook implemented a simple tool in windows: kanawin.
This is my first code with rust. I referenced ChatGPT and komokana.
This might help a little.

[reidprichard]

Wow, would you believe that timing! I just finished my own daemon to interact with Kanata's TCP server. I guess it's pretty similar to kanawin with a few pros and cons.

Cons

• It's not Rust :(
• Looping is less efficient than using the Windows event hook (but I've yet to see it break 0% CPU usage in Task Manager)
• No pattern matching for mapping applications to layers

Pros

• For those of us with Rust skill issues, C isn't bad!
• No config file needed. You open firefox.exe, layer "firefox" is activated.
• Additional utility "window_manager" allows you to use hotkeys to save and activate windows. Always find yourself searching for that one browser window? Bind it to a hotkey and refocus it later with a single button press.
• No dependencies
• Doesn't need to run as administrator

While it's still a work in progress, it's 100% working on my end. I'd love feedback if anyone gives it a try!

Window Tools

https://github.com/reidprichard/window_tools

[Zerogaku]

Hey are there any plans for linux application aware layer switching or is xremaps the only solution?

[jtroo]

@Zerogaku Example: #892 (comment)

printf '{"ChangeLayer":{"new":"requested-layer"}}\n' | nc -w1 127.0.0.1 10000

[Zerogaku]

@Zerogaku Example: #892 (comment)

printf '{"ChangeLayer":{"new":"requested-layer"}}\n' | nc -w1 127.0.0.1 10000

That's so cool! I'll give this a try when I can!

[voronind-com]

Keyd supports per-application configurations. It's experimental, but it's been working fine for me for over a year.

[haithium]

@jtroo Why doesn't Kanata use a direct Bash command to change a layer, instead of creating a server and handling it through a client? Would it be beneficial to add a new Kanata option, such as kanata change-layer <layer_name>, for direct interaction?

[jtroo]

How should the CLI command invocation work behind the scenes such that a new process (the CLI command) can interact with the original process?

These types of functionality use inter-process communication mechanisms, of which TCP is a common one. The TCP server is a prerequisite, not a "instead of".

[devsunb]

Hi. I created a tool for application (and input source) aware key mapping on macOS based on kanata's virtual keys.
https://github.com/devsunb/kanata-vk-agent
I thought it might be helpful for macOS users.

[jtroo]

Thanks!

[aljustiet]

Should this feature be implemented in Kanata? If not, why? I'd also like to point out that Keyd seems to take the most minimalistic approach to application-aware remapping.

[jtroo]

Sure, the only reason why it's not is that nobody has implemented it. I don't have much motivation to do so because I don't prefer to use such functionality. The TCP server seems like a fine interim mechanism until it's added natively.

Keyd only supports one OS so it's somewhat easier to do. Keymapper supports application awareness on all Windows|Linux|macOS though.

[Frestein]

Linux
https://github.com/7mind/kanata-switcher
https://github.com/haithium/hyprkan

[malpern]

App-aware keymaps via virtual keys + switch (no layer duplication needed)

I wanted to share a pattern I've been using in KeyPath (a macOS Kanata frontend) that solves this without requiring any Kanata changes and avoids the need to duplicate entire layers per app.

Most tools in this thread switch layers on app change. The downside is you need a full copy of your layer for every app — if you have 3 apps with custom bindings and a 60-key layout, that's 3×60 key definitions even if you only want to override 2-3 keys per app.

The alternative: virtual keys + switch expressions

Instead of switching layers, you define a virtual key per app and use switch to branch individual keys:

(defvirtualkeys
  vk_safari nop
  vk_vs_code nop
)

(defalias
  ;; j → down in Safari, unchanged elsewhere
  kp-j (switch
    ((input virtual vk_safari)) down break
    () j break)

  ;; k → up in Safari, unchanged elsewhere  
  kp-k (switch
    ((input virtual vk_safari)) up break
    () k break)
)

(deflayer base
  @kp-j @kp-k ;; ... rest of layer unchanged
)

Your companion tool just watches for app focus changes and sends TCP commands:

Safari focused:
  → {"ActOnFakeKey": {"name": "vk_safari", "action": "Press"}}

Safari unfocused:
  → {"ActOnFakeKey": {"name": "vk_safari", "action": "Release"}}

Why this is nice:

• Overlay model — only the keys you care about get switch wrappers; everything else passes through your base layer untouched
• No layer duplication — 3 apps with 2 overrides each = 6 switch expressions, not 3 full layers
• Works today — defvirtualkeys, switch, and ActOnFakeKey are all existing Kanata features, no upstream changes needed
• 767 virtual key limit — plenty of room
• Composable — you can combine app context with other switch conditions (e.g., only override j→down in Safari when a specific layer is also active)

On macOS, detecting the frontmost app is just an NSWorkspace.didActivateApplicationNotification observer — about 30 lines of Swift. The companion tools listed upthread for Windows/Linux could use the same virtual key pattern with their respective window-detection APIs.

The full implementation in KeyPath is in AppContextService.swift and the architecture decision is documented in ADR-027 if anyone wants to reference it.

[gerhard-h]

opinions: layers vs virtual keys

Most tools in this thread switch layers on app change. The downside is you need a full copy of your layer ...
The other drawback of layer switching is that it may interfere with your layer switching while using the application.

The solution to send defvirtualkey presses would be really be much easier to add into my config.
If I really need complete new layer (e.g. gameing) that is still possible with defvirtualkey.

opinions: special helper actions for context
At first (switch ((context app safari) (context modus browser... context appeared to me to be eye candy only to reference a virtual key vk_app_safari.
But I assume the logic to depress all the other vk_app_* keys could be added as well.

(defcontext app safari terminal vscode) looks nice (is it ok to map all these keys to nop0?)

opinion: Core vs TCP server

Kanata stays focused on key remapping, companion tools handle environment awareness

I prefer the TCP server option, too. It's easier to maintain for multiple platforms, also.
The only drawback is that an extra tool will scare some users away, but that could be addressed later, when the tools have matured.

[malpern]

One thought on this — rather than building platform-specific app detection into Kanata core, would a lightweight set-context TCP command make sense? Something like:

{"SetContext": {"key": "app", "value": "safari"}}

That config could reference as:

(defalias
  kp-j (switch
    ((context app "safari")) down break
    () j break))

It would give companion tools a cleaner API than the virtual key workaround, while keeping all the platform-specific detection external where it belongs. Kanata stays focused on key remapping, companion tools handle environment awareness.

Curious what others think — @jtroo would something like this fit Kanata's scope?