
THIS FILE IS EXTREMELY OUTDATED!!!


Abstractions/simplifications in the GLE way
-------------------------------------------

GLE in contrast to Gtk+ does not make a real distinction
between widgets and containers.
The basis operations that can be applied to a GtkObject are abstracted
in a GleGObject, and operations that can be applied to GtkWidgets and
GtkContainers are handled by a GleGWidget, where a GleGWidget fully
implements the functionality that is available for a GleGObject.
If you get a feeling that this isn't appropriate, i'm willing to
consider your requests, but so far i haven't found any real neccessity
for a more detailed abstractions (i.e. treating containers and widgets
specially from a GLE perspective).


GLE widget names
----------------

In order to perform GleGWidget<->GtkWidget lookups, both have a unique
gle_name applied. As an ease for the user, GLE provides an algorithm for
genric gle_name generation. A generic gle_name normaly consists of the
widgets name, or if not provided, the widgets type followed by a dash and
a unique number for this widget type, preceeded by a dot and its parents
gle_name.
The rules for naming widgets without a parent are somewhat more complicated,
a simple widget that is not a toplevel will have its parent gle_name set to
the special name "GleUnknown".
Real toplevel names for widgets that derive from a GtkWindow will be named
after the window title, the widget name or as a fallback by the widget type
again, optionally followed by a dash and a trailing number to unify the GLE
name.
It i always possible to assign a user specified GLE name.


Linkage magic
-------------

In general GLE treats all widgets that are derived from a GtkWidget
in the same way, however Gtk+ doesn't provide the functionality to
extend this on linking a widget to a parent in general. For instance
there are generic functions to add a child to a GtkContainer or remove
a child from a GtkContainer, i.e. gtk_container_add/gtk_container_remove.
But this mechanism doesn't really support all of the flexibility that
can be made use of when adding a child to a parent, e.g. linking to a box
allowes the user to configure expansion, filling and padding behaviour,
which is not taken care of by the generic gtk_container_add routine.
Other widgets like a GtkTable (cell specification) or a GtkNotebook (tab/menu
label specification) provide different configuration options upon linkage.
In order to not replicate all of the specific widget properties, those
containers are still treated in a generic way, but for a distinct parent
type, special linkage is provided. This requires GLE to have some special
knowledge about parent linkage, which is hardcoded into the library.
With more container types arising for Gtk+, this linkage magic needs to be
extended/adapted.

	- Tim Janik <timj@gtk.org>
	  1998/02/24
