GdkWindow is a wrapper
around Xlib's Window
object. (It was discussed briefly in the section called
Realizing, Mapping, and Showing in the chapter called
GTK+ Basics.) A
GdkWindow represents a region on the screen. It can
be shown or hidden (called mapping
and unmapping the window in Xlib).
You can capture events received by a GdkWindow, draw graphics inside it, and
move or resize it.
GdkWindows are arranged in a tree structure; that
is, each window can have child windows. Child windows are
positioned relative to their parent window, and move when
the parent moves. Child windows don't draw outside of their
parent's bounds (i.e. they are clipped by the parent
window).
The tree of GdkWindows is
not specific to each application; there is a global tree of
windows controlled by the X server and the window manager.
The root window has no parent; all
windows derive from it. All or part of it is visible as
your desktop background. Each window can be owned by a
different UNIX process; some windows will be created by the
window manager, some will come from user applications.
GdkWindow and GtkWindow are very different things; GtkWindow is a GTK+ widget used to
represent toplevel windows (toplevel windows are the
highest application-controlled windows in the window
hierarchy). Window managers typically create decorations for toplevel windows;
decorations include title bars, close buttons, and the
like.
It's important to understand that an X window is primarily
an object on the X server. X clients receive a unique
integer ID for each window, and refer to windows by ID.
Thus, all window operations take place on the server; all
functions that deal with X windows go across the network.
GdkWindow is a wrapper
around the integer ID returned by X. It does keep local
copies of some information (such as the window's
dimensions), so some GDK operations are more efficient than
the corresponding Xlib operations. Still, GdkWindow is essentially a handle for a
server-side object. Many GDK objects are similar; fonts,
pixmaps, cursors, and so on are also handles for
server-side objects.
Many GtkWidget subclasses
have an associated
GdkWindow. In theory, GTK+ applications could
create only toplevel windows, and have all widgets draw
into them. However, it would make little sense to do so;
GdkWindow allows the X
Window System to automatically handle many details. For
example, events received from GDK are marked with the
window they occurred in; GTK+ can rapidly determine which
widget each event corresponds to.
There are some widgets with no associated GdkWindow; these are called "no
window" widgets, an allusion to the GTK_NO_WINDOW flag that marks them.
(You can test this flag with the macro GTK_WIDGET_NO_WINDOW().) Widgets without
a window render themselves into their parent container's
GdkWindow. Windowless
widgets are relatively small and lightweight; GtkLabel is the most common example.
Because events are always received on a GdkWindow, windowless widgets do not
receive events. (The
GtkEventBox container can be used if you need to
capture events on a windowless widget.)
