Folks offered a lot of feedback on my article on headerbars last year, some of which was skeptical or critical. I’d like to address some of the arguments people made in this follow-up:
It doesn’t really matter that there’s less visible or actual window drag space
People pointed out that you can drag on the UI controls, or use the hidden Alt-drag shortcut. Other people questioned how useful it is to drag windows around anyway, preferring to maximize everything or use window tiling keyboard shortcuts. I will address these responses:
“Just drag on the controls in the headerbar”
First of all, dragging controls to drag the window isn’t very intuitive. What other controls outside the headerbar allow you to move the window when dragging on them? Sure, you can learn it, but this isn’t the same as a good user interface that re-uses familiarity with existing elements rather than making you learn new modes.
Second, you can’t drag the window by dragging on controls that themselves implement draggable behaviors–such as tab bars, comboboxes, pop-up menus, and sliders. So those controls can’t be put on the headerbar without reducing the drag area and violating the “you can drag the window by dragging on the controls” rule. In the original post, I gave an example of Firefox’s horrendous CSD that puts draggable tabs in the headerbar, reducing the drag area for the window itself to almost nothing. Ensuring draggability by only using controls that are not themselves draggable reduces developer flexibility compared to a traditional titlebar. It’s just not a problem if you have a separate titlebar.
“Just alt-drag the window or move it with keyboard shortcuts”
This somewhat flippant answer describes a workaround, not a general-purpose solution for everyone. Most users drag their windows around all the time and probably don’t know any of those shortcuts. For them, adequate window draggability is important–especially if your desktop happens to be targeting these people as the #1 user group.
“Just maximize the window and then there’s plenty of visible drag space on the headerbar”
it depends on the implementation (e.g. Firefox’s CSD is perfectly capable of having almost no drag space when maximized), but this is broadly true. However, what if you’re not the kind of user who maximizes all of their windows? In any event, window draggability is least important for maximized windows. The whole point of dragging a window around is to move it somewhere else, which requires that it be smaller than the area in which it’s moved.
—
Taken together, these issues demonstrate that reduced draggability reduces developer flexibility and can be a real problem. It can’t just be dismissed as much ado about nothing.
You don’t need menubars anyway
A lot of people expressed many variants of this argument:
“You don’t need menubars anymore because actions and commands can be located inline, available contextually”
This works, but imposes a high bar in UI design, and results in frustrating and awkward software when implemented by a team without at least one person with A+ UI design skills who everyone else actually listens to. This approach is also very labor-intensive and bug-prone as by definition it’s custom-made for each app and requires a lot of code. It may not scale well for content with many actions you can perform on it, since there’s a limited amount of space in the content view to put contextual actions. It furthermore throws away users’ existing familiarity and muscle memory; for example when cut/copy/paste/find are always available in the same place in the Edit menu, users never need to re-learn how to cut, copy, and paste, and find text in each app. Finally, this approach doesn’t help the user learn keyboard shortcuts.
So yes, this approach works, but results in significant drawbacks. It’s definitely not a 100% slam-dunk superior user interface.
“Menubars are overkill for simple apps”
This is a reasonable argument. Most of the items in the average menu bar pertain to text manipulation, file handling, and view adjustment. An app that doesn’t have any text manipulation or file handling can probably get away with putting what’s left in toolbar buttons. In fact KDE’s Discover already does this, for just those reasons. A number of other simple mouse-centric KDE apps like the games could probably do the same.
But the thing is, you don’t need to implement a CSD headerbar to get rid of your menubar! You can do it with a traditional toolbar and a traditional titlebar, and gain all the advantages of those individual user interface elements: guaranteed space to drag the window, a legible window title, a user-customizable toolbar that can include draggable UI elements, and so on. No need to throw the baby out with the bathwater.
“Menubars don’t exist on mobile and mobile is the future therefore we need to get rid of them on the desktop or else people under 25 will perceive us as stogy old farts and won’t want to use our apps”
I see no evidence that the under-25 crowd hates desktop apps with menubars. A lot of KDE’s most active members are young, and all fully understand the productivity benefits of real desktop apps with traditional user interfaces.
The truth is, mobile phones are really only good for communication, travel, controlling portable hardware (cameras, drones, etc) and content consumption that doesn’t benefit from a large screen. Other than these use cases, mobile apps are universally worse to use than traditional desktop apps–especially for productivity. They are slower, more awkward, have fewer features, take longer to accomplish the same tasks, are harder to multi-task with, have user interfaces that are constantly in a state of flux, and are an absolute nightmare for anything that requires precise text manipulation or formatting.
Most of these limitations are imposed by the hardware’s own input and output capabilities. This means that the only way to improve the situation is to plug in a big screen and some faster, more precise input devices–essentially turning the mobile device into an underpowered desktop computer. Not coincidentally, KDE’s Kirigami user interface toolkit explicitly supports this use case anyway. 🙂
I think Star Trek nailed the ideal mobile/desktop split decades ago: people use their mobile devices for communication, information gathering, and relaxing, but when they need to be productive, they use the huge desktop-computer-style consoles built into the walls of their ships. The bigger devices offer speed, power, precision, and good multi-tasking. When you need to get something important done, those are more important features than being able to have the device in your pocket or purse all the time.
The lesson is clear: portable mobile devices are for convenience, not productivity. Mobile isn’t going to kill the desktop any more than air freight killed rail freight. They’re just for different things.
“Menubars are old and clunky and clumsy and obsolete and a relic of the past”
If this is true, why haven’t we come with anything better yet after more than two decades of user interface experimentation?
- MS Office style Ribbons take up much more space than the combination of a menubar and toolbar they replace, make it harder to find what you’re looking for when the context sensitivity feature isn’t implemented perfectly, and don’t teach the user keyboard shortcuts.
- Hamburger menus in the toolbar have to leave out most functionality or else they become too cluttered. Most also don’t make any effort to teach the user keyboard shortcuts.
- Action drawers that slide in from the left or right are basically just hamburger menus, with all the same drawbacks.
- Inline controls were already addressed above.
I have yet to encounter a feature-rich, high-functionality desktop app that completely does away with the concept of the main menubar without feeling awkward, crippled, slow, or like something has been left out. I’m sure someday we will kill the menubar after we’ve invented something genuinely better that doesn’t feel like a regression in any way, but we’re not there yet.
And in the meantime, you don’t declare something to be dead before you’ve actually killed it.
The menubar isn’t dead yet for desktop apps because we haven’t yet come up with anything that’s universally better. The GTK & GNOME approach has a hamburger menu on the toolbar that holds global controls, coupled with a limited number of inline editing controls. most of which are only available via a hidden UI (the right-click context menu or undiscoverable keyboard shortcuts). This is not a solution, it’s a regression: many features must be removed or hidden to make it not visually overwhelming; the inline controls are invisible unless you think to right-click everywhere; and it’s impossible to learn keyboard shortcuts at the moment of use. This is a steep price to pay for visual cleanliness and approachability.
Displaying a title is an application-specific issue
Only when there’s no titlebar. 🙂
When the window manager guarantees your window a titlebar, app developers don’t have to reinvent the wheel by implementing custom labels to solve the same problem over and over again; they just set the title appropriately and move on.
Iff you implement a headerbar but want to put a title in it, it competes for space with the rest of the items in the headerbar. That means it can’t be very long unless your app has almost no UI controls exposed on the headerbar, which is a problem for any application that could benefit from showing a long title–like web browsers, where the titlebar has traditionally showed the website’s title (imagine that).
When you use a traditional discrete titlebar, you don’t have any of these challenges to solve, so you can focus on more important parts of your app.
Headerbars were meant for simple apps; it’s okay for complicated professional apps to not use them
Some people defend headerbars by arguing that the menubar is obsolete, then say that complicated apps can and should still have menubars. This doesn’t work: either menus are obsolete, or they aren’t. If they aren’t, then removing them is a mistake.
The better argument is that headerbars are only intended for very simple apps that don’t really benefit much from a menubar anyway because most of the default entries are inapplicable and would be disabled placeholders. I already acknowledged that it’s probably fine to remove the menubar for very simple apps that don’t have selectable text or do any file handling. But as I mentioned before, there’s no reason why you need to implement a CSD headerbar if your app doesn’t have a menubar.
It’s KDE’s fault for not supporting client-side decorations properly, so nobody should avoid them just to work around KDE brokenness
There is a kernel of truth here: KDE developers have indeed opted not to support GTK client-side decorations as they are currently implemented.
However, this is only because that implementation utilizes optional extensions to the standard that are very challenging for KWin to also implement. Many of KWin’s architectural design decisions reflect the original spec, and not this optional extension to it. Adding support is very technically challenging, and was judged to present an unacceptable risk of breakage.
At this point, GTK developers may be thinking, “Well, that’s not my problem that you wrote KWin in such an inflexible way.” But it’s not quite kosher to extend a spec with an optional single-vendor extension and then blame other people for not adopting it. That’s not really following the spec.
Nonetheless, there are rumblings of being able to support GTK CSDs in Wayland. For now though, the situation on X11 is unfortunate but pretty much unavoidable. You can’t break a spec and then ask everyone else to support your brokenness; it defeats the entire purpose of having a spec in the first place.
Anyone interested in more of the technical details can read through the comments in the following bug reports:
https://bugs.kde.org/show_bug.cgi?id=379637
https://bugzilla.gnome.org/show_bug.cgi?id=csd
https://gitlab.gnome.org/GNOME/gtk/issues/499
https://gitlab.gnome.org/GNOME/gtk/issues/489
https://gitlab.gnome.org/GNOME/gtk/issues/215
https://gitlab.gnome.org/GNOME/gtk/issues/488
The bottom line is that it’s not fair to blame KWin and its developers for not supporting the GTK developers’ decision to implement client-side decorations without extending the X11 window manager spec so that everybody could follow it.
—
I hope this post helps to clarify my position on CSDs. I suspect that these rebuttals won’t put the issue to rest because CSD headerbars have always been more about aesthetics and vertical space savings than functionality, power, and flexibility. That’s fine! all of these arguments I’m making are sort of a roundabout way of saying that I prefer the latter traits to the former ones. I think it’s a good thing that we have choice in the desktop space–real choice, where well-implemented competing visions and design goals appeal to different sorts of people. And that’s what we’re all doing here: empowering people to find what works best for them so their needs and desires can be provided by high-quality open-source software that respects their privacy, freedom, and need for highly usable and productive applications.
