Glossary

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.

See Also requisition .

A container that can hold at most one child widget. The base class for bins is #GtkBin.

See Also container .

A container's child is a widget contained inside it.

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.

See Also widget geometry .

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.

Ellipsization is the process of replacing some part of a text by an ellipsis (usually "...") to make the text fit in a smaller space. Pango can ellipsize text at the beginning, at the end or in the middle.

Events are the way in which GDK informs GTK+ about external events like pointer motion, button clicks, key presses, etc.

A widget's position and size. Within its parent, this is called the widget's allocation.

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.

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().

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. This can be tested with the gtk_widget_get_has_window() function.

A widget's parent is the container inside which it resides.

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_get_has_window() function. Normally, these widgets draw on their parent's GdkWindow.

Note that when a #GtkWidget creates a window in its #GtkWidget::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.

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.

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.

A widget that does not require a parent container. The only toplevel widgets in GTK+ are #GtkWindow and widgets derived from it.

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 .