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



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.


Your 'procedual knowledge' can be thought of as just another type of
'state knowledge', i.e. describing how a widget relates to its parent.

GTK+ does already provide 2 things for this:

 1) Child Arguments - these are similar to standard Args, but describe
    the widgets position in its parent. e.g. widgets in a box have
    "expand", "fill", "padding", "pack_type", and "position" Args.

 2) Composite children - these are widgets which are created automatically
    as children of other widgets, e.g. the buttons in a file selection.
    These are given names to identify them (though this isn't used much yet.)

With the current Arg stuff I reckon you could cope with about 95% of widgets
created for GTK+. However, some widgets like GtkNotebook don't fit into
this scheme very neatly. I think our model could be improved, especially the
'child arg' & 'composite children' parts, but I have yet to think of a
cleaner solution myself. Maybe you have some ideas?

(As far as Glade goes, I'd like to use Args eventually. But since we've got most
widgets working OK now, and there's lots of other important features missing,
it's got a fairly low priority. I was considering it again recently for Gnome,
but Gnome widgets don't support Args yet, and people want Glade to work with
Gnome 1.0, so we have no choice but to stick to our "ingeneous but extreme" ways
for now :)

Damon




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]