manpagez: man pages & more
html files: gtk3
Home | html | info | man

Changes that need to be done at the time of the switch

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.24 would have been either impossible or impractical.

Replace size_request by get_preferred_width/height

The request-phase of the traditional GTK+ geometry management has been replaced by a more flexible height-for-width system, which is described in detail in the API documentation (see the section called “Height-for-width Geometry Management”). As a consequence, the ::size-request signal and vfunc has been removed from GtkWidgetClass. The replacement for size_request() can take several levels of sophistication:

  • As a minimal replacement to keep current functionality, you can simply implement the GtkWidgetClass.get_preferred_width() and GtkWidgetClass.get_preferred_height() vfuncs by calling your existing size_request() function. So you go from

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    static void
    my_widget_class_init (MyWidgetClass *class)
    {
      GtkWidgetClass *widget_class = GTK_WIDGET_CLASS (class);
    
      /* ... */
    
      widget_class->size_request = my_widget_size_request;
    
      /* ... */
    }

    to something that looks more like this:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    static void
    my_widget_get_preferred_width (GtkWidget *widget,
                                   gint      *minimal_width,
                                   gint      *natural_width)
    {
      GtkRequisition requisition;
    
      my_widget_size_request (widget, &requisition);
    
      *minimal_width = *natural_width = requisition.width;
    }
    
    static void
    my_widget_get_preferred_height (GtkWidget *widget,
                                    gint      *minimal_height,
                                    gint      *natural_height)
    {
      GtkRequisition requisition;
    
      my_widget_size_request (widget, &requisition);
    
      *minimal_height = *natural_height = requisition.height;
    }
    
     /* ... */
    
    static void
    my_widget_class_init (MyWidgetClass *class)
    {
      GtkWidgetClass *widget_class = GTK_WIDGET_CLASS (class);
    
      /* ... */
    
      widget_class->get_preferred_width = my_widget_get_preferred_width;
      widget_class->get_preferred_height = my_widget_get_preferred_height;
    
      /* ... */
    
    }

    Sometimes you can make things a little more streamlined by replacing your existing size_request() implementation by one that takes an orientation parameter:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    static void
    my_widget_get_preferred_size (GtkWidget      *widget,
                                  GtkOrientation  orientation,
                                   gint          *minimal_size,
                                   gint          *natural_size)
    {
    
      /* do things that are common for both orientations ... */
    
      if (orientation == GTK_ORIENTATION_HORIZONTAL)
        {
          /* do stuff that only applies to width... */
    
          *minimal_size = *natural_size = ...
        }
      else
       {
          /* do stuff that only applies to height... */
    
          *minimal_size = *natural_size = ...
       }
    }
    
    static void
    my_widget_get_preferred_width (GtkWidget *widget,
                                   gint      *minimal_width,
                                   gint      *natural_width)
    {
      my_widget_get_preferred_size (widget,
                                    GTK_ORIENTATION_HORIZONTAL,
                                    minimal_width,
                                    natural_width);
    }
    
    static void
    my_widget_get_preferred_height (GtkWidget *widget,
                                    gint      *minimal_height,
                                    gint      *natural_height)
    {
      my_widget_get_preferred_size (widget,
                                    GTK_ORIENTATION_VERTICAL,
                                    minimal_height,
                                    natural_height);
    }
    
     /* ... */

  • If your widget can cope with a small size, but would appreciate getting some more space (a common example would be that it contains ellipsizable labels), you can do that by making your GtkWidgetClass.get_preferred_width() / GtkWidgetClass.get_preferred_height() functions return a smaller value for minimal than for natural. For minimal, you probably want to return the same value that your size_request() function returned before (since size_request() was defined as returning the minimal size a widget can work with). A simple way to obtain good values for natural, in the case of containers, is to use gtk_widget_get_preferred_width() and gtk_widget_get_preferred_height() on the children of the container, as in the following example:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    static void
    gtk_fixed_get_preferred_height (GtkWidget *widget,
                                    gint      *minimum,
                                    gint      *natural)
    {
      GtkFixed *fixed = GTK_FIXED (widget);
      GtkFixedPrivate *priv = fixed->priv;
      GtkFixedChild *child;
      GList *children;
      gint child_min, child_nat;
    
      *minimum = 0;
      *natural = 0;
    
      for (children = priv->children; children; children = children->next)
        {
          child = children->data;
    
          if (!gtk_widget_get_visible (child->widget))
            continue;
    
          gtk_widget_get_preferred_height (child->widget, &child_min, &child_nat);
    
          *minimum = MAX (*minimum, child->y + child_min);
          *natural = MAX (*natural, child->y + child_nat);
        }
    }

  • Note that the GtkWidgetClass.get_preferred_width() / GtkWidgetClass.get_preferred_height() functions only allow you to deal with one dimension at a time. If your size_request() handler is doing things that involve both width and height at the same time (e.g. limiting the aspect ratio), you will have to implement GtkWidgetClass.get_preferred_height_for_width() and GtkWidgetClass.get_preferred_width_for_height().

  • To make full use of the new capabilities of the height-for-width geometry management, you need to additionally implement the GtkWidgetClass.get_preferred_height_for_width() and GtkWidgetClass.get_preferred_width_for_height(). For details on these functions, see the section called “Height-for-width Geometry Management”.

Replace GdkRegion by cairo_region_t

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:

Table 14. 

GDK cairo
GdkRegion cairo_region_t
GdkRectangle cairo_rectangle_int_t
gdk_rectangle_intersect() this function is still there
gdk_rectangle_union() this function is still there
gdk_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 replacement
gdk_region_polygon() no replacement, use cairo paths instead


Replace GdkPixmap by cairo surfaces

The GdkPixmap object and related functions have been removed. In the cairo-centric world of GTK+ 3, cairo surfaces take over the role of pixmaps.

Example 41. Creating custom cursors

One place where pixmaps were commonly used is to create custom cursors:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
GdkCursor *cursor;
GdkPixmap *pixmap;
cairo_t *cr;
GdkColor fg = { 0, 0, 0, 0 };

pixmap = gdk_pixmap_new (NULL, 1, 1, 1);

cr = gdk_cairo_create (pixmap);
cairo_rectangle (cr, 0, 0, 1, 1);
cairo_fill (cr);
cairo_destroy (cr);

cursor = gdk_cursor_new_from_pixmap (pixmap, pixmap, &fg, &fg, 0, 0);

g_object_unref (pixmap);

The same can be achieved without pixmaps, by drawing onto an image surface:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
GdkCursor *cursor;
cairo_surface_t *s;
cairo_t *cr;
GdkPixbuf *pixbuf;

s = cairo_image_surface_create (CAIRO_FORMAT_A1, 3, 3);
cr = cairo_create (s);
cairo_arc (cr, 1.5, 1.5, 1.5, 0, 2 * M_PI);
cairo_fill (cr);
cairo_destroy (cr);

pixbuf = gdk_pixbuf_get_from_surface (s,
                                      0, 0,
                                      3, 3);

cairo_surface_destroy (s);

cursor = gdk_cursor_new_from_pixbuf (display, pixbuf, 0, 0);

g_object_unref (pixbuf);


Replace GdkColormap by GdkVisual

For drawing with cairo, it is not necessary to allocate colors, and a GdkVisual provides enough information for cairo to handle colors in 'native' surfaces. Therefore, GdkColormap and related functions have been removed in GTK+ 3, and visuals are used instead. The colormap-handling functions of GtkWidget (gtk_widget_set_colormap(), etc) have been removed and gtk_widget_set_visual() has been added.

Example 42. Setting up a translucent window

You might have a screen-changed handler like the following to set up a translucent window with an alpha-channel:

1
2
3
4
5
6
7
8
9
10
11
12
13
static void
on_alpha_screen_changed (GtkWidget *widget,
                         GdkScreen *old_screen,
                         GtkWidget *label)
{
  GdkScreen *screen = gtk_widget_get_screen (widget);
  GdkColormap *colormap = gdk_screen_get_rgba_colormap (screen);

  if (colormap == NULL)
    colormap = gdk_screen_get_default_colormap (screen);

  gtk_widget_set_colormap (widget, colormap);
}

With visuals instead of colormaps, this will look as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
static void
on_alpha_screen_changed (GtkWindow *window,
                         GdkScreen *old_screen,
                         GtkWidget *label)
{
  GdkScreen *screen = gtk_widget_get_screen (GTK_WIDGET (window));
  GdkVisual *visual = gdk_screen_get_rgba_visual (screen);

  if (visual == NULL)
    visual = gdk_screen_get_system_visual (screen);

  gtk_widget_set_visual (window, visual);
}

GdkDrawable is gone

GdkDrawable has been removed in GTK+ 3, together with GdkPixmap and GdkImage. The only remaining drawable class is GdkWindow. For dealing with image data, you should use a cairo_surface_t or a GdkPixbuf.

GdkDrawable functions that are useful with windows have been replaced by corresponding GdkWindow functions:


Event filtering

If your application uses the low-level event filtering facilities in GDK, there are some changes you need to be aware of.

The special-purpose GdkEventClient events and the gdk_add_client_message_filter() and gdk_display_add_client_message_filter() functions have been removed. Receiving X11 ClientMessage events is still possible, using the general gdk_window_add_filter() API. A client message filter like

1
2
3
4
5
6
7
8
9
10
11
12
static GdkFilterReturn
message_filter (GdkXEvent *xevent, GdkEvent *event, gpointer data)
{
  XClientMessageEvent *evt = (XClientMessageEvent *)xevent;

  /* do something with evt ... */
}

 ...

message_type = gdk_atom_intern ("MANAGER", FALSE);
gdk_display_add_client_message_filter (display, message_type, message_filter, NULL);

then looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
static GdkFilterReturn
event_filter (GdkXEvent *xevent, GdkEvent *event, gpointer data)
{
  XClientMessageEvent *evt;
  GdkAtom message_type;

  if (((XEvent *)xevent)->type != ClientMessage)
    return GDK_FILTER_CONTINUE;

  evt = (XClientMessageEvent *)xevent;
  message_type = XInternAtom (evt->display, "MANAGER", FALSE);

  if (evt->message_type != message_type)
    return GDK_FILTER_CONTINUE;

  /* do something with evt ... */
}

 ...

gdk_window_add_filter (NULL, message_filter, NULL);

One advantage of using an event filter is that you can actually remove the filter when you don't need it anymore, using gdk_window_remove_filter().

The other difference to be aware of when working with event filters in GTK+ 3 is that GDK now uses XI2 by default when available. That means that your application does not receive core X11 key or button events. Instead, all input events are delivered as XIDeviceEvents. As a short-term workaround for this, you can force your application to not use XI2, with gdk_disable_multidevice(). In the long term, you probably want to rewrite your event filter to deal with XIDeviceEvents.

Backend-specific code

In GTK+ 2.x, GDK could only be compiled for one backend at a time, and the GDK_WINDOWING_X11 or GDK_WINDOWING_WIN32 macros could be used to find out which one you are dealing with:

1
2
3
4
5
6
7
#ifdef GDK_WINDOWING_X11
      if (timestamp != GDK_CURRENT_TIME)
        gdk_x11_window_set_user_time (gdk_window, timestamp);
#endif
#ifdef GDK_WINDOWING_WIN32
        /* ... win32 specific code ... */
#endif

In GTK+ 3, GDK can be built with multiple backends, and currently used backend has to be determined at runtime, typically using type-check macros on a GdkDisplay or GdkWindow. You still need to use the GDK_WINDOWING macros to only compile code referring to supported backends:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#ifdef GDK_WINDOWING_X11
      if (GDK_IS_X11_DISPLAY (display))
        {
          if (timestamp != GDK_CURRENT_TIME)
            gdk_x11_window_set_user_time (gdk_window, timestamp);
        }
      else
#endif
#ifdef GDK_WINDOWING_WIN32
      if (GDK_IS_WIN32_DISPLAY (display))
        {
          /* ... win32 specific code ... */
        }
      else
#endif
       {
         g_warning ("Unsupported GDK backend");
       }

If you used the pkg-config variable target to conditionally build part of your project depending on the GDK backend, for instance like this:

1
AM_CONDITIONAL(BUILD_X11, test `$PKG_CONFIG --variable=target gtk+-2.0` = "x11")

then you should now use the M4 macro provided by GTK+ itself:

1
2
GTK_CHECK_BACKEND([x11], [3.0.2], [have_x11=yes], [have_x11=no])
AM_CONDITIONAL(BUILD_x11, [test "x$have_x11" = "xyes"])

GtkPlug and GtkSocket

The GtkPlug and GtkSocket widgets are now X11-specific, and you have to include the <gtk/gtkx.h> header to use them. The previous section about proper handling of backend-specific code applies, if you care about other backends.

The GtkWidget::draw signal

The GtkWidget “expose-event” signal has been replaced by a new “draw” signal, which takes a cairo_t instead of an expose event. The cairo context is being set up so that the origin at (0, 0) coincides with the upper left corner of the widget, and is properly clipped.

In other words, the cairo context of the draw signal is set up in 'widget coordinates', which is different from traditional expose event handlers, which always assume 'window coordinates'.

The widget is expected to draw itself with its allocated size, which is available via the new gtk_widget_get_allocated_width() and gtk_widget_get_allocated_height() functions. It is not necessary to check for gtk_widget_is_drawable(), since GTK+ already does this check before emitting the “draw” signal.

There are some special considerations for widgets with multiple windows. Expose events are window-specific, and widgets with multiple windows could expect to get an expose event for each window that needs to be redrawn. Therefore, multi-window expose event handlers typically look like this:

1
2
3
4
5
6
7
8
9
if (event->window == widget->window1)
  {
     /* ... draw window1 ... */
  }
else if (event->window == widget->window2)
  {
     /* ... draw window2 ... */
  }
...

In contrast, the “draw” signal handler may have to draw multiple windows in one call. GTK+ has a convenience function gtk_cairo_should_draw_window() that can be used to find out if a window needs to be drawn. With that, the example above would look like this (note that the 'else' is gone):

1
2
3
4
5
6
7
8
9
if (gtk_cairo_should_draw_window (cr, widget->window1)
  {
     /* ... draw window1 ... */
  }
if (gtk_cairo_should_draw_window (cr, widget->window2)
  {
     /* ... draw window2 ... */
  }
...

Another convenience function that can help when implementing ::draw for multi-window widgets is gtk_cairo_transform_to_window(), which transforms a cairo context from widget-relative coordinates to window-relative coordinates. You may want to use cairo_save() and cairo_restore() when modifying the cairo context in your draw function.

All GtkStyle drawing functions (gtk_paint_box(), etc) have been changed to take a cairo_t instead of a window and a clip area. ::draw implementations will usually just use the cairo context that has been passed in for this.

Example 43. A simple ::draw function

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
gboolean
gtk_arrow_draw (GtkWidget *widget,
                cairo_t   *cr)
{
  GtkStyleContext *context;
  gint x, y;
  gint width, height;
  gint extent;

  context = gtk_widget_get_style_context (widget);

  width = gtk_widget_get_allocated_width (widget);
  height = gtk_widget_get_allocated_height (widget);

  extent = MIN (width - 2 * PAD, height - 2 * PAD);
  x = PAD;
  y = PAD;

  gtk_render_arrow (context, rc, G_PI / 2, x, y, extent);
}

GtkProgressBar orientation

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:

Table 16. 

GTK+ 2.x GTK+ 3
GtkProgressBarOrientation GtkOrientation inverted
GTK_PROGRESS_LEFT_TO_RIGHT GTK_ORIENTATION_HORIZONTAL FALSE
GTK_PROGRESS_RIGHT_TO_LEFT GTK_ORIENTATION_HORIZONTAL TRUE
GTK_PROGRESS_TOP_TO_BOTTOM GTK_ORIENTATION_VERTICAL FALSE
GTK_PROGRESS_BOTTOM_TO_TOP GTK_ORIENTATION_VERTICAL TRUE


Check your expand and fill flags

The behaviour of expanding widgets has changed slightly in GTK+ 3, compared to GTK+ 2.x. It is now 'inherited', i.e. a container that has an expanding child is considered expanding itself. This is often the desired behaviour. In places where you don't want this to happen, setting the container explicity as not expanding will stop the expand flag of the child from being inherited. See gtk_widget_set_hexpand() and gtk_widget_set_vexpand().

If you experience sizing problems with widgets in ported code, carefully check the GtkBox expand and GtkBox fill child properties of your boxes.

Scrolling changes

The default values for the “hscrollbar-policy” and “vscrollbar-policy” properties have been changed from 'never' to 'automatic'. If your application was relying on the default value, you will have to set it explicitly.

The ::set-scroll-adjustments signal on GtkWidget has been replaced by the GtkScrollable interface which must be implemented by a widget that wants to be placed in a GtkScrolledWindow. Instead of emitting ::set-scroll-adjustments, the scrolled window simply sets the “hadjustment” and “vadjustment” properties.

GtkObject is gone

GtkObject has been removed in GTK+ 3. Its remaining functionality, the ::destroy signal, has been moved to GtkWidget. If you have non-widget classes that are directly derived from GtkObject, you have to make them derive from GInitiallyUnowned (or, if you don't need the floating functionality, GObject). If you have widgets that override the destroy class handler, you have to adjust your class_init function, since destroy is now a member of GtkWidgetClass:

1
2
3
GtkObjectClass *object_class = GTK_OBJECT_CLASS (class);

object_class->destroy = my_destroy;

becomes

1
2
3
GtkWidgetClass *widget_class = GTK_WIDGET_CLASS (class);

widget_class->destroy = my_destroy;

In the unlikely case that you have a non-widget class that is derived from GtkObject and makes use of the destroy functionality, you have to implement ::destroy yourself.

If your program used functions like gtk_object_get or gtk_object_set, these can be replaced directly with g_object_get or g_object_set. In fact, most every gtk_object_* function can be replaced with the corresponding g_object_ function, even in GTK+ 2 code. The one exception to this rule is gtk_object_destroy, which can be replaced with gtk_widget_destroy, again in both GTK+ 2 and GTK+ 3.

GtkEntryCompletion signal parameters

The “match-selected” and “cursor-on-match” signals were erroneously given the internal filter model instead of the users model. This oversight has been fixed in GTK+ 3; if you have handlers for these signals, they will likely need slight adjustments.

Resize grips

The resize grip functionality has been moved from GtkStatusbar to GtkWindow. Any window can now have resize grips, regardless whether it has a statusbar or not. The functions gtk_statusbar_set_has_resize_grip() and gtk_statusbar_get_has_resize_grip() have disappeared, and instead there are now gtk_window_set_has_resize_grip() and gtk_window_get_has_resize_grip().

In more recent versions of GTK+ 3, the resize grip functionality has been removed entirely, in favor of invisible resize borders around the window. When updating to newer versions of GTK+ 3, you should simply remove all code dealing with resize grips.

Prevent mixed linkage

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.

Install GTK+ modules in the right place

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.

© manpagez.com 2000-2017
Individual documents may contain additional copyright information.