AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity

Mention thread-safety issues

Browse Source
This commit is contained in:
Matthias Clasen 2009-09-13 23:32:46 -04:00
parent 8f16541d93
commit f10f6b8b0c
1 changed files with 8 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/reference/gtk/migrating-ClientSideWindows.sgml
View File

@ -13,9 +13,12 @@
longer correct to assume that each window has an associated XID.
Code that makes this assumption can sometimes be fixed by calling
gdk_window_ensure_native() on the windows in question.
Calling gdk_x11_drawable_get_xid() from the X11-specific API on a
non-native window will explicitly call gdk_window_ensure_native(),
so old code using this will continue to work.
Calling gdk_x11_drawable_get_xid() (or GDK_WINDOW_XID()) from the
X11-specific API on a non-native window will explicitly call
gdk_window_ensure_native(), so old code using this will continue to
work. A small gotcha is that the GDK_WINDOW_XID() call is no longer a
trivial accessor for the XID of the window, and thus must not be called
from another thread without taking locking precautions.
</para>
<para>
@ -57,8 +60,8 @@
<para>
Due to a weird API in XClearArea the gdk_window_clear_area() call handled
a specified width or height of zero to mean "to end of window" for
non-doublebuffered drawing. This has been changed to be consistent with
the docs and what happens in the doublebuffered case. All code in gtk+
non-double-buffered drawing. This has been changed to be consistent with
the docs and what happens in the double-buffered case. All code in GTK+
that relied on this has been fixed, but it is possible (although unlikely)
that third party applications rely on this. If you need to do this, just
implement it yourself using gdk_drawable_get_size().