Re: [gtk-list] Question: Philosophy of saving widget state

[Klaus Bernpaintner <kb wharton upenn edu>]

The java language has a nice "Serializable" interface that takes care of these
kind of things. When you serialize an object, you save the object and everything
it contains and points to (recursively) so that objects and their state can
easily be restored by "unserializing". Every class implements this interface so
it is automatically taken care of and you don't have to think at all. Don't know
if this would be possible (or even desirable) in GTk+ . But it is handy, and
extensively used with java GUI-builders.



andrew@cogent.ca wrote:
> 
> 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
> 
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null

-- 
Klaus Bernpaintner
The Wharton School
(215) 417-7587