Terms relating to PHP-GTK 2.
An accelerator is a keyboard key marked with a function name (for example, Help or Delete), a function key (F1, F2), or the combination of a control key ([Ctrl], [Shift], [Alt]) with a programmer-defined key. The difference between a keyboard accelerator and a mnemonic is that an accelerator is available throughout the application, whereas a mnemonic is specific to a currently-visible widget.
An atom consists of a unique numeric ID corresponding to a string name. In GTK+, atoms are stored in a GdkAtom structure and are used mostly in selection. They can turn up anywhere GTK+ needs to avoid the overhead of passing arbitrary length strings.
A callback is a function or method that is invoked whenever a predetermined condition is met. Signal handlers, particularly, are frequently referred to as 'callbacks'.
See also: Signal handler.
A clip mask or clipping region is a specified bitmap or list of rectangles. It is used to restrict output from a graphics routine to a particular region of the destination window.
A colormap is a portable mechanism allowing pixel values to be mapped to RGB colors for display. In GTK+, the colormap is stored in a GdkColormap structure.
More than one colormap may be installed at any given time, allowing the windows associated with those maps to display with true colors. The system colormap in most cases is a limited resource that should be conserved by selecting RGB values from the predefined color database, i.e. rgb.txt.
Any method, class or variable marked as 'deprecated' may not be available in future releases of GTK+, and so should not be used in new code. Usually, deprecated functionality has already been replaced with something better.
For a list of deprecated items in PHP-GTK 2 and their replacements, see the Deprecated Widgets page.
Either windows or pixmaps can be used as destinations in graphics operations. These are collectively known as drawables. In GTK+, they are a specific type: GdkDrawable.
Events are the way an application interacts with the user; this is why GUI coding is known as 'event-driven programming'. A pointer movement, the mouse entering or leaving a widget's focus area, a key or button press, all qualify as events. The programmer ultimately has control over which events are known to any given widget and, usually over the way the event is handled (if at all). The default behaviour of an unhandled event is to propagate up through the widget's ancestry.
GTK+ event data is stored in a GdkEvent structure, and controlled via a GdkEventMask.
When a widget has focus, it receives input from the keyboard. You can usually use that input to shift focus to a neighbouring widget, as when - for example - using the keyboard to scroll through the items listed in a dropdown menu.
See also: Grab.
Widgets can grab the pointer and keyboard away from other widgets. This essentially means that the widget becomes "modal"; input goes only to that widget, and the focus can't be changed to another widget. A typical reason to grab input is to create a modal dialog; if a window has active grab, interaction with other windows is blocked.
See also: Focus.
GC is short for graphics context.
See also: Graphics context.
Meta information pertaining to graphics output, such as foreground pixel, background pixel, line width, clipmask etc, is stored in a graphics context (GC). Everything drawn to a window or pixmap is modified according to the information stored in the GdkGC that is being used.
See also: Clip mask.
Gravity referes to how an object is relatively positioned when objects surrounding it are added and removed. An object with left gravity will stay to the left of objects added in the same location. An object with right gravity will stay to the right of objects added in the same location. Gravity is normally associated with GtkTextMark objects.
When used in relation to text, gravity direction is logical direction. Left gravity is toward the beginning of the buffer and right gravity is toward the end of the buffer. When a language like Hebrew is used, left gravity is actually gravity which keeps the object on the right of newly added objects.
Certain properties, such as the preferred type of a window, are referred to as 'hints', because the window manager makes no guarantee that it will honor them. See type_hint.
A mnemonic is an application-specific keyboard shortcut consisting of the [Alt] key plus one programmer-defined keyboard character. A mnemonic is indicated by an underlined letter in the label of the menu item, button or other GUI component for which it is defined. Its corresponding keyboard shortcut is only available to the user while that label is visible.
See also: Accelerator, Underline.
A keyboard modifier is a key that can be used in combination with other keys to alter the meaning of those keys. Typical modifier keys would be [Shift], [Ctrl] and [Alt].
Modifiers can also be related to the mouse, so that the left, right and centre mouse buttons can be programmed to respond in a different way from one another within an application. For example, a left-button click might only interact with the menu bar, whereas a right-button click might display a popup menu in the vicinity of the pointer.
See also: Accelerator.
A signal is a notification that is generated whenever an event occurs. In order for it to have any effect, it needs to be connected to a callback function (also known as a signal handler).
See also: Callback, Signal handler.
A callback function that is invoked in response to a signal.
An underline is used in the label of a widget such as a button or a menu item to indicate the presence and value of a mnemonic. In PHP-GTK 2, mnemonic support is enabled by default, so that a menu item with the label text _Save will automatically have s as its keyboard shortcut. You can switch off this default behaviour when constructing simple widgets such as GtkButton and GtkMenuItem, or alternatively use a double underscore __ in order to display a single one where mnemonic support is present.
See also: Accelerator, Mnemonic.
The specifications for color handling for a drawable, including visual class, depth, RGB/pixel, etc., are collectively referred to as a visual and - in GTK+ - are stored in a GdkVisual. The visual accounts for the differences between various types of hardware in determining the way pixel values are translated into visible colors. A screen may support only one type of visual.