Re: ANNOUNCE: Style Guide available for review.

[Kai Wetzel <k wetzel welfen-netz com>]

Robert J. Slover wrote:
> 
> Christopher Blizzard wrote:
> 
> > This is dealt with in the Keyboard Binding Policies.  Also,
> > I don't think that every menu item needs an accelerator.  It
> > can get really confusing for users.

> Maybe not by default...but I hope the capability is there.

Adding accelerator keys for command identifiers which don't
have one by default is a good idea.  It should also be possible
to e.g. add F12 for "file::save" without losing Ctrl-s.

> My favorite Mac Apps are the ones where this is the case.  I can
> work *much* faster navigating by keyboard.  Also, don't forget the
> shortcuts for common GUI operations that aren't necessarily exposed
> via menus.  A typical example would be the 'nudge' feature implemented
> in a lot of drawing packages....I select an object and use the arrow
> keys to nudge it around a point or pica at a time.

This example feature would probably only be provided if the
drawing canvas has input focus in which case the accelerator
key mechanism doesn't have to be used at all.

[...]
> I'd find an application for setting global key bindings useful *if* it
> provided some heirarchical way of doing it...so the common things (Cut,
> Paste, Copy, Save, Quit, etc.) are easily changed, while less common
> ones (Alt-F-S for <F>ont <S>ize in App A) might be overloaded (to be
> Alt-F-S for <F>orward <S>election in App B) just as easily.

Most people will probably use the standard keyboard mnemonics
mechanism, in which case this cannot happen.  Even if this
is a accelerator style keyboard equivalent (e.g. Emacs binding),
a scheme which allows rebinding of any command identifier
either globally (per user) OR on a per-app basis should do the trick.

The only real problem I see is interfaces which contain a
set of command identifiers which is not known in advance and
using accelerator keys.  E.g. in an OpenDoc-like system.

[...]

kai