All posts by mclasen

Even more client-side decorations

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.

Client-side decorations, continued

Time to talk again about client-side decorations (csd).

buttonsA 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:

headerbar2These 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:

geditIf you want to experiment with this, GTK+ ships a two interactive testcases, testtitlebar and testsplitheaders:

TestcasesThis 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.

Application menu fallbackIt 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:

Better fallbackEnjoy.

A terminal surprise

I recently heard that gnome-terminal in rawhide will reflow its content when resized. I tried it out, and its true:

This has been a very longstanding feature request for gnome-terminal. It has finally been implemented by Egmont Koblinger.  Thanks!

We are planning to to land a few more improvements to gnome-terminal this cycle. Next in line is may be a gnome-shell search provider.

 

 

Client-side decorations in themes

An increasing number of GNOME applications take advantage of new possibilities with GTK+ header bars and client-side decorations.

Today I was asked if it is intentional that applications like nautilus cannot be moved or resized by border drag anymore when using themes such as Ambiance. Of course not! But client-side decorations move the responsibility for theming the titlebar and window borders from the window manager theme (which basically ceases to exist) to the toolkit theme. So, some adjustments are needed to make GTK+ themes take advantage of this.To figure out how this works in practice, I took a look at the Radiance theme. Here is how current nautilus looks with it:Out of the boxVery pointy, and neither shadows nor invisible borders – resizing the window is only possible via the window menu.

As a first step towards improving the situation, I added the following snipplet to the Radiance css:

.window-frame {
    border-color: darker(@bg_color);
    border-radius: 7px 7px 0 0;
    border-width: 1px;
    border-style: solid;
    box-shadow: 0 2px 8px 3px alpha(black, 0.5);
    margin: 10px;
}
.window-frame:backdrop {
     box-shadow: 0 2px 5px 1px alpha(black, 0.5);
}
.window-frame.tiled {
    border-radius: 0;
    background-color: @bg_color;
}

A few explanations are in order here: window-frame is the style class that GTK+ uses when deciding how to render the frame part of a client-side decorated window. The box-shadow gives our window a visible shadow, and the margin determines  the ‘invisible border’ around the window where it can be dragged. We set a less promient style for unfocused windows (in GTK+ parlance, that is called backdrop). Finally, we set a style without invisible borders and shadow for half-tiled windows. You may wonder why we don’t do the same for maximized windows: GTK+ enforces no borders for maximized windows, so the theme doesn’t have to do anything.

Shadows

TiledAs a small refinement, I’ve added a some more css to make the title bar a little rounder:

.titlebar {
    border-radius: 7px 7px 0px 0px;
}

.tiled .titlebar {
    border-radius: 0;
}

.maximized .titlebar {
    border-radius: 0;
}

Rounder

There is of course a lot more refinement that can be done here, like adjusting the padding around the titlebar buttons, and fixing the broken Home button. If you are interested in this, you should check out the relevant CSD section of the Adwaita theme.

Wayland porting continues

Mosaic by Alison's Eyes.

It has been a while since I’ve last reported progress on the ongoing port of GNOME to Wayland. Giovanni did an unbelievable amount of groundwork in mutter and gnome-shell during the 3.10 cycle. After that all landed, we took a bit of a break to catch our breath, while GNOME 3.10 matured to 3.10.1 and now 3.10.2.

Now it is time to pick up the effort again, and sort out what remains to be done for full Wayland support in GNOME 3.12. From a high-level perspective:

  • Wayland sessions in gdm
  • Keyboard handling (layout switching, on-screen keyboard, accessibility, input methods, shortcuts,…)
  • Pointer handling (pointer barriers, accessibility, better touchpad support,…)
  • Window management (lots of details)
  • Application support (gstreamer, clutter-gtk,…)
  • Application testing and porting

If this sounds like a lot of work, that is because it is a lot of work.

Thankfully, quite a few of these things are already in progress or at least being planned. For example, a new xdg_shell interface has been discussed for a while to handle window management. For keyboard handling, Rui has started by implementing layout switching for weston. A new library for sharing input handling code is beginning to take shape too. clutter-gtk support needs subsurfaces, for which Jonas has patches here.

But there is still a lot to do, and any help is welcome. If you feel adventurous and want to learn about Wayland, please join us – there are tasks in all levels of difficulty here, you don’t need to be a über-X-hacker to find something useful to do.

More details on the Wayland port, including the list of open tasks, can be found on the wiki.

Smooth progress

Alex did a nice writeup of the GTK+ 3 drawing model, explaining how the frame clock lets you do smooth animations with a tick callback. To show the difference that this makes, I did a quick exercise this weekend: I converted the activity mode in GtkProgressBar to use a tick callback. You can see the necessary changes here.

In activity mode, the progressbar displays a ‘bouncing’ block, to indicate activitity, instead of showing definitive progress. Applications manually trigger the bouncing by calling gtk_progress_bar_pulse() periodically. What we have done so far is to just move the block a fixed amount, taking care to change the direction whenever we hit the edge of the bar. This works, but gives a jumpy effect that is not very smooth.  Applications can influence the speed of the block by calling pulse() more or less frequently.

Since I did not want to change the public API of GtkProgressBar, and I still want to let applications influence the speed of the block, I use the time interval between the most recent pulse() calls to estimate of the desired speed, and move the block the appropriate amount in a tick callback that gets called for each frame. Note that the tick callback has to explicitly request a repaint, by calling gtk_widget_queue_draw().

Here is how this looks in practice:

GTK+ 3 on Windows

gtk-logo-48There have recently been some stories about applications switching away from GTK+ due to portability concerns. Therefore, I’m really happy to announce that we now have official GTK+ 3 builds for Windows. Currently, the supported version is 3.6.4. You can find these on the very informative download page:

http://www.gtk.org/download/win32.php

The driving force behind this was Manuel Bachmann (Tarnyko on irc). Thanks, Manuel !

We also have a page with instructions for GTK+ on OS X.

Montreal summit

Here is a belated update from the GNOME summit that is happening this weekend in Montreal.

Montreal at night

Jasper and I drove up from Boston Saturday morning, so we arrived a little late. Most people were already there, and there was a well-filled whiteboard with plans:

Ryan making plans

The weekend has been pretty productive so far.

We’ve talked about adding support for notifications to GApplication. This will allow us to get rid of the libnotify dependency and make our application API a bit more complete. This has been discussed for a while, on the gtk-devel list and at the last GTK+ hackfest and again at Guadec. Today, we agreed to merge the GIO patch (see bug  688492). It uses a GIO extension point to allow different implementations; currently we have implementations based on the freedesktop.org spec and on a new, nicer D-Bus API). It should be possible to write implementations for the native Windows and OS X notification APIs too. Help with this would be much appreciated !

Another session I have participated in is a design review and planning session for GNOME Boxes. We’ve done a pass over the UI and took notes about many smaller and larger issues, but we’ve also talked about new features such as multi-monitor support, import/export, snapshots and cloning, and how the user experience for these could look.

Getting ready to partyThe small piece of code I got to write this weekend is to bring back meaningful accessible names for icon-only buttons; these used to come from the GtkStock system, and we didn’t have them for buttons that are constructed from icon names or GIcons. This is an unfortunate regression in the otherwise good out-of-the-box accessibility support of GTK+, so it is nice to have it back. The fix will appear in GTK+ 3.10.2.

Another related session I participated in is a review of the Wayland port from an accessibility perspective with the GNOME accessibility team; we’ve identified a number of issues that we will have to address to keep our a11y support at the same level (such as giving the screen reader a way to identify the surface under the pointer).

GNOME / Wayland in Fedora

I’ve been itching to write this post for a while.

With the GNOME 3.10.0 release, we actually built mutter-wayland in Fedora 20, and enabled the Wayland compositor in the gnome-shell package. For a while, we were missing the xwayland support from our X server package, so gnome-shell-wayland would not actually run. As of today, with the very latest builds of xorg-x11-server, xorg-x11-drv-intel and mutter-wayland, it is actually possible to test GNOME under Wayland in Fedora 20. Note that these updates may not have made it into the updates-testing repository by the time this post appears.

Much of the credit for getting us this far goes to Giovanni Campagna, who writes about it here.

Of course, this is an early tech preview, so you should not expect wonders. The planning page for the Wayland porting effort lists the known limitations and regressions. The more noticeable ones are:

  • The generic Wayland driver is still under package review, so for now you can only try this with Intel graphics.
  • You can’t currently launch a Wayland session from gdm. To start a session, switch to a vt and run
    gnome-session --session gnome-wayland
  • Global keybindings don’t work
  • The touchpad support is very limited
  • The hot corner and pointer barriers don’t work
  • clutter-gtk applications (totem, cheese, …) display their content in the wrong place

But you can try it out, and that is huge milestone.

In the near future, we’ll focus on stability fixes and on addressing the most serious regressions. Our goal for the next cycle is to complete the port to the point where you can use it day-to-day without noticing it. There is still a lot of things that need to be done to get there, we are tracking this effort here. We are also going to discuss the Wayland port at the GNOME Montréal Summit in 10 days, feel free to drop by there if you are interested.

Help is very much appreciated.

One thing that would be helpful and can be done by anybody without expert knowledge of X or Wayland is to try applications and see which ones are working and which ones have issues. To try a GTK+ application with the Wayland backend, use

GDK_BACKEND=wayland <your-test-app>

This will only have an effect for applications using GTK+ 3, of course. There is no Wayland support for GTK+ 2. Applications using GTK+ 2 should transparently use the X server that is provided by xwayland.

 Update:

F20 alpha is not new enough for this. You need to run yum upgrade after installing the alpha, and then install the three aforementioned builds for GNOME / Wayland to work.

GNOME 3.10

I’ve just flipped the switch to release GNOME 3.10. As always, the last few days before the release were pretty hectic, trying to hunt down blocker bugs. A fun bug showed up on Monday, when all of a sudden, gnome-continuous started to show serious rendering issues on the login screen – its awesome rollback capability allowed Colin to quickly determine that the breakage had appeared within the last 24 hours. Only, there was no suspicious-looking commits anywhere to be seen. After considerable head-scratching and debugging, Ray found that the culprit was the change of the gdm version number from 3.9.90 to 3.10.0. It turned out that gnome-shell was using a simple string comparsion with the string ‘3.5.90’ to determine if the gdm version was new enough. That worked great all the way from GNOME 3.6 through 3.9 …

With that bug out of the way, and another client-side-decoration related rendering glitch tracked down by Giovanni and Owen on the day of the release, GNOME 3.10.0 is now officially available. You can find the release notes here. This time, we even managed to have a live image available at the time of the release, you can find it here.

I think it has turned out to be a pretty nice relase. As always, I’ve taken a couple of screenshots during smoke testing:

System SettingsThe new system status menu and the new display panel.

Login screenThe new system status menu on the login screen.

ApplicationsSome existing and new applications.

More applicationsSome up and coming applications to look forward to in 3.12.