again, we have to determin if show/hide is a state or action..

>
>> Two reasons against having toggle menu items which came out of that
>> discussion are:
>> - When an item is not checked, nothing indicates that it can be checked.
> ...unless you provide an empty box when it's not checked, like a
> standard checkbox should do. Also the menu text describes the state
> that you're going to have if you click on it.
>
>
> We have two conflicting forces in this case. The first one is the
> "toggle state" problem that I just stated. The other is that menu
> entries should be actions, not show state. Neither of the proposed
> solutions (checkbox, change label) satisfies both requirements.
>
>
>> My opinion is that the current way of showing a toggle action is the
>> best as
>> long as the two problems above exist.
>
> My preferred solution would be to have *both* actions listed, and grey
> out the one that is not applicable. As in:
>
> (when the bar is hidden):
>
> -----------------------------------
>  Show Search Bar
>  .H.i.d.e. .S.e.a.r.c.h. .B.a.r.  <-- disabled
> -----------------------------------
>
> (and when the bar is seen):
>
> -----------------------------------
> .S.h.o.w. .S.e.a.r.c.h. .B.a.r.  <-- disabled
> Hide Search Bar
> -----------------------------------
>
> This way
> 1) the user knows what's going to happen when clicking the menu item,
> 2) the user knows that the other entry is disabled because of the current
> state,
> 3) and you have the extra benefit that the menu items are always the
> same ones (avoiding the uncertainty of a changing interface. Remember
> MS Office disappearing menus?)
> _______________________________________________
> kde-usability mailing list
> kde-usability@kde.org
> https://mail.kde.org/mailman/listinfo/kde-usability
>


_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability