Requiring state to be shared in verb is not always correct



Hi Michael,

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

However, we've run into a case in Nautilus where sharing the state in the
verb is not appropriate. Specifically, we have two ways to toggle between
showing the URI text field and showing the search criterion UI. One way is a
menu item that is not a checkmenuitem. It toggles between two words. The
other way is a toggle button in the tool bar. Activating either of these two
items does the same thing, so they should conceptually share a verb. But
only the toggle button has "state" in the Bonobo sense. (The menu item does
have state in the sense of its label changing, but the widget itself is not
a state-full widget like a checkmenuitem would be.)

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.

I think this is a legitimate use of sharing a Bonobo verb. The state
involved here only applies to the tool bar button, so I should be able to
set the state of the tool bar button without Bonobo thinking it is an error.

I can also imagine cases where the hidden-ness of one item using verb V
might be independent of the hidden-ness of another item using verb V.

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.

Any comments?

John





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