Malte S. Stretz
msquadrat.nospamplease at gmx.net
Tue May 18 20:15:43 BST 2004
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?
> > 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
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
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
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
Show Color Picker
Hide Some Other Stuff
Show Text Format
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 :)
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
More information about the kde-core-devel