The request-phase of the traditional CTK+ 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 CtkWidgetClass. The replacement for size_request() can take several levels of sophistication:

Starting with version 1.10, cairo provides a region API that is equivalent to the CDK region API (which was itself copied from the X server). Therefore, the region API has been removed in CTK+ 3.

Porting your application to the cairo region API should be a straight find-and-replace task. Please refer to the following table:

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

CdkCursor *cursor;
CdkPixmap *pixmap;
cairo_t *cr;
CdkColor fg = { 0, 0, 0, 0 };

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

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

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

g_object_unref (pixmap);

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

CdkCursor *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 = cdk_cursor_new_from_pixbuf (display, pixbuf, 0, 0);

g_object_unref (pixbuf);

For drawing with cairo, it is not necessary to allocate colors, and a CdkVisual provides enough information for cairo to handle colors in 'native' surfaces. Therefore, CdkColormap and related functions have been removed in CTK+ 3, and visuals are used instead. The colormap-handling functions of CtkWidget (ctk_widget_set_colormap(), etc) have been removed and ctk_widget_set_visual() has been added.

1
2
3
4
5
6
7
8
9
10
11
12
13

static void
on_alpha_screen_changed (CtkWidget *widget,
                         CdkScreen *old_screen,
                         CtkWidget *label)
{
  CdkScreen *screen = ctk_widget_get_screen (widget);
  CdkColormap *colormap = cdk_screen_get_rgba_colormap (screen);

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

  ctk_widget_set_colormap (widget, colormap);
}

1
2
3
4
5
6
7
8
9
10
11
12
13

static void
on_alpha_screen_changed (CtkWindow *window,
                         CdkScreen *old_screen,
                         CtkWidget *label)
{
  CdkScreen *screen = ctk_widget_get_screen (CTK_WIDGET (window));
  CdkVisual *visual = cdk_screen_get_rgba_visual (screen);

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

  ctk_widget_set_visual (window, visual);
}

CdkDrawable has been removed in CTK+ 3, together with CdkPixmap and CdkImage. The only remaining drawable class is CdkWindow. For dealing with image data, you should use a cairo_surface_t or a GdkPixbuf.

CdkDrawable functions that are useful with windows have been replaced by corresponding CdkWindow functions:

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

The special-purpose CdkEventClient events and the cdk_add_client_message_filter() and cdk_display_add_client_message_filter() functions have been removed. Receiving X11 ClientMessage events is still possible, using the general cdk_window_add_filter() API. A client message filter like

1
2
3
4
5
6
7
8
9
10
11
12

static CdkFilterReturn
message_filter (CdkXEvent *xevent, CdkEvent *event, gpointer data)
{
  XClientMessageEvent *evt = (XClientMessageEvent *)xevent;

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

 ...

message_type = cdk_atom_intern ("MANAGER", FALSE);
cdk_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 CdkFilterReturn
event_filter (CdkXEvent *xevent, CdkEvent *event, gpointer data)
{
  XClientMessageEvent *evt;
  CdkAtom message_type;

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

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

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

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

 ...

cdk_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 cdk_window_remove_filter().

The other difference to be aware of when working with event filters in CTK+ 3 is that CDK 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 cdk_disable_multidevice(). In the long term, you probably want to rewrite your event filter to deal with XIDeviceEvents.

In CTK+ 2.x, CDK could only be compiled for one backend at a time, and the CDK_WINDOWING_X11 or CDK_WINDOWING_WIN32 macros could be used to find out which one you are dealing with:

1
2
3
4
5
6
7

#ifdef CDK_WINDOWING_X11
      if (timestamp != CDK_CURRENT_TIME)
        cdk_x11_window_set_user_time (cdk_window, timestamp);
#endif
#ifdef CDK_WINDOWING_WIN32
        /* ... win32 specific code ... */
#endif

In CTK+ 3, CDK can be built with multiple backends, and currently used backend has to be determined at runtime, typically using type-check macros on a CdkDisplay or CdkWindow. You still need to use the CDK_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 CDK_WINDOWING_X11
      if (CDK_IS_X11_DISPLAY (display))
        {
          if (timestamp != CDK_CURRENT_TIME)
            cdk_x11_window_set_user_time (cdk_window, timestamp);
        }
      else
#endif
#ifdef CDK_WINDOWING_WIN32
      if (CDK_IS_WIN32_DISPLAY (display))
        {
          /* ... win32 specific code ... */
        }
      else
#endif
       {
         g_warning ("Unsupported CDK backend");
       }

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

1

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

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

1
2

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

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

The CtkWidget “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.

The widget is expected to draw itself with its allocated size, which is available via the new ctk_widget_get_allocated_width() and ctk_widget_get_allocated_height() functions. It is not necessary to check for ctk_widget_is_drawable(), since CTK+ 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. CTK+ has a convenience function ctk_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 (ctk_cairo_should_draw_window (cr, widget->window1)
  {
     /* ... draw window1 ... */
  }
if (ctk_cairo_should_draw_window (cr, widget->window2)
  {
     /* ... draw window2 ... */
  }
...

Another convenience function that can help when implementing ::draw for multi-window widgets is ctk_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 CtkStyle drawing functions (ctk_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.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

gboolean
ctk_arrow_draw (CtkWidget *widget,
                cairo_t   *cr)
{
  CtkStyleContext *context;
  gint x, y;
  gint width, height;
  gint extent;

  context = ctk_widget_get_style_context (widget);

  width = ctk_widget_get_allocated_width (widget);
  height = ctk_widget_get_allocated_height (widget);

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

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

In CTK+ 2.x, CtkProgressBar and CtkCellRendererProgress were using the CtkProgressBarOrientation enumeration to specify their orientation and direction. In CTK+ 3, both the widget and the cell renderer implement CtkOrientable, and have an additional 'inverted' property to determine their direction. Therefore, a call to ctk_progress_bar_set_orientation() needs to be replaced by a pair of calls to ctk_orientable_set_orientation() and ctk_progress_bar_set_inverted(). The following values correspond:

The behaviour of expanding widgets has changed slightly in CTK+ 3, compared to CTK+ 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 ctk_widget_set_hexpand() and ctk_widget_set_vexpand().

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

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 CtkWidget has been replaced by the CtkScrollable interface which must be implemented by a widget that wants to be placed in a CtkScrolledWindow. Instead of emitting ::set-scroll-adjustments, the scrolled window simply sets the “hadjustment” and “vadjustment” properties.

CtkObject has been removed in CTK+ 3. Its remaining functionality, the ::destroy signal, has been moved to CtkWidget. If you have non-widget classes that are directly derived from CtkObject, 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 CtkWidgetClass:

1
2
3

CtkObjectClass *object_class = CTK_OBJECT_CLASS (class);

object_class->destroy = my_destroy;

becomes

1
2
3

CtkWidgetClass *widget_class = CTK_WIDGET_CLASS (class);

widget_class->destroy = my_destroy;

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

If your program used functions like ctk_object_get or ctk_object_set, these can be replaced directly with g_object_get or g_object_set. In fact, most every ctk_object_* function can be replaced with the corresponding g_object_ function, even in CTK+ 2 code. The one exception to this rule is ctk_object_destroy, which can be replaced with ctk_widget_destroy, again in both CTK+ 2 and CTK+ 3.

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 CTK+ 3; if you have handlers for these signals, they will likely need slight adjustments.

The resize grip functionality has been moved from CtkStatusbar to CtkWindow. Any window can now have resize grips, regardless whether it has a statusbar or not. The functions ctk_statusbar_set_has_resize_grip() and ctk_statusbar_get_has_resize_grip() have disappeared, and instead there are now ctk_window_set_has_resize_grip() and ctk_window_get_has_resize_grip().

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

Linking against CTK+ 2.x and CTK+ 3 in the same process is problematic and can lead to hard-to-diagnose crashes. The ctk_init() function in both CTK+ 2.22 and in CTK+ 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 CTK+ is easy to avoid; the problem gets harder when your application is using libraries that are themselves linked against some version of CTK+. In that case, you have to verify that you are using a version of the library that is linked against CTK+ 3.

If you are using packages provided by a distributor, it is likely that parallel installable versions of the library exist for CTK+ 2.x and CTK+ 3, e.g for vte, check for vte3; for webkitctk look for webkitctk3, and so on.

Some software packages install loadable CTK+ modules such as theme engines, gdk-pixbuf loaders or input methods. Since CTK+ 3 is parallel-installable with CTK+ 2.x, the two CTK+ versions have separate locations for their loadable modules. The location for CTK+ 2.x is libdir/ctk-2.0 (and its subdirectories), for CTK+ 3 the location is libdir/ctk-3.0 (and its subdirectories).

For some kinds of modules, namely input methods and pixbuf loaders, CTK+ keeps a cache file with extra information about the modules. For CTK+ 2.x, these cache files are located in sysconfdir/ctk-2.0. For CTK+ 3, they have been moved to libdir/ctk-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 CTK+ modules often link against libctk, libgdk-pixbuf, etc. If that is the case for your module, you have to be careful to link the CTK+ 2.x version of your module against the 2.x version of the libraries, and the CTK+ 3 version against hte 3.x versions. Loading a module linked against libctk 2.x into an application using CTK+ 3 will lead to unhappiness and must be avoided.