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 FIXME 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. Each screen has a root window which defines the area of the screen. 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 FIXME toplevel A widget that does not require a parent container. The only toplevel widget in GTK+ is GtkWindow. container unmap mapping unrealize realization view column A displayed column in a tree view, represented by a GtkTreeViewColumn object. model column widget 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. container