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

Add an migration chapter for CSW

Browse Source
This commit is contained in:
Matthias Clasen 2009-08-31 01:26:11 -04:00
parent 953d391a34
commit b6b64353a1
3 changed files with 41 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
docs/reference/gtk/Makefile.am
View File

@ -129,6 +129,7 @@ content_files = \
drawing-model.xml \
glossary.xml \
migrating-checklist.sgml \
migrating-ClientSideWindows.sgml \
migrating-GtkAboutDialog.sgml \
migrating-GtkAction.sgml \
migrating-GtkAssistant.sgml \

1
docs/reference/gtk/gtk-docs.sgml
View File

@ -435,6 +435,7 @@ that is, GUI components such as #GtkButton or #GtkTextView.
<xi:include href="xml/migrating-GtkTooltip.sgml" />
<xi:include href="xml/migrating-GtkEntry-icons.sgml" />
<xi:include href="xml/migrating-GtkLabel-links.sgml" />
<xi:include href="xml/migrating-ClientSideWindows.sgml" />
</part>
<part>

39
docs/reference/gtk/migrating-ClientSideWindows.sgml Normal file
View File

@ -0,0 +1,39 @@
<?xml version="1.0"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
"http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd" [
]>
<chapter id="gtk-migrating-ClientSideWindows">
<title>Migrating to client-side windows</title>
<para>
In version 2.18, GDK has been changed to use client-side windows. This
means that there is no longer a 1-1 correspondence between #GdkWindows
and windows in the underlying window system. In particular, it is no
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.
</para>
<para>
GDK looks for the <envvar>GDK_NATIVE_WINDOWS</envvar> environment variable
and makes all windows native if it is set. It also tries to be more
compatible with the way prior versions worked in some other ways.
</para>
<para>
Some applications assume that they can just operate on the X windows
corresponding to their GDK windows without ever telling GDK. One
example that we've seen is changing the child window stacking order
using XRestackWindows(). Fixing this properly requires to fix the code
to use GDK functions to achieve whatever it is trying to achieve.
</para>
<para>
One change that can cause problems for some applications is that GDK
is more aggressive about optimizing away expose events. Code that does
more than just repainting exposed areas in response to expose events
may be affected by this.
</para>
</chapter>