[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-look
Subject:    Re: Menu Questions
From:       "Tom Hoferek" <tomh () corel ! com>
Date:       2000-05-31 19:12:53
[Download RAW message or body]

Steven D'Aprano wrote:

> Apple's stubborn refusal to use a multi-button mouse means that they
> had to come up with a solution to this problem. To access "contextual
> menus", as they call them, the user holds the control key and clicks.
> (Recall that the Mac has a special Command key for performing command
> keyboard shortcuts.)

This is a good point to bring up for those who aren't aware of it. My concern however
is keyboard access to pop-up menus. As far as I know it doesn't exist because you need
the mouse to point to an area where you wish to invoke a pop-up menu. Sure you can
perform a RMB or Command+LMB or "Menu Button"+LMB to invoke a pop-up menu for the
toolbar, but how would you do it if you aren't using a mouse? You can't (as far as I
know). Sure, some pop-up menus may be available by keyboard (Windows has some
guidelines for this, but only for certain pop-up menus), but right now there is no way
to get all the different pop-up menus in a linux app to come up using the keyboard.
This is one of the reasons why, as you correctly state, all commands must be available
on the main menu.

> > Exceptions may include actions that require the user to have a second mouse
> > button
>
> No feature should arbitrarily require a particular input device. The
> second mouse button is a *convenience* for the user, not a
> requirement.

I agree with you here as well about the second mouse button being a convenience. My
statement about an action that requires a second mouse button is in reference to
allowing the user hide the menubar as described in the KDE style Guide. If the only way
to get the menubar back is through a pop-up menu, then that implies that the user must
have a second mouse button or at least a mouse that can be used with a key combination
to invoke a pop-up menu. If the user does not have a mouse, then they cannot get the
menubar back once it is hidden. For that reason I was suggesting that the option to
hide the menubar should not be in the main menu. That way only people using 'pointing'
devices could hide the menubar and get it back. Those users that use the keyboard only
would be safe from crippling their interface. Having this exception is one solution
(although I concede it goes against the principle of making all commands available in
the menubar). Another solution is to somehow provide keyboard access to the command
that restores the menubar when there is no menubar in sight. I question whether or not
we can come up with a logical, intuitive way to do this that is based on precedents or
user expectations. A third solution is to drop the idea of allowing users to hide the
menu bar. I would have no problem with this. Whatever is decided, the KDE Style Guide
should be revised when it comes to hiding the menubar because as it is now, the
documented implementation would not provide a fully keyboard accessible interface.

> (Obviously some features have certain hardware requirements by their
> nature. Just try doing photo retouching without a mouse or trackball
> :-)

These are the other types of exceptions I was getting at. You don't need commands like
Select Rectangle Tool, or Draw Horizontal Line in the menu when the application
requires a device of some sort to choose and use the applications tools in the first
place.

Cheers,

Tom

[prev in list] [next in list] [prev in thread] [next in thread]