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.
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:
Very 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.
As 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;
}
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.
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:
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.
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:
There 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.
Here is a belated update from the GNOME summit that is happening this weekend in Montreal.
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:
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.
The 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).
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:
gnome-session --session gnome-wayland
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.
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.
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:
The new system status menu and the new display panel.
The new system status menu on the login screen.
Some existing and new applications.
Some up and coming applications to look forward to in 3.12.
I’ve not been very good about posting updates on this GNOME development cycle. I was busy with other things, and all of a sudden, we’re already at the beta – I’ve just released 3.9.90, which is the first beta release.
High time to show some of the nice new things that will come in GNOME 3.10.
First, we have a new combined system status menu. This addresses a number of complaints about our previous system status area, such as the user name taking too much space on top bar, and privacy concerns about showing it prominently on the screen.
This screenshot does not really do the work justice, for a full impression, you should try it yourself or study the design.
Next, many applications are using header bars instead of traditional titlebars.
Our previous approach of hiding titlebars on maximized windows had the problem that there was no obvious way to close maximized windows, and the titlebars were still using up vertical space on non-maximized windows. Header bars address both of these issues, and pave the way to the Wayland future by being rendered on the client side.
Somewhat unexpectedly, the control-center has seen quite a bit of work this cycle, too. There is a new Universal Access panel…
a new display panel…
…the background panel lets you configure the lock screen image now…
…and finally, there is a new Date & Time panel.
The map is still there, if you manually configure your timezone. I hope we can enable automatic detection for 3.10, so you won’t have to, anymore.
Speaking about maps, I should mention at least one new application:
GNOME maps will be a preview in 3.10.
That’s it for now. There’s a lot more new to discover in GNOME 3.9.90, like a completely redesigned tweak tool, the note-taking application Bijiben, support for hi-dpi displays, etc.
If you find the right branches of mutter and cogl, you even use most of this under Wayland instead of X – our porting effort is making steady progress.
We had a GTK+ meeting during the Guadec BoF days. It was a long and good discussion touching on many issues. Notes from the session can be found here. Hard to summarize, but some highlights: