Community
Participate
Working Groups
There are currently 3 QuickMenuActions in the Eclipse SDK. Since their implementations are already out of sync, I think Platform/UI should provide a reusable API class for this (probably in org.eclipse.ui.actions in the org.eclipse.ui.workbench plug-in).
I think this is fixed (a dup of bug 157072). Please see QuickMenuCreator (in I20060918-0010). Markus, can you check whether this fits our needs?
(In reply to comment #1) > Markus, can you check whether this fits our needs? I'll do it thoroughly as soon as we get a clear sign from Platform/UI that the QuickMenuCreator will not be removed again (see class javadoc). Issues I've already noticed: - computeMenuLocation(..) methods need to be protected, such that clients can override them (see JDTQuickMenuAction, which places the menu at word boundaries) - some fixes in JDT/UI's version are missing in the new API: - StyledText.getLineHeight(int) not used - fix for bug 64855 is not in (leaking menu between invocations)
My concern is that bug 154130 might provide an improved dynamic menu API, and we want to limit use of the legacy API as much as possible. PW
Now that the menu API is taking shape, I think that this can be provided by a handler and a parameterized command. <command name="%command.newQuickMenu.name" description="%command.newQuickMenu.description" categoryId="org.eclipse.ui.category.file" id="org.eclipse.ui.file.newQuickMenu"> </command> would become (we'll come up with a better id): <command categoryId="org.eclipse.ui.category.file" defaultHandler="org.eclipse.ui.internal.handlers.ShowAMenu" description="%command.showAMenu.description" id="org.eclipse.ui.file.showAMenu" name="%command.showAMenu.name"> <commandParameter id="menuLocation" name="%command.showAMenu.menuLocation.name" optional="false"> </commandParameter> </command> And then we update the keybinding: <key commandId="org.eclipse.ui.file.showAMenu" contextId="org.eclipse.ui.contexts.window" schemeId="org.eclipse.ui.defaultAcceleratorConfiguration" sequence="M2+M3+N"> <parameter id="menuLocation" value="menu:new"> </parameter> </key> The handler uses the IMenuService#populateContributionManager(*) to build the menu. If we make the ShowAMenu a public handler, you could override the computeMenuLocation(*) and supply your handler for when your parts are active. PW
Created attachment 56104 [details] Quick New Menu From Handler This is a parameterized quick menu command ... but it is also a hack that includes making the new menu visible to the IMenuService and it uses the QuickMenuCreator code as a base. I just didn't want to lose it over the break. PW
THis would be best as a command
I'll see if I can slip this in 3.4 PW
I support this, +1.
Created attachment 127205 [details] QuickMenuCreator update v01 (In reply to comment #2) > (In reply to comment #1) > I'll do it thoroughly as soon as we get a clear sign from Platform/UI that the > QuickMenuCreator will not be removed again (see class javadoc). It'll stay now :-) > Issues I've already noticed: > - computeMenuLocation(..) methods need to be protected, such that clients can > override them (see JDTQuickMenuAction, which places the menu at word > boundaries) Make them protected. > - some fixes in JDT/UI's version are missing in the new API: > - StyledText.getLineHeight(int) not used > - fix for bug 64855 is not in (leaking menu between invocations) I've added this 2. PW
(In reply to comment #9) > Created an attachment (id=127205) [details] > QuickMenuCreator update v01 > Released to HEAD. I won't pursue the command at the moment (although the internal handler is already in the code). Markus, is the QuickMenuCreator still interesting to you guys? PW
The QuickMenuCreator's Javadoc is wrong: It first tries to open the menu near the current selection. The Javadoc of #createMenu() should tell that it not only creates the context menu, but also opens it. org.eclipse.jdt.internal.ui.actions.QuickMenuAction doesn't have a dispose() method. You should verify on all platforms (esp. GTK and Carbon) that the dispose strategy in HEAD of QuickMenuCreator works fine, i.e. does not keep a Menu between multiple invocations. If it's good, remove the field 'quickMenu' (make it a local variable), and deprecate the 'dispose()' method. > Markus, is the QuickMenuCreator still interesting to you guys? Yes, if you can make the dispose() method obsolete, then we will gladly dump our implementation and use QuickMenuCreator.
Created attachment 127356 [details] QuickMenuCreator update v02 (In reply to comment #11) > The QuickMenuCreator's Javadoc is wrong: Updated javadoc > > org.eclipse.jdt.internal.ui.actions.QuickMenuAction doesn't have a dispose() > method. You should verify on all platforms (esp. GTK and Carbon) that the > dispose strategy in HEAD of QuickMenuCreator works fine, i.e. does not keep a > Menu between multiple invocations. If it's good, remove the field 'quickMenu' > (make it a local variable), and deprecate the 'dispose()' method. This is the dispose strategy that works on win32/gtk/carbon in PopupMenuExtender, it's pretty solid. I've removed the field and tested without it, dispose is called consistently PW
(In reply to comment #12) > Created an attachment (id=127356) [details] > QuickMenuCreator update v02 Released to HEAD >20090303 PW
> > Created an attachment (id=127356) [details] [details] > > QuickMenuCreator update v02 Looks good. I need to use my QuickMenuCreator in a handler at 2 places, so I added the following to my subclass of QuickMenuCreator: public IHandler createHandler() { return new AbstractHandler() { public Object execute(ExecutionEvent event) throws ExecutionException { createMenu(); return null; } }; } If you think that's generally useful, you can also pull this up. Otherwise, I think we're done here. I filed bug 266938 for us to catch up.
I think I'll hold off on the handler method for 3.5. Released to HEAD >20090303 PW
In I20090310-0100 PW
