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

["John Sullivan" <sullivan eazel com>]

on 10/15/00 5:45 AM, otaylor redhat com at otaylor redhat com wrote:

> 
> "John Sullivan" <sullivan eazel com> writes:
> 
>> 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.)
> 
> Perhaps there needs to be a concept of a dual-label menu item
> 
> state 0 => Show URI field
> state 1 => Hide URI field
> 
> Because there _is_ state in this menu item, and if you had multiple
> menu items for this verb, they should all coordinate.

It's true that there is a concept of state in this menu item, but not in the
way it's implemented. That is, we have to do extra work outside of the
widget guts to make the state work properly. In this case, it is an option
to modify Bonobo to know about a new kind of state-ful object -- menu items
that have two states, expressed via different labels. But there's no
guarantee that this will be the last case where someone wants to express
state in the UI in a way not currently supported by Bonobo. The next obvious
one is tool buttons that have two different labels depending on what state
they're in. Then maybe there are variations where the images change also, or
instead. It seems that we have the following options:

(1) Update Bonobo for each such new state-ful widget type as we think of it.
(2) Update Bonobo for each such new state-ful widget type as a client
actually uses it.
(3) Disallow sharing verbs between such new state-ful widget types and the
ones Bonobo knows about.
(4) Allow sharing verbs between arbitrary new state-ful widget types and the
ones Bonobo knows about by allowing the state to be stored with the widget
rather than the verb.

(1) seems silly to me. (2) seems impractical in the general case, though
perhaps workable. (3) is what we have now, which is workable but clumsy. (4)
is what I was asking about. It has pros and cons, the main con being that
doing so would remove a helpful check that people aren't *accidentally*
putting state in widgets that they meant to put in verbs. It's not a huge
deal; I can live with the (3) that we have now.

> (I assume the reason why you are avoiding the toggle button here
> is you think it is clearer to say "show/hide" rather than
> have 
> 
> [ ] URI field

More or less right. In the particular case that hit this problem, the menu
item switches between "Find" and "Browse". We do have other menu items that
switch between "Show Foo" and "Hide Foo" though. I have enough experience in
UI development to know that there are circumstances where toggling the text
of a menu item works better than a check mark, and vice-versa.

> I'm somewhat, though not 100% not convinced of that, but I'm
> definitely not convinved that handling this in different ways in two
> different places is a good idea... anyways.)

I'm not 100% convinced that the specific case in Nautilus that caused us to
run into this issue couldn't be improved. But I am quite sure that
programatically requiring that a menu item and a tool bar button must use
the same basic UI is wrong. For instance, tool bar buttons have much more
limited space for text than menu items, so if the clearest way to express
something is via longer text, the tool bar button might have to settle for
the second clearest way, whereas the menu item has room for the clearest
way.


John