Update: Since I have been asked about this. The engineering position that is on the website with a location of Munich can also be filled in Boston (or Brno, for that matter).

This post is not going to talk about exiting (or boring) technical stuff – I’ll get back to that in my next post. Today, I want to point out some job openings in the desktop group at Red Hat.

While our daily business is to maintain and improve GNOME  and its underpinnings, we are also responsible for the user experience of servers and other non-desktoppy deployments.  We have a small team that is looking to bring our design principles and many desktop technologies into that space. We are currently looking for an engineer to join that team.

Please check back on our website – we are going to have more positions open in this team soon.

Other things we are concerned with in the desktop group are graphics (ie X and graphics drivers) and virtualization (mainly desktop virtualization, with technologies like Spice). If you are a graphics wizard who knows GPUs and video codecs inside out and know something about virtualization, then we have a job for you at the intersection of these topics.

If you are more into managing development teams than into writing code, you may be interested in this position.

Finally, we have an opening in our Brno office for a software engineer to help us  maintain and support our products. This is an entry-level position that does not require a super-long resume of GNOME contributions (we expect you to grow that list on the job). If you are a student near Brno, we also have a number of desktop-related intern projects in the Brno office that are opening very soon – but I don’t have a link for these just yet.

Now back to my regular technical content – I have a GNOME release to do that will be chock-full of cool new stuff.

There was some discussion on fedora-devel-list about how to make it more obvious that the Fedora desktop spin. Various proposals were worked out to the point of working implementations.

Kamil Paral made the start with an extension that puts an ‘Install’ button in the top bar. I’ve followed up with a notification that pops up at login, explains that you are using live media, and offers you to install (The backstory here is that we’ve actually had a shell extension for showing the installer on the desktop spin for a while before F16, but the gnome-shell team asked that we ship GNOME 3 without extensions installed, so we’ve taken it out.). The notification was never my favourite approach to this issue; I preferred to just auto-start the installer.

We are very lucky that Cosimo Cecchi and Kalev Lember teamed up for an outstanding job, and got a much nicer solution implemented, polished and integrated in a matter of days, so the initial experience when booting the F17 desktop spin will be this:

I’m looking forward to it !

While the release is building on my laptop, I have time to write about a few more things I am looking forward to in GNOME 3.4.

Easy Extensions

We has been working hard to make GNOME 3.4 smooth and remove the small things that have been annoying people. But everybody has his own habits, and sometimes you just need that extension to support your specific workflow. This will be much easier from now on; with extensions.gnome.org, extensions are just one click away, and you can try them out right from your browser.

GNOME goes virtual

Two exciting things in one screenshot: gnome-boxes is beginning to make VM access easy in GNOME, and gnome-shell is running fine in qemu with software rendering.

Admittedly, the gnome-boxes release in 3.4 is more of a preview of things to come, but it is already working well enough for simple tasks, such as testing nightly spins. And for software rendering to work, you need recent drivers – the current F17 beta works nicely, as seen in the screenshot.

Update: Yes, the aspect ratio of the VM is slightly off; I hear that this will be fixed in F17 final.

GNOME for Artists

I can only manage to draw squiggly lines in GIMP. I am not really much of an artist at all, even with proper tools like a well-calibrated tablet.

Bastien Nocera and Peter Hutterer together with Jason Gerecke and Olivier Fourdan have worked really hard this cycle to bring first-class support for Wacom tablets to GNOME.

These tablets are amazingly complex devices, with programmable buttons, multiple styli, ‘touch rings’ and other fancy controls. In GNOME 3.4, all of their functionality will be accessible from the Wacom panel in gnome-control-center.

Together with our color management support, this should make artists feel more at home.

GNOME for Everybody

Accessibility has always been an important characteristic of GNOME. With 3.4, GNOME 3 will catch up in this area. Orca now reads all of the gnome-shell interface to me. And, what is more important, I can leave it running for a long time without problems – the stability of the accessibility stack has really improved.

We’ve also added a dialog that gives very detailed access to the options of the built-in gnome-shell magnifier. These options are just fun to play with for me, but for people who really dependent on a magnifier, they can be essential for being able to use the computer at all.

I didn’t manage to write a second post during the hackfest, so this is a somewhat belated summary.

We had several long discussions around multi-touch, gestures, event controllers and input handling in general, as well as theming, css, clutter and render objects. At the end of the weekend, we tried to condense these into a rough roadmap for GTK+ and clutter. You can see the notes on that here. One result of the roadmap discussion is that the clutter-based GTK+ will be 4.0 – introducing this kind of new dependency is just not suitable for a 3.x release.

As mentioned, touch was an important topic. Carlos Garnacho has done important pioneering work on multi-touch in GTK+. During the hackfest, he started to separate out the parts of his branch that we agreed to get into 3.4: XInput 2.2 support, basic touch events, kinetic scrolling and smooth scrolling. In the week since the hackfest has ended, I’ve made some API adjustments and cleanups.

The touch-related API in 3.4 will be fairly minimal. We have a GdkEventTouch event, with subtypes for GDK_TOUCH_BEGIN, GDK_TOUCH_UPDATE and GDK_TOUCH_END. To receive these events, use the GDK_TOUCH_MASK event mask and connect to the ::touch-event signal on your widget. Kinetic scrolling in scrolled windows can be turned on and off with the kinetic-scrolling property. To receive scroll events with deltas (aka smooth scroll events), use the GDK_SMOOTH_SCROLL_MASK. Such scroll events have a scroll direction of GDK_SCROLL_SMOOTH, and their deltas can be obtained with the gdk_event_get_scroll_deltas() function.

Today I’ve merged the whole thing, so GTK+ 3.4 will have basic touch support.

A  concrete positive result of a very successful hackfest – thanks to the people in the Red Hat Czech office who helped organize this, in particular Tomas Bzatek.

A while ago, I wrote about our new better way to do deprecation warnings in the GTK+ stack by letting the compiler do the warnings.  That work came out of the Montreal summit. Here we are, half a year later, and the our next get-together (the GTK+ hackfest last week in Brno) produces another big improvement for our deprecation technology.

This time it was Emmanuele Bassi who took the initiative and added versioning information to our deprecation annotations. This means that it is now possible to say to your compiler:

Warn me about deprecations up to version 2.30, but I don’t want to chase the recent deprecations that have been going into 2.31 yet.

Doing this is just as easy as turning off deprecation warnings altogether. You just define a preprocessor symbol. In the case of GLib, it would be

#define GLIB_VERSION_MIN_REQUIRED GLIB_VERSION_2_30

While Emmanuele was at it, he threw in another nicety: You can now get compiler warnings for ‘too new’ API too. And it is just as easy:

#define GLIB_VERSION_MAX_ALLOWED GLIB_VERSION_2_28

will produce a compiler warning if you use API that was not available in GLib 2.28. This comes in handy when you want to ensure that your application continues to build on older distributions.

GTK+ has these new deprecations as well, the relevant preprocessor symbols to use here are GDK_VERSION_MIN_REQUIRED and GDK_VERSION_MAX_ALLOWED.

Versioned deprecations should make it a lot easier to gradually port applications to new API, as opposed to the current situation where you either have to chase all the latest API or ignore deprecations altogether. Thanks, Emmanuele !

I arrived late to the developer conference / hackfest / general get-together in Brno, but so far I am really enjoying it. The GTK+ hackfest is off to a very good start; not so much in producing code, but in clarifying my views on what direction we want to take for integrating touch into our APIs. The concrete take-away from todays multi-touch discussion are:

• We will have basic touch events in GDK 3.4. These will be pretty direct wrappers of the TouchBegin/TouchUpdate/TouchEnd events that are the basis of touch support on all the platforms that we are interested in.
• Support for smooth scrolling will also find its way into GTK 3.4.  This works on OS X and X11 (with XI 2.2).
• Combining touch events into touch clusters and multi-touch events will not be part of GTK 3.4. The general consensus was that it is better to do this inside GTK+, instead of exposing it as GDK api.
• Gesture recognition will also not make it into 3.4. The exact form in which this will appear in GTK+ 3.6 (or later) is still a bit up in the air, but breaking out event controllers as separate objects, and registering them with widgets seems like a very plausible approach. Doing things this way will allow us to unify touch gesture recognition with the handling of mouse event sequences like press-and-hold or double-clicks.
• It is still somewhat undecided whether capture-bubble event propagation (ie sending events first from the top down, before propagating them from the target widget up) will make it into 3.4.

Tomorrow will be focused on talking about clutter and meeting the GNOME design team. Should be fun.

First an update on deprecations: GLib and GTK+ master have been fully converted to use function attributes for deprecations now, and most uses of G_DISABLE_DEPRECATED guards in GLib headers have been removed. They are still used for deprecated things that are not symbols, like macros and enum values. I haven’t done the same for GTK_DISABLE_DEPRECATED yet, but it should happen fairly soon. Looking forward to a future of less deprecation-induced build breakage (unless you insist on -Werror, of course…).

Continuing the theme of ‘making things suck less for developers’… another favourite is logging.  It is very hard to get right; you want to add plenty of debug and diagnostic messages to help with, well, debugging. But then people complain if you fill up their syslog or .xsession-errors with tons of debug spew, like here. The GLib logging system with g_log() and the macro wrappers g_debug(), g_warning(), etc leaves much to be desired. It does have the concept of replaceable log handler functions, which is ok for complicated uses. But unfortunately, the default handler is so inflexible that many applications are forced to install a custom handler just to be able to turn debug output on and off.

As a small step towards making better logging, the default log handler in GLib master now only emits errors, warnings and criticals. Informational and debug messages are only emitted if you set the G_MESSAGES_DEBUG environment variable. The value can be a list of log domains that you are interested in, or the special value ‘all’ to get it all. As a reminder, the log domain is almost invisible in your code unless you use g_log() directly; it’s what you define by adding -DG_LOG_DOMAIN=”MyCoolApp” to your CPPFLAGS.

There was a lot of discussion last weekend about building an OS, and the various complications that inevitably come up when you put together a system out of many evolving pieces. One of the problems is that it is next to impossible to do a full build without running into at least a couple of modules that don’t build.

Naturally, this happens more frequently early in the cycle, when its deprecation season. Deprecations are meant to give the users of an API some early warning that a function they are using might disappear at some point in the future, and give them time to prepare.

We make things more difficult for ourselves by doing deprecations in a lo-tech way that involves just hiding deprecated symbols behind an ifdef. And to help people find the uses of deprecated symbols in their code, GNOME_MAINTAINER_MODE_DEFINES enables those ifdefs. Taken together, these two imply instant build breakage whenever a new deprecation is added.

Thankfully, gcc (other compilers too) has long supported a way to annotate deprecated functions so that each use triggers a compiler warning and we even have a macro wrapper (G_GNUC_DEPRECATED) around this function attribute in GLib. We just never got around to actually using these annotations for our own deprecations – in part because gtk-doc also used to rely on the ifdefs to recognize deprecated APIs and generate suitable warnings in the documentation.

During and after the Monreal summit, I set out to finally modernize the deprecation system in GLib and GTK+ by using annotations. If your code is using deprecated GLib or GTK+ function, you will now get compiler warnings. It is your choice to turn these into build failures with the help of -Werror. You can also make them go away by using -Wno-deprecated-declarations or by defining GLIB_DISABLE_DEPRECATION_WARNINGS (for GTK+, use GDK_ as a prefix for the define).

I’ve left the ifdef deprecation guards in place for now. For one thing, they can be used to deprecate other things like enumeration values, where the attribute doesn’t help.

Now we just need to neuter GNOME_MAINTAINER_MODE_DEFINES for a future with hopefully less deprecation-induced build breakage.