UI idea: Mixed-mode window decorations

[jpetso]

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:

UI idea: Column-titled window decorations

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 K…

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.

1. Mock-up of a page in System Settings. (There’s an annotated version further down, you don’t have to hunt for differences.)

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

[johnandmegh]

For what it’s worth - while this isn’t my personal taste (I would always choose a big honkin’ colorful SSD titlebar), I think it’s a very elegant approach to implementing that integrated titlebar + top-of-application style

Just curious, in the Breeze Classic color scheme example, what parts of the title/headerbar would you see as being colored-in?

[ostfriese4]

@jpetso

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.

This could be problematic because the app does not know how much space the window-controls need.

My Idea would be:

1. The compositor asks the app to keep 200 px on the right side and 50 px on the left side free.
2. 1. The app disagrees and uses normal SSD
   2. The app does not answer (does not support the protocol) and uses either SSD or CSD (gtk)
   3. The app agrees and optionally returns an area that can be used to drag the window. This area is drawn by the app but interactions (like scroll to maximize) are managed by the compositor

• The compositor can re-ask for free space every time the settings change
• The app can change the dragging-area every time the contents change

[jinliu]

If we focus on the “excessive duplication of page titles” problem, and ignore “combined header bar” for the moment, then the simplest solution is for systemsettings (and all other single-instance apps) to just remove the page title from its window title, because there won’t be multiple systemsettings windows, so you don’t need the page title (or document name) to differentiate them. The same case for Discover. (Your proposal requires the same change, anyway.)

Dolphin is a different case. We do have a duplication between the window title and the location bar here, but while we probably do want the window title to only show “Dolphin”, we still want the location name in task manager, window switcher, etc. when there are multiple Dolphin windows.

So we probably should allow apps to set a “short window title” (that doesn’t include document name / page title) for the decoration, in addition to the current “(long) window title” for (icon and text) taskbar, window switcher, etc., because the “duplication” only happens in the app window.

This doesn’t necessarily require a new protocol. Maybe we can use some invisible Unicode characters to mark the “short” part in the title, and hope it won’t disrupt existing compositors.

[CeruleanDerpo]

The thing is that the title that gets shown on the title bar is also visible on the panels’ tooltips, where it is useful

[veryfat]

And here I was just yesterday lamenting at my work PC running windows 11 how I dislike how MS puts search bar and other function bars on the title bar in stuff like teams and office. In this user’s humble opinion, the title bar is not a place for anything else but the Window Menu on the left, window title in the middle and the 3 buttons on the right. With 90% of it serving simply as space to grab and move the window. I strongly prefer the unmodified screenshot to the mock-up you made. I like the way KDE has the windows’ title bar relatively thin so that not much of screen space is wasted by the “empty” drag-and-move (and double-click to maximize/restore) title bar space. I would even go as far as saying that this (classic) KDE’s current approach is a part of why I use KDE and not other desktops I don’t like like Gnome or, heaven forbid, windows. I would hope that if your suggestion makes it into KDE in the future, there would at least be an option somewhere in settings to keep it how it is currently. All this is just one user’s opinion of course, sorry that I don’t like your idea.

[xdenyer]

It feels like complexity for the sake of it?

I use normal title bars on things like browser windows personally. Not very bothered about how consistent things are within windows in terms of different toolkits, but with the view that window furniture should be consistent and individual developers that think they know better than users and try to insist on being exceptions without very good reasons can take a long walk.

A few things that aren’t everyday usage apps slip by if they’re useful enough, but title bars are there for showing unabbreviated titles and as a convenience for window movement without reaching for the keyboard. It also means they don’t need to be particularly tall taking up space, and the user can tailor that to preferences.

Allowing devs to override has always mainly seemed to be a symptom of the rot that one interface can/should fit drastically different screen sizes and pointer/touch input paradigms rather than giving each interfaces that suit them best.

[meven]

FYI, There is a proposed protocol that would allow apps to do some of those ideas, if I am not mistaken: draft: allow apps that support cutouts to draw below the titlebar (!9603) · Merge requests · Plasma / KWin · GitLab

[ngraham]

I do like that there’s no longer duplication of titles. I also like the left-aligned app name.

I have a few questions and concerns:

With this proposal, it seems like we’d need two UIs for each app, right? One conventional, one specific to compatible compositors that agree with the app’s respect. So, double the layout work for the header area? I wonder if this is realistic.

I’m not in love with the visuals; I think it’s no longer clear what’s drawn by the app and what’s drawn by KWin. With the GNOME and MacOS approaches, everything looks unified, like it’s drawn by the app (even if the window manager is doing the buttons). With this, it’s clear that there’s some difference, but it’s not clear where it lies. This is a current problem with the existing header-color approach, but I feel it gets worse here. If we want to draw a hard separation between the two, I feel like the visuals should match the implementation.

What happens when the page becomes scrollable? Do “Mouse” and “Configure extra buttons” also scroll away, or do they remain in place, and a separator line appears below them? If the latter, I don’t like this; it makes it hard for the user to visually parse the UI and tell what lives where, or grasp the visual hierarchy. IMO something should only appear to live on an area that’s scrollable if it can scroll away.

Is the window draggable only bu the darker gray areas provided by the compositor? Or any any areas where the titlebar used to be?

How would this handle apps that do want a traditional-style toolbar? Where would it go and how would it look?

---

I think for me, the bottom line is that if we want to improve the situation, we need to stop visually misleading users, and make sure things that are functionally distinct look visually distinct.

[jpetso]

Hey everyone! Thanks for all your feedback. I wanted to respond with more mock-ups, but I haven’t made more so far, so let’s address your points in textual form for the time being.

@johnandmegh

Just curious, in the Breeze Classic color scheme example, what parts of the title/headerbar would you see as being colored-in?

I was thinking that both server-side areas would be colored-in:

• The part above the “< Back” button, from the very top left to the vertical divider line. That part would be as tall as the traditional titlebar appears right now, i.e. just the background of the “System Settings” window title, but not including the “< Back” button.
• And also the top-right area. Note how the background behind the close/maximize/minimize buttons is the same shade of gray as the background behind the “System Settings” window title. That gray would change to the dark blue-gray titlebar background color of Breeze Classic, while the lighter gray of the page background would remain untouched.

A modified mock-up would be better than describing it with words. Sorry! Maybe in a bit.

@jinliu

If we focus on the “excessive duplication of page titles” problem, and ignore “combined header bar” for the moment, then the simplest solution is for systemsettings (and all other single-instance apps) to just remove the page title from its window title, (…)

You’re right of course. Perhaps I was overly ambitious in trying to give more space to pages as well. Either way, I’m happy with the discussion that this post has kicked off here and on Matrix. Maybe something good will come out of it one way or another

@jinliu

This doesn’t necessarily require a new protocol. Maybe we can use some invisible Unicode characters to mark the “short” part in the title, and hope it won’t disrupt existing compositors.

Plasma’s hover tooltip for window/apps in the panel already splits the app name from the “short” part of the title. Probably some heuristics involving a windowTitle.endsWith(appName) or such. It doesn’t work for everything, for example Element which looks like “Element * | My Matrix Room” with the asterisk indicating “unread”. Explicit protocol IPC could help with consistency, but I agree it’s not strictly necessary.

@CeruleanDerpo

The thing is that the title that gets shown on the title bar is also visible on the panels’ tooltips, where it is useful

That’s true! What I had in mind is that the app keeps setting the (traditional) window title as it currently does, but the presentation for mixed decoration mode is expected to look different.

@veryfat

I would hope that if your suggestion makes it into KDE in the future, there would at least be an option somewhere in settings to keep it how it is currently.

If I had any say, I would definitely insist on an option to keep the traditional titlebar for all windows (as long as they aren’t full CSD like in GNOME; in that case there’s little we can do about it). I think it’s important that apps don’t rely on mixed-mode decorations to be supported. This proposal is about making something new possible, not about removing existing functionality.

@xdenyer

It feels like complexity for the sake of it?

Not in my opinion. I mentioned in my post the duplication of page titles, as well as the way that the Kirigami framework encourages simple applications to waste screen space on a toolbar that they might not even need. I think these are real problems that deserve to be solved. Maybe there are different, simpler solutions than what I proposed here.

If other KDE devs don’t agree that these are problems worthwhile solving, or if my proposal isn’t good enough, then things will stay as they are and KDE app design will develop into a different direction.

For reference, I also enable the system titlebar for browsers on my system, because filling the entire titlebar with tabs takes way too much space for my liking. Personally, I think there’s a pleasant middle ground to be found between filling the entire titlebar with controls vs. not allowing any app-specific content across the entire top edge of the window.

Nate asks a number of hard questions, let me get back to those in a different comment.

[jpetso]

@ngraham

With this proposal, it seems like we’d need two UIs for each app, right? One conventional, one specific to compatible compositors that agree with the app’s respect. So, double the layout work for the header area?

Actually no, the goal here is to allow a single design that works with mixed-mode decorations and gracefully handles the fallback to traditional full-width titlebars. In this design, the fallback would work like this:

1. The hamburger menu stays in the titlebar, where we already have a button for it.[*]
   • Maybe instead of sticking to the right edge of the top-left titlebar area, it gets placed immediately to the right of the window title as no such right edge exists in the full-width titlebar.
2. The page header including page title (“Mouse”) and contextual page actions (“Configure Extra Buttons…”) move down below the titlebar.
   • As the page header moves down, it doesn’t have to share horizontal space with the top-right window controls, so it has more space available on the right. This being an auto-expanding layout, it moves the contextual page actions to the right edge of the window.

So the final layout would very similar to the current one, except there still isn’t a horizontal divider line between page header and page contents. One implementation handles both titlebar modes.

Again, another mock-up would really help to demonstrate my thinking here.

[*] Yes, I am aware that there are implementation issues with assuming that the hamburger menu can always be located in the titlebar. KWin does support titlebar hamburger buttons, but not through a widespread Wayland protocol, instead through a legacy D-Bus protocol that we adopted from old Ubuntu versions. This means we have to think about what happens in non-KWin compositors. Maybe moving the hamburger menu into the titlebar is a pipe dream, and including it here needlessly complicated this proposal. Oh well; one can dream.

What happens when the page becomes scrollable? Do “Mouse” and “Configure extra buttons” also scroll away, or do they remain in place, and a separator line appears below them?

Admittedly I had not put enough thought into this to have a good answer to this question. And yes, this is an important question.

I think “Mouse” and “Configure Extra Buttons…” can’t just scroll away, they have to remain in place. If they scrolled away, then the entire rest of the page would need to scroll up to the top of the window, and various controls like the “Device” drop-down would have to partially hide behind the titlebar area. That would be super awkward both in terms of looks and usability.

So however much space the app dedicates to the titlebar in the top-right corner, the page that shares this space with the titlebar should keep its header fixed. The scrolling page contents would need to disappear underneath.

My thinking is that, for a page that’s taller than the window (so it needs to scroll), we’d have to reintroduce a horizontal divider line like the one from the existing header toolbar. Just like we only show the scrollbar of a page when there is anything to scroll in the first place.

As it stands, my design isn’t clean enough to make this look good both with and without horizontal frame above the page contents. We’d have to iterate on it to see if we can make it look good both with and without.

Is the window draggable only by the darker gray areas provided by the compositor? Or any any areas where the titlebar used to be?

Any area where the headerbar used to be, except if there’s a control on it. So in practice, the following areas would be draggable:

• The top-left compositor titlebar area, including the “System Settings” window title (minus buttons).
• The page title (“Mouse”) and all of the empty space to its side, except for the “Configure Extra Buttons…” button which steals inputs from the headerbar by having its own click handler.
• The top-right compositor titlebar area (minus buttons), i.e. the dedicated drag space that we mandate for this area.

How would this handle apps that do want a traditional-style toolbar? Where would it go and how would it look?

Toolbars tend to be full of buttons, which are not drag space, so apps want to be careful about not putting too many controls into the very top of the window.

In general I think there are two cases to consider:

• The toolbar contains just a tiny handful of buttons that don’t need a lot of space.
  • Say, an app like Konsole that only needs “New Tab”, “Split Tab”, and “Find”, plus maybe “Copy” and “Paste”. At least three of these can easily use the icon-only buttons, if not all five.
  • IMO, the toolbar for these apps can be placed next to the compositor’s window title and window buttons. I’d use GNOME’s Document Scanner (a.k.a. simple-scan) as example, except in my design all of the buttons would go in the center of the title.
• The toolbar contains a large number of buttons and takes up as much space as it can get.
  • Honestly, for this kinds of app I don’t think it makes much sense to ask for mixed-mode decorations. Just use a traditional full-width titlebar on top of a traditional full-width toolbar.

More generalized, I’d say stick with a traditional titlebar unless your ideal headerbar/toolbar controls easily fit into the narrower horizontal space that an MMD design provides.

I do think we’re going to have to look at cases where the app generally uses MMD (like the System Settings mock-up here) but some pages ask for a more extensive toolbar. I figure we’d prefer if System Settings doesn’t regularly switch back and forth between full-width titlebar and MMD. So we’d still need designs that move a relatively full headerbar (e.g. on the “Global Theme” page) into a toolbar below the page title.

It could get messy.

I think for me, the bottom line is that if we want to improve the situation, we need to stop visually misleading users, and make sure things that are functionally distinct look visually distinct.

Point taken. Applied to this design, I think this means: “If the page header is fixed and allows dragging, whereas the page contents are scrollable and do not allow dragging, then we shouldn’t share the same blended background between them without divider lines.”

I think in theory, the inconsistency is fixable:

1. Make the entire page background draggable, not just the headerbar.
2. Visually separate the headerbar from page contents only if the page contents are scrollable.
   • If page contents are scrollable, dragging the page background would scroll the page, not the window. This still makes sense imho

Thanks for asking the hard questions! Maybe we can address these in a coherent story, if not then this proposal gets shelved again. But hey, at least I gave it a shot.

[Atem18]

That design looks great, it makes the apps look more modern and finally cut on wasted space.

[techperson3033]

someone please make this a window decoration style for kde I can’t handle the wait

[jinliu]

Can’t be done with a window decoration alone. Apps need modification to leave the room for the decoration.

[smileyhead]

I will also put my two cents in.

Personally, I very much prefer having a clear distinction between the title bar and page contents, so the page colour bleeding into the title bar, as well as the vertical title bar colour areas in the left and centre being unaligned look very unappealing to me. (I also don’t like how GNOME’s mixed-mode title bars make every button unnecessarily large, wasting a lot of space unless you’re using a touch screen.)

Short tangent about page title bar buttons

Adding to this, I’ve never really understood the relation of buttons included in the page’s title bar. It’s like a sub-page within a sub-page? Couldn’t that be included in the normal hierarchy on the left, or as a tab or button inside the main page? Regardless, I will ignore this in my suggestion.

I would suggest moving the Back button inside the list (on the precedent that some file browsers include a .. option at the top of their lists) and moving the Menu button up into the title bar. With this, the entire mixed-mode title bar can be made as thin as the regular one, while retaining clear distinction between the title bar and page contents.

With this, the left and right edges are reserved for window decorations, with a little margin to ensure dragging space, and then the centre bit can include the entire toolbar as-is (as horizontal space loss is minimal), or otherwise be customised by the application.

I’ll also post some more edits in different contexts:

Konsole:

Dolphin (with and without menu bar):

@jpetso

• Say, an app like Konsole that only needs “New Tab”, “Split Tab”, and “Find”, plus maybe “Copy” and “Paste”. At least three of these can easily use the icon-only buttons, if not all five.

IMHO, labelled buttons should not be consolidated to icon-only (heck, as many buttons as possible should be labelled) for mnemonic accessibility.

[techperson3033]

How… did you get this on your main system? It litterally looks well, so real. That says something in Hungarian, so I translated it. It’s “My folder”.

[smileyhead]

I didn’t – I just edited screenshots I took of my own system, which is set to Hungarian. The folder you’re talking about is the user folder.

[Atem18]

That looks great @smileyhead. There is already a proposal to have a local menu in the title bar : Draft: kdecoration: Add support for locally integrated menus (!529) · Merge requests · Plasma / Plasma Breeze visual style · GitLab so why not having other buttons.

[smileyhead]

Ah, interesting! I like this very much. Perhaps, the integrated toolbar could also be a window decoration option, with the in-app version automatically hidden if the decoration is in use.