Hi! A long time ago, I posted this set of mock-ups in search for a way to keep server-side window decorations (SSD) while also cutting down on the excessive duplication of page titles across KDE apps:
Needless to say, this wasn’t good enough to inspire further efforts. Let’s have another go!
I’ve heard people talk about another way forward, taking inspiration from macOS which allows apps to customize the titlebar while their OS still draws the three colorful window buttons (close, minimize, maximize).
I seem to remember that compositor people called this concept “mixed-mode decorations” (MMD), although my memory may deceive me because I can’t find any references to this term with a quick web search. It’s a middle ground between server-side decorations (SSD) where the compositor draws the entire decoration above the window content, and client-side decorations (CSD) where the app draws everything, including even the close button, usually with a common library underneath (e.g. libadwaita/libdecor).
The MMD concept is different from another historical suggestion called DWD. With DWD, the compositor would draw the entire titlebar by itself, same as SSD, but there would be a rich protocol to ask the compositor for widgets to include in the titlebar.
With MMD, the compositor sticks to just the responsibilities it already has for SSDs - window buttons, window title, a few optional buttons like a hamburger menu or always-on-top, which can be configured by the user.
Before I get into too many details and lose your attention span, I should probably get started with the pictures.
- Mock-up of a page in System Settings. (There’s an annotated version further down, you don’t have to hunt for differences.)
- Unmodified screenshot:
Let’s unpack this. MMD works like this:
- The app draws a surface with window contents.
- The compositor (e.g. KWin) overlays titlebar contents on top of whatever the app draws.
- App and compositor negotiate (via Wayland protocol) what parts of the titlebar get drawn in how large of an area.
In this proposal, the compositor remains responsible for the contents of the top left and right corners of the app. The app gets to draw anything in between, and also gets all the input events so it can react to clicks except for the titlebar corners.
Negotiation means that the app says to the compositor something like,
- On the left side of the window, I have 374 pixels width that you can draw on. I use a light theme to draw the background there. Fill that space, and make the titlebar as tall as you like.
- On the right side of the window, I have a maximum of 550 pixels width that you can draw on. I use a light theme to draw the background there. Please keep the width as narrow as possible, and make it a fixed 59 pixels tall (the size of my page header).
The compositor considers this request. If it agrees, it confirms to the app that it will paint both the left and right corners, with width and height for both titlebar areas respectively.
If the compositor doesn’t like it, it tells the app nope, sorry, we’ll use a regular SSD titlebar instead. Please line up your controls like you usually would.
Here’s a breakdown of how the mock-up differs from the current status quo:
The foundation of this whole design is the dismantling of the header bar from Kirigami’s PageRow component. In its current state, it draws a long horizontal line across the whole window. The app has to use that space, regardless of whether it has a need for it. So the app fills the space with titles that are already duplicated in the real titlebar. Or it wastes a lot of space, and then fills it up with random buttons to avoid letting all that space go to waste.
You get it, I’m not a fan of the header bar. If we want to reduce title duplication and make space-efficient, good-looking apps, then each page or sidebar must be encouraged to make its own layouts from top to bottom. No more assumptions about one page continuing the horizontal line of another one to its left or right.
So this mock-up throws out the long horizontal header bar. We can move up the page title to the top of the window, because no framed underline would make it look weird and misaligned with the sidebar on the left.
Without a toolbar surrounding them, any contextual page actions now have to be drawn as actual buttons or they just look like regular text. This is generally a good thing in terms of usability.
This mock-up uses the slightly darker hue of grey for both the left and right titlebar corners. That’s the default color for active titlebars in Breeze Light. This mock-up also visually separates the right titlebar corner from the “Mouse” page background, which has a lighter hue of grey.
But this is just one way it could be drawn.
- The Breeze Classic color scheme paints a dark titlebar against a light background. This is possible here as well.
- The window decoration can decide not to draw its own background, and instead blend in with the app’s preferred background. With proper negotiation, this shouldn’t be a problem.
- The compositor could decide to only take on one of both corners, or (as mentioned) fall back to a full-width regular titlebar.
Despite all the blending-in, the final decision remains with the compositor. Which preserves the ability to configure and theme the titlebar independently from the app itself.
I think it looks better than my previous attempt. Hopefully also easier to advocate for.
Let me know what you think of this! At this point it’s just a design concept without any plan for implementing anything.
