Re: Requiring state to be shared in verb is not always correct

[Michael Meeks <michael helixcode com>]

Hi John,

On Tue, 10 Oct 2000, John Sullivan wrote:
> Currently Bonobo expects that items that share a callback via sharing   
> a verb will also want to share state, sensitivity, and hidden-ness. If
> code tries to put those three attributes on an item rather than its
> verb, Bonobo emits a warning (though currently it continues to work
> despite the warning).

        Correct; this is to help people migrate to cmd / widget
separation.

> We use bonobo_ui_component_set_prop (ui_component, path, "state", "0",   
> NULL) to set the state. If we pass the path for the tool bar toggle
> button in as "path", then Bonobo complains about command/widget
> separation being violated. But if we pass the path for the command in   
> as "path", then Bonobo complains about setting state on "wierd object   
> 'GtkMenuItem'" (because Bonobo is surprised that a non-stateful
> standard menu item is using a state-full verb). Either way, Bonobo is   
> unhappy.

        This would seem to suggest to me that already the cmd / widget
separation is broken by not putting the type="toggle" on the cmd. This
seems to me a rather bad idea. Clearly, if you want both a way to toggle (
or roll ) a state and you want a way to set a state these are two rather
different things. I would reccommend 2 different verbs
EditSetWhateverState and EditToggleWhateverState, and do the state set on
one and the toggle logic on the other.
 
        Of course another solution is to kill the 'wierd object'
warning; it seems to me a rather pointless debugging tool from this angle.
 
> For now, I will work around the problem by using different verbs for
> the menu item and tool bar, but I think this is a design mistake in
> Bonobo. The simplest solution is to support setting the state (and
> hidden-ness, and sensitivity presumably) on either the command or the
> individual item, with different results -- setting the property on the
> individual item would affect only that item; setting it on the command
> would affect all items sharing that command. The disadvantage of this
> solution is that it would make errors where the programmer intended to
> change the verb property but only changed an item property harder to
> notice. make errors where the programmer intended to change the verb
> property but only changed an item property harder to notice.
          
        I would very much like not to do this; not only because of the
problem you enumerate, but the old design used to try and sync the state
value across the cmd and widget nodes and got ugly fast. eg. you toggle
a checkbox and want to update the widget, but do you update the cmd as
well ? if so you then need to update all the other widgets, but if you are
a radio-button this is already being done. The problems are called legion
for they are many.

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot