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

[Carl Nygard <cjnygard fast net>]

On Mon, 2004-03-29 at 21:22, James Curbo wrote:
> Carl Nygard wrote:
> > Here's the first cut, as a tarball.  You should be able to do this:

> I'm curious why you implemented tied and binded versions of both. Are 
> there enough situations where you would need either to warrant writing 
> both types, or were you just bored? :)

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.

Later, I added some code to try to store the value as the var is untied,
but that's not quite working when the widget gets destroyed.

> IMHO those looking for 'simple' modules will not particularly care about 
> if they are tied or binded; I know that when I first used SimpleList I 
> was just happy to not have to mess with the MVC stuff, much less worry 
> about the internal implementation. I'd like to see a plain 
> Gtk2::Simple::<widgetname>.pm breakout.

I would have liked to as well, and that's how I started until I realized
the above.  There is a difference, at least for my usage.
> > Note the ctor code for the widgets.  I prefer a generic
> > Gtk2::Simple::<Object>->new_from_widget() instead of more specific
> > new_from_entry (etc.).  This makes it easier to batch the ctor code
> > instead of writing it all out by hand (yes, I use this stuff for real in
> > some GUI scripts).
>
> Sounds good to me... although perhaps new_from_existing would sound 
> better in the general case? Personal preference, no real reason other 
> than aesthetics.

Whatever, maybe we can take a vote.  I obviously prefer _from_widget.
> > The multiselect lists are a bit inconsistent.  Tie'd versions have
> > essentially a bitset with selected indexes = 1, nonselected=0.  The Bind
> > version just has an array of selected indexes.  I.e.
> > Tied:  @sel = ( '',1,'','',1,'',1);
> > Bind:  @sel = (1,4,6);
>
> The bind looks much more natural and is what I would expect, also 
> considering that the selection functions in some other widgets just 
> return a list of indexes.

Yeah.  Got any ideas for improving the Tied version?

> I was just thinking that this stuff would be good for SimpleMenu. :)

How?  Menus are typically for activation.  Well, perhaps this would be
useful for toggle items, but not much else.  Hadn't occurred to me
really.


> I think that the only thing I would really change infrastructure wise is 
>   creating a ListStore tied object like previously discussed and basing 
> any Simple stuff that uses it (like SimpleList and my SimpleComboBox and 
> whatever else uses a simple ListStore) on it, instead of subclassing 
> SimpleList like you have done. (SimpleList in its current implemenation 
> would be replaced anyway)

I disagree.  My List.pm classes are simplified in the extreme, and don't
really provide for anything more than a simple label.  SimpleList at
least allows for multiple columns and different data types.  So I think
there's a place for both.  I would advocate moving/renaming to
Gtk2::Simple::TreeView.pm though.

Thanks for the comments.

Regards,
Carl