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.