komorebi-application-specific-configuration

so consumed by at least one other window management project, Whim[5]. I think a lot of existing tiling window manager users from Linux and macOS look for straight "equivalents" on Windows if they end up here, but from my point of view both as an end user of tiling window managers and a developer of a tiling window manager, this is a huge missed opportunity. Komorebi initially took a lot of inspiration from bspwm and yabai, but as I spent more time working with different monitors (square, wide, ultrawide) in different orientations, I became more and more convinced that a layout algorithm-driven design provides for a better overall experience than painfully manually manipulating a BSP tree to do something as simple as getting 3 columns on an ultrawide. More recently I also integrated some interesting ideas from more niche WMs such as PaperWM[6]. Tiling window manager development on Windows is really at the bleeding edge of the entire field these days, where the boundaries (especially in UX) continue to be pushed unencumbered by the inertia of established heavyweights and tradition. Within the next decade I wouldn't be surprised to see this come full circle and find people implementing "Window Manager ___ From Windows, but for Linux/macOS". [1]: https://www.youtube.com/watch?v=JNZw0qUf_PE [2]: https://github.com/LGUG2Z/komorebi/commit/45894be4ff5162e1c2... [3]: https://github.com/LGUG2Z/komorebi-application-specific-conf... [4]: https://lgug2z.github.io/komorebi/example-configurations.htm... [5]: https://dalyisaac.github.io/Whim/docs/customize/filtering.ht... [6]: https://github.com/LGUG2Z/komorebi/commit/b799fd30774b5ae928...

ain configuration format preferred by the community[6] Most interestingly for me, I used the subscription service to write an automatic application-aware keyboard layer-switcher[7], which means that I never have to store a key binding to switch between programmable keyboard layers ever again; whichever window I switch to with my tiling window manager, if there is an application-specific keyboard layer that I have defined with custom bindings or shortcuts etc specifically for that application, they get automatically applied without me even having to think about it. It's such a huge productivity booster, a real "the future is now" moment for me personally. [1] https://github.com/LGUG2Z/komorebi/#dynamically-changing-lay... [2] https://lgug2z.github.io/komorebi-custom-layout-generator/ [3] https://github.com/LGUG2Z/komorebi/#window-manager-event-sub... [4] https://github.com/LGUG2Z/komorebi-application-specific-conf... [5] https://github.com/LGUG2Z/komorebi/#generating-common-applic... [6] https://github.com/LGUG2Z/komorebi/#autohotkey-helper-librar... [7] https://github.com/LGUG2Z/komokana

ions * Dynamically select layout based on the number of open windows * Configure work area offsets to preserve space for custom taskbars * Toggle mouse follows focus * Subscribe to event and message notifications If you want to see what komorebi looks like in action, there are two great little demos from komorebi users on the project readme. For me personally, the coolest new features in this period have been: * Being able to define custom layouts in YAML and JSON, this is really awesome and has been a total game changer for me, and in many cases space can be used way more efficiently than a traditional BSP layout on wider-than-average monitors. There is also a visual custom layout generator[1] that you can play with to generate the JSON for your custom layouts! * Being able to set rules to automatically change between different built-in and custom layouts depending on the number of windows open on a screen. This is one of those things that seems so simple in retrospect but I haven't seen it implemented in other tiling window managers. Maybe you think BSP works well with up to 3 or 4 windows on the screen, but once you go over that, you want the workspace to switch to a different custom layout that you think is more space-efficient and productive for a higher number of windows. No problem! Just tell komorebi which layout to switch to once a certain threshold of open windows has been reached! * A push-based event subscription API that allows other applications to subscribe to the latest komorebi events. This is in particular super useful if you want to write your own status bar. yasb[2] is a great example of a status bar written in Python that subscribes to the latest events from komorebi to always show the most up-to-date information about workspaces and application windows to the user. * Introducing a decoupled library of application-specific fixes[3] in YAML that can be used to generate the majority of configuration options[4] 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. If you're interested in trying out komorebi for the first time, it is now easier than ever as you can now install it directly from the extras bucket with Scoop! If you have any questions about using Rust to develop for Windows, writing your own tiling window manager, or even anything you spot in the project code that you'd like to discuss I'll do my best to answer in the comments. [1]: https://lgug2z.github.io/komorebi-custom-layout-generator/ [2]: https://github.com/denBot/yasb [3]: https://github.com/LGUG2Z/komorebi-application-specific-conf... [4]: https://github.com/LGUG2Z/komorebi#generating-common-applica...

ger that has been proposed to this day. 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...