|GTK+ Reference Manual|
See Also requisition .
See Also container .
GTK+ contains several widgets which display data in columns, e.g. the GtkTreeView. These view columns in the tree view are represented by GtkTreeViewColumn objects inside GTK+. They should not be confused with model columns which are used to organize the data in tree models.
See Also model-view widget.
A widget that contains other widgets; in that case, the container is the parent of the child widgets. Some containers don't draw anything on their own, but rather just organize their children's geometry; for example, GtkVBox lays out its children vertically without painting anything on its own. Other containers include decorative elements; for example, GtkFrame contains the frame's child and a label in addition to the shaded frame it draws. The base class for containers is GtkContainer.
GDK inherited the concept of display from the X window system, which considers a display to be the combination of a keyboard, a pointing device and one or more screens. Applications open a display to show windows and interact with the user. In GDK, a display is represented by a GdkDisplay.
Events are the way in which GDK informs GTK+ about external events like pointer motion, button clicks, key presses, etc.
Note that due to the asynchronous nature of the X window
system, a widget's window may not appear on the screen
immediatly after one calls
you must wait for the corresponding map event to be received. You can do
this with the
A column in a tree model, holding data of a certain type.
The types which can be stored in the columns of a model
have to be specified when the model is constructed, see
See Also view column .
These widgets follow the well-known model-view pattern, which separates the data (the model) to be displayed from the component which does the actual visualization (the view). Examples of this pattern in GTK+ are the GtkTreeView/GtkTreeModel and GtkTextView/GtkTextBuffer
One important advantage of this pattern is that it is possible to display the same model in multiple views; another one that the separation of the model allows a great deal of flexibility, as demonstrated by e.g. GtkTreeModelSort or GtkTreeModelFilter.
A widget that does not have a GdkWindow of its own on which to
draw its contents, but rather shares its parent's. Such a widget has the
GTK_NO_WINDOW flag set, and
can be tested with the
This is the step in a widget's life cycle where it
creates its own GdkWindow, or otherwise associates itself with
GdkWindow. If the widget has its own window, then it must
also attach a style to
it. A widget becomes unrealized by destroying its associated
GdkWindow. When a widget is realized, it must turn on its
Widgets that don't own the GdkWindow on which they draw are
called no-window widgets.
This can be tested with the
GTK_WIDGET_NO_WINDOW() macro. Normally,
these widgets draw on their parent's GdkWindow.
Note that when a widget creates a window in its
handler, it does not actually show the window. That is, the
window's structure is just created in memory. The widget
actually shows the window when it gets mapped.
See Also allocation .
GDK inherited the concept of screen from the X window system, which considers a screen to be a rectangular area, on which applications may place their windows. Screens under X may have quite dissimilar visuals. Each screen can stretch across multiple physical monitors.
In GDK, screens are represented by GdkScreen objects.
A style encapsulates what GTK+ needs to know in order to draw a widget. Styles can be modified with resource files.
See Also container .
A displayed column in a tree view, represented by a GtkTreeViewColumn object.
See Also model column .
A visual describes how color information is stored in pixels. A screen may support multiple visuals. On modern hardware, the most common visuals are truecolor visuals, which store a fixed number of bits (typically 8) for the red, green and blue components of a color.
On ancient hardware, one may still meet indexed visuals, which store color information as an index into a color map, or even monochrome visuals.
A control in a graphical user interface. Widgets can draw themselves and process events from the mouse and keyboard. Widget types include buttons, menus, text entry lines, and lists. Widgets can be arranged into containers, and these take care of assigning the geometry of the widgets: every widget thus has a parent except those widgets which are toplevels. The base class for widgets is GtkWidget.
See Also container .