Hi, we’re Filip and Krešimir, we’re new to KDE and we have been working on sprucing up the lock, login, and logout screens for Plasma 5.16. In this post we’ll be highlighting some of the key changes we made and why.
It’s no secret that we started out by toying with the idea of removing the blur effect from the login screen. On the other end of the extreme lay our so-called wallpaper fader, which would apply a lot of blur and darken wallpapers to the point that it was actually starting to look like a bug. So we decided on a compromise – tone down the fader effect and make the background pretty but with labels you can actually make out.
Improved visual hierarchy
Every single label on your login screen being 9pt is hardly ideal, and sometimes information just has to take priority. With that in mind, we’ve made:
the usernames most prominent (12pt by default)
followed by the login fields and action buttons (11pt by default)
…and the rest stays the same or gets bumped from 9pt to 10pt in the case of the login screen. It should be also be noted that the font sizes are modular now and that you even have the option to change the default font size in SDDM.
Yet another improvement is a new magnification effect for the user in focus – so you can be certain you’re logging into the right user account:
Instead of being glued-on icons with a label, action buttons now have some visual feedback. When hovering over them you’ll get a subtle transparent background and the text will also light up a bit:
Some of the icons have been reworked or replaced with new ones:
The login button has been simplified (because why have a really wide button with a label you have to translate?):
The end result should look like something like this:
We’ve had a lot of fun implementing all of these changes, our knowledge of Plasma and of computer science in general has increased by leaps and bounds, and the process and the results have been incredibly rewarding. We’re hoping that this login screen will stand the test of time and that it’ll also encourage others to contribute, because yes – it’s worth it.
Let us know if you have any comments or ideas regarding what we’ve been doing!
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:
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.
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:
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!