1<?xml version="1.0"?>
2<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
3               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
4]>
5<chapter id="gtk-migrating-ClientSideWindows">
6
7  <title>Migrating to client-side windows</title>
8
9  <para>
10    In version 2.18, GDK has been changed to use client-side windows. This
11    means that there is no longer a 1-1 correspondence between #GdkWindows
12    and windows in the underlying window system. In particular, it is no
13    longer correct to assume that each window has an associated XID.
14    Code that makes this assumption can sometimes be fixed by calling
15    gdk_window_ensure_native() on the windows in question.
16    Calling gdk_x11_drawable_get_xid() (or GDK_WINDOW_XID()) from the
17    X11-specific API on a non-native window will explicitly call
18    gdk_window_ensure_native(), so old code using this will continue to
19    work. A small gotcha is that the GDK_WINDOW_XID() call is no longer a
20    trivial accessor for the XID of the window, and thus must not be called
21    from another thread without taking locking precautions.
22  </para>
23
24  <para>
25    GDK looks for the <envar>GDK_NATIVE_WINDOWS</envar> environment variable
26    and makes all windows native if it is set. It also tries to be more
27    compatible with the way prior versions worked in some other ways.
28  </para>
29
30  <para>
31    Some applications assume that they can just operate on the X windows
32    corresponding to their GDK windows without ever telling GDK. One
33    example that we've seen is changing the child window stacking order
34    using XRestackWindows(). Fixing this properly requires to fix the code
35    to use GDK functions to achieve whatever it is trying to achieve.
36    To make this easier in the case of stacking order changes, we've added
37    a gdk_window_restack() function.
38  </para>
39
40  <para>
41    One change that can cause problems for some applications is that GDK
42    is more aggressive about optimizing away expose events. Code that does
43    more than just repainting exposed areas in response to expose events
44    may be affected by this.
45  </para>
46
47  <para>
48    Problems can also occur when using cairo for drawing. One thing that can
49    go wrong is clip handling. If you ever need to reset the clip region on
50    a cairo_t (i.e. use cairo_reset_clip()), you have to to use
51    gdk_cairo_reset_clip() instead. The reason for this is that the cairo_reset_clip() call will remove the initial clip region that limits your drawing to
52    the client-side window at hand, so you will end up drawing over stuff
53    outside the window. You also need to use gdk_cairo_reset_clip() if you
54    use a cairo_t that was not allocated in a double-buffered expose handler
55    and keep it in use after window hierarchy changes (resizing, moving,
56    stacking order changes). The easiest fix for this kind of problem is to
57    simply create a new cairo context for each expose event.
58  </para>
59
60  <para>
61    Due to a weird API in XClearArea the gdk_window_clear_area() call handled
62    a specified width or height of zero to mean "to end of window" for
63    non-double-buffered drawing. This has been changed to be consistent with
64    the docs and what happens in the double-buffered case. All code in GTK+
65    that relied on this has been fixed, but it is possible (although unlikely)
66    that third party applications rely on this. If you need to do this, just
67    implement it yourself using gdk_drawable_get_size().
68  </para>
69
70</chapter>
71