Closed Bug 48322 Opened 24 years ago Closed 4 years ago

Missing Keybindings for Sparc keys: Help Stop Again Find Undo Copy Paste Cut

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Sun
All
defect

Tracking

()

RESOLVED WONTFIX

People

(Reporter: timeless, Assigned: timeless)

References

Details

(Keywords: platform-parity)

This bug is split off from bug 13168.
Depends on: 13168
Keywords: pp
No longer depends on: 13168
Accepted. Will re-assign to timeless when he has his CVS account. timeless,
let me know when that is. If you faxed it to leaf at the beginning of the
week, he should have done it by now.
Status: NEW → ASSIGNED
Assignee: rich.burridge → timeless
Status: ASSIGNED → NEW
I have checkin privs and will get an r= and a= for the patch.
Updating QA Contact to pmac@netscape.com
QA Contact: paw → pmac
Mine, copy cut and paste work. Awaiting Sun HCI on others.
Status: NEW → ASSIGNED
Timeless, I've received feedback from the Sun HCI group. I've included it
below. To sum up, we would like the following key bindings:

Open=>*Not Bound*
Front=>*Not Bound*

Props=>{Edit} Preferences   (or *Not Bound* - see comments below).
Undo=>{Edit}Undo
Again=>{Edit}Redo

Stop=>Stop
Find=>Find

Please also make sure the bindings make sense for all Netscape 6 apps.

When you have these bindings worked out, please add an attachment to this bug,
and I'll test it on my SPARC machine (and keyboard). Thanks.

--

Please pass on the following to Josh. These are not just my opinions but 
those of several of the HCI community here at Sun. Thanks for following
the recommendations to maintain consistency.

----

Are these suggested key bindings purely for the Navigator component of 
Netscape, or the whole application? If so, please ensure that the 
bindings make sense for Netscape Mail, Address Book, Composer etc.
 
>> Open=>Open location
>> Front=>*Not Bound*

Open and Front are caught by the window system (iconifying a window 
or deiconifying an iconified window and fronting/backing the selected 
window). So I don't think you can get your hands on these (nor should 
you). 

>> Props=>Context Menu

No. Props does not mean "Context Menu". The Props button should bring 
up a property display of the current selected object. Using it for 
anything else dilutes the user's confidence in its meaning. The best 
approach would be not to bind it. I would definitely not show the 
context menu -- that makes no sense. You could show the Netscape 
preferences window and not be too offbase. If you bind the Props key
to the context menu, against Sun HCI objections, Properties *must* 
be one of the commands in the context menu.

If you need a keyboard way to bring up the contextual menu, both JLF 
and Windows use Shift+F10. I can't find any key combination in either 
Openlook or Motif that supports this activity.

>> Undo=>{Edit}Undo

Fine. 

>> Again=>{Edit}Redo

OK. 

Although, HCI believes that Again should really mean, "Do unto the new 
selection all the actions that I just did to the last selection." This
means "repeat" versus simply redo-ing what you just undid.

The Openlook styleguide says:
 
   Provide the Again command item on the Edit menu to allow users to 
   repeat the last action [onto the newly selected object].  
   
However, precedence seems to have gone the other way. 

Investigating this a little more, we discovered that in Word, Repeat 
shares a command-position with Redo in the Edit menu. That is, after 
an Undo, the command in the Edit menu right under Undo is called Redo.  
It has the accelerator Ctrl-Y.  But after any other operation, the 
command right under Undo is called Repeat. It also has the accelerator 
Ctrl-Y. Redo and Repeat have different graphics. (On the toolbar, 
however, only the Redo graphic appears. When Redo is not relevant, the 
graphic grays out rather than turning into the Repeat graphic.) I think 
MS is correct that Repeat and Redo are mutually exclusive, and this is 
a reasonable way to offer both functions.

Given this, having the Again button perform both Repeat and Redo seems 
acceptable to me. The Again button would perform Repeat if it were *not* 
hit after an Undo. It would perform a Redo if it were hit after an Undo. 
However, if Repeat isn't implemented, having it just do Redo would be 
ok. 

>> Stop=>Stop

Fine.

>> Find=>Find

Fine. 
What about "Props" --> Page Info ?
Blocks: 13168
Depends on: 57261, 57262, 57263
Component: Themes → Keyboard Navigation
Blocks: sunkeymeta
QA Contact: pmac → sairuh
Help:  GDK_Help
Stop:  GDK_F11  (works by mapping to ESC)
Again:   GDK_F12
Props:   GDK_F13
Front, Open: used the the WM
Find:  GDK_F19

Undo:  GDK_F14
Copy: GDK_F16
Paste:  GDK_F18
Cut:   GDK_F20
(copy paste and cut currently works, see bug 11355)
Can we map the special keycodes for different vendor to some same value.

for example:  
Find -->  Ctrl + F
Stop -->  F11  (which is done)
Find and Help are now supported thanks to bug 229438.
QA Contact: bugzilla → keyboard.navigation
Component: Keyboard: Navigation → User events and focus handling

No longer a thing

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.