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