komorebi-application-specific-configuration VS komokana

Haha hello!

I don't use Teams personally but I believe some people have solved this and it is part of the standard application-specific fixes that are used to generate base configurations.[1]

Thanks to the architecture of komorebi, it's pretty easy for users to fix (and then contribute fixes for) weird behaviour of individual apps without touching the source code.

Thankfully an army of dedicated users has congregated on the project Discord so if you ever get stuck with the sort of behaviour you're describing with any application, someone on the server will be able to show you to fix it (and then add the fix to the application-specific fixes repo so future users never have to deal with it).

[1]: https://github.com/LGUG2Z/komorebi-application-specific-conf...

[4] https://github.com/LGUG2Z/komorebi-application-specific-conf...

Introducing a decoupled library of application-specific fixes in YAML that can be used to generate the majority of configuration options for applications that are uncooperative-by-default. The goal is to eventually just be able to run one command to generate 99% of your configuration, leaving you to focus on the other 1% which should essentially be your preferred shortcuts and workspace layout options.

komorebi dev here. I can't tell you the number of times I've wanted to just write my own take on sxhkd[1] for Windows and use that to manage my own keybindings for komorebi instead of ahk.

You can just as easily write your own/use another hotkey daemon or PowerShell scripts to handle komorebi's configuration and keybindings, in that sense there is no dependency on ahk at all. However, the inertia around ahk in the Windows ecosystem is undeniable and it's in the interests of making adoption and onboarding easier that the project provides example ahk files and has invested in an ahk code generation library.

My thoughts on the dominant hotkey daemon in the Windows ecosystem aside, I remain convinced that the famous bspwm socket communication architecture[2] is the best way to handle both configuration and keybindings for a tiling window manager that has been proposed to this today.

Unfortunately I have to concede that there is a certain configuration burden that comes with komorebi, which is amplified in some cases by having to write/maintain ahk. This configuration burden is largely due to the highly fragmented nature of Windows application development that is discussed often on HN and it is inescapable.

With this in mind, the next release of komorebi (currently available on master) will invest even more heavily in automatic configuration generation.

A separate repository of common application-specific configuration tweaks[3] (in YAML!) has been created which I and others from the komorebi Discord server are contributing to, with the goal of having the edge cases for as many applications as possible fully documented so that a comprehensive configuration file can be generated[4] for the user which ensures that every (major) Windows application behaves as expected under a tiling window manager.

I hope that other Windows tiling window manager developers can use these YAML definitions in the future to handle the same edge cases in their projects so that eventually there will be a tiling window manager of every flavour (bspwm, i3wm etc.) available for Windows users where having to manually accommodate and compensate for the non-standard behaviour of individual applications is a thing of the past.

[1]: https://github.com/baskerville/sxhkd

[2]: https://github.com/baskerville/bspwm#description

[3]: https://github.com/LGUG2Z/komorebi-application-specific-conf...

[4]: https://github.com/LGUG2Z/komorebi/#generating-common-applic...

kanata[1] and komokana[2].

kanata is basically like QMK for any keyboard without the firmware requirement. I use kanata with my trusty old iMac keyboard which is to this day my favourite keyboard of all time. But now I have all the cool QMK-style layers with it.

So that is awesome on its own, but where it gets even better for me, and this is where the seconds have really added up to hours, is that I wrote another piece of software which programmatically changes layers on kanata whenever a different window is focused in my tiling window manager.

This has honestly changed -everything- for me. I no longer have to waste keys on my keyboard to switch layers, I no longer have to -think- about switching layers, I just focus another window with alt+hjkl and whatever keyboard layer I expect for any given application is automatically applied. Definitely one of those "you can never go back" experiences for me.

[1]: https://github.com/jtroo/kanata

[2]: https://github.com/LGUG2Z/komokana

I have an Ergodox EZ sitting collecting dust these days. I got a great deal of use out of it and before long I was compiling my own firmware and making use of various advanced QMK features that were not available through the online visual layer configuration tool.

The keyboard has great build quality, the customer service is great (I got a free replacement for the right half after an issue with one of the keys), the ortholinear layout isn't that difficult to get used to, but ultimately the issue for me was that my hands aren't big enough to use the keyboard comfortably or to type as accurately as I'd like / as I'm used to typing.

I'm now back on my Apple Magic Keyboard and happier than ever, though with a few tweaks and improvements taken from my time using the Ergodox EZ.

I am now using kanata[1] which allows me to have multiple QMK-style layers on my regular old keyboard. This is already a huge step up from my pre-Ergodox days! I also like that I can have my layer configurations version controlled in a plain old git/dotfiles repo.

Since the layers are handled at the software level, I wrote my own integration with kanata, called komokana[2] to switch keyboard layers programmatically based on different state events emitted from my tiling window manager[3].

What that means in practice is that my keyboard can automatically switch to an app-specific layer when that app's window is focused, or to a workspace specific layer, or to a browser tab-specific layer, or really just switch on any event emitted by the window manager or any specific window manager state.

For me, this is really the killer feature of my setup now, and one that I don't think would be anywhere near as easy to implement with QMK which sits at the hardware level.

[1]: https://github.com/jtroo/kanata

[2]: https://github.com/LGUG2Z/komokana

[3]: https://github.com/LGUG2Z/komorebi

Hello friends! You may know me from my previous posts about my tiling window manager and my automatic keyboard layer switcher (or maybe even my harebrained attempts to get Helix to behave more like Vim!)

With all of these pieces now in place, I am very happy to introduce komokana. an automatic application-aware keyboard layer switcher for Windows.