Re: Gtk2::Simple::* example/sample code

["A. Pagaltzis" <pagaltzis gmx de>]

* Carl Nygard <cjnygard fast net> [2004-03-30 14:53]:
> Not bored;)  Started with tied version.  Then realized that the
> tied vars depend on the widgets being around and the var still
> hooked to the widget.  My app has many instances of common set
> of data, and the different instances get swapped in and out to
> allow editing.  untie states that the original value of the var
> gets restored upon untie, so swapping a new struct into place
> blows the old away.  Hence the bind version, which stores
> modifications as they happen.

In the case of SimpleList, it works because the tied thing is
separate from the widget. I think all SimpleFoo widgets *should*
be implemented in this fashion; and really, that's what your
bound version does, conceptually.

Thinking out loud from here on..

It would probably be best if there is one class that represents a
scalar and one for an array, both with a standard interface for
SimpleFoo widgets, where the widget attaches itself as a listener
for changes and also knows how to update the data store on
change.

The user interface for the data stores should probably be
overloaded stringification/numification/array access etc. It's
harder to implement and get right than a tie, but lets things
work the same on all ends.

Actually, now that I'm thinking about it, if it's the user's
responsibility to tell the data store which widgets are connected
to it, it might be feasible not to require any SimpleFoo *widget*
classes at all -- the data store might install a signal handler
to update itself into the widget at connect time, f.ex.

Of course it would need a lookup table for signal name by widget
type.. and such a lookup table is basically what a class is.. so
maybe having SimpleFoo classes for the widgets is still better.
They could be trivial though, they'd just inherit from their
ancestor and only add a single method along the lines of
get_data_store_update_signalname(). Nothing else would need to be
in there.

The SimpleFoo classes could all inherit a couple simple functions
from a common ancestor. Such as a new_with_datastore() method
that does nothing other call the data store's connect method to
have itself added as a listener.

The listeners should be added actively by the data store though,
so that the closures connected to the widgets' signal handlers
have direct access to the variable that actually serves as the
data store. Otherwise a layer of indirection would be required.

One might also have the data store auto-disconnect destroyed
widgets, this would just require it to install another signal
handler.

-- 
Regards,
Aristotle
 
"If you can't laugh at yourself, you don't take life seriously enough."