Community
Participate
Working Groups
Created attachment 203270 [details] plug-in project that implements the command From bug 219305: Add a command that opens the context menu on the current selection. In Eclipse, some views have actions that are only available as context menu items on certain selections (e.g. Synchronize view's "Mark as Merged", or Package Explorer's "Assign Working Sets..."). These actions are currently very hard to use on the Mac without a mouse, because the OS doesn't offer a way to open a context menu without the mouse. On other platforms, there's Shift+F10, but it wouldn't hurt to also offer the command on those platforms, so that users can rebind it if they want. I'm attaching a plug-in project that implements the requested command.
Created attachment 203319 [details] v2 After sleeping over it, I realized that the initial version contains 2 bugs: - binding was not enabled in dialogs - command only worked for custom context menus, but not for native ones Both are fixed in v2.
Markus, would you just like this included at the org.eclipse.ui level? PW
Yes, I think it would make sense there. But I didn't want to just release it without asking first, and I'm not yet up to speed w.r.t. the 3.x/4.x branches in Git.
Thanx for the contribution, Markus. Released as http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=afca0df60f9dea9c9dd216baf0503f8b7eebcd1a in 4.2 and http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=dbb41d48c47a9c832f4fcc5a9b9a39a0d383dc84 in 3.8. Markus, I noticed that M1+M2+F10 is already set to something else for carbon (and doesn't appear to work correctly on Oleg's Mac) so I left the keybinding as CTRL+SHIFT+F10 PW
Why CTRL+SHIFT+F10 and not just SHIFT+F10?
Sorry, I have to reopen this. It only work on Cocoa by accident, see bug 365473. The ContextMenuHandler should use: mouseEvent.button = 3; (In reply to comment #5) > Why CTRL+SHIFT+F10 and not just SHIFT+F10? Because F10 has traditionally been mapped to the Exposé command that shows all windows of an application, and unfortunately, Shift+F10 is a slower version of that animation. The Apple HIG state that F9-F12 are a reserved keys, but they apparently missed to include Shift+F9-F12. An alternative to binding Ctrl+Shift+F10 on all platforms could be to bind it only for platform="carbon". The we could also use Ctrl+F10 (Mac only).
> bind it only for platform="carbon" I think you want to bind only for platform="cocoa". :) >> Why CTRL+SHIFT+F10 and not just SHIFT+F10? > Because F10 has traditionally been mapped to the Exposé command I would like to try to convince you to use shift+F10 for the default binding. :) Apparently, Exposé was moved to the F3 key around 2004. http://en.wikipedia.org/wiki/Expos%C3%A9_(Mac_OS_X) And it has been replaced in Mac OS X 10.7 (Lion) by Mission Control. I tried Shift+F10 on multiple Mac Lions, and it is currently unbound. MS Office products on the Mac, and NetBeans, both use Shift+F10. On older Macs, Shift+F10 can be used by rebinding "slow motion exposé" to something else, like ctrl+shift+F10. http://hints.macworld.com/article.php?story=20061211122216478 http://wiki.netbeans.org/FaqPopupFromKeyboardOnMac So, for Mac users who are used to Shift+F10 because it's the standard on other platforms, they have already worked around the exposé problem long ago. For Mac newbies, they will probably have a newer Mac and it won't be an issue. McQ, do you have any input on this? Do you run any Mac apps that have Shift+F10 as the key binding for bringing up the context menu? (note that ctrl+space is the key binding for Firefox on Mac, and Safari and Chrome apparently need VoiceOver's ctrl+option+shift+M, according to the dijit.Menu doc: http://dojotoolkit.org/reference-guide/dijit/Menu.html)
FYI, the history of this problem is in bug 219305. Bottom line is that Mac OS never provided a key binding for context menu, so apps choose their own.
(In reply to comment #7) > > bind it only for platform="carbon" > I think you want to bind only for platform="cocoa". :) Nope, the SDK still uses "carbon" everywhere, since carbon bindings are also active for cocoa. See bug 296927, bug 217810, etc. . To keep consistency, we should stay with "carbon" until the "sequenceModifier" extension point has been fully tested and we do the "big sweep". > >> Why CTRL+SHIFT+F10 and not just SHIFT+F10? > > Because F10 has traditionally been mapped to the Exposé command > I would like to try to convince you to use shift+F10 for the default binding. > :) [..] Thanks for the explanations, I'm convinced now that Shift+F10 is the best choice. Summary of necessary changes: - The ContextMenuHandler should use: mouseEvent.button = 3; - Command should be bound to SHIFT+F10, but only for platform="carbon" We can only advertise this in the N&N after SWT bug 365473 has been fixed.
Markus, just a heads up. I am looking at possibly fixing bug 110005, which says that the context menu comes up at the wrong place if the keyboard is used to pop it up. This is cross-platform, and has been a problem since the beginning. At the moment, I can't see a way to fix this on Mac if the context menu comes from display.post() from Eclipse UI. I think I may need to provide the key binding for Mac right down deep in SWT. I haven't decided what the API might be yet. Perhaps add a field to MenuDetect Event that says whether the app should try to provide a focus-based location (would only be true if the event came from the keyboard). SWT controls need to specify a control-specific location, such as below the selected item, or to the right of the selected text. However, it may turn out that you might want to back out your changes if I do put a fix in at a lower level. I haven't done anything yet - just looking. But I wanted to let you know what might happen.
(In reply to comment #9) > - Command should be bound to SHIFT+F10, but only for platform="carbon" > I released this change into 4.2 PW
(In reply to comment #10) That sounds great, thanks. I think the best fix for the Mac would be an API in SWT that allows clients to open the context menu. E.g. Display#post(..) could support the MenuDetectEvent with the new field that tells that the coordinates should come from the focus control. Then we have full flexibility to map this to any shortcut, and the Eclipse platform could ship with Shift+F10 as default on the Mac. I don't think SWT should hardcode a shortcut that is not reserved by Apple. If you do that, then nobody can fix conflicts any more.
> - The ContextMenuHandler should use: mouseEvent.button = 3; Released into R3_development as commit d039ac9b48804eb8e8e5ebfb6ff070cf98c91868 and into master as commit 7ebbcd35a03bfd869f0571389ddd69c021ab1bc6 . Adding bug 110005 as dependency, since a change there could also require an update in ContextMenuHandler. Marking as fixed.
Re: comment 10 and comment 13 FYI, I created bug 374320, rather than reopening this bug, to address getting the new key binding to assist in notifying that the context menu is being requested by the keyboard rather than the mouse, so that controls can position the context menu accordingly. In the new bug, I pasted some (tested) code for ContextMenuHandler. It would be great if this new code could go in soon (right after M6 if possible) so that I can use it when I am testing future changes to controls to continue fixing bug 110005.
