Re: Requiring state to be shared in verb is not always correct
- From: "John Sullivan" <sullivan eazel com>
- To: Michael Meeks <mmeeks gnu org>, Michael Meeks <michael helixcode com>, Darin Adler <darin eazel com>, Owen Taylor <otaylor redhat com>
- Cc: <gnome-components-list gnome org>
- Subject: Re: Requiring state to be shared in verb is not always correct
- Date: Tue, 17 Oct 2000 16:35:40 -0700
on 10/17/00 3:07 PM, Michael Meeks at michael helixcode com wrote:
>
> 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.
I agree that if we simply removed the warnings, people would tend to make
fragile code, and that would be bad. It's probably possible to design an API
that solves all these issues, but starting with the current one it isn't a
simple change, and is probably not worth considering further at this time.
> 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.
I think I was unclear. I wasn't arguing that Bonobo required that a menu
item and tool bar button that do the same thing must use the same basic UI,
just that it would be wrong to do force this. This was in response to Owen
saying something that could be interpreted as suggesting that the best UI
solution would always be to have the menu item and tool bar for a given
function behave just the same way (both switch labels, or both be toggle
items, or whatever).
>> 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"/>
Right, and this is good. Currently Nautilus does not define commands in xml
for all its verbs, only for the ones that are actually shared by multiple
widgets. I guess we should change this to make potential future editors
happy.
> 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.
I will do so if I can figure out exactly what it is I want. : )
John
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]