Window decorations revisited (or: using the right tool for the job)

User Interface Design 4 Minutes

Today let’s talk a bit about the importance of using the right tool for the job. There’s a bit about this in my post about KHamburgerMenu, about how it was not designed to be a universal thing for every app but rather the ones where it can makes sense. No need to shoe-horn everything into an identical paradigm.

So I want to use that context to talk a bit more about window decorations, and specifically client-side decorations–everyone’s favorite topic for getting the blood pumping! 🙂 But first, some terminology to make sure we’re all on the same page:

“Client-side” refers to content is drawn by the app or window itself (the “client”)

“Server-side” refers to content drawn for the app or window by something else (typically the window manager, or the “server”).

Now, KDE apps typically do not use client-side-decorated headerbars for their header areas like GNOME apps do. Instead, we generally hew to the traditional arrangement of a titlebar, menubar, and toolbar. The titlebar is “server-side” because it’s drawn by KWin, our window manager. Everything below the titlebar–such as the window’s menubar, toolbar, and content view–are drawn by the window itself; the window being a “client” of the window manager. Hence, “client-side”.

In the interest of aesthetics, our Breeze theme has recently been updated to visually merge these components, even though they’re still drawn by different parts of the stack and still serve different functions (though you can still drag the window from any empty area of the header, not just the titlebar). Here’s how it looks in Okular, a fairly traditional app with a titlebar, menubar, and toolbar:

…And for Dolphin, which has a hamburger menu in its toolbar by default rather than a menubar:

Not too bad, eh? Yet we have often been asked why we don’t use GNOME-style client-side decoration headerbars, which would provide the same merged look and save some vertical space too. I wrote a series of blog posts about this a few years ago which are still largely accurate, so I will paraphrase:

Why our apps don’t use CSD headerbars

If we did, they be worsened in the following ways:

  1. They would either lose a lot of space used for dragging the window, or else lose the ability to click-and-drag-and-release to activate headerbar items in menus, comboboxes, pop-up menus, etc. You can’t have both with CSD headerbars.
  2. There would be no place to display the name of the app, window, or open document–unless the app left a big empty space in the middle of the header for it. Even then it would be up to every app to implement this title itself, rather than it being an automatic thing provided by the window manager.
  3. We would probably have to remove or severely restrict how customizable the toolbar can be given the above restrictions on space.
  4. Also given the above restrictions, the CSD headerbar would probably have to omit some of the window decoration buttons currently present on the SSD titlebar, since they would be taking up a lot of space that apps would need. Customization flexibility would also be reduced.
  5. Windows would all have to have hamburger menus with no provision for a traditional in-window menubar, since there is nowhere to put one in a CSD headerbar without it looking really weird.
  6. When a window is not responding, the close button would not work to force-quit it, since it would be drawn by the thing that is not responding (the window) rather than a thing that is still working (the window manager)… unless the window manager itself implemented a hack for this. So it would not work in other window managers.
  7. It would suck for people using our apps on other platforms without window manager level support for CSDs.

So there’s your answer. 🙂

But wait, what about DWDs?

“DWD” refers to “Dynamic Window Decorations“, an old KDE proposal to marry visual appeal of CSDs with some of the functionality of SSDs by allowing the app to pass various actions to the window manager, which would then put them in the titlebar for the app. The proposal looked pretty like CSD apps do, and would have solved problem #6 and #7 from the above list, and improved on problem #4–but the other problems would have remained. So the idea was ultimately shelved and we did not apply it to our app windows. Too much cost, not enough benefit. That’s how it goes, sometimes.

Actually I lied, we totally use DWDs already… sort of

You might not have realized it, but Plasma’s System Tray uses the rough concept of the DWD paradigm and has for a few Plasma releases! Here, take a look at the Clipboard applet:

That “clear” action with the broomstick is drawn by the “server” (in this case, the System Tray popup) but the action came from the applet (which is acting as the client)! the Clipboard applet told the System Tray, “Hey, here’s a “Clear history” action for you to display with this icon, that tooltip text, and so on”. And the System Tray itself took care of turning that action into a clickable button. The Configure icon next to it is the same.

This arrangement was actually not deliberate; we kind of re-discovered the DWD concept by accident. But it turned out to work really well in the System Tray. This is because the System Tray popups don’t suffer from any of the remaining problems plaguing CSDs:

  1. The System Tray popup is not movable by dragging, so you can fill the top bar with lots of stuff without impairing that or losing the click-drag-release method of getting at menu items.
  2. The name of the applet isn’t robbing anything of space because because these are every small applets with a limited set of features; the number of actions is super limited.
  3. The header actions don’t need to be customizable because the full set of actions can be presented by default.
  4. Not being a movable window, there are no relevant window decoration buttons to customize, except for the single “Pin” button that keeps the popup open, which we can always show because there’s always space for it.
  5. These applets never had full menubars anyway, so nothing has been lost.

To be clear, there are still no DWDs for app windows, and there probably never will be–because they would basically just be slightly-less-bad CSD headerbars. However the DWD concept really shines for small platform-specific widgets!

It’s all good

So like KHamburgerMenu, we now have another tool in our toolkit. We can apply it to the parts of our software where it makes sense, without feeling the pressure to force it everywhere. Because the best craftsmanship really does come from using the right tool for the job.

Published by Nate

Published

22 thoughts on “Window decorations revisited (or: using the right tool for the job)”

  1. So we need something that’s a dumbed down app and a smarted up widget! =) hmmm, isn’t that something MAUI are doing right now? I haven’t tested any of it but I read that it’s pretty and power users hate it because it’s dumbed down or something. I’m sure in KDE worlds future there’s probably something like that as an option, maybe a global “easy” mode or something, that would use my newly invented upsmarted widgets: SMARTLETS! ..geez I need to lay off the caffeine..

    Like

    Reply

  2. I don’t like the waste of vertical space of a window decoration, but I want it to me managed by the window manager. I really don’t like unresponsive window decorations when apps are frozen, and that apps freely decide on the look and feel of it and obviously some space need to be there to allow moving the Window (though these days I don’t bother aiming at the decoration, I just use Alt+click to move windows).

    Ten years ago, I implemented a window manager in JavaScript. I did not have any clue that CSD existed but really liked that the app could draw widgets in the window decoration.

    Apps could request a surface to the window manager and add widgets in it. The window manager added this surface next to the window title. Apps could require minimum height for this surface.

    You had both widgets in the window decorations, and “SSD”. You also had customizability for the window decoration (look and feel, button order…), and an area to grab the decoration where the window title was drawn.

    I used this feature to draw tabs in the window decoration. The feature was optional so apps had to handle the case where the window manager didn’t support this feature and put their widgets elsewhere.

    I wonder if such a thing would be possible or desirable today in the free desktop ecosystem. I imagine nor Wayland nor X11 are designed in a way that makes this possible, though I have not looked into this.

    Like

    Reply

    1. It’s an interesting idea. This is what Microsoft Office apps do, in fact: They provide a space for a few actions to be displayed in the SSD titlebar.

      The thing is, this isn’t really a game-changing paradigm. It mostly gives you to a slight speed boost for clicking on those actions since they benefit from Fitts’ Law when the window is maximized. And it’s also most useful when the toolbar content below the titlebar is dynamic and always changing, as with the case of a Ribbon UI. If that toolbar content is static, then isn’t such a big advantage to putting some buttons in the titlebar, because they could just as easily live in the static toolbar instead.

      Putting tabs in the titlebar strikes me as only being functional working with a very very small number of tabs. The need to preserve space for window dragging and showing the title means that the space for tabs would have to be limited to half the window width or less. Imagine if you had 10 tabs open, which is, like, the bare minimum for a lot of people with their web browser. The limited amount of horizontal space would then them into indistinguishable little stubs. The gain from being able to trigger them more easily with the mouse due to Fitts’ Law would be offset by their reduced size and distinguishability. I don’t think it would be a clear win. Maybe it would be better for tabbed document-based apps where you rarely have more than 4 or 5 documents open at once. But I don’t think it would ever work for browsers or other apps where there may be zillions of tabs.

      Like

    2. Indeed. Actually, the tabs I used in this “app” where for switching modes, so there were in small, fixed number. I should have mentioned that.

      > But I don’t think it would ever work for browsers or other apps where there may be zillions of tabs.

      For tabbed apps like browsers, showing the title is redundant with the label of the currently active tab, so you can remove the title. You avoid tabs going to an impossibly small width by making the tab list becomes scrollable at some point. The drawbacks are the small area to drag the window (I add a spacer between the tab list and the window buttons for that, on Firefox), and the window title being very small (the width of the tab). However, these drawbacks are weaker for me than the UI being as much out of the way as possible when browsing. I still don’t like that the window is managed by Firefox though.

      Like

    3. I don’t think the window title is redundant with the tab title. The window title is always longer than the tab title by usually an order of magnitude. Even two tabs with each one horizontally filling the available space will result in most titles being elided.

      Like

    4. IMO the browser should show the full title in the address bar. Browsers are the few areas where tabs in the title bar are superior with the Fitt’s Law advantage. GNOME have gone overboard though putting CSDs everywhere when only a select few applications would benefit from it.

      Like

  3. I propose two solutions.
    1. Allow window to tell WM, he need to use CSD or DWD (you choose). In this mode, small titlebar would been rendered, when mouse cursor is not above window. Titlebar would also be visible, when user move cursor to top of window. User do not need to be informed about window title if he/she already working with it (because user should known it already).
    2. Place any CSD bellow titlebar, when user activate special button – show titlebar widgets.

    Also, in both ideas – you could allow user to configure, which widgets shown in titlebar or panel bellow it, such like user already do with each window. Simply – application tells, which windows (role/title/etc.) delivers which buttons (name/icons/actions) and user could right click on titlebar or DWD/CSD and select configure and select, which buttons window should shown.

    Like

    Reply

    1. So you’re basically proposing that a titlebar be drawn for CSD windows but get hidden when the cursor is within the window? What would happen if the window was tiled to the side? Where would the titlebar go when you move the cursor out of the window?

      Like

    2. The titlebar (first proposal) will be shown in two cases:
      1. User move mouse cursor outside window
      2. User move mouse cursor on top of window

      Second proposal is different. We shown normal titlebar, but add button to show additional menu/panel.

      Like

  4. There’s another major difference between something like the applet and standalone app: you will never run the standalone applet with anything else besides KDE and thus it’s irrelevant how do other environments handle decorations, avoiding the problem of running a SSD-expecting app on a CSD-expecting environment and having no window bar at all. Recently, this turned out to be a problem with Electron apps on Wayland.

    Like

    Reply

  5. DWDs is the way. Just about recently I needed a screen annotation tool and I couldn’t find a better alternative than openboard which is not totally great but better than nothing. Now I think DWDs could be used separately almost like a TV remote. I am not yet a KDE developer yet, but I can see the so many opportunities and the trophy.

    Like

    Reply

  6. As I said above, I think CSDs have an advantage in limited circumstances, such as web browsers where you get a space saving and Fitt’s Law advantage of having the tabs in the titlebar. It would be a disappointment for you to abandon the DWD idea entirely, as I will not use Falkon, for example, as it does not have the efficient tabs-in-titlebar design.

    That said, GNOME have taken the CSD idea to a stupid obsession where they are pushing it in every app for “consistency” rather than realising that each application needs to be suited to its function. The result is that I now find many GNOME apps clunky to use as have multiple confusing hamburger and elipsis menus when a traditional menu/toolbar would be far simpler.

    Additionally, while on the topic of window decorations, I really don’t think the Breeze window button icons are as intuitive as they could be, and for me had a learning curve. It took a while to remember down does not do the opposite of up and what on earth the diamond does. It’s the same confusing arrow design that frustrated me with Windows 3 in 1993!

    Liked by 1 person

    Reply

  7. I understand not wanting to support CSD, but could you guys *at least* make it easy to enable shadows on windows that use CSD. GTK CSD windows now have it with breeze-gtk, but there’s no real easy way for other apps. Take chromium (without titlebar), steam, or electron apps with the frame disabled, for example. Right now it’s convoluted. First you need to force a frame, then you need to go to window decorations, add a rule, and tell it to hide the titlebar, just to get a shadow. What makes matters worse, if you’re using wayland, there’s no obvious way to hide the titlebar, so this solution doesn’t even work in the wayland session (even in 5.22).

    I recognize CSD will never be officially supported or a feature of KDE apps, but even if DWD were to be a thing, CSD isn’t going anywhere for apps that don’t care about KDE, or gtk for that matter. Unlike gnome, at least KDE has cared about making GTK apps look somewhat okay in KDE, so they should do the same for these apps. Even if it were not automatic and required some intervention, simplifying the process like I described above would be nice.

    Also, I know you guys are planning to potentially add rounding to the bottom of windows. I’m not sure how you want to go about this, but if you do, please keep in mind to not round windows that have the titlebar hidden in window decorations, otherwise you would end up with rounds on the bottom of the window but not the top, or rounding on the entire window that shouldn’t have it.

    Like

    Reply

  8. Hi Nate, thanks for the article, just some corrections: The problems numbered 1 through 5 are referred to as caused by CSD headerbars, but these are only problems caused by the style of headerbars used in GTK/GNOME. CSD just means that the application itself is drawing the headerbar, there is no reason an application that draws CSD can’t draw its headerbars in a different, more traditional style. You may want to revise this to make it clear that these are only problems with the GNOME style of CSD, not with CSD in general.

    Regarding problem #7 and platform support for CSDs, I have never seen a modern desktop platform that didn’t support turning off the native window decorations. CSD seems to be supported by Qt on all major platforms: https://www.qt.io/blog/custom-window-decorations

    That leaves problem #6, where the close button cannot be used anymore for force quit on an unresponsive window. In GNOME at least, this problem is solved by automatically showing a “force quit” dialog on the window after a few seconds of unresponsiveness. Maybe not the ideal solution but it shows there are other ways to solve that problem.

    Like

    Reply

  9. SSDs are inclusive, CSDs are exclusive, meaning, apps with SSDs will look native and coherent with major (if not all) environments, while CSDs will look foreign outside of Gnome or everywhere (if CSD is hardcoded and not in adwaita way).
    SSDs will benefit from various WM options, while CSDs are just non-customizable. CSDs may look cool and modern in many ways, but they are less functional and cause more problems than they solve. In few cases CSDs will work much better than SSDs, but for most purposes SSDs are more universal and capable.

    Liked by 1 person

    Reply

  11. Almost all of the arguments are nonsense apart from the subjective customizability issues (most of which could probably be solved anyway with a little thought).

    Applications don’t need to advertise their branding to existing user base — having app name in window title is worthless. Other utilities such as alt-tab can extract window title by other means.

    Placement of the menubar in apps is mostly a theming issue. Don’t make crappy themes that make the menubars look weird. Aside tabbing, I don’t think it would be all that “weird” having the menubar be at the bottom of chrome — other toolbars and window decorations — instead of in the middle. It looks very weird even in the middle, don’t lie to me!

    Years ago I complained how click-drag-release is bad UX because it’s too easy to accidentally trigger a menu item by moving mouse cursor a couple pixels during the release of context menu button. Qt/KDE devs replied that it’s in fact an unfixable Xorg bug… I haven’t touched KDE in a long time but IIRC this was circumvented by adapting the theme and adding deadzones?

    WMs should be able to notify users of unresponsive windows without the user having to click on the “close” button on the window decorations. Detecting unresponsive windows should be a standardized Wayland protocol, not proprietary about hacks.

    Not all that hard to come up with some new ideas instead of desperately grasping on to decades-old limited functionality……..

    Like

    Reply

    1. Detecting unresponsive windows is already standard in Wayland, with the xdg_wm_base.ping and xdg_wm_base.pong events. Even KDE will have to support this, e.g. for Qt applications that happen to use CSD. So the problem cannot really be avoided by enforcing SSD only in KDE apps.

      Liked by 1 person

  12. What about merging the menubar and titlebar, like good ol’ Unity did? It could show the usual window decoration buttons, and reserve some space for the menubar in the middle. As the window gets smaller, the menubar would become scrollable, until only 4-5 menus remain, when it would switch to the “one button” menubar that you can currently add as a titlebar button. Best of both worlds really, and half of it already implemented, since apps already export their global menus to KWin and Plasma. On other window managers that don’t support the feature, the menubar would be drawn in the traditional fashion.
    Oh, window title. It could become optional: always show (space is shared between menubar and title), show menu on hover (like Unity), hidden (only menubar), only app name (like option 1, but only the app name is shown instead of the full title). I think I would do the Unity thing by default.

    Like

    Reply

Leave a comment