Community
Participate
Working Groups
In 3.2, we built some important infrastructure that will allows us to rationalize our commands and key bindings story. We need to complete this effort, making sure the new story supports all of the existing functionality (e.g action sets), and migrate over to the new support. We also need to make it easier to add and edit key bindings. [UI]
We'll be putting together the plan for this work over the next 6 weeks or so at http://wiki.eclipse.org/index.php/Platform_UI_Command_Design There is background information there now, and it should be more readable by Aug 25. Comments and suggestions can made on the page discussion section (http://wiki.eclipse.org/index.php/Talk:Platform_UI_Command_Design) or in this bug report. PW
Some comments on menu proposal 2. Item #3. 1. We do want a dynamic menu interface, possibly added declaratively as suggested in the RFC. I would start with the assumption that The I*ActionDelegate stuff is not available, then once we have the dynamic menu working the way we want we can see if it makes sense to reuse that interface from the legacy hierarchy. item #4. 2. Since the visibility can be tied to the part, I don't see the need to distinguish between main toolbar actions that "came from" actionSets and ones from editors. 3. We would have to allow them to be placed in the view menu: view:<viewId>/<path> would work 4. context menus are registered with unique IDs by their part, like #TextEditorContext ... or the part ID if the part didn't specify an ID when registering the context menu. It would be sufficient to use - context:<menuId>/<path> A menuId of "any" could add to all context menus. As with editor actions, they actual visibility of contributions would be determined by its <visibleWhen> clause. PW
Thanks Paul. for your #1: For dynamic menu support I think that as long as we allow the definition of the 'IWorkbenchWindowPulldownDelegate2'(?) on -any- menu then anybody adding a sub-menu could make it dynamic. My suspicion for the current restriction is that dragging down through the menu may activate the dynamic sub-menu possibly leading to unwanted plugin loading. My view is that we should -discourage- (but not prevent) dynamic menus; guidance should state that, where possible (i.e. a particular view's context menu), the menu delegate should be implemented in the same plugin as the view. We simply can't avoid pathological cases where some outside contributor adds a dynamic menu to someone else's view that takes forever to figure out how to populate. Note that they can already do this by having really inefficient visibility/enablement calcs... for your #4: While the context menus do have an id I think that it'd be simpler for our users to use the 'viewId' with a modifier for which of the context/chevron menus we're referring to. View id's are already common knowledge to IDE contributors since they're used in many different extension points.
(In reply to comment #3) > Thanks Paul. > > for your #1: > > For dynamic menu support I think that as long as we allow the definition of the > 'IWorkbenchWindowPulldownDelegate2'(?) on -any- menu then anybody adding a > sub-menu could make it dynamic. I'm interested in the dynamic menu API ... I just don't think that we should include anything based off of I*ActionDelegate since it is legacy code and pulls all of those things (run(), selectionChanged()) in with it. > for your #4: > > While the context menus do have an id I think that it'd be simpler for our > users to use the 'viewId' with a modifier for which of the context/chevron > menus we're referring to. View id's are already common knowledge to IDE > contributors since they're used in many different extension points. Except it is possible for any part to contribute multiple context menus. For the most part views don't do that, but they can. Editors based on AbstractTextEditor already contribute 2 (or 3) context menus. PW
(In reply to comment #2) > > Item #3. > > 1. We do want a dynamic menu interface, possibly added declaratively as > suggested in the RFC. I would start with the assumption that The > I*ActionDelegate stuff is not available, then once we have the dynamic menu > working the way we want we can see if it makes sense to reuse that interface > from the legacy hierarchy. I've expanded on what I mean by 1 on the wiki just below Proposal A. PW
Paul, what do we do with the situation where there are more than one context menu, merge them?
(In reply to comment #6) > Paul, what do we do with the situation where there are more than one context > menu, merge them? > No, they remain separate, identified context menus. The easiest example is you can right-click on the java editor ruler to get the second context menu, which contains only stuff to do with breakpoints, bookmarks, tasks, etc, instead of the main context menu which has cut, copy, paste, source, refactor, etc... Later, PW
The proposal misses the support for gestures and mouse buttons which were in the original RFC. Are there plans to support this in 3.3? If not, the envisioned solution should not prevent us from doing this in the future. When crafting the new story it should be done in a way that allows to let the user configure his menu structure via UI (preference). While the user configurability itself is not a must for 3.3, the solution should allow to add it at a later point.
(In reply to comment #8) > The proposal misses the support for gestures and mouse buttons which were in > the original RFC. Are there plans to support this in 3.3? If not, the > envisioned solution should not prevent us from doing this in the future. There are no plans for this in 3.3, but gesture support isn't precluded either. The IBindingService, Binding, and TriggerSequence were written to support other gestures than keybindings (KeyBinding and KeySequence). Although when finally added I'm sure there would be some tweaking necessary :-) > When crafting the new story it should be done in a way that allows to let the > user configure his menu structure via UI (preference). While the user > configurability itself is not a must for 3.3, the solution should allow to add > it at a later point. It is part of the plan to provide a product a way to override visibility of individual menu items, making then visible or not despite their <visibleWhen/> clauses. We see this as being used to remove a lot of unwanted menu items in RCP applications. We could provide a preference page (at a later date) that the product could choose to expose (or not) if they want to allow the user to fiddle with their overrides. PW
I'm not just thinking about visibility: I'd also like to be able to add a command to a menu which isn't out of the box.
(In reply to comment #10) > I'm not just thinking about visibility: I'd also like to be able to add a > command to a menu which isn't out of the box. OK, so all of the components to do that would be available as well. With the proposed menu service, there would be API for adding a menu item to a specific location programmatically, and they would be "first class" menu items (equivalent to those read in from the extensions). But the GUI to allow the users to do that on the fly would be beyond the scope of 3.3, I think. Later, PW
Removing duplicate depends. PW
Currently, I cannot make menu actions visible/invisible using the <visibility> tag, as I can for popup menu actions, when describing them via plugin.xml. Will this new design allow them to be made visible/invisible similar to how it can be done for popup menus? When do you anticipate this support?
(In reply to comment #13) > Will this new design allow them to be made visible/invisible similar to how it > can be done for popup menus? Yes, the <visibility/> or <visibleWhen/> tag should be available for all types of menu contributions (except possibly trim). > When do you anticipate this support? 3.3 ... hopefully we'll have basic support in by M4, but that's still up in the air. PW
As an alternative for now, I'll have to make my sub-menu dynamic and change the menu items based on the nature of my project. Could you provide an example of an action delegate that changes menu items dynamically?
I have started a wiki page listing concrete examples for commands in the SDK with their placement, enablement, and visibility: http://wiki.eclipse.org/index.php/Platform_UI_Commands_and_Placement
Created attachment 52499 [details] mock example code v01
Created attachment 52571 [details] mock example code v02
We have a number of examples that describe the new menu placement and visibility story that would replace org.eclipse.ui.actionSets, org.eclipse.ui.editorActions, org.eclipse.ui.viewActions, and org.eclipse.ui.popupMenus. The wiki describes the new API look and feel. http://wiki.eclipse.org/index.php/Menu_Item_Placement_Examples Please add your comments to the Discussion area on the wiki, or to this bug. I'll try to collect feedback and respond after M3, the week of Nov 6th 2006. PW
Created attachment 52624 [details] mock example code v03
(In reply to comment #19) > org.eclipse.ui.popupMenus. The wiki describes the new API look and feel. > Uh, look and feel is not the correct term in a UI context, sorry about that. I mean the shape and capabilities of using the new API. PW
Hi, you mentioned the actionSets <visibleWhen> support for hiding menu items might be available in M4. I'm being asked for a time-table on that. Would you have a rough estimate of when we might be able to start using a pre-release version of eclipse that supports this? Thanks a lot!
(In reply to comment #22) > Hi, you mentioned the actionSets <visibleWhen> support for hiding menu items > might be available in M4. It'll be the new menu syntax, not actionSets. > I'm being asked for a time-table on that. Would you > have a rough estimate of when we might be able to start using a pre-release > version of eclipse that supports this? Thanks a lot! http://www.eclipse.org/eclipse/development/eclipse_project_plan_3_3.html Friday Dec. 15, 2006 - Milestone 4 (3.3 M4) - stable build We hope to have an API roughed in and actionSet visibility support by then. PW
From the wiki: "an RCP app should be able to hide any menu items that it doesn't want but picked up through the inclusion of a plugin." This is a great idea and something I have often wished for in my RCP apps. Putting it in the product makes a lot of sense too.
Committed in >20061114. Added a new view, "MenuContributionHarness", to org.eclipse.ui.tests. Also updated the test's plugin.xml to contain menu contributions in the new format. This simply provides a shared area in which to test the implementation of the new functionality... The initial version shows how to construct a context menu using the new additions (testing the parsing and rendering). To use install the test suite, start an inner and open the "Menu Test Harness" view. If reads the additions in 'createControl' and 'hookContextMenu' shows how to use the new 'service' to render a context menu. It's a (good) start...
Finally found time to go through all those examples - nice work and right direction! Here are some comments and questions that arose: - performance: I see potential performance penalties for switching from one part to another once we introduce the new 'visibleWhen' and 'activeWhen' syntax and in addition the indirection via the proposed expression templates. There needs to be a mechanism to cache and eventually pre-parse the visible and active states per part type otherwise this can burn us. Part activation performance tests (e.g. org.eclipse.jdt.text.tests.performance.Activate*EditorTest) should be carefully watched while implementing this. We should also port a considerable amount of existing contributions in order to see that the new approach scales well. Since 'enabledWhen' condition will probably be tested more often and might also be more expensive than the 'visibleWhen' and 'activeWhen' conditions, the framework should evaluate the 'enabledWhen' condition at the end even if it appears above the others in the plugin.xml. - I like the proposed expression templates (functions? ;-) because otherwise the contributions get too verbose - the menu definitions will get pretty long even with expression templates. We might think about externalizing them outside the plugin.xml as we do for example with code templates. For example the plugin.xml could specify something like: <extension point="org.eclipse.ui.menus"> <menuCollection location="menu://org.eclipse.ui.views.ProblemView" definition="problemsViewMenu.xml"> </extension> - I don't like the command state, especially when it holds UI information. To me the state on commands that got added during 3.2 rather looks like some internal hacks needed to support the legacy action contribution story. Why would I put the UI state into the command? The command extension point doc irritates me as well: State information shared between all handlers, and potentially persisted between sessions. This is typically something like a check box state or the label of a handler. The state is simply a class that is loaded to look after the state. See the API Information for more details. Two different handlers might have two different UIs with different actual values why would I store that in the command? - editor story regarding editor action bar contributors: now that also the same view can be opened more than once we might also introduce a similar concept for views and unify it with the editor action contributor story. - overriding menus: currently it is suggested to be per active workbench window. While I agree that this grade of flexibility is needed I think the common case will be to remove a menu (item) from the whole product and hence there should be a simple way to do this which doesn't need the active window. Possibly through XML in the product plugin.xml. - examples are fine but we also need documentation that - explains when to use plugin.xml and when to contribute the menu via code - provides guidelines on how to register the initial menu so that it is easy extensible by others (e.g. 'additions') - shows how to extend existing menus - explains how the old and new story play together, e.g. - can I use new syntax to extend old menu? - while clients that extend my menu still work when I convert my menu to use new syntax? - how to migrate old contributions (i.e. migration guide) - the editor's prev/next navigation drop down tool bar buttons would also be an interesting example to test the new APIs and extension points
Thanx for the feedback. (In reply to comment #26) > Finally found time to go through all those examples - nice work and right > direction! Here are some comments and questions that arose: > > - performance: I see potential performance penalties for switching from one > part to another once we introduce the new 'visibleWhen' and 'activeWhen' syntax > and in addition the indirection via the proposed expression templates. There > needs to be a mechanism to cache and eventually pre-parse the visible and > active states per part type otherwise this can burn us. Part activation > performance tests (e.g. > org.eclipse.jdt.text.tests.performance.Activate*EditorTest) should be carefully > watched while implementing this. This is a good idea, and watching the tests will be important. The design of the MenuService is similar to the handler service. There is a menu authority that caches the visibility state of all the menu items. On a part change, the expression is evaluated once and all items that share that expression have their visibility updated accordingly. The same strategy will be employed for declarative enablement as well. > We should also port a considerable amount of > existing contributions in order to see that the new approach scales well. Since > 'enabledWhen' condition will probably be tested more often and might also be > more expensive than the 'visibleWhen' and 'activeWhen' conditions, the > framework should evaluate the 'enabledWhen' condition at the end even if it > appears above the others in the plugin.xml. We'll watch the evaluation order carefully. As part of (early) M5 I hope to have an internal translation engine that will feed org.eclipse.ui.actionSets and org.eclipse.ui.viewActions into the new MenuService. > - I like the proposed expression templates (functions? ;-) because otherwise > the contributions get too verbose While this won't be in M4, we'll definitely have it in M5 ... they'll probably be globally named expressions instead of templates, but that'll still cut down on the verbosity :-) > > - the menu definitions will get pretty long even with expression templates. We > might think about externalizing them outside the plugin.xml as we do for > example with code templates. For example the plugin.xml could specify something > like: > <extension point="org.eclipse.ui.menus"> > <menuCollection > location="menu://org.eclipse.ui.views.ProblemView" > definition="problemsViewMenu.xml"> > </extension> ... for now I think we'll stick with the plugin.xml. In theory the new Menu API will be comparable and only slightly bigger than the extension points used today. > > - I don't like the command state, especially when it holds UI information. To > me the state on commands that got added during 3.2 rather looks like some > internal hacks needed to support the legacy action contribution story. Why > would I put the UI state into the command? The command extension point doc > irritates me as well: > State information shared between all handlers, and potentially persisted > between sessions. This is typically something like a check box state or the > label of a handler. The state is simply a class that is loaded to look after > the state. See the API Information for more details. > Two different handlers might have two different UIs with different actual > values why would I store that in the command? Hahaha ... were you reading my command+handler cheat sheet? A command having state is a useful feature depending on the nature of the command, but yes the states you are referring to (like checkbox state) are a hack to support the legacy contribution story :-) We have some other ideas that might make remove this hack (but still leave state available for commands+handlers). Currently an ExecutionEvent can contain the SWT Event that caused it to fire. I think that an interface that would allow a handler to communicate with its UI could also be passed in the execution event. Just like legacy IActionDelegates receive an IAction that they can update. A less restrictive (but *far* more dangerous) route would be to allow anybody to request the new equivalent of the IAction from the MenuService for a given menu. But that would expose all menu items to all plugins (that could set enablement or change the label or icon as they saw fit). > - overriding menus: currently it is suggested to be per active workbench > window. While I agree that this grade of flexibility is needed I think the > common case will be to remove a menu (item) from the whole product and hence > there should be a simple way to do this which doesn't need the active window. > Possibly through XML in the product plugin.xml. In 3.3 there will be product level customization that uses XSLT to transform incoming plugin.xml ... allow the product to remove and/or modify any incoming extension. The menu override mechanism will be a little more variable (you can change the overrides at runtime). But you are correct, it will be per workbench not per workbench window (although we might allow that flexibility later). > - examples are fine but we also need documentation that Yes, we'll definitely need both examples and a Migration Guide (which is more than one page long :-). M5 will involve a lot of conversion of the code that Platform UI owns (to provide examples). That will also provide the basis for our Migration Guide. The new Menu API is backed by JFace MenuManagers and ToolBarManagers, so the legacy contributions (added through IActionBars or the ApplicationActionBarAdvisor) should continue to work. The new contributions should also play nicely. PW
Created attachment 55371 [details] Patch to add contributions to the main toolbar This patch is of dubious quality. PW
Created attachment 55376 [details] Least change contribution item patch v01 This takes the ActionContributionItem for a walk. PW
Released callback API >20070121 This mechanism allows the caller of a command to provide a callback. The callback is used in the handler to provide feedback to the user. The feedback is specific to what the caller can support. This replaces the use of Command State as a means to provide information to the user and support the "contribution legacy hack" :-) For example, a CommandContributionItem generates a ToolItem or MenuItem, and can support updating such properties as the label, tooltip, image, and potentially the checked state (not currently supported). A keybinding does not currently provide feedback and so does not register a callback. The API also supports a way to find all callbacks currently registered against a specific command. PW
OK, Callback API take 2 Instead of requesting UI element callbacks, the command service will pass each callback to its command's active handler on handler activation and new UI element registration. A refresh can also be requested from the command service for a specific command. org.eclipse.ui.tests.menus.ToggleContextHandler is an example of creating a parameterized toggle context command that updates its toggle button. PW
Bug 53896 says it will be dealt with by this bug, which says it will be fixed for 3.3 (do I read that correctly?) -- is there a migration guide yet? (I see that 3.3 isn't final; in fact I've had trouble getting 3.3Mx to work: see Bug 181787.)
In 3.3 no one will be forced to migrate to the new framework as we haven't deprecated any of the original contribution extension points. For use of the new contributions we've started http://wiki.eclipse.org/Menu_Contributions ... It still needs to be update to match the "final" 3.3 version. PW
Removing plan keyword for bugs that are not linked to the 3.5 (Galileo) plan.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
