komorebi-application-specific-configuration VS PaperWM

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...

But with auto-tiling you need to place windows according to a pre-set configuration, it needs to fit whatever layout you want to go for and it needs to be able to resize the window without breaking the content. This works pretty well for libadwaita apps, but a lot of webapps seem to assume a certain minimum window size. Another issue is how to handle modal dialogues, where paperwm for example sets an override to ensure they're not attached to the main window. Should the settings window then be treated as a separate window and tiled, or should it be left floating above all others?

I like Gnome's simplicity, agree with most of its deviations from the tired old Windowsy desktop status quo, and am very happy to depend on all its great integration work. I can't quite live with the simplistic window management, but extensions cover that (as they do much else). With Fedora + Gnome + PaperWM, I'm quite at peace with the current linux desktop situation.

Still I'm looking forward for something like PaperWM to be possible in KDE - or even to write it by myself

I have noticed in one of your comments in this thread that you are looking for novel ideas of the UI look. As others commenters stated, you might be interested in tiling window managers like i3 [0] or sway [1]. They are truly a gem for productivity and sometimes for an eye [2].

However, I love the concept of scrollable window manager like PaperWM [3] is. When I had a smaller screen (24" 16:9) I was complaining a lot on unused space on my screen. With PaperWM I was finally happy with its dimensions, because I could have huge IDE on the left and small part of terminal displayed on the right. That way I knew if something was printed to terminal, while my editor took 80% of the screen.

[0]: https://i3wm.org/

[1]: https://swaywm.org/

[2]: https://www.reddit.com/r/unixporn/

[3]: https://github.com/paperwm/PaperWM

If you want something really different, give PaperWM a shot.

You may want to try PaperWM (GNOME extension) https://github.com/paperwm/PaperWM