Community
Participate
Working Groups
This came from Dorian Birsan --> birsan@ca.ibm.com There is an issue with the help menu items that is not properly solved in the current action set design. --> the menu items should be dynamically computed, based on the information sets defined by arbitrary plugins. In previous versions we had a code contributor for action sets. Dorian feels that for the special case of the help system it should be ok to define the action sets in the old style, and just add the extra "visible" flag. The only drawback is that the help system plugin will be active on workbench startup, but in my opinion this is not such a bad thing, assuming help is an integral part of the IDE. If we're to stay with the current implementation of action sets, then all the menu items will need to be known in advance and added into a help action set, or each documentation plugin containing an information set would have to define the corresponding help menu (more like what we used to do in the past). Dorian Birsan NOTES:
Consider additional improvements post 2.0
Reopened for investigation
Dorian, I'm trying to understand exactly what the issue(s) you ran into and what workaround you have used. From reading the PR, it seems to say there are independent plugins that want to contribute an action to the same help menu. The list is unknown until Eclipse starts up (i.e. until all the plugin.xml are read in). One workaround which plugins have used in the past is to have each plugin declare the same menu definition in xml and add their actions to it. Now this has a few drawbacks (especially maintenance if you want the menu somewhere else), but it does work. We are looking at being able to "inherit" a menu definition from a prerequisite plugin. That way, the definition is in one plugin and can be changed without affecting the other plugins (as long as the id for the menu definition does not change).
The issue is really about dynamically contributed menu items under Help or under Help -> Help Contents. By dynamic I mean dynamic like in the context menus, where a contributor adds the menu items, because the menu items cannot be statically defined in plugin.xml files. In 1.0 help had the notion of "infoset" (books) and it was desired to have an entry for each book defined as a menu item under Help, or as a menu subitem under Help -> Help Contents (cascading menu). In 2.0, this is still a valid issue, but the workaround was to display a list of all books in the help navigation and have the user select it there. It would still be nice to pick a book right from the Help menu (that's why I guess the menu is called Help; there is actually just one entry, Help Contents, under the Help menu that actually deals with help. Since books are *computed* (not just discovered, but actually assembled from smaller sections), we can not hard code the menu items for each book.
Ok, now I understand the issue better. Assuming no plugins are added/deleted, the menu items for these "books" would remain constant once they have been computed once correct? One idea we are thinking about is allowing a plugin to contribute via code dynamic menu items in a form which the workbench could persist and show the next time without starting the plugin. Lets use the debug plugin for example. Each time a debug session of a java app is started, the debug plugin adds it to the recently run sub-menu. So this menu is dynamic in the sense only the debug plugin knows what the most recently run list is. Now instead of doing that, if the debug plugin would tell the workbench, here is a dynamic action (maybe using some XML form or something) to add to this menu. The workbench adds the menu item and remembers it. When the workbench is shutdown, it saves these dynamic menu item declarations. On start up, it adds these back in the menu. Therefore, now the debug menu does not need to be started to populate this dynamic menu. It looks like this would work for the help plugin. The only issue would be, until the help plugin is started, it would have no way to populate the dynamic menu. That is, workbench starts up, and Help > Help Contents is empty. But if the user looks at the help system (causing the help plugin to startup and populate the dynamic menu), then the menu Help > Help Contents would have items in it all the time (no matter if the help plugin is started up again or not next time eclipse is started). One extra option would be to allow a plugin to flag it wants to startup the first time to populate the dynamic menu and then will not be started automatically next time Eclipse starts up.
Yes, I think the proposed solutions should work well. I'd suggest a little change regarding populating submenus the first time: Take the Help menu for example. Right now, there is a Help Contents action that opens the help browser. If we want to provide a dynamic submenu for help, then the Help Contents action will be replaced by a submenu, where most of the menu items would be contributed dynamic by help. However, the first time the Help Contents submenu opens it will only show the fixed actions (likely the equivalent of the current Help Contents action), and a "down arrow". Clicking on the down arrow, would then load the help plugin, and more actions contributed. After that, persistance and everything else works like you describe. So, the "down arrow" works like a "more..." kind of thing. So, when you first open the Help menu, it looks like: Help Help Contents All Books v After selecting the down arrow (v) or the "All Books" the menu would look like Help Help Contents All Books Workbench User's Guide Platform User's Guide etc.
Reassigning to Platform-UI-Inbox (I left IBM 18 months ago..)
Moving Dougs bugs
Assigning to component owner PW
These will not be worked on. Please re-open if you feel the community should get a crack at them. PW
