From: Rod Armstrong (rod_at_san-jose.tt.slb.com)
Date: Fri Oct 12 2001 - 23:11:15 BST
Russ's proposal seems quite workable, but it is a bit weird. I was wondering
about another issue that other have mentioned: keys for other common
things like expand, compress, and even scroll up or down. Some things
like start and step could be differentiated by case,: e.g S for start and
s for step, but this borders on the two key awkwardness. If we stuck
to lowercase, perhaps the key letter in the button label could be
underlined. Try Ups*UnderlineVars: on to see the effect on variable
names.
A possible mnemonic device would be to add text in the mousehole, so
if the cursor is over the Next button for instance, it would show
_ _ _
select || || ||
(n) || || ||
|| || ||
- - -
I think it would be nice visual feedback to see the button pressed
when accelerators are used. If we went for the concept of screen regions
taking focus, then it would mesh with the current mouse cursor scheme:
if the cursor is a vertical bar, it is over a region that can accept text input,
otherwise it is over a button or scrollbar area (the filename box is one small
exception).
One idea is to add a toggle item to the windows menu that would switch
keyboard focus on or off to match the cursor - when the mouse cusor is a
vertical bar, keyboard input would be in the typing line (default), or in
the display or output windows. When the mouse cusor is the cross, scroll
or pan icon, it would be in key driven mode.
Rod
This archive was generated by hypermail 2.1.4 : Wed Feb 13 2002 - 21:58:24 GMT