Today we’re going to talk at length about something a little different: the headerbar, a combined titlebar-and-toolbar control that holds a window’s toolbar buttons, close/minimize/maximize buttons, drag area, and (sometimes) app name/title/filename, but with no menubar:

This type of headerbar is used to a extensively in GNOME and macOS. The adoption of headerbars appears to be an industry trend, and people often ask why KDE apps don’t have headerbars or even seem to be working towards gaining them.

Today I will attempt to answer that question from my own personal perspective. Note that these are my views, and should not be seen as necessarily representative of the views of the KDE Community as a whole. This is just how I see it. 🙂

I feel that the headerbar is a fatally flawed user interface concept that must not be used under any circumstances!

To back up this bold and controversial statement, I offer the following list of problems introduced by replacing a window’s traditional titlebar and toolbar with a headerbar:

Reduced drag space to move the window

A traditional titlebar generally consists of 90%+ draggable space, no matter how wide the window is. This provides a large and convenient target for clicking and dragging on to move the window around.

But when you combine the titlebar with the toolbar, the previously empty drag area becomes filled with interactive controls. If like macOS’s implementation your headerbar doesn’t allow dragging the window from the user interface controls, then there is an inherently very low upper limit on the number of things you can put on a headerbar in the interest of preserving adequate drag area:

If, like GNOME’s implementation, your headerbar can be dragged from the clickable controls, this provides relief at the expense of intuitiveness (who would think to drag a window by grabbing one of its buttons?). But it also precludes the use of any user interface controls that can be clicked and dragged. This is an acute problem with the most popular web browsers, and Firefox implements a truly awful headerbar with draggable tabs in it, reducing the space available for dragging the window to almost nothing:

Nowhere to put the menubar

Traditionally on Linux, apps’ menubars are integrated into their parent windows, between the titlebar and the toolbar–rather than sitting on a global menubar at the top of the screen like macOS has. When you decide to merge a Linux app’s titlebar and toolbar, what do you do with the menubar that’s in between them?

macOS solves the menubar location problem by having an always-visible global menubar at the top of the screen. This provides the visual design benefits of headerbars with all of the advantages of traditional menubars. However, it isn’t any help if your desktop environment doesn’t force the use of an always-visible global menubar.

The GNOME-style headerbar deletes the menubar entirely, replacing it with in-window controls, a small number of headerbar buttons, and a hamburger menu (ugh) to hold everything else. In practice this requires a near-total rewrite of the app’s user interface, which happened for GNOME 3.0.

Unfortunately, for all but the most trivially simple apps, lots of functionality will no longer have any visible user interface. For example classic cut/copy/paste features are almost always missing from headerbar apps’ hamburger menus; you need to use keyboard shortcuts or a right-click context menu to access them. Believe it or not, lots of users don’t use the keyboard shortcuts or context menus to access these features! If they’re not available in a menu, many users will falsely assume they aren’t implemented. Menubars also teach users keyboard shortcuts right at the point of use, aiding in the transition to proficiency. Without keyboard shortcuts being visible and connected to their functionality, most users will never learn them and will be stuck endlessly clicking around.

I’m not convinced that menubars should be abandoned–especially not before we’ve come up with something better to replace them. Hamburger menus certainly don’t cut it. Microsoft’s Ribbon paradigm is interesting and innovative, but even they don’t fully implement it everywhere. Heads-up displays are a promising concept, but the last production-ready implementation died with Ubuntu 17.10. Bottom line: it’s premature to kill the menubar on desktop apps.

Not universally implementable even by all apps on the same platform

Expanding on the above point, many apps cannot simply lose their traditional menubars. This includes all “productivity” and “prosumer” grade apps that are packed with features–as well as many of the simpler apps too. Take a look at all the functionality available in the menubars of Gwenview and Okular, which are fairly typical content viewing apps:

I don’t know about you, but I sure wouldn’t want most of those features to get removed, become invisible and disconnected from their associated keyboard shortcuts, or go into a single hamburger menu. It would probably overflow the screen.

And that’s just two basic content viewing apps! Forget about it for content creation apps like Krita, LibreOffice, GIMP, Inkscape, or Kdenlive.

Since a headerbar can’t accommodate menubars, and many apps can’t lose their menubars, only some apps will be able to adopt headerbars. You’ll wind up with very simple apps that use headerbars, and complex apps that either use traditional titlebars, menubars, and toolbars.

This inconsistency is exactly what’s happened on GNOME and macOS–platforms that make extensive use of headerbars. In fact on macOS, all document-based apps (1st party as well as 3rd-party) do not and cannot use headerbars because key features are attached to the titlebar’s window title and its proxy icon, which are missing from headerbars.

Reduced flexibility for users and developers

Since the arrangement of controls in a headerbar is critical to ensure that there’s adequate drag area, headerbars are non-editable and generally impose a minimum window width. The headerbar user interface is thus very inflexible compared to traditional toolbars and titlebars, both of which can be customized by the user, and can show some of their elements in an overflow menu if the window becomes really narrow. These technical limitations could theoretically be solved by allowing headerbar contents to be edited like traditional toolbars and display overflow menus instead of imposing minimum window widths, but in practice no implementation that I’m aware of does these things.

With multipurpose non-editable headerbars, developers have to take great pains to ensure that the controls they put there don’t interfere with any other functionality. I mentioned the example of browser tabs in a prior section, but it goes beyond that: every other user interface control that needs to respond to a click-and-drag (such as a slider or combobox) is perilous to use on a headerbar because it will reduce the amount of draggable space. Best not to use them at all, either. For headerbar implementations that don’t allow you to drag the window from the buttons, the number of controls that you can fit on a headerbar is very low or else there is practically no space to drag the window.

Because traditional toolbars and titlebars do not need to pull double duty and merge together, users are free to adjust the controls to best suit their needs and preferences.

App name/window title/filename are omitted or else take up excessive space

A traditional titlebar displays the app name and window title right in the center. It’s a nice wide space that can accommodate quite a bit of text, which is especially handy for web browsers and document-based apps where the webpage’s title or document’s filename appears there:

But with headerbars, this space is filled with user interface controls, so the titlebar text has to compete with them for space. If the headerbar-using app’s developer decides not to show the app name, window title, filename, etc. in that space, then that information is simply… gone!

This is a particular concern for document-based headerbar apps, where the name of the current document is important information that has to be visible. GNOME’s Gedit editor resolves this by putting that information in the headerbar’s precious center position:

As you can see, the need to ensure enough space for the filename doesn’t leave much room for anything else, giving the impression that the app can’t do much.

When it’s up to each headerbar app developer to figure out how to present their app’s name, window title, or the name of the open file, every app needs to reinvent the wheel. If you use a traditional titlebar, your app gets enough space to show its name, window title, or the open document for free!

Unimplementable in a cross-platform manner

The traditional system has a clear separation of roles: the titlebar is drawn by the operating system’s window manager, and the app content is provided by the app. The window manager draws the titlebar however it likes, but leaves the app responsible for defining the actual user interface controls, only theming them to blend in visually. Because every operating system’s window manager knows how to draw a titlebar, this aids in write cross-platform apps and improved the ability of cross-platform apps to blend into whatever operating system they’re run on.

Combining titlebars and toolbars muddies the roles and causes many problems. If the headerbar implementation uses “client-side decorations” (CSD), the app itself becomes responsible for drawing its headerbar. This means that client-side-decorated headerbar apps look and feel totally alien on platforms not specifically targeted by the developers: close/minimize/maximize buttons are in different places or don’t appear at all; windows don’t get shadows or any space along the edges for resizing; there’s no visual change when an app loses focus; and so on.

This destroys visual and behavioral consistency with the operating system’s own style, reducing apps’ ability to work properly outside of their native platforms, and encouraging developers to abandon the concept of cross-platform apps entirely.

A proposed alternative is the implementation of a server-side “dynamic window decoration” spec that all toolkits and window managers would adhere to, allowing apps to tell the window manager what controls they want drawn in the titlebar. This proposal would theoretically work but has no chance of ever being implemented in the real world due to technical and philosophical disagreements between the developers of the different Linux window managers. This is in fact exactly what has happened any time such a spec is proposed.

Even if somehow all of them actually did come to some agreement, there is no chance that Apple and Microsoft would sign on because they prefer that developers use in-house, platform-specific interface toolkits rather than a cross-platform toolkit such as Qt. Without buy-in from macOS and Windows, it would be impossible to write a truly cross-platform headerbar app, which means that toolkits like Qt that care about being cross-platform wouldn’t be able to implement it, and even so, developers wouldn’t use it because it would require much more work to write a headerbar implementation for Linux and a titlebar-and-toolbar implementation for macOS and Windows.

So what are the advantages, anyway?

With all of these problems, I often wonder why the concept even exists in the first place. What’s the advantage? Nevertheless, there are a few:

• Headerbars are very visually clean and attractive. There is something about them that just looks good. While I was taking screenshots of GNOME apps, I kept remarking, “dang, these apps look great!” The attractiveness is probably a big factor driving adoption and user desire for more of them, despite the disadvantages I’ve brought up. I also think a big part of this attractiveness is the fact that in GNOME, generally all the buttons actually look like pushable buttons, and different areas are separated from one another with single-pixel lines rather than enclosing everything in frames. But that’s another story. 🙂
• Headerbars consume roughly 44 pixels less vertical space by omitting menubars and making the toolbar also function as a titlebar. This amounts to an almost 6% vertical space savings on a low-quality 1366×768 screen, and about 4% on a 1080p screen. Thus, headerbar apps can indeed provide a bit more space to their content areas and less to the window chrome and user interface controls.
• Headerbars reduce some redundancy by providing an opportunity to display a relevant title in only one place (in the center of the headerbar), rather than duplicated in the titlebar and in the window, which is especially common in Settings apps where the window content consists of multiple pages of settings, each with its own title.
• Finally, headerbars offer the opportunity to make the close button enormous. Not all do (macOS does not, for example), but in GNOME, headerbars have gigantic close buttons that are very easy to click on once you’re sick of using a headerbar app (I kid, I kid!).

Assuming these are valid advantages, perhaps we can gain the same things in KDE software without needing to go all the way to headerbars. Let’s take a look:

• It’s true that GNOME apps just have that je ne sais quoi of visual attractiveness that many KDE apps lack. This is a major concern of mine that I plan to put some work into in 2019–without removing or hiding any features of course! Stay tuned!Beyond that, KDE apps can gain the visual cleanliness of the titlebar and toolbar sharing a visual style in a variety of ways in. For example all colors are customizable, so you could simply make the titlebar color match the toolbar color. Also, windows are draggable from their empty toolbar areas by default, so it is actually very easy to simulate a merged titlebar and toolbar, but without any of the disadvantages:
  
  The old Oxygen theme implemented all of this by default, and many other 3rd-party themes do too. Nothing stops a KDE distro from shipping this way by default.
• In KDE Plasma, you can already save the vertical space taken up by in-window menubars by using a single always-visible global menu, or put the whole menubar in the titlebar behind a button! This latter option is really quite cool:

  

  Again, there’s no reason why a distro couldn’t ship with one of those two configurations out of the box.

• The problem of textual redundancy between the titlebar and the window content in some apps is real, especially Plasma’s System Settings app. However this is fixable with design and code changes: We could make the titlebar simply not repeat the name of the active page, while still somehow exporting that text so that it can be visible in the Task Manager. This is a solvable technical problem.
• Finally, KDE Plasma also offers you the ability to make your window’s close buttons gigantic if you’d like–perhaps for accessibility purposes:
  

So we see that for the small number of advantages that headerbars offer, KDE Plasma already allows you to benefit from nearly all of them without needing to butcher your apps. Now it’s true that headerbars offer the advantages tied up in a nice neat package that’s available by default. That’s true. But the costs hugely outweigh the advantages in my book, especially when there are relatively trivial configuration changes and visual design improvements capable of producing most of the same benefits.

Let me repeat that I plan to put some work into modernizing the look of KDE apps in 2019, and I hope that we can tweak the Breeze theme in a few small but important ways that make our apps really stand out and look fantastic.

Phew, if you’ve gotten this far, you must really care about user interfaces! Might I suggest checking out KDE’s Visual Design Group, where we discuss this kind of thing all the time? Head over to https://community.kde.org/KDE_Visual_Design_Group and make a difference in the most awesome open-source desktop environment’s user interface!