As part of the release preparation, I’ve done some smoketesting of GNOME 3.14 – looking good! As I usually do, I’ve taken some screenshots while testing things, to share some impressions. Now back to final release preparations.
At the release team BoF at this years Guadec, I said I would write a blog post about the whats and hows and ifs of release team work. I’m a little late with this, but here it is: a glimpse into the life of a GNOME release team member.
We are in the end phase of the development cycle, when the release team work is really kicking into high gear.
Since the .90 release, we’ve been tracking blocker bugs. The way this works is that we are setting the GNOME Target field to the next release. During the cause of the development cycle, we’ve had 50 bugs that were marked with
at some point . Today, we’re down to a single one, which will hopefully be gone before the weekend is over.
We don’t have formal criteria for what bugs to mark as blockers, we are mostly going by the instinct and experience of bug zapping veterans like Andre Klapper. My own criteria for setting this flag mostly come down to these questions:
Is it a crash in a core component ? Is it very visible or annoying ? Will it affect many users ?
For finding bugs that should be blockers, I am regularly scanning all incoming bugs in bugzilla. On an average day this query finds between 100 and 200 bugs – with some practice, one can get through that list in 15 minutes.
We also get ‘nominations’ for blockers from maintainers and developers, which is very helpful.
The duty of ‘doing’ releases is distributed among all of the current, active release team members.
Our development schedule has a pretty well-established cadence of development releases: We do a number of early development snapshots which are roughly a month apart (3.13.1, 3.13.2, 3.13.3 and 3.13.4 this cycle), followed by the beta releases which are 2 weeks apart (3.13.90, 3.13.91, 3.13.92, this cycle).
Most of the mechanics of creating the modulesets by rewriting our regular modulesets (which point at git repositories, not tarballs), and creating those symlinks on the server are handled by scripts that have been passed down through the generations.
The time-consuming aspect of creating a release is that it usually takes several attempts to create candidate modulesets, hunt down missing releases (or doing them ourselves – which is sadly necessary for a number of ‘weakly maintained’ modules), and do a full jhbuild using the final modulesets. As a consequence, while our official release day is always Monday, the release typically happens on Wednesday or Thursday of the same week.
Towards the end of a development cycle, the release team also starts to plan for the next cycle.
This includes creating the schedule, taking a look at annoying bugs that we should tackle in the next cycle, figuring out if there are project-wide goals that we should push, and collecting input on new modules and features that people want to work on for the next release.
Since we are at this point right now, let me end with this request:
Please let us know what features are on your modules roadmap for the next cycle!
It has been a while since I last wrote about the GNOME Wayland port; time for another status update of GNOME 3.14 on Wayland.
So, what have we achieved this cycle ?
- Keyboard layouts are supported
- Drag-and-Drop works (with limitations)
- Touch is supported
The list of applications that work ‘natively’ (ie with the GTK+ Wayland backend) is looking pretty good, too. The main straggler here is totem, where we are debugging some issues with the use of subsurfaces in clutter-gtk.
We are homing in on ‘day-to-day usable’. I would love to say the Wayland session is “rock-solid”, but I just spent an hour trying to track track down an ugly memory leak that ended my session rather quickly. So, we are not quite there yet, and more work is needed.
If you are interested in helping us complete the port and take advantage of Wayland going forward, there is an opening in the desktop team at Red Hat for a Wayland developer.
Update: After a bit of collective head-scratching, Jasper fixed the memory leak here.
My talk at GUADEC this year was about GTK+ dialogs. The first half of the talk consisted of a comparison of dialogs in GTK+ 2, in GTK+ 3 under gnome-shell and in GTK+ 3 under xfwm4 (as an example of an environment that does not favor client-side decorations).
The main take-away here should be that in 3.14, all GTK+ dialogs will again have traditional decorations if that is what works best in the environment it is used in.
The second part of my talk was discussing best practices for dealing with various issues that can come up with custom GTK+ dialogs; I’ve summarized the main points in this HowDoI page.
The GNOME-Continuous continuous integration and delivery system has been helping us to keep the quality of the GNOME code base up for a while now.
It is doing a number of things:
- Builds changed modules
- Creates vm images that can be downloaded for local testing
- Smoke-tests the installed image by verifying that it boots up to the login screen
- Runs more than 400 tests against the installed image
- Launches all the applications that are part of the moduleset and takes screenshots of them
All of this happens after every commit, or at least very close to that, and the results are available at the build.gnome.org website.
You can learn more about GNOME-Continuous here.
As a member of the the GNOME release team I am really thankful for this service, it has made our job a lot easier – at release time everything just builds and works most of the time nowadays.
Earlier this year, we’ve made the smoke-testing aspect of gnome-continuous more useful by verifying not just GNOME, but also GNOME Classic and GNOME on Wayland.
Today, we’ve had a minor breakthrough: for the first time, the GNOME/Wayland smoke test succeeded all the way to taking a screenshot of the session.
To get this far, we had to switch to the egl-drm branch of mesa, which adds support for running KMS+DRM GL applications with QXL.
GUADEC is almost here. GTK+ will be presented with 3 talks:
- GTK+, dialogs, the HIG and you (by me)
- GTK+ and CSS (by Benjamin)
- The GTK+ scene graph toolkit (by Emmanuele)
All of these will be on Monday, the 28th. We will also have a GTK+ team meeting on the 31st.
I’ve made a small collage to summarize my talk:
I’ve last written about GtkInspector in early June. Since then, a few things have fallen into place, so it is time for another status update.
Show all the things
An early focus of my work on the inspector was to make as much information visible as possible (objects, styles, settings,…).
For widgets, we now have a Style Properties tab, which shows the values of known style properties, and importantly, where they originate in the theme css. This tab is still a bit preliminary, but it is a start towards answering the question: why does GTK+ not pick up this selector in my css ?
The property editor popover in the Properties tab is now showing information about GObject and GSettings property bindings, with an easy way to jump to the other object.
The environment section in the General tab includes GSETTINGS_SCHEMA_DIR when set.
Test all the things
Next to making things visible, the inspector is supposed to make it easy to test an application in various situations, such as different themes or right-to-left locales.
I found that I often use the widget picker right after opening the inspector window, so I figured that I should try to combine these two actions. As a result, Ctrl-Shift-I will now open the inspector and select the widget that was under the pointer before. Ctrl-Shift-D still toggles the inspector on and off.
Another small improvement to picking is that the Escape key can now be used to cancel a picking operation.
As I’ve mentioned above, some of the things that the inspector lets you change at runtime can also be set from environment variables (e.g. GTK_THEME). And when they are set, the environment variables often override any runtime changes.
I’ll continue to improve the inspector, but there’s more good ideas for possible features than one person can handle. If you want to help out, feel free to come by on irc, or just put your contribution in bugzilla, where the inspector has its own component now.
I’ve done the release team duty for the GNOME 3.13.3 release this week. As I often do, I took some screenshots of new things that I’ve noticed while smoketesting.
There is quite a bit of good new stuff in this release, starting with an rewritten and improved Adwaita theme that is now part of GTK+:
Next, I’ve noticed that our sharing infrastructure has become network aware, and lets you change what is shared depending on what network you’re on:
At the other side of media sharing, gnome-online-accounts has learned to set up access to the media servers in your local network:
There are more things to discover that I could not capture in a screenshot. For example, I noticed that GNOME shell now remembers which workspace windows where on when you disconnect and reconnect external monitors.
This is also a good occasion to announce publicly that we are aiming to have GNOME 3.14 in Fedora 21 – it may be a little tight, schedule-wise (the GNOME 3.13.91 beta release happens on Sep 1, a few days after the beta freeze for F21), but we’ve been able to squeeze things in, in the past.
Keeping up with the theme of making life easier for application developers, I decided to take an afternoon off from releasing GNOME 3.13.3, and wrote a little application that shows icons from the icon theme, their symbolic variants, and some extra information from the icon naming spec, such as the icon description, and the context for the icon.
This should make it a little easier to find the right icon to use in your application. gtk3-icon-browser will be available in GTK+ 3.13.4.
This has been a long time coming. We’ve wanted to replace the default GTK+ theme for a very long time.
-#define DEFAULT_THEME_NAME "Raleigh" +#define DEFAULT_THEME_NAME "Adwaita"
The Raleigh theme that we’ve used as the default until now has some advantages:
- It is very simple
- No dependency on a theme engine (external or internal)
- It does not use a lot of resources
But there is no nice way of putting it: it is very ugly.
This may not be such a big deal on Linux, where distributions generally have ‘their’ theme, not to mention the many packaged and readily available themes. So, basically no Linux user ever sees the default GTK+ theme. The situation is very different on other platforms, where GTK+ is often bundled with applications, and it may not be easy to install themes, or get the bundled GTK+ to use them.
For a very long time, we’ve held onto the belief that the theming system is a way to make applications blend smoothly into the platform, and that there should be a native theme for each major platform that GTK+ can run on.
This is a great idea in theory. In practice, it has not worked out so well. The one platform where we have a native theme is Windows, and even though the ms-windows theme has received much appreciated attention and updates by Руслан Ижбулатов this cycle, it is still incomplete and has problems with some recent GTK+ features.
(No need to panic though. Even if it is no longer the default, the ms-windows theme will still be available.)
Adwaita on the other hand, is a very complete theme that has received a lot of attention over the last three years. Not only does it support all recent GTK+ features, many of the CSS improvements that the GTK+ theming machinery has received in the last years were direct responses to the needs of the Adwaita designers.
With Adwaita, GTK+ applications can rely on having a 100% complete theme that will look and feel the same on all supported platforms. A theme that is constantly receiving a lot of love and attention and keeps up with new GTK+ features.
Another big plus: Adwaita has a high-quality dark variant, which will now also be available everywhere.
So, why not do this switch earlier ? After all, Adwaita has been around for a while.
The main reason is that we did not want to lose the ‘no theme engine’ characteristic of the default theme. Theme engines, and loadable modules in general, are something we’ve been moving away from for a while now. They are
- questionable from a security perspective (executable code thats shipped separately, inserted into all your applications)
- associated with search path problems
- require stable APIs for many things that are more or less internal
(No reason to panic, though. Theme engines will not stop working overnight in GTK+ 3.)
The alternative to engines that we want themes to use is CSS. Our CSS implementation has only recently become powerful enough to replace the last features from the Adwaita theme engine (focus rectangles and menu shadows). That is why we are doing the switch now.
One of consequences of moving Adwaita into GTK+ is that we will no longer ship application-specific theming as part of the theme (many core GNOME applications currently have small amounts of CSS glue inside gnome-themes-standard). Where this is still relevant, applications should just install it themselves. Here is an example for how to do this.
Thanks for the huge amount of recent work on Adwaita go to Jakub Steiner, Lapo Calamandrei, Jon McCann and Cosimo Cecchi.