Time to talk again about client-side decorations (csd).
A while ago, I’ve talked about themes and what adjustments they need to make csd windows look respectable. Back then, I avoided the most thorny issue with csd: window controls. Window controls are the close, minimize, and maximize buttons that window managers have traditionally put into their titlebars.
Early in the GNOME3 era, we tried to save some vertical space by simply hiding titlebars when the they containing important information. This is particularly relevant for maximized windows on small screens, where vertical space is scarce. This was the hide-titlebar-when-maximized property. As we soon found out, the lack of a reliable close button in the upper right corner with this approach is a big problem for many users.
More recently, we’ve switched to a different approach: Reclaim the area that has traditionally been taken up by the titlebar for applications. To this end, we’ve introduced the GtkHeaderBar widget, which lets applications use this space for its own purposes. This was pretty successful. Many GNOME applications are making good use of this now, e.g. nautilus:
These custom titlebars require window managers to have support for mwm hints, so we can convince them to not show their own titlebar. These hints have traditionally been well-supported in window managers — so far, the only problematic case we’ve found is xfwm4.
As you can see in that nautilus screenshot, there is a window control — a close button in the upper right corner, which will stay in there as the window is maximized, addressing the problem with hidden titlebars. Since the header bar is application area, the close button is only shown if the application author explicitly allows this by setting the show-close-button property.
This is a nice and clean story, but of course, things never stay that simple.
Window decorations, and in particular window controls are a traditional area for distro differentiation and theming (you may still remember the discussion about Unity buttons), and unsurprisingly, we soon got requests to allow some themability.
In 3.10, GTK+ added a style property, gtk-decoration-button-layout, to let themes control the button layout. At first, we only respected this property for client-side titlebars that were not explicitly added by the application. This turned out to be insufficient and opened us up to some (justified) criticism about the (lack of) consistency with client-side decorations.
So, shortly before christmas, I’ve gone back and redone the configuration mechanism one more time, changing it to a combination of a setting, GtkSettings::gtk-decoration-layout, and a regular property, GtkHeaderBar::decoration-layout, whose default value is taken from the setting. The settting is backed by an xsetting, Gtk/DecorationLayout.
This adds more flexibility: Themes can influence the default value of the setting (via their settings.ini file), distributors can set a default value and users can override it via the xsetting (hopefully soon from gnome-tweak-tool).
But application developers / designers have the last word: they can hardcode the property to just show a close button on the left, if the application design does not accommodate wild variations in the header bar layout. Or they can read the setting and make adjustments, e.g. for the case of split header bars, as can be seen in the new gedit design:
If you want to experiment with this, GTK+ ships a two interactive testcases, testtitlebar and testsplitheaders:
This is a difficult area for a toolkit. We find ourselves between multiple competing interests:
- Users expect consistency across applications
- Distributors expect applications to adapt to whatever environment they are running in
- Application designers want applications to appear as designed, and not wildly different depending on the environment
I hope that the mechanism that is in place now is flexible enough to allow balancing these interests, and to make GTK+ applications work well in different environments.
One last thing I should mention in this context is the GNOME application menu. GtkApplicationWindow has had a built-in fallback for other environments since day one, but it is not that great.
It uses a mostly-empty menubar, which adds to the vertical space problems, and it duplicates the application name. In GTK+ 3.12, the fallback menu will be integrated in the header bar, and look much more natural:
Enjoy.
Is it already possible to write a theme that takes the application menu out of the global top bar and puts it back inside each application window, thus restoring usability in focus-follows-mouse mode?
If not, when will it be possible?
You’ll have to write a shell extension that, I think.
Can’t wait for this extension !
There’s an extension that does that: https://extensions.gnome.org/extension/32/remove-panel-app-menu/. It’s for 3.6 and 3.8. I don’t know how much work it would be to update it for later shell releases.
Is there a way to put the application menu ALWAYS in the titlebar (as a configuration settingà in GNOME 3?
This is really one of the things I dislike about GNOME 3 / GTK 3 / HIG 3. It forces me to move my mouse (and eyes!) a long distance (thing multidisplay) to sometimes do the most tivial things.
Hey even after 2 gnome releases (maybe more, maybe less?) I often forget the menu is there (there: as in far far away) in the first place!
I really like this app-menu-in-headerbar too! Might make sense to think about making that the default.. I’m afraid the app menu-in-top-WM isn’t the wild success we hoped to achieve.
Maybe just have it in both places (global menu and header bar) by default so that everyone’s happy!
Thirded, for another reason: there have been numerous UX studies showing that it’s better to show all UI elements and disable some, rather than changing the UI based on the current state of the software. That’s why menus have disabled-but-present menu items, toolbars have disabled buttons, and so on. For the same reason, if you have multiple windows, the application menu shouldn’t only show up for the app with the focus, it should show up for all apps, which works best if it’s attached to the app.
I fourth, I aggree with the previous Anonymous reply
This would be SO nice. With 2 x 1920×1200 monitors and focus follows mouse, the app menu is one of the features that I really don’t need.
Or how about having the app menu in the window title bar only when the window is not maximized.
I miss titlebars – they make a desktop look professional IMO. Especially on a hi-res screen where they can be a nice narrow stripe. The classic monochrome Mac Windows had a light-weight feel (ditto Amiga OS 2.0).
I also miss “right-click on the desktop for the application launcher menu”, so I am clearly getting old.
I like expose window navigation, so maybe there is hope for me yet!
Openbox will be the answer to your dreams sir.
While headerbars are nice, they are complicated. And that means bugs, more app developer work, more theme developer work, more inconsistencies. And bugs.
Maybe server side decorations weren’t the best idea ever, but they were simple and consistent. And listened to me, not to app devs. My PC was mine. Now it belongs to people that have different opinions about design and aesthetics. (Not that I dislike Gnome 3 apps, they are quite nice (!), except for few things.)
And thanks to the author for writing this article!
Yes, the key to a professional desktop is definately a clusterfuck of nested words with fiddly navigation.
Nice work ! The possibility to truly integrate the application menu into the header bar is really awesome :
– for small windows
– for full screen GNOME Shell experience thanks to one of the extensions that hide the top bar
– for people who are not used to computers (the application menu is not easy discoverable)
I feel you are making concessions to please people that were disappointed with GNOME 3 (which is not my case), I think you are doing the right thing.
Keep on the good work !
Pretty interesting work! It looks very nice, looking forward to see how well it works in practice.
One thing I’m wondering, does/will GtkHeaderBar have a fallback for the case that the user or the window manager wants a traditional title bar? It could simply hide all window controls in that case. I know, you’ll loose vertical height, but it has some benefits too (uniform appearance, you can still move/close/minimize hung windows)/
I also wonder if it would have been better to improve window-manager-side decorations instead. I hacked metacity a while ago to allow clients to draw on their titlebars. It was just a proof of concept, and I never finished it. Basically, I added a new X window property for windows to opt-in. Then they would get a custom event, and they’d receive a Drawable from the titlebar’s window to draw on. Surprisingly, this worked cross-processes without problems. My POC used it to draw tabs in the titlebar, like Chrome.
Of course, a real implementation would need to report safe areas to draw to. It could be integrated with gtk’s draw events (you get a separate notification with a negative y value to draw on the titlebar), and you could place widgets there with some trickery (either windowless widgets, or windowed widgets by reparenting them into the titlebar). Another nice feature would be to allow custom buttons in predefined slots. They would take on the style of the window manager and should be really easy to implement.
THIS.
Finally a sane fallback menu!
This post explains the motivation behind the header bar. However, it would be nice to know why the window border is drawn by the window manager – i.e. why there are no client-side window frames.
Great work! The elementary OS crowd will be pleased. (I use plain Gnome so I’m already happy.)
It would be nice if tab bars also looked at this setting to determine whether to show the close button at the left or right of each tab. Ditto the Activities overview’s window close buttons, and the shell’s notification pop-ups.
One of my favourite unadvertised features is middle clicking the window title bar to send the window to the back. How will this work with apps with hidden titlebar? Can I middle-clicking the blank space in the new GTKHeaderBar?
yes, you can
Oh, good!
But I guess there won’t be a “collapse to titlebar” window option, since there’s no titlebar…?
Although as a user of this feature, I would point out that HeaderBars have created some problems. The blank spaces are different from app to app, and even within the same app. For example, in Files, as the breadcrumb grows longer, the space you can middle click gets smaller and smaller. This all creates more effort for the user finding a clickable space.
Perhaps gnome developers can consider that adding a window control bottun beside the close button, and let users maximize, minimize a window or move a window to other workspaces by using window control bottun.
I really like the concept of titlebar, but somehow I feel it is too simple!
I really like the concept of header bar, not titlebar! I had a little typo in original comment, sorry~
https://plus.google.com/u/0/+MartinGr%C3%A4%C3%9Flin/posts/ZZBaE8Kg24X
I love they way vertical space is being utilised with the GtkHeaderBar but users with Netbooks still can’t use GNOME applications like Photos and such because they have a minimum window height larger than 600px. These apps won’t maximise and the bottom of the apps/toolbars are cut off. Bugs have been reported but it doesn’t seem like anything will change.
I’ve seen an issue (at least in the 3-10 stable branch) where the window context menu options with GtkHeaderBar weren’t localized even though the relevant gtk+ translations are complete. Anyone else?
How hard will it be to draw content that seamlessly extends from the main part of the window into the titlebar? This is important for Web browsers (Chrome, Australis).
Me gusta.