
THIS FILE IS EXTREMELY OUTDATED!!!

hm, as of now, i'm not sure i need this doc or whether i even want it ;)
but i think putting it down and revealing it later wouldn't do much harm...


GtkWidget<->GleGWidget and GtkObject<->GleGObject relationships
---------------------------------------------------------------

similar to what is stated in design.txt, i'm still of the opinion that
combining the stuff of a potential GleGContainer and the existing
GleGWidget structures is a reasonable approach, though i must admit that
especially with the implementation of child arguments on GtkContainers,
i don't remain as convinced as before... ;)

a GleGWidget will either be created because of parsing a widget tree
description file, or because the tree of an existing Gtk toplevel widget
is "scanned" by GLE.
if one of those child widgets is "unparented" (i.e. removed from its
parent) or destroyed within the Gtk tree, the associated GleGWidget remains
with its children and parent pointers within the GleGWidgets tree.
if a GtkWidgets that has an associated GLeGWidget does get reparented (i.e.
added to a new container), the associated GleGWidget does get moved [into
the new tree] as well. on the other hand, reparentation of a GleGWidget
will immediatedly cause the reparentation of its associated GtkWidget.

a pure GleGObject (i.e. a non GleGWidget thingie) is always meant to be
persistent unless its destruction is explicitely requested.

in general, the destruction of a GleGObject and a GleGWidget does not
actually affect its associated GtkObject in regards to destruction.
thus, an imperative step of the destruction of a GleGObject and GleGWidget
is the disassociation of the corresponding GtkObject.

	- Tim Janik <timj@gtk.org>
	  1998/07/12
