The design for the new GTK+ color chooser had its buttons at the top from the beginning. When I implemented it, we just didn’t have client-side decorations and headerbars to realize this aspect of the design. Now we do, so we can complete the redesign of the color chooser:
Of course, it doesn’t make sense to do this only for one dialog, so the other dialogs that are included in GTK+ have received a similar facelift.
Apart from recovering vertical space (do you really need the typical dialog title “Open a file” to remind you that the window you are looking at is a file chooser ?), the main advantage of this change is consistency: There is always a control at the top right corner of a window to close it.
These new-style dialogs are also more consistent with applications using client-side decorations, like all the modern GNOME applications. But of course, GTK+ is not just a toolkit for GNOME, therefore we’ve done our best to introduce this change in a way that does not upset our other audiences.
The use of header bars in GTKs built-in dialogs is controlled by a setting, GtkSettings::gtk-dialogs-use-header, whose default value is FALSE. As usual, the setting is backed by an Xsetting, Gtk/DialogsUseHeader. For 3rd party dialogs which are derived from GtkDialog, header bars can be enabled with the construct-only property GtkDialog::use-header-bar. Buttons that are added with gtk_dialog_add_button() or its variants are automatically relocated to the header bar. And if you are manually adding content to the action area, we will keep it visible.
You can try these dialogs with the development branch GTK+. If you are using running gnome-settings-daemon, it is as simple as overriding the Xsetting with:
gsettings set org.gnome.settings-daemon.plugins.xsettings \
overrides "{'Gtk/DialogsUseHeader':<1>}"
The changes in GTK+ master are not 100% complete yet, I expect that we will make some adjustments to the dialogs.
Is there an “always use menu button” setting?
Awesome stuff. Though not liking “x-scheme-handler/mailto-type” files
me too
This is completely crazy.
You mention “consistency” but this just marks another step for GNOME to push itself into a corner. How can this be consistent when users will have a desktop where the dialogs of Firefox, Chrome, GIMP, Inkscape etc will have buttons in a way and the ones of the (few) gnome applications will have them in another way?
I am confused, are buttons supposed to be at the top now?
> the main advantage of this change is consistency: There is always a control at the top right corner of a window to close it.
The first thing that springs to my mind is that these “top right corner buttons” are in fact not very consistent.
For example, in the case of “x” button, then the dialog will be closed without anything happening.
However, the other dialogs have a “Select” button which doesn’t just close the dialog: it also acts on what was chosen inside the dialog.
Not sure whether that would be confusing though, as I guess the “x” button would only be used precisely in the cases where there is nothing to “act upon” (e.g “Select”) ?
Is the position of the Cancel button and action buttons final?
As said above, given that the X button, which tends to act like a cancel button, is on the right by default, the Cancel button would make sense on the right and the action buttons on the left. The added advantage of that would be faster access to the action buttons, as the right hand can access the top left corner easier than the top right corner (I believe this was the reasoning behind the top left Activities corner and the bottom right notification corner; can’t find the source now) and, with LTR locales, the mouse cursor tends toward the left rather than the right, as more content is on the left.
I do not like this and I tried to at least make it clear on bugzilla and I hope
other application developers will speak up too.
This pushes the burden to the application developers that are now forced to
duplicate work in both combinations, check their design work with both kind of
buttons, duplicate the documentation effort with having two kind of screenshots
for each dialog and conditionally changing “above” with “below” etc.
ISV are forced to either do this extra work or pick between targeting only gnome
or ignoring it and targeting all the rest of the systems. Which one do you think most will pick? This will only harm the Gtk echosystem which has not exactly been thriving lately.
And for what gain exactly? A little bit of vertical space? For windows that are
smaller than their parent window by design in the first place?
Mind you, there some dialogs where I like this change (the about dialog looks quite
good) and I think it makes sense for preferences dialogs, which in most of gnome
applications are instant-apply and they just have a close button to dismiss
them.
However for “pickers” this looks plain wrong and you left out a screenshot of the
most controversial of these changes: the file chooser. And yes, to answer your
question, I think that a title that distinguishes “Open a file…” from a “Save as…” is useful
The “open with” dialog has a “Software” button, which I assume launches GNOME Software to search for applications which can handle this MIME type.
How does it work on non-GNOME platforms using Gtk? (e.g XFCE, but also Windows)
Does the button disappear automatically if GNOME Software is not installed? Or can it invoke the preferred graphical “software manager” on these platforms?
Note: I’m merely curious about this point, but I’m a very happy GNOME user who loves Software. 🙂
Wow, now that there is an easy way to do client-side decorations, there is an avalanche of innovation going on (after no big changes to titlebars in almost 20 years)!
I also applaud that you thought about non-GNOME users, and there is a fallback, so stuff looks good on other platforms, too.
I like it. Some of the design changes in Gnome have been quite misguided, but this one seems good.
This looks a lot more polished than before, and things like this are really the difference between Gnome being a nice environment in its own right that people want to use or just being a hackish Linux DM.
Will have to see how this works in use…
In the current state of affairs you interact + read from the top to the bottom, with the new system it will be [top]-[bottom]-[top].
We could really do with some UI input + usability testing on this, like back in the Sun days.
http://lwn.net/2001/0726/a/gnome-usability-report.php3
I think this is an “iOSfication” of the interface, where on iOS you go back to the previous window with a back button on top. I predict wizards will be change on the future to have the previous and next button on the top too. This change is visually pleasing but I think so the [top]-[bottom]-[top] Stu mentions is not right. Try a web page that have a few fields and then when you finish you need to scroll to the top to submit, it is not right UI for that, it is not a right UI for this case either.
About the no titlebar text on the file save dialog, what about GIMP? the father of GTK. The file save dialog is used for export and save, There should be something that tell me for what is the window, and I think only changing the action button text is not enough.
All those changes look really great until I wake up from my dream where the only toolkit used on a Linux distribution is GTK 3. After wakeup I remembered I use GTK 2, QT and Java Swing business applications (GTK 2 themed). I remember how I hate the new GTK 3 scrolling behaviour, not because it is bad, not because I can get used to it, but because I can’t get used to it because I switch between applications with different scrolling behaviours that I always make mistakes, or I need to memorize and think everytime “let remember, which toolkit uses this window, oh! it is GTK 2, I can use the new scrolling behaviour, ALT-TAB, mistake scrolling, Oh! this one uses GTK 3, use new scrolling behaviour” repeat multiple time. What could have happened if Apple when they changed to what they call “natural” scrolling, hasn’t added a visible UI to disable it?
Now we will get dialogs with buttons on top and other toolkit with traditional buttons. The hidden setting can not be trusted because, first it is hidden, second wait a few more GTK releases and it will be removed and hardcoded like the menu-has-icons settings, when developers notice people are using that setting too much, they will force it.
Hi,
Interesting point about the iOSification, and I guess it does make sense.
Certainly the (lack of) integration of Java apps is a problem already… maybe the gnome foundation could fund someone to do support for Java and Qt (though QT already seems to integrate fairly well).
Java integration is just baaad… font rendering and size is all wrong.
S++
I’ve peeking through the code and the “software” button on the app chooser dialog is hard coded to only shown if “gnome-software” is found.
It is very easily patched to support other software stores that accept arguments through the command line, if they support searching for packages for specific mime types. However, I don’t see an option in Ubuntu software-center launch it with an option to search for a content type.
I guess you could also use the more generic gpk-install-mime-type.
I know GTK is designed with Gnome in mind, but devs should not forget that it must remain cross-platform. It should keep some degree of abstraction over platform-specific dependencies, specially such one as gnome-software.
For size constrained screens, such as phones or tablets, this seems ok, as the headerbar wastes the minimum amount possible of screen real state. But for desktops, top-bottom interaction is much better. As Stu has pointed out, my guess is that concerning usability, top-bottom interaction is better than top-bottom-top interaction. It could work well for netbooks, though.
Yeah, I was thinking that myself. This would be great for my old netbook where vertical space is absolutely priceless, and where a number of current apps have dialogs that don’t fully fit on the screen – even it was suboptimal in general, it’s still going to be a win on that scale.
But I’m less convinced that it’s a good idea in general – it looks cool, but I’d like to see some usability testing done, particularly on high-use dialogs like file open/save. I don’t care that it’s different from what went before, but I *am* concerned about inconsistency between apps that use these “top buttons” and apps that do more traditional “bottom buttons”.
Visually they look good when taken individually, but as also others have expressed, this doesn’t look very consistent. I’d rather have the “Cancel” button lie in the same place where the “X” button is found (wherever that is), because that’s essentially the same action.
Perhaps “Cancel” is the new “back” button which is usually on the left (in browsers and iOS).
I *want* to like this because it’s shiney and new, but it does feel a tad inconsistent.
In the About dialog screenshot I’d be more comfortable seeing proper tabs than buttons used as tabs.
It’s notable that in the new Gnome apps (Clocks, Documents, Weather, …), the Cancel button for leaving the selection mode is on the right, so this positioning is inconsistent with the new apps as well.
Is the Select button hidden or grayed out until a selection is made?
Suppose an app developer loads up the GtkHeaderBar with lots of buttons. Will the user still be able to find an area to grab the window to move it?
I dream of a future where GTK and GNOME developers will stop changing and deprecating things. As an application programmer I feel that I use more and more of my time developing for the toolkit – instead of developing for the user. I’m so tired.
No one is forcing you to use header bars or the new functionality.
Sooner or later his users will, if everybody else is using them.
In that case he will be developing for his users, no?