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 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:
For those of those of you who noticed that the highlighted menu item is using the wrong icon, I already fixed it 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!
—
If you’re interested in even more on this topic, I’ve written some rebuttals to common objections.
Adventures in Linux and KDE 
Obvious comment: at least with kwin you can drag windows by holding Alt + LMB anywhere in the window.
But nevertheless, I agree with your observations.
LikeLiked by 2 people
Quite true, but that’s an example of an “invisible UI” of the type that should only ever be an accelerator for proficient and expert users–never a requirement for casual users. If the user interface relies on the use of invisible features for basic functionality, casual users will never find them and will stop using the software before they have the opportunity to become proficient or expert users at all!
LikeLiked by 2 people
Thank you! I’ve been looking for this “simple” shortcut for a long time and… I couldn’t. I knew it’s possible because I saw that somewhere but how can I name it to search for it? I tried and tried… nope, nowhere to find. And now I came across this. So easy I can facepalm myself and yet… so unknown and not spoken by anyone.
So yeah, users can’t rely on “invisible UI” features, because they can be frustratingly hard to find even if we know they exist.
LikeLike
I love it, but it doesn’t work in Wayland.
GlobalMenu also doesn’t work in Wayland and it doesn’t look like it will in year or two…
LikeLike
“I feel that the headerbar is a fatally flawed user interface concept that must not be used under any circumstances!”
Oh god yes…
Thank you for your lengthy explanation, that’s always an interesting read.
LikeLiked by 3 people
Really great article which, IMHO, includes all relevant arguments. Thanks for writing!
LikeLiked by 2 people
I think what makes the CSD decorations so favorable is that it look so clean like you mentioned in the article. For the average user it looks cluttered with options they do not need or will never need. I would love seeing an implementation of a mix of CSD and ServerSideDecorations (SSD) where the user is able to toggle it.
Another point I can come up with is that vertical space is way more relevant then horizontal space. Personally I do not like my Browser stealing 50px on top of the screen with a 90% blank bar just to add dragging space.
LikeLike
I agree that the visual cleanliness is a big part of the appeal. I hope we can improve the look for KDE apps without having to completely rewrite their user interfaces the way GNOME did for GNOME 3.
As I pointed out in the article, the titlebar is not wasted space–especially for a browser. A wide titlebar is the perfect place to display the web page’s title. Where does this information go in a browser that has tabs in a headerbar? Nowhere! The page title is simple not displayed at all. It’s a functional loss.
LikeLike
In addressbar maybe? I mean combining the title and show full url when you click it.
LikeLike
But then you can’t see the URL.
This is actually what Apple’s Safari browser does and I find it really annoying since it takes extra effort to see and edit the URL.
LikeLiked by 1 person
Being able to see the URL is more important than many could think as it helps to avoid phishing. And in my book, security beats any flashiness.
LikeLiked by 1 person
I think that more than 90% of the time you will look at the content of the page and not at the title. I really prefer to use that space for content and not for title.
Also yes, URL is more important than page title.
I am using Firefox and i have the title bar hidden. I just activated it to see what does it show and i was wow there is something written on it, i never knew. Anyway it’s not something that is worth occupying that space all the time.
True, it’s hard to drag the window, but it looks so much better than having a bar only with 3 buttons and a title.
Just my opionion.
LikeLike
Menubar in title bar == hamburger menu. Even the icon is the same.
You say it is crap in the beginning, but in the plasma section it is ‘cool’. Why?
LikeLiked by 3 people
I think it’s cool because of the very fact you can put it there if you want to.
p.s. Great article Nate
LikeLiked by 1 person
Hah, that’s a good point!
The difference is that our titlebar menu is optional and off by default and actually shows the full, complete menu structure, including keyboard shortcuts. It’s not some type of abridged or abbreviated summation like most hamburger menus.
One thing we’re discussing internally is the possibility of making the button optionally show the full menu on the titlebar when hovered over, so it even looks and feels more like a compact representation of the traditional menu bar rather than a hamburger menu.
LikeLiked by 1 person
I really love the history of UI (Hamburger button vs. Menu) that was shown in a cycle of posts of probono:
View at Medium.com
It made me a fan of the standard Menu even more.
That cycle is the reason I started using Global Menu aligned right to the System Tray.
file:///home/pyro/Pictures/Screenshots/Screenshot_20181219_165725.png
And this placement sometimes shortens the span of Window Tabs in Task Manager in Panel, but honestly, it feels quite nice and saves a lot of space. I love this change. I am a user that keeps the number of opened apps small, thou.
It can be an interesting middle-ground solution (between titlebar and headerbar) – an option to place the standard Menu in the Titlebar, aligning Menu to the left side or to the right side. No need to invent new set of buttons, just place Menu there.
LikeLike
Do you understand difference between URL to local resource and one accessible globally?
LikeLike
I always loved that about Unity – appmenus in titlebar on hover. Not all will like this and that is why as usual, it would be the best to have the option to change the button into appmenu upon mouse hover (without it it would show the regular title).
However, with this feature, we would have to solve some situations where titlebar is too small for the whole menu to show up. How unity handled it? Hmmm…. I can’t remember.
Title applet (from latte developer) is handling quite well situations where the menu is too long – it hides graciously behind systray (so not awkward overlap), but that’s ok, because it happens mostly for browsers where titles may be too long and pushing menus toward systray. But on windows who can be of any size, this is different and we would lose important functionality.
This appmenu on titlebar on mouse hover is also very important when you have the focus follow the cursor (my preferable setting). This way I could avoid moving the mouse quickly for upper global menu or clicking for a hidden menu which is good to have but not which is not as functional as a straight, visible, horizontally placed menu.
LikeLiked by 1 person
I got menu on hover using Active Window control. It’a bit tricky to configure(got many overlaping bugs), but when tyou got it, its rock-solid (and you don’t need latte dock [it looks nice in theory, but I use full maximized apps, so standard panel is perfect for me])
LikeLike
I was talking about the menu in titlebar (locally integrated menu), not on the panel. AWC is setting menu on the panel only. By the way, AWC is obsolete, discontinued, and buggy, we have now much better options.
https://github.com/psifidotos/applet-window-buttons
https://github.com/psifidotos/applet-window-title
https://github.com/psifidotos/applet-window-appmenu
An additional bonus is, they are way easier to customize then AWC which was confusing and incredibly bugged (only github version really worked, those posted on various sites were never fully complete).
LikeLike
1. Why do you say a header bar can’t contain the menu? Imo it can, if the menu is that important.
2. I have a problem with the menus and toolbars of many apps. Most of them are seldomly used and therefore should not be as prominent. The advantage of having such header bars is that the ui designer has to think about what to put there and what the user really needs. Dolphin did that and I love it (although I miss the ‘directory up’ button).
3. Missing drag space is imo not a real issue. Most ‘large’ apps are full screen, ‘small’ apps have enough widget space that can be used for dragging, and some special apps that are in between, or that need all of the space for controls (browser, text editors) can provide a special drag space.
4. Vertical space is an issue and you can save much more than the advertised 44px by removing unneeded controls.
Just my 2 Cents,
And thanks for all the work you do for KDE. I do appreciate it 🙂
LikeLiked by 1 person
1. Well where would it go?
2. If you don’t use menus, toolbars, and titlebars, there is a strong chance that you are an expert user. Whish is great! Plasma is made for you! You can hide all of them if you don’t use them, which will gain you far more space than an app that replaces them with a chunky headerbar. UI designers need to carefully consider the default set of buttons for any toolbar, not just a headerbar. It’s just even more important that they get it right with headerbars because they’re non-customizable. With a traditional toolbar, you can change it! For example, if you want an “up” button in Dolphin, that’s easy and takes 10 seconds: Just right-click on the toolbar and choose “Configure Toolbars…” and go do it! With a headerbar, you’re stuck; if the UI designer didn’t put an “up” button in the headerbar, you can’t ever have it, too bad, so sad!
3.It not generally a big issue for expert users, who use tiling and know the hidden commands for moving windows. It is also not an issue for KDE apps where by default you can indeed use the empty space in the toolbar and menubar for dragging. That’s precisely why having some of that empty space is important! If it were all used up cby combining everything into a headerbar, then there wouldn’t be mush empty dspace left for dragging, would it! You’re actually describing an advantage of the traditional approach, especially when used for KDE software.
4. Right, and expert users like you can indeed do this–in fact, much better than in GNOME or macOS, because you can remove everything if you want! KDE software grows with your level of expertise and desire for customization and doesn’t lock you into anything.
LikeLike
1. Well, just as other ui goes into the header. It’s just another element, and the designer would have to think of what to put there and what not (so we don’t have to many menus).
2.1 Yes, I probably am an expert user, but I also switch machines often (work / home / laptop / on site installations / testing). I don’t have time to customise that everywhere, for every program. Defaults are kings :).
2.2 UI designers often do not consider the menus and tool bars, but use the old age default (file, edit, view, .. for menus, new, open, save, copy, cut, paste.. for the toolbar). having a header bar also doesn’t necessarily mean, that you can’t edit it. Summary: IMO using header bars forces the ui designer to think about that stuff more. menu / toolbar, otoh, tempt the designer to just use the standard layout, no matter how often these are used.
also:
casual users will not use all the expert features and they will be overwhelmed by the amount of options. expert users will quickly learn the shortcuts. Note that i’m not advocating to hide or remove features. Put them into overflow menus or menu buttons, instead. that’d ensure they are discoverable.
LikeLiked by 1 person
1. I’m afraid good design is a lot harder than handwaving away all the challenges. 🙂 Sure, it could go in the headerbar, but how?
2.2. There is tremendous value in consistency. The presence of File, Edit, View, and Settings menus is an enormous usability aid, quite far from being “redundant” or “unnecessary”. It’s important that common things be in the same place. That makes is really easy to find them! 🙂
Also, the nature of headerbars as implemented on a per-app basis means thamaking them editable requires every app developer to implement the feature. In practice, none do. Compare this with the toolbar provided by KXMLGui for KDE apps; it’s editable automatically, no special work required.
LikeLike
1. File | Edit | View | Application Name: filename.ending [ drag space ] [min][max][close]
(Though imo all those standard menus could go into one button like in dolphin)
2. There is also tremendous value in not having the user interface cluttered with buttons and menus hardly anybody is using 🙂
The fact that somebody implements header bars without abstraction, doesn’t mean that it has to be that way. One could make an abstraction that contains a few standard elements (menu button, search box, min/max/close buttons etc) and allows customisation. Btw, customisation is possible for instance in Firefox (afair).
LikeLiked by 1 person
As far as I remember, there was simillar option in Ubuntu’s Unity.
LikeLike
You gave a good example of simplicity, economy of space and usefulness: dolphin, as it is now. Personally, I like to replace the menubar with a button on the toolbar. BUT, this button in Dolphin shows a hierarchical menu like a vertical menubar, with sub-panels opening at the side of their mother-panels, which enabels the user to see all the context. This is good, much better that some hamburgers that (1) shuffle all menu options and/or (2) make the sub-menus open in the same place, so that you loos sight of where in the menu tree you are.
That said, I think that moving a “menu button” (either with the hamburger icon or any other) to the customizable titlebar (buttons left or right; title centered or to one side; enabling the choice of heigth of bar and size of buttons, etc.) is a good choice that would be coherent on all the windows of all applications. And of course with (1) keeping an information bar at the bottom and (2) the ability to customize the toolbar.
LikeLike
You may be interested in this: https://phabricator.kde.org/T9830
LikeLike
I am so very very happy you wrote this! I agree wholeheartedly, especially when it comes to the dropdown menus. This switch to headerbar apps (along with other deprecations of useful and important UI features such as icons in menus) is the main reason I am currently migrating my machines from GTK-based desktops to KDE and Plasma. Excellent work and I am again very thankful you are all creating such an amazing desktop that is made to fit all user cases and truly works toward a goal of “more is actually more, if implemented in a smart way”. (As opposed to the common miskonception ‘less is more”.)
LikeLiked by 1 person
An FYI in case you’re stuck on a Mac: on Firefox, if you right click on the toolbar and select “Customize”, there’s a “Drag Space” checkbox at the bottom of the customize tab that adds a few extra pixels to the top of the window to enable easier dragging.
LikeLike
If your aim is good you can drag the window from that very slim title bar that has not actual title!
I think Mozilla missed the shots with their rushed CSD implementation.
LikeLike
Maybe menus branches could instead overlay on top of the existing tree. For example, if you select Files, a list appears, and then you select Foo, which has its own list, it would be nice if that list is overlayed on top of Files (with a back arrow to go back). This saves space, looks clean, and avoids wrong selections from accidental jitters.
LikeLike
It’s also much slower and you lose the ability to select a menu item with click+hold->move->release. It also doesn’t actually solve the problem of having an unsteady hand since you could still click the wrong entry in whatever menu you’re in.
LikeLike
UI shouldn’t be done by graphic designers: usability is not a painting.
Unfortunately a lot of people (even developers, marketers etc.) doesn’t understand this simple concept. Thanks for the article: it should be read by a lot of people.
LikeLiked by 3 people
Graphic design is not the same as painting.
LikeLiked by 1 person
Industry adopts “a trend”.
Users flee from the trend like hell, finds refuge on another ecosystem.
Ecosystem then starts to considering adoption of “that new cool trend”.
Refuges despair.
Oh man, I’m glad this isn’t the case!
“visual attractiveness that many KDE apps lack.”
KDE apps are cute, cute!
I have to point this, people can say that they aren’t all that good looking, which is subjective, but they can never say that they are ugly. It’s an important distinction. For me they’re ok, the richness of features is a big quality that needs to be praised always and more importantly, you can customize the way you want. With just a few clicks, just a few, I can turn most of them into minimalist interfaces.
LikeLiked by 3 people
I agree 100%. Trend-following is one of the most destructive things that creative people can do, because it necessitates that their hard work is periodically thrown out and restarted from scratch rather than polishing the existing product until it’s near-perfect. Of course by the time the new trend has been adequately implemented and the polishing stage begins, it looks “dated” and trend watchers are clamoring for the next thing that looks “sleek” or “modern” or “fresh” and the cycle starts all over again.
Big companies have the resources to periodically redo their entire user interface and interaction model every few years. It’s stupid, because their users hate it, but they can pull it off. In the FOSS community, we can’t match those resources, so if we try, not only do we piss off our users, but we can’t even manage to do it as well or as quickly as the big guys.
The only way to win this game is to not play! The benefits to avoiding trends is enormous. When you focus on things that are timeless and never go out of style, people stop bugging you to abandon the current trend for the new one. And you can spend much more time polishing instead of reinventing the wheel, so eventually your software becomes truly magnificent.
LikeLiked by 2 people
I may take this opportunity to add this.
“there’s no reason why a distro couldn’t ship with one of those two configurations out of the box.”
What about if Neon gave the example?
Now Ubuntu distros ask during installation if the user want to choose a “minimal installation”.
What about asking if they want to install with the “default” setup for the interface or if they want to enable a “alternative setup” with a few things hidden for aesthetics? Think about Mate layouts.
LikeLiked by 1 person
Locally integrated menus save space with virtually no downsides. Zero additional clicks required to get to the menu. Example: https://youtu.be/nzFXRz-b3Ns?t=43s
To make this more discoverable, hamburger menu icon could be shown in the titlebar. Here’s an issue/discussion: https://bugs.kde.org/show_bug.cgi?id=375951
LikeLiked by 1 person
Thank you for writing this up, I’ve been wondering myself what made UI designers want to go down the path of putting controls in window title bars, and the only answer I could come up with was: “they might all be copying Chrome, but a browser is a very special case which is closer to being a nested window manager, and tabs are nothing but a compact window titlebar. In ChromeOS, the distinction between browser tabs and other windows fades completely.
If KDE is looking for a good UI refresh, I’d ignore MacOS and Windows and look at ChromeOS for inspiration. As I’m writing, my desktop contains 3 browser windows with dozens of tabs, plus a terminal (with 2 vertical splits), an email client (Thunderbird, implementing its own tabs), and a LibreOffice Calc (with tabs at the bottom). Wouldn’t it be great if all these tabs looked and behaved the same way and could be dragged between windows regardless of which application created them?
LikeLiked by 1 person
Have you thought about doing something like Unity’s locally integrated menus? I feel that would be the best of both worlds and technologically very similar the single button menu in title bar KDE already has.
Most recently VSCode has implemented something very similar in the CSD implementation. Screenshot: https://imgur.com/a/VE9P8by
Original announcement blog post: https://blog.3v1n0.net/informatica/linux/ubuntu-introducing-locally-integrated-menus-to-unity-7/
A plugin like this even if not default would be amazing for Plasma.
LikeLiked by 1 person
Check out https://bugs.kde.org/show_bug.cgi?id=375951
LikeLike
Thanks. Is it something you’d approve of or think of as an improvement as part of the UI beautification effort your mentioned above?
LikeLike
this is amazing
LikeLike
I really love the workaround that Canonical apply mixing the global-menu and the buttons in the left side when the windows was maximized and remove the SSD but show the bar when isn’t maximized.
But What really useful for me was the possibility to drag the window grabbing the left space that has de upper bar. I always though (and I’m still thing) that it is the good way to get a really production-useful-environment
LikeLike
I really love how Canonical manage this situation in the last versions of Unity. Yes, it was horribly regarding performance and (I’m not a devel) some other stuffs but they just give the better of this two implementations (SSD and CSD) and mix is some DE that brings to us a solution that indeed some companies and people use in its production environments.
What i liked was when I maximized a window and the SSD disappear integrating this functionality to the top-bar, showing the window buttons in the top-left corner and to get again the window just grab some blank space space in the panel bar and drag it to get it again.
All of this maintaining the global menu which I like too, it’s really useful.
Plasma brings me the majority of this functionality, I’m in home.
LikeLike
This is already possible with latte. The only thing we lack now are integrated menus on mouse hover in titlebar. Moreover, we have more customization options for the panel and it’s more dynamic than it ever was on Unity where we mostly stuck with only a few workable themes/settings.
LikeLike
https://store.kde.org/p/998910/ is that without the wasteful of pixels and resources dock.
LikeLike
AWC is not developed anymore and uses old and buggy version of global menus (so it won’t work correctly with Firefox, Thunderbird and many other programs). The new solution to this is a triad of those applets (made by the latte developer):
https://github.com/psifidotos/applet-window-buttons
https://github.com/psifidotos/applet-window-title
https://github.com/psifidotos/applet-window-appmenu
An additional bonus is, they are way easier to customize then AWC which was confusing and incredibly bugged (only github version really worked, those posted on various sites were never fully complete).
LikeLike
Interesting, I’ve been using AWC for quite a while and never noticed any significant issue.
OTOH I just tried your alternative, feels much wonkier and harder to put together. I’ll try to get the hang of it.
LikeLike
Bugs are not obvious and not seen everywhere. For example, if you want to use global menus in Firefox or Thunderbird they are not working fully correctly (you need to re-focus to make them work) and there are many apps (often electron apps) where you can see some weird issues with menus.
It is happening because AWC is using a very old version of Plasma global menus.
Also, AWC is usually working fully when you use git version, while repo or opendesk copies are broken and some things simply don’t work, which confuses people.
The only downside of the new applets is that I can’t move program icon on the left of the buttons, because not icon is part of the title applet.
I also recommend using git versions of those applets to get most recent upgrades to work correctly with the newest latte-git (dynamic colors update):
http://psifidotos.blogspot.com/2019/02/latte-and-colors-tale.html
Or maybe official releases were already updated with it? I don’t know, because I use always git versions of the projects I want to test and help with.
LikeLike
Looks like I have to break the thread because there is no “reply” button respond this deep,
> if you want to use global menus in Firefox or Thunderbird they are not working fully correctly (you need to re-focus to make them work) and there are many apps (often electron apps) where you can see some weird issues with menus.
I checked out the latest and greatest from github, but I’m not seeing any global menu entry for my Firefox/Thunderbird (plasma 5.15.1). No better no worse than AWC at least 🙂
> The only downside of the new applets is that I can’t move program icon on the left of the buttons, because not icon is part of the title applet.
Aha I reached the same conclusion on my own, and ended-up with a hackish and ugly duplication of the window-title plasmoid: one to hold the icon at the left end of the panel, the menu, the second window-title to, well, accommodate the title (for real this time), and the buttons.
Maintained or not, AWC offers a tad more convenience.
LikeLike
Not sure which distro are you using but to get global menus in Firefox or Thunderbird you need to install their patched versions (compiled with unity patches, Ubuntu ships those by default, others distros do not), so on Manjaro I just install firefox-kde-opensuse (is in Manjaro community repo) and compile from AUR thunderbird-appmenu (this takes ca. 2 hours so this one is a pain, plus you need to wait for newer thunderbird versions longer). But since you don’t have a problem to run them without global menus, it’s better not to change anything because as I said, AWC is not dealing with those global menus well.
However, latte and those applets are still gaining new, cool features that AWC will never heave. For example, the latest changes added smart, dynamic, colors – panel and the applets adjust their colors and panel’s background based on the wallpaper, elementary OS style. Another new feature is the menu and tiles behavior like in Unity, meaning, you can set to show the only title in the panel, but when you move the cursor over it, it changes to the menu, cursor out, it switches to title again. And so on.
As to the icon, I realized it doesn’t have to be with window buttons, it works just fine and looks good with the title, so I don’t miss any AWC functionality in the end but enjoy some additional perks.
LikeLike
I think KDE should focus in making every single option (for apps too when possible) configurable from a text file. Like a big milestone before making more changes. Even better if the format is lintable (enforceable with schema versions) and predictable across the ecosystem.
Right now there’s a lot of “state” mixed with configuration and even some regedit syndrome where you need to hunt down bits here and there. There was a good example about this in the KDE subreddit but I can’t find the link anymore.
Why am I saying this in a post about headbars? Because it would make really easy to provide a “defaults switch” for every type of user. You could offer that customization in the setup and after too. It would help in other areas too like versioning, sharing, reproducing bugs.
Great post btw.
LikeLike
Sounds like you should keep an eye on https://bugs.kde.org/show_bug.cgi?id=397602
LikeLike
while I obviously agree with most if not all the points, I think you forgot one important one where you talk about the app being responsible for the functionality:
this means that whenever an app is occupied and thus slow to respond (or even completely frozen), buttons like “close” won’t work. So for users unaware of other ways of closing applications, you lose the ability to close an unresponsive app. And as good as we all might code: none of our apps are bug free, especially if they depend on (and wait on) external data sources or hardware.
LikeLike
Excellent point. How does GNOME’s Mutter window manager handle this? Does it try to detect when an app is hung or something? Or is it just a pain in the butt to kill a hung GNOME app?
LikeLike
I don’t know for GNOME apps per se and, in my cases, if it would eventually jump in and offer to kill it but on Ubuntu 18.04 not even an insistent repetition of Close context-menu (or I guess there it’s called Leave) on taskbar item gets to that point. So when my patience goes off after waiting and then trying that, I kill it with (x)kill. =/
LikeLike
That’s probably not my idea – I have read about DWD (Dynamic Window Decorations) many years ago, but didn’t remember full the idea.
KWin could use XEmbed or DBus and still uses SSD (Server-Side Decorations). XEmbed is worse solution, because if application creates button on titlebar, kwin probably doesn’t get events from it, Instead KWin could provide an DBus API to create controls on top of titlebar and uses DBus to tell app button on titlebar was clicked.
LikeLike
Nice article. On the last sentence, change “desntop” to “desktop.”
LikeLike
Oops, fixed! Thanks for pointing that out.
LikeLike
what about this
https://phabricator.kde.org/M128/506/
its good idea
LikeLiked by 1 person
KDE already had it and was removed when breeze came along
It is expected to return someday (I hope)…
https://bugs.kde.org/show_bug.cgi?id=343690
LikeLike
“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.”
What is stopping official breeze theme to have this as well?
LikeLike
Nothing really. It’s just a matter of agreeing to a new design. For that purpose, I have opened https://phabricator.kde.org/T10201
LikeLike
Been a kde user for most of the 13 years running linux (exclusively on my personal computers) and even though I am not suppose to love CSD and your made valid points… Yet.. I love them. I love their look and feel and how they make an application clean and even more user friendly. I have been using gnome 3 now (something I considered an abomination before) since 3.30 was released and I absolutely love it. It has been a long time since I loved my a desktop computer this much.. heck I use my laptop now more than I use my phone. Most of this is thanks to gnome online account and how it ties to the evolution PIM suites.. but a big part of it is also the general gnome 3 presentation especially the client decoration. CSD might just be one of those instances where the developer echo chamber differs from what users want. It would have been awesome to have the DWD as a compromise and a way of achieving crossplatform support. But I can understand the politics involved. I hear you and you make sense. But I love csd and I prefer it to having to digg into menus. Yes you can hide menus in KDE and make your app as minimal as possible.. but it is never the same. I spend a lot of time on my laptop and hence I want my UI would be good on the eye and functional making it easy to get simple things done without much hassle.. CSD does that for me. A great deal.
LikeLike
Yep. This is exactly what I’m talking about. Despite all the problems, they just feel right somehow! I think we can probably gain the visual benefits without actually adopting the radical user interface changes required.
LikeLike
i think the mac module is the best
they use the beautiful look of the headerbar
and they don’t sacrifice the functionality with the global menu
LikeLike
Heh might be called a troll, but I feel obliged to comment because of how bold of this entry is to create what basically absurd complaints in regards to headerbars. If i were to use the same ideology boi I would also have a lot to complain about traditional god-bless titlebar by complaining same absurd things!
LikeLike
If you feel my arguments are absurd, please feel free to refute them and offer your own perspective!
LikeLike
I believe that locally integrated menus could be left as they are and that https://bugs.kde.org/show_bug.cgi?id=343690 would be a much better way to use those 90% free space, no?
Nate: I fount a typo. You missed an S on “perhaps we can gain the same things in KDE oftware without needing to go all the way to headerbars”
I loved the post, by the way!!!
LikeLike
Oops, thanks so much!
LikeLike
I have to say, this post is gold.
Cheers!
P.S.- Oxygen rocks, long live Oxygen! =)
LikeLike
You say “who would think to drag a window by grabbing one of its buttons?”
This attitude basically defies any new solution and is a manifestation of neophobia.
LikeLike
Well, who would think to drag a window by grabbing one of its buttons? This just feels weird to me. Sure, people can learn and get used to anything. But if we’re designing a new UI paradigm, why not shoot for the moon and create something that isn’t hampered by awkward compromises from the start?
LikeLike
That was one of the reasons i’m using kde for last several years.
I couldn’t agree more with your statements and i’m glad that people like you works with kde. I could suspect a bright future for this DE then.
In my opinion, CSD may burn in hell, i won’t miss it at all. It’s ugly. I even tried one evening to get it out of xfce, but no luck.
LikeLike
Hey Nate,
Gnome is working on a feature like the HUD. It is called command palette and is currently implemented (WIP) in the dev version of Builder (Gnomes IDE).
Video: https://youtu.be/dttQr2CWb7Y?t=52
LikeLike
Mockup: https://gitlab.gnome.org/Teams/Design/os-mockups/raw/master/command-search/command-search.png
LikeLike
Yeah, various KDE people are also working towards this. macOS has had a similar feature for ages. In practice, it’s most useful to find difficult-to-locate menu items in advanced apps with enormous menus. People generally don’t go out of their way to use it for Save, Copy, Open, Quit, etc. The existing keyboard shortcuts work just fine.
I think a HUD is a nice-to-have, rather than a must-have, and I don’t think it can replace the menubar entirely.
LikeLike
or may be the headerbars works perfectly with some apps
and dont work with in another
LikeLike
> I don’t know about you, but I sure wouldn’t want most of those features to get removed, become invisible […], or go into a single hamburger menu.
You took a wrong examples with gwenview and okular. I don’t see anything in their menubar that would not be better possitioned in the toolbar (navigation actions), in hamburger menus on elements (edit actions), in the setting panel (setting actions).
In my opinion, apps that focus primarly on navigation and viewing should not have a menubar. It takes too much space that would be better used to display content. That’s why there is no menubar in modern browsers.
At the same time, I agree with you when you say the menubar should not be removed from apps that focus on content creation. There is no better solution when the app has too much tools.
I don’t see it as an inconsistency, it is just a matter of use the right tool for the right work.
LikeLike
The problem is that removing the menubar would make a huge assortment of those features non-discoverable, because you can’t put all of them on the toolbar. And even if you somehow could, you’d lose the ability to learn their keyboard shortcuts at the moment of use.
I agree that menubars are not perfect. But declaring them dead or obsolete for certain use cases is premature before we’ve come up with an alternative that improves on all of its drawbacks without also throwing out its strengths.
LikeLike
Couldn’t agree more, and I’m glad someone actually involved in UI design has said it.
And, in fact, I’m not convinced they look any better either – used well they can, but as often as not they just look cluttered – or that, in general, making the close button easier to hit is actually a good idea. Obviously it’s helpful in accessibility situations, but for the vast majority of users I think it’s a disadvantage. For similar reasons to having the window buttons grouped together on the same side, in fact. Apple used to boast that their pre-OSX arrangement was more ergonomically sound because the user was less likely to close a window by accident. I wonder what happened. To be fair, making everything larger mitigates this problem somewhat, but it shouldn’t be a problem in the first place.
LikeLike
Headerbars are not for me, I think. In particular the Gnome example shows the pitfalls all too clearly:
– Look at the size of the buttons, the padding in them. Notice the aspect ratio: entirely out of proportion.
– Then look at the vertical margins. Entirely unbalanced, made so much worse by the lack of proportionality to the buttons.
– Look at the left most button (reload, refresh, retry?) Observe how this is out of balance with the right side: having broken up the buttons in two piece, scanning is gone (the window is too large for it to be obvious if you are looking at the center) and visual symmetry is not retained. A heavy element that looks visually out of place made worse by a nasty squeeze in margins that makes the rounded corner look ‘pinched’. That last flaw might be because the curves of the corners do not appear to line up properly.
– Look at the window layout. Headerbars are supposed to be great because they save precious pixels leaving room for meaningful content. Look at sheer amount of pixels wasted on humongous padding for the individual items of a trivial list.
– Let’s not count the typography against it here as that example leaves typography entirely to be desired. Hopefully this is just an artifact of downscaling the image or something.
Quite simply, if the Gnome look and feel is how headerbars are supposed to be done then for me they are not worth doing. For the Gnome look, both back in the GTK2 days as well as now if saving pixels for content was a concern, fixing the proportionality of their controls and typography would be a much more efficient approach.
Of course, in theory this UI is easier to use on a tablet or phone than a menu. On the other hand, I have never seen any Gnome app on either in the wild, and to me it seems like this is much better solved with proper toolkits that assume less of a desktop and widgets that promote a good touch-based UX like Kirigami anyway.
LikeLiked by 2 people
I think CSD look really good, but I also agree with the points you brought. I also agree that having the title bar with the same color as the rest of the application is a good decision to bring KDE closer to that look and feel CSD apps have.
Off-topic: This text talking about the flaws of Linux user interface is really good, you should check it out: https://medium.com/@probonopd/make-it-simple-linux-desktop-usability-part-1-5fa0fb369b42
LikeLike
Yep, I’ve read the whole thing. 🙂
LikeLike
Some thought about possible solutions:
1. Display window title above headerbar (when mouse cursor is outside headbar) and hide it, when mouse cursor is above headerbar
2. Create special toolbox with two states: (1) as headerbar and (2) as toolbox. When this toolbox is toolbox, special button making this toolbox as headerbar is displayed above. When this toolbox acts as headerbar, buttons making it toolbox are displayed above and below. When acts as headerbar, we shrinks real toolbox height and display window above window title,
For second point – user can fast switch between headerbar and toolbox thanks to position of this buttons.
LikeLike
I also think, titlebar culd be removed for maximized windows, which have toolbar. In this case, close, minimize, etc. buttons will be showed on toolbar.
LikeLike
Latte can be used as upper panel and it has an option to hide titlebar when window is in maximized mode. There are also 3 applets (buttons, title, appmenu) so buttons may appear on a panel when window is maximized. Each applet is customizable and buttons can follow aurorae theme so all can be really well adjusted.
LikeLike
He didn’t mention the fact that you could take Ubuntu’s approach. Display application name by default and when app name is hovered display menu bar.
LikeLike
There was once a nice compromise called Locally Integrated Menu. But as it was a Ubuntu/Unity specific feature, it has never been « translated » into any other environment : when hovered the title bar shows the menu. It saved more vertical space than CSD while keeping the complete / full lettered menu. It did not change the menu itself.
I know plasma has almost the same thing : menu « behind » a hamburger button, which needs being clicked. Goods news you work on that 😉 But just look at how Locally Integrated Menus worked in Ubuntu 16.04 / Unity, I never understood why it did not gain more « attraction ».
LikeLiked by 1 person
Nate, I love you! You spoke all those things that I thought about CSDs. I should bookmark this article for future use in discussions ;). It’s perfect!!!
I do feel that some (not all) CSDs/headerbars look great but in general, it’s not worth the hassle, because of lack of consistency and customizability with system other programs, plus all the issues mentioned above.
MacOS is a special case because it is a closed, rigid environment. Gnome devs try to do the same thing but:
1) lack the design skills to make it look so good
2) they don’t understand the whole “always visible global menu” feature for exposing advanced options
3) they forget that Gnome is not all Linux, what MacOS can do is not possible on Linux with all its variety, so we simply cannot force developers for one UI, one WM because we have a lot of them, so we HAVE TO USE UNIVERSAL DESIGN
4) they ignore other DEs and think only about Gnome which is selfish and arrogant (so Gnome apps look weird, foreign, out of place or straight out ugly on other DEs)
5) they don’t understand that only simplistic apps can relay on headerbars but more complex, professional programs cannot contain their features in CSD without seriously damaging usability and intuitiveness of that program – so headerbar CANNOT BE UNIVERSALLY USED, at least not without forced global menus, which gnome devs refused to support.
6) they have proven many times they don’t know what they are doing and have just a general idea what they want to do but not understand all implication of the choices, so they create UI abominations (like weirdly placed tray icons, or lack of well-implemented appmenus into headerbars) to scratch them completely a few years later without offering solution or alternative (so they ignore usability), the same is with transparent panel, they implemented it and then deleted it just because they didn’t find a solution (while on Plasma’s side latte solved those problems…), the same with the whole theming system, or… lack of thereof, so that leads to endpoint:
7) gnome devs seem to be incapable of solving complex UI designs, so they simplify everything to a point they can handle
Uh, but I digressed too much on Gnome so ignore above.
My point is, headerbars can be ok if they are not forced or not the only one solution. At least firefox or chrome/chromium can use both. Majority of programs out there do not use headerbars so no matter how we push the idea to have headerbars, we always get this confusing mix of CSD and SSD apps, which is awkward and problematic because headerbars cannot be easily customized and integrated into DEs look and theme.
Plasma is currently the only DE that is trying to solve UI design problems in a universal way, not forcing anything on anyone giving us maximal freedom. Sure, it makes things more complicated but Plasma shows that complicated things can be solved. Maybe not always ideal but there is something we can improve with time. Plasma is complex DE and is not afraid to solve complex problems. Is it perfect? No, but it’s aiming for it by getting better and better with each release, creating a bigger and bigger gap between itself and the competition.
LikeLike
Menubars can be implemented as a gear button which drops down to a list that contains all the options a menubar would have. This way you save space and have the functions of a menubar. Still though, the menubar implementation is hard for a user to use, because the functions of a program get hidden behind menu labyrinths.
The drag space problem can be solved the gnome way.
Headerbars might not be as flexible, but sometimes flexibility is not the best option. A flexible UI can be abused by the designer, the same way it is abused now by KDE Devs.
Cross platform headerbars can work. I can use the same gtk+3 headerbar app in all main 3 OS families (Linux, macOS, Windows) without sacrificing headerbars.
LikeLike
Personally, I disagree with your assessment that Header bars look good.
“Headerbars are very visually clean and attractive. There is something about them that just looks good.”
From my perspective they look ugly, non functional, and well… unfinished. They seem to me like an unfinished project that someone is trying to sell at an exorbitant price. One of the reasons why I moved from Ubuntu to Linux Mint Cinnamon.
They seem to me to be a very expensive solution to a non problem or at worst minor issue.
LikeLike
Thank you for not implementing stupidity “paradigm” into KDE. Thank you, thank you, thank you.
LikeLike
PS. If only there was a port of GNOME DISK UTILITY and BLEACHBIT (now GTK3, had to remove some usr/share because otherwise it wouldn’t upgrade…) were ported to Qt. Ahhhh wishful thinking, but maybe some day… who knows.
LikeLike
The gnome headerbars are one of the worst things to come out of gnomeland (aside from no or broken application menu). Some of us do real work on our computers and like to have the title bar a sharply contrasting colour (like CDE). So I know right off where focus resides (the current trend of changing the text to gray is just painful). letting app d3evs set the headerbar colour and text means I spend more time finding the window I want (normally 5 plus windows open in each workspace) and then finding the function I need. Gnome has become a toy that is good for browsing and not much else. Gnomized applications seem to loose more functionality over time as they are dumbed down. In the mean time I am looking for the way I managed to force title bars in my last install.
LikeLike