This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
If a Java source file is open in the editor, the mnemonic 'G' for the "Go To" menu does not work, since Alt-G is bound to [Go To] Declaration. Should either choose a different keybinding for this action or a different mnemonic for the menu.
Fixed in main trunk: Checking in Bundle.properties; /cvs/core/src/org/netbeans/core/Bundle.properties,v <-- Bundle.properties new revision: 1.410; previous revision: 1.409 But now mnemonic for GoTo is T, mnemonic for Tools is L, which is not very nice. Maybe some editor shortcuts revision would be better?
I think this is pretty ugly too. Every other app I can think of uses T as the mnemonic for Tools. IMHO the app should never bind Alt-<letter> for any keyboard shortcut - reserve these for mnemonics. But it's a big change for anyone used to using the NB editor's key bindings.
Glad to hear Jesse has the same opinion. Jano, please note this somewhere as it won't get forgotten during our shortcuts rearranging work (which is planned anyway I think?)
I think this fix needs to be reverted or changed. Using L as the mnemonic for Tools just will not stick in my head - it's been three weeks and I still use Alt-T every time and am surprised when the Go To menu is displayed. We should consider just not having *any* mnemonic for the Go To menu. It is hardly necessary - there is only one menu item in the menu that has no accelerator: "Recent Document", whatever that does. So if you are a keyboard user, you just don't invoke this menu very often at all, except a few times when learning how to use the IDE. By contrast, the Tools menu is full of occasionally used actions with no accelerators, so as a KB user this is the one menu which you most frequently invoke via its mnemonic. We should optimize for usage of the Tools menu over Go To.
This is a very good point. I also tend to say that we should rather move back to 'T' for Tools and don't use any mnemonic for Go To. We'll have an a11y problem, but I would rather stick with it than moving away 'T' from Tools, which seems to be a standard mnemonic in other apps. Should I reopen this issue?
Ok, as you wish my lords. Moreover Alt+L clashes with editor actions anyway (back or forward action).
fixed in main trunk: Checking in Bundle.properties; /cvs/core/src/org/netbeans/core/Bundle.properties,v <-- Bundle.properties new revision: 1.414; previous revision: 1.413
Sorry guys, I don't agree with Go To having no mnemonic. Go To / Class.. is the most frequent action I use and I cannot use Alt+Shift+O for it because I have Shift+Alt mapped to switching between keyboard layouts in Gnome. OK, I could change the keyboard switching shortcut to something else, but anyway top level menu item MUST have a mnemonic. This should be P2 IMHO.
Ok, seems like more complicated usability problem, passing directly to Jano.
Re. Shift-Alt switching KB layouts: - Is this a standard shortcut on Gnome when you have >1 KB layout, or your own customization? - Note that Go To can still be posted via Alt-S Left, though of course it is not as nice.
> Is this a standard shortcut on Gnome when you have >1 KB layout, > or your own customization? OK, I created a test user on my machine, logged in as the test user and tried. The default shortcut to switch keyboard layouts in my FC3 gnome (gnome 2.8) is "both alt keys together". Alt+Shift is among the available options you can see in the list in Preferences. > ... Go To can still be posted via Alt-S Left ... First I thought you were joking. :) Well, you are right, it is accessible this way. But who would use it?? I'd rather grab my mouse and click... And have a look at the main menu now. It's so ugly without a mnemonic for Go To. ;)
*** Issue 65710 has been marked as a duplicate of this issue. ***
Sorry, I don't think the main menu without mnemonic is acceptable here. At least from A11Y point of view. What about Alt-O ? I've also moved the issue to the core, because issue reported against ide component are not tracked under NB 5.0 bugcount.
Alt-O is also taken. (Go to Source)
IMO this is a good reason to rethink all shortcuts we have in Netbeans and do necessary changes to have ALT+whatever for accessing menu items. This release will be a major release (5.0), so NOW is the time to do it...
We consulted with HIE guys, on nbusability and conclusion fow now is: Current state will remain in 5.0, issue will be solved by shortcut's general rework, in future release.
Do you really want to leave it without mnemonic for NB 5.0 ? I can't believe it. Common, just think about it, change the name, find another mnemonic. Mnemonics in the main menu are the most important mnemonics in the IDE. How we can ask another developers to fix mnemonics in any dialog, if we agree to leave one of the main menu without it? And what about A11Y? BTW: according to Bug priority guideline, this is P1: http://qa.netbeans.org/processes/bug_priority_guidelines.html If you really want to leave it without mnemonic for release, ask for waiver.
Adding Honza to the loop.
Mariane, which item of the Bug priority guidelines doc makes this to be qualified as P1? I guess there's too few non-conflicting shortcuts to satisfy all the requests so the module developers should seriously start to think about using two-key shortcuts for less commonly used actions (I know it's hard to say which one is less used ;) ) The editor currently uses the following Alt-shortcuts: Alt-G - goto declaration Alt-J - select word Alt-K - jump list back Alt-L - jump list forward Alt-O - open source Alt-U - prefix key for several other actions I'm prepared to make changes to these shortcuts if the UI team agrees on them.
OK, I see what's wrong: One of: accessible description, name, mnemonic is missing for a major component such as a window, dialog box or main menu
Easy and quick solution - renaming the menu to "Navigate To" with ALT+N as the mnemonic. How about that?
Okay we're going to change the "Go To" menu to "Navigate" and use 'N' for mnemonic. This would mean adding "Go to" label into most of the items in Navigate menu. See the full spec in URL field. Marian, please confirm that this solution will satisfy a11y. Patrick or John, please approve or reject this late UI change. Once we have the confirmation from Docs and QE, we should implement it for 5.0.
It looks nice. Probably we can group all Go To menu items under one submenu (see below). But without deep and long discussion, I agreed with proposed solution. ================================ | Navigate | ------------ Go to -> Class... File... Test Recent Document ------------------ Source Declaration Super Implementation Last Edit Location ------------------ Line... ------------ Back Forward ---------------------------- Toggle Bookmark Next Bookmark Previous Bookmark ---------------------------- *Next Method *Previous Method ---------------------------- Next Error Previous Error ---------------------------- Select in Projects Select in Files Select in Favorites =============================
I think it's OK. When would the final decision on this be? We need to update several help pages and the keyboard shortcut guide. Please add it to PromoFLateUIChanges and put me as the docs approver.
I'm waiting for final decision on this as well: should I implement GoTo submenu suggested by mmirilovic or not? jrojcek & mmirilovic please settle on final solution and write final conclusion here, thanks. My UI advice is to go without submenu, as it is one click/key press less for frequently used features, which is IMHO more important then grouping/aesthetics reasons that stands behind GoTo submenu.
OK, after offline discussion FINAL solution is: redesign menu as UI spec in URL field dictates, it means rename to Navigate with proper renaming of items in menu. Submenus will *not* be introduced. fixed in main trunk: Checking in core/src/org/netbeans/core/Bundle.properties; /cvs/core/src/org/netbeans/core/Bundle.properties,v <-- Bundle.properties new revision: 1.416; previous revision: 1.415 done Checking in java/editor/src/org/netbeans/modules/editor/java/Bundle.properties; /cvs/java/editor/src/org/netbeans/modules/editor/java/Bundle.properties,v <-- Bundle.properties new revision: 1.13; previous revision: 1.12 done Checking in openide/actions/src/org/openide/actions/Bundle.properties; /cvs/openide/actions/src/org/openide/actions/Bundle.properties,v <-- Bundle.properties new revision: 1.4; previous revision: 1.3 done Checking in editor/src/org/netbeans/modules/editor/Bundle.properties; /cvs/editor/src/org/netbeans/modules/editor/Bundle.properties,v <-- Bundle.properties new revision: 1.49; previous revision: 1.48 done Checking in junit/src/org/netbeans/modules/junit/Bundle.properties; /cvs/junit/src/org/netbeans/modules/junit/Bundle.properties,v <-- Bundle.properties new revision: 1.68; previous revision: 1.67 done Checking in core/windows/src/org/netbeans/core/windows/actions/Bundle.properties; /cvs/core/windows/src/org/netbeans/core/windows/actions/Bundle.properties,v <-- Bundle.properties new revision: 1.19; previous revision: 1.18 HOWGH. hopefully...
verified in NB5.0(200510251800)