kdemultimedia (setCheckedState)

[Malte S. Stretz]

Hi,

some comments from a user here, including a real-life experience with such 
kind of menu "actions" (see below).

Actually, why is stuff like this always discussed on core-devel where nobody 
except the core hacker can raise their voice? 

Oh, and what does Aaron say about this? ;-)

On Tuesday 18 May 2004 12:13 CET Scott Wheeler wrote:
> On Tuesday 18 May 2004 11:49, David Faure wrote:
> > On Tuesday 18 May 2004 11:43, Scott Wheeler wrote:
> > > And a toolbar being visible / not visible is not a state?  Sorry, but
> > > I don't see a fundamental difference.  If you were to put that same
> > > action in a dialog you would do it with a checkbox, not a button that
> > > changed its text, no?

ACK

> > Exactly. Which proves that checkboxes and menuitems *are* different
> > things.
> >
> > File / New is not a state ("this is a new file"), it's an action
> > ("create a new file").
>
> Sure.  There's a long list of things which are not states.  Something
> being visible or not is not in that list.  ;-)
>
>[...]
> > It's not a separate issue. The above leads to "two kinds of menu items:
> > those that represent a state and those that offer an action". The whole
> > reason why it's confusing _is_ the existence of two kinds. 

But there *are* two kinds of menu items, just like for other widgets: The 
states and the actions. There's even one more which is not yet looked at 
all: The options.

What do youn want to do about menus like KMail's "View->Attachments"? Or 
even in the composer "Options->Set Encoding->..."? Ok, you could argument 
that "Set Encoding" is an action and the submenu are the... options for the 
action?

Actually, the whole "Options" menu in KMail is a good example as all menu 
items in there are options (I guess that's why the menu is called 
"Options"). Do you want to rename the whole menu to "Set Options"?

> > Changing the 
> > way they look doesn't eliminate the fundamental problem. By changing
> > the text, we can unify all this and have only one kind of menu item,
> > which is much less confusing.

You can't get rid of one essential GUI metapher by just renaming a few menu 
items :)

And another point: The "Show" you don't like doesn't have to be an action 
which ends after you clicked on the menu item. If your mother tells you 
"show me your hands", she doesn't want to see them for a glimpse but wants 
to inspect them so she can see if they are clean or something. Have you 
ever tried in such a case to use "show" in the way you see it? :) So "show" 
can also be a state, the application is "showing" the toolbars, until you 
tell it otherwise -- not via "hide" but "don't show anymore".

> Well, we currently have 18 KAction subclasses in kdelibs.  We have
> actions that represent state, selection, actions, widgets, etc.  While it
> might be interesting to consolidate everything to a "pure" action based
> organization, In the menu-bar case this would mean getting rid of state
> and selection.  I don't think that's what we're really headed for and I
> think would have a lot of practical limitations.
>
> And really this is still another distinct type of action -- it's now "an
> action item that changes its function every time you click it" which I
> think is hardly less confusing.

Ok, here's now "My Experience With Menus Like This (And Why I Hate Them)":

Have you ever used Adobe products like Photoshop? Their interfaces aren't 
the worst. If you roughly know where everything is, you'll always find it 
again quickly.

But apps like Photoshop have loads of palettes, floating toolboxes or 
whatever you call them. Often you need one of them just shortly and after 
you used it you click it away. That's a quick action. But getting it back 
isn't that quick. Why? Because Adobe uses those morphing menu items for 
options. I can't recall what the exact menu names are, but if you need one 
of those toolboxes back, you go to some menu like "View->Toolboxes->". And 
there opens a BIG submenu which looks like
  Hide Toolbox
  Hide Layers
  Show History
  Show Color Picker
  Hide Some Other Stuff
  Show Text Format
  Show Exporter
  Hide This And That
  Hide Yet Another One
  Show That Other One
  Hide Something Else
  Hide You Know What

With fixed fonts and in English its relatively easy to spot, but trust me, 
if you quickly want to choose something from that menu, its a nightmare. In 
Paint Shop Pro, which used checkboxes instead of "actions" it was way 
easier to find stuff in the menus.

Microsoft once even went that far and put input boxes in some menus (to 
configure toolbars in Office). While that looked weird on the first glance, 
once you became used to it, it was very useful. While ther "feature" with 
those ever changing menus is once of the most horrid things ever invented. 
(If they want to have a Software Patent on those menus, I won't stop them.)

The reason why the latter type of menus and those "actions" you proposed are 
confusing is exactly what Scott wanted to point out (though his example was 
flawed): After some time you roughly "know" where the menu items are. You 
don't read the texts anymore but just look for font pattern you're familiar 
with. This is shot down by menus which always switch from "Show" to "Hide" 
or from "Start" to "Stop".

> (And I promise I'll shut up for a while and see if others have thoughts
> on this.  :-) )

Hope I worded it so my (our) point gets bit clearer :)

Cheers,
Malte
-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>