Bug 4322 - Packages view: Comment mnemonic same as for Copy (1GLCAXS)
Summary: Packages view: Comment mnemonic same as for Copy (1GLCAXS)
Status: RESOLVED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 2.0   Edit
Hardware: All Windows 2000
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Kai-Uwe Maetzel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-10 23:09 EDT by Nick Edgar CLA
Modified: 2002-05-02 09:50 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Edgar CLA 2001-10-10 23:09:46 EDT
The Comment and Copy actions share the same mnemonic in the package view's context menu.

NOTES:
Comment 1 Erich Gamma CLA 2001-11-11 05:09:29 EST
where does the Comment action show up in the packages view?

Comment 2 Nick Edgar CLA 2001-11-12 11:36:51 EST
Sorry, I meant the Java editor.
Comment 3 Nick Edgar CLA 2001-11-12 17:16:25 EST
There's also a duplicate for A between &Add and Select &All.
Comment 4 Erich Gamma CLA 2001-11-12 18:14:50 EST
duplicates in menus do no harm, the user can press a letter multiple times and 
will still get to the action.
Comment 5 Nick Edgar CLA 2001-11-12 21:33:54 EST
Yes, this works.  However, for the second occurrence, it changes it from 2 
keypresses (menu key + mnemonic) to 4 for (menu key, mnemonic, mnemonic, Enter).
Also, the platform UI guidelines recommend against duplicates.

Comment 6 Erich Gamma CLA 2001-11-13 03:44:25 EST
agreed on the 4 key strokes, but I don't see how we can enforce uniqueness in 
the general case. Consider editor or view menu contributions from plugins.

>the platform UI guidelines recommend against duplicates
where can I see these guidelines?
Comment 7 Nick Edgar CLA 2001-11-13 09:08:38 EST
We can't guarantee uniqueness in general.  If two plugins contribute to the 
same menu, and there is no dependency between them, they have no way of 
predicting conflicts.

However, we can (and I believe we should) strive to avoid conflicts within the 
plugin itself, and with any prerequisite plugins.
Comment 8 Nick Edgar CLA 2001-11-13 09:10:30 EST
If the problem is that it's hard to come up with decent mnemonics because the 
menu is getting too long, we should consider reorganizing it.
I'm open to any suggested reorganization of the Navigator menu if you want to 
make corresponding changes to the Packages view.
I believe we discussed this briefly when you were here.
Comment 9 Erich Gamma CLA 2001-11-13 09:42:42 EST
Yes I think we have a menu organization issue. I'd like to get feedback from a 
Usability person on what is the best approach. Questions:
- do you show disabled menus
- is the context menu stable
- do we provide use VA/Style fad menus
- is it OK to have submenus in context menus
Comment 10 Nick Edgar CLA 2001-11-13 10:47:34 EST
Kevin, can we get the TO usability lab to address these general usability 
questions?
Comment 11 Adam Kiezun CLA 2002-02-27 06:04:51 EST
still an issue in 20020214
(comment and copy are ok now but
'Add', 'Select All' share a mnemonic
'Undo' - 'Uncomment'
'Paste' - 'Show in Packages View'
'comment' - 'add import')

and 
'surround with try/catch' misses a mnemonic
Comment 12 Kai-Uwe Maetzel CLA 2002-05-02 09:50:13 EDT
Will partially be resoved with the new Java Editor context menu proposal. (E.g. 
uncomment and undo.) However, when having large menus, it is common that 
multiple menu entries use the same mnemonics. In this case, the system offers 
the interaction that repeated use of the mnemonics character toggles between 
the entries. Therefore, the design goal can only be to reduce overlapping 
mnemonics to menu items which are more rarely be used then others.

Close PR as it's part of menu reorg issue which is pursued.