tl;dr: Let’s get rid of title bars. Join the revolution!
Unless you’re one of a very lucky few, you probably use apps with title bars. In case you’ve never come across that term, title bars are the largely empty bars at the top of some application windows. They contain only the window title and a close button, and are completely separate from the window’s content. This makes them very inflexible, as they can not contain any additional UI elements, or integrate with the application window’s content.
All GNOME apps (except for Terminal) have moved to header bars over the past few years, and so have many third-party apps. However, there are still a few holdouts. Sadly, these include some of the most important productivity apps people rely on every day (e.g. LibreOffice, Inkscape, and Blender).
There are ways to hide title bars on maximized and tiled windows, but these do not (and will never) work on Wayland (Note: I’m talking about GNOME Shell on Wayland here, not other desktops). All window decorations are client-side on Wayland (even when they look like title bars), so there is no way to hide them at a window manager level.
The CSD Initiative
The only way to solve this problem long-term is to patch applications upstream to not use title bars. So this is what we’ll have to do.
That is why I’m hereby announcing the CSD Initiative, an effort to get as many applications as possible to drop title bars in favor of client-side decorations. This won’t be quick or easy, and will require work on many levels. However, with Wayland already being shipped as the default session by some distros, it’s high time we got started on this.
For a glimpse at what this kind of transition will look like in practice, we can look to Firefox and Chromium. Chromium has recently shipped GNOME-style client-side decorations in v63, and Firefox has them in experimental CSD builds. These are great examples for other apps to follow, as they show that apps don’t have to be 100% native GTK in order to use CSD effectively.
What is the goal?
This initiative doesn’t aim to make all apps look and act exactly like native GNOME apps. If an app uses GTK, we do of course want it to respect the GNOME HIG. However, it isn’t realistic to assume that apps like Blender or Telegram will ever look like perfectly native GNOME apps. In these cases, we’re are aiming for functional, not visual consistency. For example, it’s fine if an Electron app has custom close/maximize/minimize icons, as long as they use the same metaphors as the native icons.
Thus, our goal is for as many apps as possible to have the following properites:
- No title bar
- Native-looking close/maximize/minimize icons
- Respects the setting for showing/hiding minimize and maximize
- Respects the setting for buttons to be on the left/right side of the window
Which apps are affected?
Basically, all applications not using GTK3 (and a few that do use GTK3). That includes GTK2, Qt, and Electron apps. There’s a list of some of the most popular affected apps on this initiative’s Wiki page.
The process will be different for each app, and the changes required will range from “can be done in a weekend” to “holy shit we have to redesign the entire app”. For example, GTK3 apps are relatively easy to port to header bars because they can just use the native GTK component. GTK2 apps first need to be ported to GTK3, which is a major undertaking in itself. Some apps will require major redesigns, because removing the title bar goes hand in hand with moving from old-style menu bars to more modern, contextual menus.
Many Electron apps might be low-hanging fruit, because they already use CSD on macOS. This means it should be possible to make this happen on GNU/Linux as well without major changes to the app. However, some underlying work in Electron to expose the necessary settings to apps might be required first.
Apps with custom design languages will have to be evaluated on a case-by-case basis. For example, Telegram’s design should be easy to adapt to a header bar layout. Removing the title bar and adding window buttons in the toolbar would come very close to a native GNOME header bar functionally.
How can I help?
The first step will be making a list of all the apps affected by this initiative. You can add apps to the list on this Wiki page.
Then we’ll need to do the following things for each app:
- Talk to the maintainers and convince them that this is a good idea
- Do the design work of adapting the layout
- Figure out what is required at a technical level
- Implement the new layout and get it merged
In addition, we need to evaluate what we can do at the toolkit level to make it easier to implement CSD (e.g. in Electron or Qt apps). This will require lots of work from lots of people with different skills, and nothing will happen overnight. However, the sooner we start, the sooner we’ll live in an awesome CSD-only future.
And that’s where you come in! Are you a developer who needs help updating your app to a header bar layout? A designer who would like to help redesign apps? A web developer who’d like to help make CSD work seamlessly in Electron apps? Come to #gnome-design on IRC/Matrix and talk to us. We can do this!
Happy hacking!
Update:
There have been some misunderstandings about what I meant regarding server-side decorations on Wayland. As far as I know (and take this with a grain of salt), Wayland uses CSD by default, but it is possible to add SSD support via protocol extensions. KDE has proposed such a protocol, and support for this protocol has been contributed to GTK by the Sway developers. However, GNOME Shell does not support it and its developers have stated that they have no plans to support it at the moment.
This is what I was referring to by saying that “it will never work on Wayland”. I can see how this could be misinterpreted from the point of view of other desktop environments but that was not my intention, it was simply unfortunate wording. I have updated the relevant part of this post to clarify.
Also, some people seem to have taken from this that we plan on lobbying for removing title bar support from third-party apps in a way that affects other desktops. The goal of this initiative is for GNOME users to get a better experience by having fewer applications with badly integrated title bars on their systems. That doesn’t preclude applications from having title bars on different desktops, or having a preference for this (like Chromium does, for example).
The wiki page does not seem to exist (or the link is not correct). About apps, I would happily nominate Firefox.
Thanks, the link should be fixed now.
CSD support for Firefox is already being worked on. You can try the experimental builds here: https://firefox-flatpak.mojefedora.cz
Can’t edit the article. What about Thunderbird, Remmina?
In fact, firefox on Fedora has CSD included already. You may enable it when customizing the GUI of firefox.
There is also evolution still using server side decorations. It’s one of main sellers in the Linux office related applications department.
I believe this too disruptive for the little to be gained. Better leave it alone.
CSD might not be my main preference (I liked what Unity did, put drop down menu items in them) but I can see they have a few points. I work with people who, for various reasons, have a hard time using computers. Usually due to problems with short-term memory. These people find drop down menus (since they use text which makes funtions easy to find even if you forget where they were) and clear, colorful icons (preferably with a description) very useful. For them, the current CSDs are very impractical. So I wonder, would it be possible to keep drop-down menus as an option and/or (more importantly) put text beneath those small, random icons that tend to fill up CSD headerbars? Like the old, sadly deprecated text under icons option? I am sure that would help many users out there, with or without disabilities.
You want to use KDE, it has text under icons, no CSD
Please do NOT do this! I like title bars and how they are separate making the min/max/close buttons trivial to find. I hate hunting these and other things like menus down in these custom UIs. There’s nothing wrong with some space to air out the UI (i.e.: I don’t consider it “wasted” by any means). Every time I encounter one of these apps I cringe and seek out an alternative. I’m sure I am not alone, and for all of us out there I beg of you: do NOT push this on us!!!
I see “Transmission – GTK3 – medium – not started” on the wiki.
Is that a joke ? They are doing it since 2015 https://github.com/derekstavis/transmission/issues/3
In this case “not started” just means “we’re not aware of it having been started”. Thanks for the info, it’s now updated on the Wiki.
Is it true that all window decorations on Wayland are CSD? A quick search suggests that KDE uses server side decorations there, for example:
https://blog.martin-graesslin.com/blog/2013/02/client-side-window-decorations-and-wayland/
Also is it even possible to make CSD window controls that would look native with all themes? And on tiling WMs without window controls? That sounds like a burden for developers.
From what I understand KDE has a custom protocol for server-side decorations on Wayland that is only supported by KWin.
Regarding your questions, look at Chromium for an example that ticks all the boxes. They use native-looking controls, respect the settings, and even allow you to turn CSD off. I agree that we should make this easy for developers by supporting it at the toolkit level (in e.g. Qt or Electron).
The KDE protocol is also implemented by Sway. The Sway developers contributed support for it to GTK+.
“There are ways to hide title bars on maximized and tiled windows, but these do not (and will never) work on Wayland.” is false, as demonstrated by those and other Wayland-based systems. I’d suggest correcting the post, and maybe rethinking it, since this is falsely used to make a case for this initiative.
I’ve updated the post to clarify: I was never talking about Wayland in general, only about GNOME Shell, which does in fact not support SSD.
Part of the reason for this initiative is that some people on GNOME-based desktops currently use extensions or other hacks to hide title bars, and this solution does not work on Wayland/GNOME Shell. The part of the post you’re referring to was written with that audience in mind.
This has nothing to do with other desktops, and has been blown way out of proportion.
Thanks for the clarification!
This protocol is also supported by GTK+ and Sway.
You are wrong. KDE’s SSD protocol extension is supported by Sway (i3 clone) and a bunch of other Wayland compositors, as well as GTK.
But not by GNOME Shell, which is what I was talking about. I’ve updated the post to clarify.
I use on daily basis Emacs with disabled menu, Qutebrowser, Thunderbird with disabled menu. What you gonna do with title bar for them? It would be only wasted space for the three buttons I never click on because I have configured keyboard-driven workflow (e.g. tiling manager, vim-modes, etc).
I want to be clear: for those apps where menus can’t be disabled, I am personally fine with the style you suggested. I just want to point out that this does not remove a need in some protocol to disable title bar for peoples using keyboard-driven workflow (which, given you have touch-type ability, is an amazing improvement, you really should try).
ATM I am travelling, and typing this text from a small 1366×768 screen, and (not) having a title bar on my Emacs is a big deal for me.
You know what’s funny: I was just pondering your suggestion against my sentence that protocol for disabling title-bars still needed about being future-proof. I asked myself: could that happen that my usecase disappears? Well, increasing screen resolution does not influence screen size, so no — the only possible way for that to happen is if we moved into virtual/augmented reality. But if that gonna happen — you won’t have any use for title bars either! Because you would just drag windows by pinches or gestures.
Just my 2 cents. Sorry about that.
I love headerbars! But please stop calling them “new” and “modern”, ’cause they aren’t. See the screenshots of Xerox’s GlobalView DE, which already had headerbars back in 1996: http://toastytech.com/guis/gv.html
Oh wow, they even have hamburger menus, this is awesome!
From now on, I’ll call them “classic” :D
This is a good initiative, it could do with some blog posts since each kind of app will have a different porting experience.
It would be nice if there was some sort of standard – I like to use things like pixelsaver that remove the titlebar, if there was some sort of standard, maybe some of that could display in the global GNOME shell bar.
I’m still disapointed that rolling up windows doesn’t work with CSD, as Winamp showed back in the day, rolled up Windows and CSD are a great combo.
The problem is that things like Pixel Saver do not work on Wayland. That’s one of the reasons why we need this initiative. There is no solution that will work for all apps, we need to fix each app individually.
If you want to help, reach out to the maintainers of apps you use and convince them to join the initiative :)
There is the “No Title Bar” Extensions (i think it’s a fork of Pixel Saver), which also works on wayland with nativ wayland Apps. https://extensions.gnome.org/extension/1267/no-title-bar/
Don’t ask me how they do it, i am not a developer, but it works, i am using it right now.
It says “This extension does not work on native Wayland applications. The necessary support is simply not available upstream, and can’t be fixed at the extension level.” in the README. Therefore I’d assume it won’t be very useful anymore once most apps are native Wayland apps rather than XWayland.
That’s not really the point though. What I was trying to say in the post is that I think this is a good opportunity to stop applying hacks on our individual setups and actually fix these problems upstream, in applications. It’s harder to do, but more sustainable in the long term, and it benefits everyone. Unlike you and me, most people don’t install extensions to fix minor nuisances with their system, and are stuck with badly integrated apps.
Did you open my link? when i open it it says: “Wayland support: from version 7, titlebars are also hidden for Wayland-native clients that don’t use CSD. Some of the options may be incompatible with this. For issues on Wayland please visit github!”
But you are right, i would like to see more CSD apps. But until then the extension works for me.
Oh I didn’t see that, I just went straight to Github.
I wonder what kind of black magic they’re using to get that to work XD
Edit: Seems like they’re putting some custom stylesheets in the user’s theme directory
IntelliJ (and the other apps of the family) is a big one
I really like this initiative and it is a good moment to promote change, however, we have to discuss certain elements that break with the coherence that an application with HeaderBar may have but that is not part of GNOME such as Gmenu.
As a user I think Gmenu was something that didn’t work and keeping it makes things worse. Not all GNOME applications use it and when you change the settings to be displayed in the application window, you get different behaviors (eg Gedit) in addition to adding an additional button to the interface with options that can easily go in another place. This would add an additional problem for non-Gnome applications (a user would find the same options in different places = bad design)
Eliminating the Gmenu would facilitate usability for the user, who is used to finding the “preferences”, “help” or “about” in the hamburger icon (eg Firefox).
Note: I have seen many closed tickets asking the same for LibreOffice even though they already use CSD so it will be somewhat difficult, on the other hand, the Telegram devs have long wanted to do this, but they don’t know how (PR are welcome)…
I agree that the app menu has problems, and I can tell you that we are probably going to get rid of it sooner or later. The will is there, we just need to actually do the work of figuring out where exactly to move the menu items in the app window, especially for more complicated apps.
If you’re interested in this, we’d very much love contributions in this area. Come talk to use on IRC ;)
About LibreOffice and Telegram: I wasn’t aware of this, could you give me the links to the relevant discussions?
>I agree that the app menu has problems, and I can tell you that we are probably going to get rid of it sooner or later.
WebOS had very similar appmenu and over time they also realized that it was better not to have it.
>About LibreOffice and Telegram: I wasn’t aware of this, could you give me the links to the relevant discussions?
LibreOffice:
https://bugs.documentfoundation.org/show_bug.cgi?id=113388
https://bugs.documentfoundation.org/show_bug.cgi?id=97445
There are many more, but these are the last ones I remember about the subject. With the work that is being done with NotebookBar, it is a good opportunity to rethink the UI for LO.
Telegram:
https://github.com/telegramdesktop/tdesktop/issues/1999
https://github.com/telegramdesktop/tdesktop/issues/379
https://github.com/telegramdesktop/tdesktop/issues/2818
Bonus… There are many projects that have investigated this and even add methods to change from a “headerbar” mode to another “classic” mode like gnome-mpv. Take, for example, the work in Quod Libet. https://github.com/quodlibet/quodlibet/issues/2297
It seems they changed their minds…
https://bugs.documentfoundation.org/show_bug.cgi?id=115512
Yes, great – I’m using qt and from what I can see I’d need to manually draw the header / title bar (incl max min and close icons) for every de / os that I target, incl reimplementing user options and then maintain over time as the interface / options evolve – too hard! Qt needs to deliver on its cross platform promise.
That’s just not true. Qt provides a CSD for Wayland clients. It just doesn’t look very good but that doesn’t matter at this moment because xdg-shell-v6 clients don’t work very well.
Very nice to see this happening, I wonder how long it will take and how many apps will still remain using title bars at the end. The link to the wiki is still broken. I’d add Ardour to the list – native plugin windows could benefit from csd and would save huge amounts of space, it would also make the whole programm look more professional. Not sure how much they’re willing to address this though https://community.ardour.org/node/8694
fingers crossed!
I’m curious: is there a way for non-gtk headerbars to display the usual menu on right click? (The one with options like “always on top”.) If not, perhaps Gnome Shell’s Overview should show this menu when user clicks a window miniature?
May I suggest moving evolution to the high priority list? It is supposed to be the GNOME email experience, but in terms of design it is way overdue. There were some suggestions by Allan Day 7 years ago, even without headerbars that looked so much better:
https://www.google.co.uk/amp/s/afaikblog.wordpress.com/2010/11/25/evolution-re-evolved/amp/
I can imagine that with clever used.of headerbars menus the horrendous labyrinth of preferences may get srreamlined.
When I look at the header bar for that GNOME Builder window, I wonder how a user is expected to move that window. There is hardly any space on that bar where a user can click and drag.
You can move the window by clicking on the buttons. Also, keep in mind that this is the extreme case (lots of elements in the header bar, smallest possible window size), usually there’d be much more empty space between buttons. Generally, GTK enforces a certain minimum spacing between elements so that it can be moved without knowing that you can do so on the buttons.
Breeze is 1/4 way there, since it extends the area of the window decoration over the main menu. If the window manager would know about the area of the main menu/toolbar/header/ribbon/ which contains buttons, you already have everything that’s needed to achieve the same result as with CSD: the window manager extends the area of the decoration wherever the programs lets it. You let programs that want special headers have them, the ones that don’t will just look similar by virtue of this mechanism.
I don’t want to be complaining, but I also want to state my opinion on this topic. I agree, that title bars on Gnome waste a lot of space, which could be better used for other functionality. But I only notice that on Gnome, because the title bars are ridiculously big. I mainly use KDE and sway/i3. There a title bar is either nonexistent or so small, that you are not bothered by it. Sometimes the functionality is enhanced, by putting the first row of dropdown menus into it or by allowing you to put windows into tabs for better space management, but those are easily changable settings.
Gnome on the other hand wastes a lot of space, because the title bar is at least twice as high. Also putting buttons with images or more advanced functionality in there is not something, you could easily switch of. So, please allow me to still use the title bar for window management on different WMs/DEs. CSDs are cool, but I don’t feel like they provide any value for me and I would prefer to use SSDs.
As you seem to be the target of a lot of vitriol on the internet, I’d just like to write that I appreciate your efforts towards visual consistency on the GNOME platform.
PS (offtopic) your “Dynasty” visualisation tool is really cool and neat!
Hello Tobias Bernard!
Thanks for this action, I did create the article for CSD on Wikipedia:
https://en.wikipedia.org/wiki/Client-Side_Decoration
Please help to improve and expanding it.
Blender:
“In order to save vertical space, we’ll likely get rid of window decorations. Such as Chrome (screenshot below), Photoshop, or many others.”
https://wiki.blender.org/index.php/Dev:2.8/UI/Workshop_Writeup#Global_Bars
Hi Tobias, I just read about CSD at Martin’s blog [1] and below in the comment section he finally wrote:
> I and many others misunderstood. In my blog posts I tend to write KWin/Wayland or Plasma/Wayland to make clear that things are not general for Wayland. I think it would be easy for Tobias to make this more clear by explicitly stating that it is only gnome shell.
I think that lead to a lot of confusion. So, would you like to edit your blog post accordingly?
Sincerly
[1] https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/
Hahaha, I was drafting the clarification when I saw your comment :)
Yes, that is indeed the misunderstanding, hopefully it’s now clearer that I was referring to GNOME Shell specifically.
Odd, my Mac OS X 10.13.2 does show title bar on Slack and couldn’t find a way to disable it.
Go ahead. I am in for the Header Bars. Currently on a 19″ 1440×900 and this title bar is eating 1cm of pixel height, even 5mm would be too much, i don’t need that information or at least, this one taking the full width of the window, I do know that I use Firefox right now or Gnome Terminal.
Don’t let yourself pushed back by a bunch of people who does not even try to use the actual software.
Good luck with your endeavour.
/me currently happily using Gnome shell on a 2009 computer since release 3.0.
It sounds great, but before that they would have improved the GNOME HIG about the headerbars.
For example, if we analyze the search bar currently offered by GNOME applications, it is very bad and a better design is offered by Elementary OS HIG (interestingly, GNOME-Builder offers something similar). However, as the idea is not to universalize everything and each application has the freedom to implement the system as best suits the needs, in any case it would be good to improve the UI.
Personally I really like what Gedit offers (a small overlay search bar) which makes the interface more dynamic. On the other hand this could solve the problem of search “tags”.
Another problem are the appmenu that don’t make any sense and could be perfectly integrated into the main menu. On the other hand it is not very intuitive in applications that use the headerbar intensively as a user can move the window and although it can be moved from anywhere, it would be good to add white space to the beginning of the bar, similar to how it is making Mozilla with Firefox.
Finally, I would suggest standardizing Plotinus (GTK+ alternative to Unity HUD), as well as applications such as Gimp, LibreOffice, Inkscape, etc. they would improve their usability without depending on the menu bar lists, being able to use CSD more easily.
Will it be possible to change the location of the “Minimize”, “Maximize” and “Close” button when a CSD-enabled application does not under the GNOME Shell? Or will it look alien there?
Please please please, could you add an action to this list: remind developers using this feature that Fitt’s law exists and that moving windows is actually a highly desired action!
I.e. don’t go overboard, don’t make it hard to move the window because there’s no space left on the top…
Agreed, but in our Linux world this would not be a huge issue if it would happen with some app. Hold down ALT and you can click and hold anywhere to move the window around, very neat feature! :)
FINALLY! I’ve been waiting on this for a long time, and I wished so many times that I was a programmer so that I could help out on this. I’ll help out on other areas, but unfortunately this is not one of my skills…
Seeing this getting priority put a huge and grateful smile on my face!! Many apps looks extremely ugly and old because of the titlebar, this will be a huge improvement. Thank you!
Touchscreen dragging and dropping is needed for future support along with current mouse and touch-pad interaction. With touch also comes the requirement for ambidextrous interaction. Dragging and moving a Windows with a Header bar instead of a Title bar just requires a globally used design.
Firefox 58 on OS X 10.11.6 is a good example. On the left side of the header just after the window controls is a space that spans the width of a thumb, left hand interaction, and on the right side there is also another span that is also a width of a thumb, right hand interaction.
By utilizing space of the header on both the right and the left side of the window, about the width of a thumb, allows for a place to easily drag and move a window with either touch or pointer. This would also be a prime spot at apply middle and right click to bring up older title bar interactions.
With out this it becomes a pain to manipulate a Window and that is also the number one complaint against moving to Headers vs Titles.
Apps should be able to override the title bar space to include frequently used menu entries alongside the static, draggable title and buttons. Visual consistencies may become optional in upstream communication when some essential elements are rendered server-side. The conversation may then focus on functional space (which is the goal of the initiative).
Please add Cheese, SoundConverter and perhaps also GTick to the list.
I have thought about this a lot, and what I really believe these header bars need to be really user-friendly, even for people who need extra accessability, is something like this: https://developer.gnome.org/hig-book/unstable/toolbars-labels-tooltips.html.en
Text under (or next to) icons was amazing, and every time I use an app designed that way it hits me how practical it is and how often I immediately find what I need, instead of having to stop and think for a few seconds – even after using an app for years.
Text under icons and clear, colorful (not symbolic) icons. Text so it’s always obvious what each action does and in which menu to look for things and colorful icons since it’s much easier to remember where to look when you have more things (colors, shapes, detail) to go by. I work with helping people with various neurological impairments such as aphasia to learn computers, and for most of them this would mean the whole difference of being able to use the app or not, even after lots of training. Having small things like that to “connect” your memory with is so very important, and single, grey glyphs is not enough.
Hi,
please, 3 months later, can you share any possible progress? Or some update on how things look like now? I’ve no illusions that there is big progress, just to keep it going so the initiative doesn’t fade away, updates from time to time would be nice.
Thanks
There is progress in the sense that the app developers I talked to are interested. In terms of actually fixing up apps it’s slow-going though, since that requires a ton of up-front design work that I currently don’t have the bandwidth for (porting GNOME to mobile is keeping me busy these days :D)
I understand the idea, however there is one glaring problem that they forgot to thing about… games… games don’t care about window decorations, do they expect each game to implement their own window handling as well?
Is this initiative still going? There are no updates since February…