Community
Participate
Working Groups
This is a bid to stop using the accelerator table to help better support multiple stroke key bindings, and to provide consistency across platforms, locales and keyboard layouts. No accelerators would be set on menu items, though potentially backward support for ActionContributionItem might be permitted.
Could you give a bit more context. Which table are you referring?
on native widget systems, menu accelerators are typically managed by a low level system called an 'accelerator table'. what doug means is that we do not want to have to put accelerators on menu items to receive key strokes for key bindings. instead, we now have an alternate, and in theory, superior system at our disposal - we can get key events directly from Display before they get to the widget hierarchy. this functionality will allow key bindings to work properly on shells without menus like dialogs or, in the future, hopefully, undocked modeless tool windows (think photoshop..) also, for those shells that do have menus, we want key bindings to work properly whether or not the command to which the key binding is assigned has a menu item or not. (not every key binding appears on the menu) using the term 'accelerator table' is additionally confusing because it should be possible to create native accelerator tables without requiring a menu, should swt choose to provide us API to do so. this was another potential means to solve the above use cases, but the functionality on Display seems to be working out well. moving key bindings to display and reducing our dependancy on the menu for accelerators has been a major behind the scenes effort over the past few milestones, unfortunately some issues still remain. this pr exists to group those issues that remain.
I have just had a conversation with Michael Van Meekeren (manager for platform-ui), and it looks like we will be doing this for M6. There are a few things to do before this can happen: + Investigate the interaction of OLE editors (and their menus) when the accelerator table is removed. Make sure that the OLE bindings will continue working. + Write a draft email for eclipse-dev. The email will describe a suggested set of key bindings, and recommend that teams migrate to those key bindings. It will also describe expected changes in behaviour. Areas where we are expecting changes in behaviour: + Numeric and punctuation keys will have different behaviour on the Windows platform. "Ctrl+7" used to match "Ctrl+/", and "Ctrl+Shift+7" used to match "Ctrl+Shift+/". Without native accelerators, "Ctrl+7" will not match anything but "Ctrl+7" -- while "Ctrl+Shift+7" will match both "Ctrl+/" and "Ctrl+Shift+/" (Bug 46588). + On GTK, "Ctrl+Shift+[0-9A-F]" will stop working (Bug 46580). + On Mac, function key accelerators will not look quite right (Bug 44003).
I've written a draft email which will go out today. OLE editors continue to have functional key bindings on the Windows platform. Keyboard shortcuts no longer using native accelerators on the menu. Everything is passed through the key binding architecture.
Verified in I200312162000. The native accelerator table is no longer in use.
