Unity-Headers Concept: using server-side hearderbars to create a consistent, customizable and space-saving UI, for most applications.
Why headerbars and HUD?
Headerbars, sidebars and HUD are replacing toolbars, menubars and emty titlebars in new GUI applications. They leave more space for content, allow for neater display of tools and options, and improve discoverability compared to traditional UI models.
Why server-side?
Gnome has already adopted Headerbars and is now beginning to adopt the HUD because headerbars alone can’t cut it. Future releases of Gnome Builder will have this this exact combination of Headerbars and HUD, but executed from the client side:
Unity had native, consistent HUD working for virtually every app. And it had locally-integrated widgets in the titlebar of every app. In comparison, Gnome’s approach to do it all client-side has proceeded at a snails pace and can never deliver a consistent or native UX. It also means a massive duplication of effort, as each is app is required to decorate itself and provide its own HUD.
After a decade of GTK+3, only one app has a HUD. This was obviously never going to work for the Linux app ecosystem as whole. Server-side headerbars and centralized HUD can deliver all the benefits of client-side equivalents with none of downsides, at an infinitely faster rate.
Unifying window decorations for all apps.
The solution requires two things: window manager support for a few simple widgets in the decoration and application support for global menu.
The proposal is substantially similar to KDE’s proposed “Dynamic Window Decoration” protocol. Both ideas rely on server-side decorations. However the DWD protocol seems to rely solely on the application developers for implementation. The Unity-Headers concept should implement DWD as well but its primary focus is on locally integrated menus and user customization of the header.
With the wide adoption of Gnome CSD, the Unity-Headers concept is the ONLY way to get a reasonably consistent UI on Linux, without seriously limiting user choice.
It is unclear which window manager is the best candidate to for proposed idea. This cannot be implemented in Mutter because Gnome is opposed to server-side decorations and Gnome is too tightly coupled with Mutter. To get around this restriction, an older version of this post proposed using CSD containers as intermediary server-side decorations, but the developer of the DWD protocol explained that this would be excessively complex. So Gnome Desktop is ruled out as a candidate unless someone — perhaps Librem — is willing to maintain a patched version of Mutter.
KWin seems to be a plausible candidate although Mutter forks like Gala should also be considered. For example, it would make all applications looks great on the Pantheon desktop, not just those that were designed for it. MATE DE already has global menu, HUD, and a forked version of Mutter, so it is a logical candidate as well.
Support from applications can bring additional benefits. However, with the exception of global menu support, no changes to the underlying applications are needed for this solution to work. User input however is required to get the most out of the Unity-headers solution.
Boilerplate:
“Unity-Headers” is a concept for bringing the features offered by Ubuntu Unity (LIM + HUD Menu) and GTK’s space-saving “header bars” to nearly all applications. The goals are as follows:
- Allow the user to make server-side decorations consistent with Gnome-style client side decorations.
- Allow the user to change the colors of server-side decorations. (Already implemented on KWin)
- Allow the user to position and customize flexible menus in the server-side decorations (partially implemented on KWin)
- Allow applications to negotiate widget placement with the window manager (DWD procol, partially implemented on KWin)
- Allow the user to add programmable widgets (primarily buttons) to the titlebars of particular applications. A widgets can trigger a menubar event or even an custom command.
- Create a HUD interface to search through menu items (or any other actions exposed by the application, if applicable) (fully implemented by Plotinus and Mate-HUD)
For several years now Gnome has been pushing CSD and most of the newer Gnome apps have adopted it. The central feature of Gnome’s CSD design is the headerbar, wherein application widgets are combined with the title bar.
These “modern” Gnome applications are visually and functionally inconsistent with nearly all other applications in the Linux ecosystem, most of which use a traditional UI design (server-side decorations, menubar, toolbar).
There is no way give modern Gnome apps a true traditional UI without rewriting them one by by one, though GTK-Mushrooms is a good attempt. So there is no way to bring consistency by changing Gnome applications.
But there is a way to give the vast majority traditional applications a headerbar, thereby making them remarkably consistent with modern Gnome apps. It is possible to do if — and only if — the window manager can implement user-customizable server-side decorations.
Please fill out the survey at the bottom after reading. Thanks!
The Problem
Many Gnome applications use the new headerbar UI, some others use their own eccentric CSDs, and all the rest stick to the normal traditional layout.
Some applications provide a “HUD” search feature that allows you to search through the various tools and options (Sublime text and Gimp), while others make you visually scan all the toolbar and menu items (LibreOffice).
Some applications have configurable toolbars (KDE apps) other applications provide no way to configure toolbars (almost all GTK applications).
The UI is hopelessly fragmented and bound to get even more fragmented with time, as more and more applications start getting CSDs and various other novel widgets. It’s as bad as Windows.
The last attempt to unify the linux desktop was Ubuntu Unity, which relied on menubars and titlebars to achieve the “unifying” effect. With Gnome CSD, it is no longer possible to guarantee that an application will have a menubar or a titlebar. This calls for a different approach to unifying the Linux desktop.
To summarize, the following problems need to be addressed:
- visual inconsistencies between GTK CSD apps and all the others.
- space-wasting menubars and toolbars.
- the lack of discoverability.
- Inflexible UIs that allow for little to no user customization.
- inconsistent colors between the application and the titlebar.
The “Unity-Headers” Solution: Windows.
The solution is to allow the user to add menu items to the header, either as menubar or individual buttons. If using buttons, user intervention would be required for each app. Solely relying on support from application developers (as in DWD) cannot possibly be a good strategy, because there is no guarantee that developers will support it. Actually, there is a guarantee that the vast majority will not.
Like Unity, “Unity-Headers” take the menu as its starting point. Luckily, most applications with lots of features still use menubars. Most toolkits can export menu bars, and virtually all applications on Ubuntu today work flawlessly with “global menus”. Even the latest versions of Jet Brains developer tools now export menu bars, to conform with KDE’s recent “global menu” feature. So coverage is excellent.
Instead of a global menu, Unity-Headers will use “locally integrated menus” (LIM). Unity had locally integrated menus, and the feature exists today on KDE:
LIM has several advantages over a global menu, particularly on Linux:
- They don’t require a top panel.
- There is no problem with multi-monitor support.
- They can, potentially, be used independently of a particular desktop environment.
- Gnome applications don’t use menubars and thus would not benefit from a global menu.
- The menus stay inside the window regardless of whether or not the menubar is exported. Even if a particular application fails to support LIM it remains consistent with those that do.
Unity-Headers takes the LIM concept one step further by allowing the user to customize the placement and appearance of the exported menu:
- An LIM can be either a dropdown, a menubar or both depending on window width.
- An particular menu item can be picked out from the array and associated with a button in the headerbar. The headerbar configurations will be saved for each application.
- KDE’s DWD protocol which allows the applications themselves to expose various actions in the decoration will be supported.
- Potentially, the buttons and widgets in the decoration will be made fully programmable. So if a user wants to launch an arbitrary script from the headerbar, they may be able to do it.
Let’s take an app like Evolution, a Gnome app that uses a traditional design, Gnome’s CSD initiative notwithstanding:
Here’s what Unity-Headers could do:
There isn’t enough space for a full menubar, so the LIM is reduced to a dropdown. The user has decided to pick out several items (Mail, Contacts, Calendar) from the exported menu array and place them as buttons into the headerbar. The user can also add menu items to the customizable hamburger menu on the right. All of the buttons here come from the exported array of menu items.
Evolution allows the user to hide almost any pane and any toolbar. Since the user has buttons for Mail, Contacts and Calendar in headerbar, he no longer need for the pane on the bottom-left. So the user hides this pane from the interface.
The resulting application now looks like a “modern” Gnome app, fully consistent with all the others. And a ton of screen space was saved.
One could also do it another way:
There is enough space in this window for a full menubar and also a customizable hamburger menu.
But there is also another problem. You can’t launch Evolution with a custom theme and expect the titlebar to be match. The titlebar will remain white because . While nobody really cares about changing the color of Evolution, here’s a case where it would be useful:
Here’s what Unity-headers could do:
The user set a custom color to the decoration. This is already possible in KWin. The button on the right is associated the “full screen” menu item.
To take another example, you can make KDE Okular look virtually identical to Gnome’s Evince. Here is a regular Okular window:
Here’s one with Unity:
Again, the menubar has been exported as a dropdown and the user added a few menu items to the headerbar as buttons, then picked out some icons for them. There is also the same “favorite tools” menu on the right. There is now much more room for content and the user still has access to all the controls they need (which are also accessible with HUD, more on that later.)
Indeed the user might be able to transform even LibreOffice in exactly same way, putting the essential tools and menus into the headerbar and using the HUD to search for less used functionality.
A major problem with the CSD initiative is that most linux apps outside the Gnome universe will not support it. At present, the only ones I know of are Firefox, Chrome and VSCode. And those that do support CSD, will never look or behave natively on Gnome or any other platform, no matter how hard they try (and most of them won’t try).
Here’s Firefox with CSD:
Can you easily drag the window? No, the grab area is tiny. Do the decorations look native on any desktop? Absolutely not. Can you do a right-click on title-bar area to maximize (that’s a gsettings option)? Hell no!
If you think this sucks you will want to disable CSD. But then you have empty space at the top. Your custom themes will never match your titlebar. Finally, unless you have learned all the shortcuts, you’ll need to use the tiny hamburger menu on the right, which requires great aim.
Now here is Firefox running with Unity-Headers:
Theme doesn’t clash and we now have a full menu bar instead of wasted space (at least on Ubuntu and Debian).
Here’s another application that has “moved to CSD”:
This is Visual Studio Code. CSD isn’t the default option and you have to do extensive googling to figure out how to enable it. And no wonder, because that’s not an option anyone in their right mind would choose. Obviously the window drag area is greatly reduced, the borders are hideous and and you can’t right-click to maximize or pull up the window menu. Gnome designers insist that CSD will boost UI creativity but there is nothing creative about this design. Indeed most apps that will implement CSD will just move the menu bar into the titlebar, at the expense of all other concerns.
Unity-Headers: What about titlebar actions?
You can still drag headerbars from anywhere, unless they contain draggable widgets. Buttons and Menus aren’t draggable.
Gnome has solved this problem with their CSD headerbars. You can drag them from anywhere, even from a place that contains widgets. You can also replace double-click to maximize/restore with right-click to maximize/restore in gsettings, and you can you middle-click to bring up the window manager’s menu options.
The titlebar’s functionality is NOT lost with headerbars! In fact, since headerbars are thicker than normal titlebars, they are easier to grab and drag.
The Unity-Headers solution part 2: the HUD
Ubuntu Unity made all menus searchable with HUD:
Today we have Mate-HUD, which does the same thing using Rofi.
And for GTK+ 3 apps we have Plotinus (Mate-HUD only exposes the appmemenu for Gnome CSD apps):
Plotinus relies on loadable modules to accomplish this and loadable modules are removed in GTK+ 4. There may however be another way to make this work for GTK+ 4 apps. Plotinus also has the benefit of showing the user all the keyboard shortcuts right in the search interface. There is no need to pull up a separate “shortcut help window” then close it just to figure out one shortcut.
Finally Gnome designers may be planning to suggest HUD for developers of GTK+ 4 applications. There is a mockup somewhere on gitlab, but I can’t find. HUD is the only choice for feature-rich applications that don’t use a ton of toolbars and menu, both of which Gnome applications lack. Therefore it seems like more and more Gnome apps will implement HUD internally in the future, just like many developer tools.
CSD-Headers would be complemented by a HUD interface just like Plotinus and Mate-HUD. Since the menu items already need to be serialized in order to populate the headerbars, it make sense to allow the user to search through the menu items.
To summarize, the HUD will have near universal coverage with Unity-headers. It will cover:
- All applications that can export menu bars.
- Virtually all GTK+ 3 applications, even if they don’t have menu bars (see Plotinus)
- Many applications will implement HUD internally.
And again, if one or two applications don’t support HUD, who cares? Most will. The HUD provides a great deal of consistency to the interface.
TL;DR: The Result
- All apps can now have have headerbars. An app that now has a simple titlebar gets a headerbar instead. All of these headerbars are customizable by the user.
- Virtually all menubars can now be rendered in a Gnome-style headerbar, just like Unity’s or KDE’s locally-integrated menus. You can choose between KDE style and Unity style depending on your preference, or make it dynamic depending on window size.
- You can add any menu item (provided the application exports menus) as a button to the headerbar. Let’s say you want to add the highligher tool button from Okular to the headerbar. You just pick pick the menu option for the highligher and add it as a button to the headerbar. You can actually pare down and even hide whole toolabars (if the application UI supports user customization) by moving some functionality into the headerbar.
- You can if you wish, hide all your toolbars and just use the menus and buttons in the headerbar, for any app that has customizable/hideable toolbars. You can make Okular look like Gnome’s Evince, leaving much more room for content without losing access to the controls you need. You might even be able to do the same for LibreOffice.
- Nearly every app that doesn’t have a HUD interface out of the box gets a HUD.
- You can now save lots of screen real estate in most apps by hiding the menubar and paring or hiding down the toolbars.
- **Near universal coverage **on Ubuntu, Arch Linux and many other platforms.
Interested?
Yes, No? Please fill out the survey so I can gauge the enthusiasm for this (click “End Survey” to submit your response). If people don’t really want this and don’t want to help with the project, then it will not happen.
Survey results:
Seems like there is plenty of interest in this.
