[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Customize buttons that change user's customfileshouldaskforconfirmat

From: Drew Adams
Subject: RE: Customize buttons that change user's customfileshouldaskforconfirmation
Date: Tue, 15 Feb 2005 11:51:25 -0800

    >  - A context-sensitive menu (e.g. mouse-3)

    I any proposal of this kind I think it is important to give the
    possibility to use only the keyboard. Some people do not want
    to use the mouse and some simply can not use it.

That's standard practice: there should be keyboard access to the same
functionality provided by the mouse - in particular, popup menus. I don't
know if that's the case generally with Emacs (I think not), but it is
standard in many apps these days. Some such mechanism is, I think, in fact
required for accessibility standards that apply to disabled people - e.g.
W3C WCAG (Web Content Accessibility Guidelines) Double-A recommendations.

    Why not let the menu-bar menu have entries for working with the "current
    option". The "current option" could be that where the point is. (I
    implemented this kind of functionality in my proposal long ago for a
    redressed Custom GUI.)

That's possible, but I don't think it's desirable.

That is not standard in any UI I'm familiar with. A context-sensitive menu
is usually associated with a mouse button, because you are generally using
the mouse to manipulate things associated with that context. This is the
practice nearly everywhere in MS Windows, for instance. For example, you are
doing things in a dialog box, and you use mouse-3 to open a menu for
manipulating something in the dialog box that is under the mouse pointer.
Users are very used to this behavior.

It is true that Emacs has a notion of point (cursor) that is separate from
the pointer location, so that such an operation as you describe can be
unambiguous without the mouse. Dired, for instance, has a menu-bar menu
(Immediate) that is largely for manipulating an individual file at point.

I nevertheless think that in most contexts (e.g. Customize) the position of
point is not a very useful (because not very obvious) indicator of the
current focus of action.

Also, if the context is to sometimes be a _set_ of options, then point is
not a sufficient context indicator. It is better to make the focus of action
obvious - e.g. using visible marks. Another possibility in this regard is,
as Richard suggested, to list the options to which an action will apply (a
la Dired asking if you want to delete these files).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]