← Back to branch summary

~canonical-dx-team/ubuntu/maverick/gtk+2.0/menuproxy

« back to all changes in this revision

Viewing changes to docs/reference/gtk/migrating-ClientSideWindows.sgml

  • Committer: Bazaar Package Importer
  • Author(s): Sebastien Bacher
  • Date: 2009-09-23 09:50:04 UTC
  • mfrom: (1.5.3 upstream)
  • mto: This revision was merged to the branch mainline in revision 129.
  • Revision ID: james.westby@ubuntu.com-20090923095004-e9xauadn4bjs5n7m
Tags: upstream-2.18.0
Import upstream version 2.18.0

Show diffs side-by-side

added added

removed removed

Lines of Context:
docs/reference/gtk/migrating-ClientSideWindows.sgml
13
13
    longer correct to assume that each window has an associated XID.
14
14
    Code that makes this assumption can sometimes be fixed by calling
15
15
    gdk_window_ensure_native() on the windows in question.
16
 
    Calling gdk_x11_drawable_get_xid() from the X11-specific API on a
17
 
    non-native window will explicitly call gdk_window_ensure_native(),
18
 
    so old code using this will continue to work.
 
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.
19
22
  </para>
20
23
 
21
24
  <para>
30
33
    example that we've seen is changing the child window stacking order
31
34
    using XRestackWindows(). Fixing this properly requires to fix the code
32
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.
33
38
  </para>
34
39
 
35
40
  <para>
39
44
    may be affected by this.
40
45
  </para>
41
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
 
42
70
</chapter>