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

Carl Nygard wrote:
 > 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.

You're stretching the limits of my perl-fu here, but I think I understand after looking at some more code. Since the bound variables are not contained within the widget's structure itself, you can freely attach/detach them at will. But since the tied widgets are linked to the actual instances of the tie/untie, the data is destroyed when you untie.

With the bound widget you have to remember to call update_widget when you change the data in the variable, correct? The tied version automatically updates, which is the advantage there.

Now I see why you wrote both :)

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.

With regards to the above, I am not against the tied/bound approach, but I am still wondering about the namespace itself.

For example, you used:


I am curious about alternatives to this, with respect to readability and making it easier to remember which module to use. Perhaps:


or perhaps encasing the tie/bind choice within the module itself, perhaps as a argument to new_from_widget:

$optionmenu = Gtk2::Simple::OptionMenu->new('type' => 'tie', ... );

I don't know if this is feasible however.

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?

The only suggestion I have is one that comes to me from looking at the ('', 1, '', '', 1) structure... perhaps return a hash instead of an array, and set selected items to 1 and unselected items to 0. You'd still have to traverse the hash to get what is selected though... so I don't know if it's a good idea or not.

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

I was smoking crack here, please ignore. I am way too tired tonight.

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

I had a thought like this in my SimpleComboBox thread and now that I have thought about it, you are right. SimpleComboBox for example was designed to only a simple array of strings that are choices in the combobox, but things like SimpleList can have more than one column and such like you say. Unless setting the level of complexity is done at SimpleListStore object creation time or something.

Thanks for the comments.

Thanks for the clarifications :)



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