So the argument against client-side decorations (CSD) is mainly that we trust the compositor to do a better job at providing basic window management functionality than the app would, plus we’re skeptical about the app plastering the title bar with buttons and tabs that take away from a consistent place to click, grab, and move it. Like so often, Nate wrote the canonical blog post about concerns that keep the KDE community more attached to traditional server-side window decorations (provided by KWin).
Y’all are also obviously aware of GNOME apps being all in on CSD, which combined with libadwaita dominance leads to arguably beautiful user interfaces such as these screenshots of Errands or Flare. Meanwhile, Kirigami is lost in the nowhereland between drawing page titles, but then not fully committing to it. As a result, we get apps with a window decoration that doesn’t just avoid providing interactive controls for app functionality, but also duplicates the same titles that are already taking up a lot of space in the app’s main surface.
Here’s a current screenshot of System Settings (Plasma 6.0) to demonstrate. I picked a wide view to include three Kirigami pages instead of just two, hopefully capturing Kirigami’s page stack design language well:
You see where this is going. Out of three pages, two are using the default large Kirigami titles. The leftmost and rightmost page are additionally using controls in the toolbar. Use of space isn’t particularly efficient, especially when we consider that this app gets used on low-res devices like the Steam Deck which don’t have a lot of vertical space to begin with.
I’d like to suggest a new Wayland extension that (optionally) lets the app communicate columns of titled pages to the Wayland server. Each column declares a title, location and width within the window, and maybe some extra metadata like preferred column header background color. If the server supports this extension and agrees, it will draw the declared page titles in the window decoration, depending on theme. Apps, and Kirigami in particular, can then optimize their own use of space by using the space for actual content.
Here’s an amateur GIMP mockup to convey the idea:
Note how the middle column can now use the entire height of the window view, and the rightmost page is able to fit in an extra control (here: search bar. but could be anything, depending on the page) that would have otherwise had to replace the page title. Now we get both, and the long vertical grid view gets more space for showing actual themes.
I can’t think of any real negatives. No clickable space is lost. The compositor retains full control over whether and how these column titles get rendered. Apps make much better use of the potential wide space in the window title, leaving more room for other content. We can expose this in Kirigami as runtime optimization upgrade, making use of it if supported and leaving everything as is (or switching to evil CSD mode!) if the compositor says no.
Any reason why this may not be a viable idea? Shoot some holes in my proposal please. Thanks!
… yes, i know they are colors, ffs that’s why i’m here.
