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

[Michael Meeks <michael helixcode com>]

Hi John,

On Mon, 16 Oct 2000, John Sullivan wrote:
> (1) Update Bonobo for each such new state-ful widget type as we think  
> of it.

        Or think of a more generic approach for this ?

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

        This is really bad, bad bad news. Until I have the time to sit
down and come up with a more generic solution for this case, which is not
going to make it for Gnome 1.4 this is staying as it is.
        
        The reason we are not putting state such as hiddenness,
sensitivity and 'state' on the menu item is to preserve cmd / widget
separation. Removing the warnings when people violate cmd / widget
separation may make your particular unusual case slightly easier ( at the
expense of complicating the bonobo-win internals further ). But in the
general case it will allow people to be sloppy and not do the cmd/widget
separation at all.

        We have to get people to use the cmd / widget separation,
otherwise there is no point in having it. Proposal 4 will not help people
do this or understand why at all. It will also have totaly evil
consequences since it will introduce a new kind of item that cannot be 
moved in the hierarchy without screwing up the app using it.

        In the bad old days of the old UI handler you would have had to
create a plurality of items and maintain them individualy, now you have to
have 2 verbs / ids if you want 2 different behaviors, I do not see this as
in any way unreasonable.

        I do like Owen's suggestion of having a state switch on the label
if we need to do that. We could mangle it _label_0 etc. or something which
would sort out the accelerator transferal from the verb to the item.  

> It's not a huge deal; I can live with the (3) that we have now.

        Thanks; I _really_ think that unless people are sheparded to use
cmd / widget properly they will go the quick hack way. Of course it might
be possible to add an

        int bonobo_win_i_know_i_am_doing_something_broken = 0;
   
        into bonobo-win that would kill the warning, but this sucks even
more :-)
        
> 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.
  
        Of course, we also do this in evolution in at least one place.

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

        This is not the case. You can put whatever _label on the toolbar
buttons you provide; all I ask is that you also provide a default _label
on the command so that an editor can have a meaningful default. There is
no warning for setting _label, _tip or pixmaps on individual items.

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

        Sure, and this will give no warning currently, of course if you
want to switch the label you will probably want two verbs:

        <cmd name="ChangeLabelToolbar" _label="hide wdgt"/>
and
        <cmd name="ChangeLabelMenu"    _label="_hide widget"/>

        It would be good if you could add the feature request to the
bonobo bugtracker at bugs.gnome.org as a wishlist item for Gnome 2.0.
        
        Thanks,

                Michael.

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