Question: Philosophy of saving widget state

[andrew cogent ca]

I think I have finally figured out how to express a nagging concern I
have about writing a GUI builder under GTK+, and would like to run it
past those who are less ignorant than myself ...

It seems to me that there are two kinds of knowledge that must be
stored with a particular GUI layout, ignoring code bindings for the
moment.  These would be:

1) procedural knowledge, containing in some form information about how
   a GUI layout was created, and the order in which it was done.  This
   would be things like packing of widgets within a box.

2) state knowledge, containing information about what a widget looks
   like, such as size, color, text, children, parent.

>From looking at the API, it seems that much of the state knowledge is
available through the Argument mechanism.  I can query an argument to
a widget by name, and receive a sensible result.  If the arguments are
fully implemented for all widgets, I should be able to retrieve enough
state knowledge to be able to recreate an entire GUI layout based
solely on this knowledge.  For some state knowledge that is not
available by argument, I can often query the GtkWidget for common
information through a function call (and thus, arguably, it should be
representable as an argument).

However, some of the knowledge in a layout is not state knowledge at
all, but rather procedural.  I need to know how the current GUI came
to be.  This means that no amount of querying the arguments of widgets
will ever allow me to fully recreate an existing layout.  The steps
that Glade, for example, has had to take to create persistent layout
are ingeneous but extreme.  

So what seems to be needed is a means by which the introspection
(argument) mechanism can be expanded in scope to the point where state
information is sufficient to fully specify a given layout.  Once this
is achieved, GUI builders will become much simpler, alternate language
bindings, especially to OO languages, will become much more robust,
and non-code representations of GTK layouts will become possible.

Is it a goal, either stated or implicit, of the GTK+ project to make
it possible to query a GTK widget to the level where its layout and
appearance can be reproduced from the knowledge thus obtained?  (Does
this exist and I'm just blind?)

Andrew