in the emacs keymap, many alt key combinations are bound to actions. these same
strokes are the conventional keystrokes to enable the menubar.
on windows, the menubar menus can be accessed by pressing and releasing the alt
key, and then pressing the now-highlighted accelerator. this allows for emacs
style bindings by hold-alt-and-press-key, and the menubar by type-alt-type-key,
in short, the best of both worlds.
on linux, pressing the alt key by itself doesn't focus the menubar, making the
emacs keymap almost useless.
an unqualified press of the alt-key needs to activate the file menu in linux as
it does on windows.
This will probably have to be implemented somewhere in core, if possible at all.
Activating the main menu bar by pressing and releasing alt should work
independently on what TopComponent is focused. The problem is not related to
editor nor it is related to Emacs keybinding profile. Generally, any component
that installs key bindings and actions suffers the same problem including
editors and all their keybinding profiles of course.
I tried native Linux applications as Nautilus or Gimp and none of them uses typed Alt to access the menu. Our primary
aim is to feel and behave like native applications, so I would say that current behavior is as designed as desirable.
CCing usability guys to comment just in case I'm wrong.
i've only used Nautilus and Gimp occassionally so i can't say if they're an appropriate comparison. my gut feeling is that they're solving different sorts of
problems than NB. though now that you mention it, i've had this same basic problem with gtk in the past (looked quickly in the mailing list archives, but
don't see the discussion). i believe that openoffice has implemented this functionality (i'm travelling in europe and can't try it here) and that this might be a
closer comparison the the two programs mentioned.
regardless of how other programs behaive, i think there needs to be some easy way to access the menus - there are too many commands to remember the
shortcuts for all of them, and the menus provide a nice heirarchical arrangement. i see F10 mentioned in the 69423 bug. i'll try it when i return home. i use
shift-F10 and am ok with it (though i really wish the menu key had the same effect - my parents' box handles the menu key correctly for some apps, so
this may be a problem with my settings) but it's still not nearly as easy as touching alt or menu.
as a point of comparison, emacs provides M-x and tab completion (and command-appropos)
one other vote for this behavior:
the number of commands available in NB itself is large, and potential plugins make the list huge. for NB to continue to scale, there needs to be a
keyhandling mechanism that is reliable, visual and heirarchical for the seldom used commands to complement the few single-keystroke shortcuts a user
i guess in short, my arguement is that accessibility without useability isn't worth too much
I think I understand and I'm reopening, changing to enhancement and passing to usability guys to have it on their radar.
moving opened issues from TM <= 6.1 to TM=Dev
F10 activates the main menu on Linux.
Please reopen if the issue is still valid, thanks.
f10 activates the file menu on my machine
on a windows machine, pressing and releasing alt focused on the menubar (it might highlight the file menu entry, but doesn't activate it). you could then press f for file, e for edit, n for navigate, ..., h for help to activate the named menu
on linux, pressing f10 then e results in "open project" instead of the edit menu. the only workaround i've found is to use f10 (or an unbound menu accelerator) to activate one of the menus and then use the arrow keys to move to the desired menu
even in the case of an unbound accelerator, pressing and releasing alt and then hitting the accelerator is faster and easier on the fingers than the alt+letter combos
I'm not sure this is feasible, a single press of Alt key is consumed by the OS to display Ubuntu search bar.