From a37b9d757854cbdac2ddbb86b703f45415e1cf69 Mon Sep 17 00:00:00 2001 From: Matthias Clasen Date: Sun, 24 May 2020 11:12:56 -0400 Subject: [PATCH] docs: Drop the glossary It is very incomplete, somewhat outdated, and we lack the resources to maintain it properly. --- docs/reference/gtk/glossary.xml | 366 ------------------------------- docs/reference/gtk/gtk4-docs.xml | 2 - docs/reference/gtk/meson.build | 2 - 3 files changed, 370 deletions(-) delete mode 100644 docs/reference/gtk/glossary.xml diff --git a/docs/reference/gtk/glossary.xml b/docs/reference/gtk/glossary.xml deleted file mode 100644 index 38deb7341b..0000000000 --- a/docs/reference/gtk/glossary.xml +++ /dev/null @@ -1,366 +0,0 @@ - - - - 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. - - - - - - - - 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. - - - - - - 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 GdkSurfaces 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_surface_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 GdkSurface 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_surface() function. - - - - - - 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 GdkSurface, or otherwise associates itself with - its parent's - GdkSurface. If the widget has its own window, then it must - also attach a style to - it. A widget becomes unrealized by destroying its associated - GdkSurface. When a widget is realized, it must turn on its - %GTK_REALIZED flag. - - - - Widgets that don't own the GdkSurface on which they draw are - called no-window widgets. - This can be tested with the gtk_widget_get_has_surface() function. Normally, - these widgets draw on their parent's GdkSurface. - - - - 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. - - - - - - 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. - - - - - - 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 - - - - diff --git a/docs/reference/gtk/gtk4-docs.xml b/docs/reference/gtk/gtk4-docs.xml index 1d13375288..9e12315a03 100644 --- a/docs/reference/gtk/gtk4-docs.xml +++ b/docs/reference/gtk/gtk4-docs.xml @@ -428,8 +428,6 @@ - - Index of all symbols diff --git a/docs/reference/gtk/meson.build b/docs/reference/gtk/meson.build index 6c2170a115..cdeaeec609 100644 --- a/docs/reference/gtk/meson.build +++ b/docs/reference/gtk/meson.build @@ -340,7 +340,6 @@ images = [ ] content_files = [ - 'glossary.xml', 'gtk4-broadwayd.xml', 'gtk4-builder-tool.xml', 'gtk4-demo-application.xml', @@ -359,7 +358,6 @@ content_files = [ ] expand_content_files = [ - 'glossary.xml', 'question_index.xml', 'text_widget.xml', 'tree_widget.xml',