Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 43804

Summary:	[KeyBindings] Entering key sequence appends to previous by default
Product:	[Eclipse Project] Platform	Reporter:	Nick Edgar <n.a.edgar>
Component:	UI	Assignee:	Douglas Pollock <douglas.pollock>
Status:	VERIFIED FIXED	QA Contact:
Severity:	normal
Priority:	P1	Keywords:	usability
Version:	3.0
Target Milestone:	3.0 M5
Hardware:	PC
OS:	Windows XP
Whiteboard:
Bug Depends on:	43657
Bug Blocks:

Description Nick Edgar

2003-09-27 22:22:22 EDT

build I20030917 + latest from head for UI

- In Keys pref page, select a command with an existing binding, e.g. File > 
Close.
- Select one of the assignments, e.g. Ctrl+F4.  It fills in the key sequence 
field.
- Give focus to the key sequence field, either by tabbing or by clicking with 
the mouse.
- Type a new key binding, e.g. Ctrl+W.
- It appends the new key to the old one, rather than replacing it, e.g. 
Ctrl+F4 Ctrl+W.

It is far more common to associate single key sequences to commands than multi 
key sequences.
When the key sequence field is given focus, it should assume that any key 
entered is to replace the old binding, not to be appended to it.
This should be indicated by automatically selecting the whole existing key 
binding (e.g. as is done in the Address field of a web browser).
Only if the user enters two keys (or key combinations) after the field is 
given focus should it accept a multi key sequence.

Comment 1 Douglas Pollock

2003-10-01 11:37:30 EDT

Um.  I don't think this is "Major", but it can be irritating.  I'll get a 
patch together (as described in the following) for M4.

The problem is more easily fixed by getting the preference page itself to not 
set the key sequence entry widget value when a command is selected.  The 
command is already visible in the table, there is no point putting it into the 
entry widget as well.

For a more sophisticated approach to selection and so forth, please see Bug 
43657.

Comment 2 Nick Edgar

2003-10-02 10:00:02 EDT

I marked it as major because, in my view, it was a definite usability problem 
encountered in the typical use case.

Comment 3 Douglas Pollock

2003-10-02 12:48:40 EDT

I guess I moved it to minor because an "easy workaround is present".  :)  Bumped
it to P1 though.

Unfortunately, I've puzzled over this for a while, and it doesn't look like
there's any easy way to get this done on time.  Any change I make seems to make
the GUI more difficult to use, rather than easier.  I think this should probably
be lumped in with Bug 43506.

Changing KeySequenceText to allow type-over on selections is too risky to pull
off in the next day and a half.  See Bug 43657.

The problems I'm having are tied into the fact that everything is currently
funnelled through a monolithic update() method, which requires that everything
stay in lock step.  That, and the Add/Remove/Restore buttons are meant to apply
to the whole preference page.  By breaking apart the semantics of the two panels
(sequence and command), it the work those buttons are supposed to do.

If there is a quick fix here, only Chris will be able to find it for M4. 
Punting back to Chris.

Comment 4 Chris McLaren

2003-10-07 12:57:14 EDT

i read comment #3 carefully enough i think, but i don't think this has to do 
with the operation of keys preference page. it could be fixed with a number of 
changes to the keys preference page - looking at different UI for assigning 
keys (bug 43506) - not just looking at the update method. one option, for 
instance, would be to popup the key entry widget in a dialog whenever you want 
to assign a key binding. then it always comes up empty. 

possible future changes to the preference page aside, that is really a red-
herring. this bug is very closely related to bug 43657, and we should try to 
fix the key entry widget for M5.

there is no fix possible for M4. 

upgrading to normal, downgrading to M5, downgrading priority to P3 until we 
properly prioritize M5 bugs, assigning to doug.

Comment 5 Douglas Pollock

2003-11-04 10:13:05 EST

This is available as a branch of KeySequenceText.  The branch is tagged as
"Bug43657".  Please provide feedback.  Thanks.

Comment 6 Douglas Pollock

2003-11-06 14:38:10 EST

There are still focus issues outstanding, but they are related to how SWT is
handling focus and selection.  Bug 46059 covers these problems.  However, using
tab traversal will correctly select all the text.  I'm closing this bug.  The
rest of the problems should be handled by a fix to Bug 46059.

Comment 7 Douglas Pollock

2003-11-20 10:37:17 EST

This bug has been verified to work on I200311192030.  It only works for tab 
traversal (not for mouse traversal), for reasons outlined in Bug 46059 (SWT).