The GBin widget is a container with just one child. It is not very useful itself, but it is useful for deriving subclasses, since it provides common code needed for handling a single child widget.
Many GTK+ widgets are subclasses of GtkBin, including GtkWindow, GtkButton, GtkFrame, GtkHandleBox, and GtkScrolledWindow.
GBox is an abstract widget which encapsulates functionallity for a particular kind of container, one that organizes a variable number of widgets into a rectangular area. GBox currently has two derived classes, GHBox and GVBox.
The rectangular area of a GBox is organized into either a single row or a single column of child widgets depending upon whether the box is of type GHBox or GVBox, respectively. Thus, all children of a GBox are allocated one dimension in common, which is the height of a row, or the width of a column.
GBox uses a notion of packing. Packing refers to adding widgets with reference to a particular position in a GContainer. For a GBox, there are two reference positions: the start and the end of the box. For a GVBox, the start is defined as the top of the box and the end is defined as the bottom. For a GHBox the start is defined as the left side and the end is defined as the right side.
Use repeated calls to GBox::packStart() to pack widgets into a GBox from start to end. Use GBox::packEnd() to add widgets from end to start. You may intersperse these calls and add widgets from both ends of the same GBox.Use GBox::startDefaults() or GBox::endDefaults() to pack widgets into a GBox if you do not need to specify the expand, fill, or padding attributes of the child to be added.
Because GBox is a GContainer, you may also use GContainer::add() to insert widgets into the box, a nd they will be packed as if with GBox::packStartDefaults(). Use GContainer::remove() to remove widgets from the GBox.
Use GBox::setHomogeneous() to specify whether or not all children of the GBox are forced to get the same amount of space.
Use GBox::setSpacing() to determine how much space will be minimally placed between all children in the GBox.
Use GBox::reorderChild() to move a GBox child to a different place in the box.
Use GBox::setChildPacking() to reset the expand, fill, and padding attributes of any GtkBox child. Use GBox::queryChildPacking() to query these fields.
|GCalcMdiBounds||A helper class, computes max and min coordinates on each MDI child.|
|GCallbackInterface||A general GFC callback class interface.|
The GContainer widget provides a abstract container implementation. This is abstract class and cannot be used itself.
There are many widgets bases on GContainer, GVBox, GHBox GFixed, GBin, GMdiFrame
|GException||A general GFC run-time error|
The GFixed widget is a container which can place child widgets at fixed positions and with fixed sizes, given in pixels. GFixed performs no automatic layout management.
For most applications, you should not use this container! It keeps you from having to learn about the other GTK+ containers, but it results in broken applications. With GFixed, the following things will result in truncated text, overlapping widgets, and other display bugs:
Fonts other than the one you used to write the app will of course change the size of widgets containing text; keep in mind that users may use a larger font because of difficulty reading the default, or they may be using Windows or the framebuffer port of GTK+, where different fonts are available.*
Translation of text into other languages changes its size. Also, display of non-English text will use a different font in many cases.
In addition, the fixed widget can't properly be mirrored in right-to-left languages such as Hebrew and Arabic. i.e. normally GTK+ will flip the interface to put labels to the right of the thing they label, but it can't do that with GtkFixed. So your application will not be usable in right-to-left languages.
Finally, fixed positioning makes it kind of annoying to add/remove GUI elements, since you have to reposition all the other elements. This is a long-term maintenance problem for your application.If you know none of these things are an issue for your application, and prefer the simplicity of GFixed, by all means use the widget. But you should be aware of the tradeoffs.
The GInnerFrame is a implementation of GMdiChild, that provides a basic implementation of a MDI client.
The GInnerFrame is a green Motif inspired window, with some basic buttons, maximize, minimize anf close.
|GMdiChild||The GMdiChild provides needed abastraction to implement a MDI widget, that can be placed in a GMdiFrame.|
This is a container class for the MDI child.
This class provied MDI area widget, where you can place GMdiChilds on, can be useful bulding applications with a real MDI interface.
It is based on the GFixed widget that can place widget on a fixed position, with improvements to handle MDI clients.
|GMoveChilds||A helper class, moves each MDI child a xOffset pixels left or right and a yOffset up or down, when a scrollbar is dragged or clicked.|
|GObject||This is op class of the GFC class hierchy, it has some basical properties, can be dynamic, can be serializable, it has a virtual destructor. A reference count, so the object will not be deleted before the objects ref count reach 0.|
The GTarget class provides basic functionality for signal handling between GTarget objects.
The idea is that each defined GTarget class sets up a list of outgoing signal and incoming signal (slots), then you can connect the signals between GTarget objects without they to know anything about each other.
example: the GWidget has the following slots defined
A GButton can emit a "clicked" signal when you click on it, so you can connect the "clicked" signal from a GButton to the "destroy" signal on a GWindow
button- connectObject ("clicked",widget,"destroy");
This class provides a abstract interface for implementing a widget type, that can be shown on screen.
It provides all necesary event handling, and properties needed by a widget ...
All classes in namespace gfc::widget are derrived from GWidget.
|GWindow||A general top level window on desktop.|