Glossary

Glossary allocation The final size of a widget within its parent. For example, a widget may request a minimum size of 20×20 pixels, but its parent may decide to allocate 50×20 pixels for it instead. requisition bin A container that can hold at most one child widget. The base class for bins is #GtkBin. container child A container's child is a widget contained inside it. column 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. model-view widget container 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. widget geometry display 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. event Events are the way in which GDK informs GTK+ about external events like pointer motion, button clicks, key presses, etc. geometry A widget's position and size. Within its parent, this is called the widget's allocation. mapping This is the step in a widget's life cycle where it actually shows the GdkWindows it created when it was realized. When a widget is mapped, it must turn on its %GTK_MAPPED flag. 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 gdk_window_show(): you must wait for the corresponding map event to be received. You can do this with the GtkWidget::map-event signal. model column 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 e.g. gtk_list_store_new(). view column model-view widget 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. no-window widget 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 GTK_WIDGET_NO_WINDOW() macro. parent A widget's parent is the container inside which it resides. realization This is the step in a widget's life cycle where it creates its own GdkWindow, or otherwise associates itself with its parent's 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 %GTK_REALIZED flag. 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 ::realize() 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. requisition The size requisition of a widget is the minimum amount of space it requests from its parent. Once the parent computes the widget's final size, it gives it its size allocation. allocation screen 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. style A style encapsulates what GTK+ needs to know in order to draw a widget. Styles can be modified with resource files. toplevel A widget that does not require a parent container. The only toplevel widgets in GTK+ are #GtkWindow and widgets derived from it. container unmap mapping unrealize realization view column A displayed column in a tree view, represented by a #GtkTreeViewColumn object. model column visual 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.