GTK+ 3 is a major new version of GTK+ that breaks both API and ABI compared to GTK+ 2.x, which has remained API- and ABI-stable for a long time. Thankfully, most of the changes are not hard to adapt to and there are a number of steps that you can take to prepare your GTK+ 2.x application for the switch to GTK+ 3. After that, there's a small number of adjustments that you may have to do when you actually switch your application to build against GTK+ 3.

The steps outlined in the following sections assume that your application is working with GTK+ 2.22, which is the final stable release of GTK+ 2.x. It includes all the necessary APIs and tools to help you port your application to GTK+ 3. If you are still using an older version of GTK+ 2.x, you should first get your application to build and work with 2.22.

With GTK+ 2.x it was common to include just the header files for a few widgets that your application was using, which could lead to problems with missing definitions, etc. GTK+ 3 tightens the rules about which header files you are allowed to include directly. The allowed header files are are gtk/gtk.h for GTK gtk/gtkunixprint.h for low-level, UNIX-specific printing functions gdk-pixbuf/gdk-pixbuf.h for GdkPixbuf gdk/gdk.h for GDK gdk/gdkx.h for GDK functions that are X11-specific gdk/gdkkeysyms.h if you need the GDK keysym definitions (these relative paths are assuming that you are using the include paths that are specified in the gtk+-2.0.pc file, as returned by pkg-config --cflags gtk+-2.0.pc.) To check that your application only includes the allowed headers, you can use defines to disable inclusion of individual headers, as follows: make CFLAGS+="-DG_DISABLE_SINGLE_INCLUDES -DGDK_PIXBUF_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_SINGLE_INCLUDES"

Over the years, a number of functions, and in some cases, entire widgets have been deprecated. These deprecations are clearly spelled out in the API reference, with hints about the recommended replacements. The API reference also includes an index of all deprecated symbols. To verify that your program does not use any deprecated symbols, you can use defines to remove deprecated symbols from the header files, as follows: make CFLAGS+="-DG_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DGTK_DISABLE_DEPRECATED"

GTK+ 3 removes many implementation details and struct members from its public headers. To ensure that your application does not have problems with this, you define the preprocessor symbol GSEAL_ENABLE. This will make the compiler catch all uses of direct access to struct fields so that you can go through them one by one and replace them with a call to an accessor function instead. make CFLAGS+="-DGSEAL_ENABLE"

Key constants have gained a _KEY, prefix. For example, GDK_a is now GDK_KEY_a. In GTK+ 2, the old names continue to be available. In GTK+ 3 however, the old names will require an explicit include of the gdkkeysyms-compat.h header.

In GTK+ 3, the GDK drawing API (which closely mimics the X drawing API, which is itself modeled after PostScript) has been removed. All drawing in GTK+ 3 is done via cairo. The #GdkGC and #GdkImage objects, as well as all the functions using them are gone. This includes the gdk_draw_ family of functions like gdk_draw_rectangle() and gdk_draw_drawable(). As #GdkGC is roughly equivalent to #cairo_t and #GdkImage was used for drawing images to GdkDrawables, which cairo supports automatically, a transition is usually straightforward. The following examples show a few common drawing idioms used by applications that have been ported to use cairo and how the code was replaced. Drawing a pixbuf onto a drawable used to be done like this: black_gc, pixbuf, 0, 0 x, y, gdk_pixbuf_get_width (pixbuf), gdk_pixbuf_get_height (pixbuf), GDK_RGB_DITHER_NORMAL, 0, 0); ]]> Doing the same thing with cairo: Note that very similar code can be used for drawing pixmaps by using gdk_cairo_set_source_pixmap() instead of gdk_cairo_set_source_pixbuf(). Tiled pixmaps are often used for drawing backgrounds. Old code looked something like this: black_gc; gdk_gc_set_tile (gc, pixmap); gdk_gc_set_fill (gc, GDK_TILED); gdk_gc_set_ts_origin (gc, x_origin, y_origin); /* use */ gdk_draw_rectangle (drawable, gc, TRUE, 0, 0, width, height); /* restore */ gdk_gc_set_tile (gc, NULL); gdk_gc_set_fill (gc, GDK_SOLID); gdk_gc_set_ts_origin (gc, 0, 0); ]]> The equivalent cairo code looks like this: Again, you can exchange pixbufs and pixmaps by using gdk_cairo_set_source_pixbuf() instead of gdk_cairo_set_source_pixmap(). Drawing layouts clipped is often used to avoid overdraw or to allow drawing selections. Code would have looked like this: text_gc[state]; gdk_gc_set_clip_rectangle (gc, &area); /* use */ gdk_draw_layout (drawable, gc, x, y, layout); /* restore */ gdk_gc_set_clip_rectangle (gc, NULL); ]]> With cairo, the same effect can be achieved using: text[state]); /* draw the text */ cairo_move_to (cr, x, y); pango_cairo_show_layout (cr, layout); cairo_destroy (cr); ]]> Clipping using cairo_clip() is of course not restricted to text rendering and can be used everywhere where GC clips were used. And using gdk_cairo_set_source_color() with style colors should be used in all the places where a style’s GC was used to achieve a particular color.

Stippling is the usage of a bi-level mask, called a #GdkBitmap. It was often used to achieve a checkerboard effect. You can use cairo_mask() to achieve this effect. To get a checkerbox mask, you can use code like this: Note that stippling looks very outdated in UIs, and is rarely used in modern applications. All properties that made use of stippling have been removed from GTK+ 3. Most prominently, stippling is absent from text rendering, in particular #GtkTextTag. The gdk_draw_drawable() function allowed using the same drawable as source and target. This was often used to achieve a scrolling effect. Cairo does not allow this yet. You can however use cairo_push_group() to get a different intermediate target that you can copy to. So you can replace this code: By using this code: The cairo developers plan to add self-copies in the future to allow exactly this effect, so you might want to keep up on cairo development to be able to change your code. GDK provided a way to ignore the color attributes of text and use a hardcoded text color with the gdk_draw_layout_with_colors() function. This is often used to draw text shadows or selections. Pango’s cairo support does not yet provide this functionality. If you use Pango layouts that change colors, the easiest way to achieve a similar effect is using pango_cairo_layout_path() and cairo_fill() instead of gdk_draw_layout_with_colors(). Note that this results in a slightly uglier-looking text, as subpixel anti-aliasing is not supported.

This section outlines porting tasks that you need to tackle when you get to the point that you actually build your application against GTK+ 3. Making it possible to prepare for these in GTK+ 2.22 would have been either impossible or impractical.

Starting with version 1.10, cairo provides a region API that is equivalent to the GDK region API (which was itself copied from the X server). Therefore, the region API has been removed in GTK+ 3. Porting your application to the cairo region API should be a straight find-and-replace task. Please refer to the following table: GDKcairo#GdkRegion#cairo_region_t#GdkRectangle#cairo_rectangle_int_tgdk_rectangle_intersect()this function is still theregdk_rectangle_union()this function is still theregdk_region_new()cairo_region_create()gdk_region_copy()cairo_region_copy()gdk_region_destroy()cairo_region_destroy()gdk_region_rectangle()cairo_region_create_rectangle()gdk_region_get_clipbox()cairo_region_get_extents()gdk_region_get_rectangles()cairo_region_num_rectangles() and cairo_region_get_rectangle()gdk_region_empty()cairo_region_is_empty()gdk_region_equal()cairo_region_equal()gdk_region_point_in()cairo_region_contains_point()gdk_region_rect_in()cairo_region_contains_rectangle()gdk_region_offset()cairo_region_translate()gdk_region_union_with_rect()cairo_region_union_rectangle()gdk_region_intersect()cairo_region_intersect()gdk_region_union()cairo_region_union()gdk_region_subtract()cairo_region_subtract()gdk_region_xor()cairo_region_xor()gdk_region_shrink()no replacementgdk_region_polygon()no replacement, use cairo paths instead

In GTK+ 2.x, #GtkProgressBar and #GtkCellRendererProgress were using the GtkProgressBarOrientation enumeration to specify their orientation and direction. In GTK+ 3, both the widget and the cell renderer implement #GtkOrientable, and have an additional 'inverted' property to determine their direction. Therefore, a call to gtk_progress_bar_set_orientation() needs to be replaced by a pair of calls to gtk_orientable_set_orientation() and gtk_progress_bar_set_inverted(). The following values correspond: GTK+ 2.xGTK+ 3GtkProgressBarOrientationGtkOrientationinvertedGTK_PROGRESS_LEFT_TO_RIGHTGTK_ORIENTATION_HORIZONTALFALSEGTK_PROGRESS_RIGHT_TO_LEFTGTK_ORIENTATION_HORIZONTALTRUEGTK_PROGRESS_TOP_TO_BOTTOMGTK_ORIENTATION_VERTICALFALSEGTK_PROGRESS_BOTTOM_TO_TOPGTK_ORIENTATION_VERTICALTRUE

Linking against GTK+ 2.x and GTK+ 3 in the same process is problematic and can lead to hard-to-diagnose crashes. The gtk_init() function in both GTK+ 2.22 and in GTK+ 3 tries to detect this situation and abort with a diagnostic message, but this check is not 100% reliable (e.g. if the problematic linking happens only in loadable modules). Direct linking of your application against both versions of GTK+ is easy to avoid; the problem gets harder when your application is using libraries that are themselves linked against some version of GTK+. In that case, you have to verify that you are using a version of the library that is linked against GTK+ 3. If you are using packages provided by a distributor, it is likely that parallel installable versions of the library exist for GTK+ 2.x and GTK+ 3, e.g for vte, check for vte3; for webkitgtk look for webkitgtk3, and so on.

Some software packages install loadable GTK+ modules such as theme engines, gdk-pixbuf loaders or input methods. Since GTK+ 3 is parallel-installable with GTK+ 2.x, the two GTK+ versions have separate locations for their loadable modules. The location for GTK+ 2.x is libdir/gtk-2.0 (and its subdirectories), for GTK+ 3 the location is libdir/gtk-3.0 (and its subdirectories). For some kinds of modules, namely input methods and pixbuf loaders, GTK+ keeps a cache file with extra information about the modules. For GTK+ 2.x, these cache files are located in sysconfdir/gtk-2.0. For GTK+ 3, they have been moved to libdir/gtk-3.0/3.0.0/. The commands that create these cache files have been renamed with a -3 suffix to make them parallel-installable. Note that GTK+ modules often link against libgtk, libgdk-pixbuf, etc. If that is the case for your module, you have to be careful to link the GTK+ 2.x version of your module against the 2.x version of the libraries, and the GTK+ 3 version against hte 3.x versions. Loading a module linked against libgtk 2.x into an application using GTK+ 3 will lead to unhappiness and must be avoided.