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

[James Curbo <james teyandei net>]

Carl Nygard wrote:
> Here's the first cut, as a tarball.  You should be able to do this:
>
> cd ~
> tar zxf gtk2-simple.tar.gz
> cd Gtk2
> ./bindtest.pl
> ./tietest.pl

Thanks, this stuff is pretty interesting. Comments below.

> The two examples work the same, essentially.  Hit the Update button and
> see in the terminal window the contents of your local vars.  Hit the
> reset and see what happens to the widgets when the local vars are
> changed.

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? :)

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.

> 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.

> 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.

> This is more a problem of the interface for Tied objects.  As I write
> this, I'm thinking of passing a ref to ref to array, and letting the
> TiedScalar figure out if it points to a scalar or a ref->array, and do
> the required magic there.  We'll see.  
>
> Comments appreciated.
>
> Also, whoever was talking about the OptionMenu/SimpleMenu integration,
> feel free to munch this code to integrate.  Then we can all check it out
> and discuss.

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

> Regards,
> Carl
>
> PS - pod docs are invalid, I think they're just remnants from the
> initial yank/paste.  Sorry.
>
> PPS - ignore the CascadeList.pm stuff, that's something totally
> different (hooking lists together to modify the contents of one
> depending on the selection of the previous, hence the "Cascade"
> moniker).  I could post that too, but it's just a duplication of
> TreeView functionality in a different presentation, so I doubt it's
> really useful to anyone.

Heh, I was wondering Cascade was and all I could find on google was some 
web CMS system. Really had me confused.

> PPPS  let me know if you have any problems...

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)

James