Community
Participate
Working Groups
M4 A typical perspective, e.g. the Java perspective, ends up with many cool items, some of which have only one or two buttons. We need some mechanism to reduce the number of cool items. One idea is to use the "toolbar id" mentioned in the spec for an action set action's toolbarPath. This is currently ignored (must be "Normal"). If we allowed this to refer to a toolbar/cool item, then this would allow multiple action sets to contribute to the same tool item. The default case ("Normal") would still contribute the action to the cool item for the action set (the current behaviour). If the action set's cool item ended up empty, it would not be shown. This approach would have some "interesting" side effects. Adding or removing action sets could affect the number of items in existing cool items, requiring the coolbar to relayout so that all items are shown. This may feel strange, especially if it occurs frequently, e.g. due to action set / part associations. Before we decide on a mechanism, we need to determine how we really want it to look. Erich, how would you group things differently in the Java perspectives if you could do so?
The goal should be to not have singular cool items in the middle, they result in a very noisy appearance. Here is a possible grouping for the Java Perspective (the comments follow below) --- New --- Save Save As Pin Editor (1) Print --- Build Run External Program (2) --- Debug Run --- Search Open Type (3) --- New Java Project New Package New Snippet New Type --- Goto Last Edit (4) Back Forward --- (with active Java Editor) Show Selected Element Only Next Error Previous Error (1) editor pinning is file related and could be in the "file" group (2) external tools are commonly Ant scripts and they are highly related to building. (it would actually be nice to have a build drop down where Ant scripts would be added) (3) Open Type is a search related action (4) These are all navigation related actions. The problem of singular cool items is also obvious in WSAD. See the attached screen shot.
Created attachment 3099 [details] wsad screen shot
I have a solution that allows an action set item to be added to the coolitem for another action set. The solution does not allow an action set to be split into multiple coolitems. Supporting that behavior is more complicated due to the design of the action set code and attempting this change at this point is not a good idea. Outstanding issues with the solution include: - ordering within a coolitem (i.e., when coolitem consists of multiple action sets and action sets deactivated/activated, right now order of items dependent upon when action set created) - how to handle the workbench coolitems (e.g., need to make ids public, would be nice if these could be spec'd, etc.)
*** Bug 24155 has been marked as a duplicate of this bug. ***
Per NE, put Pin Editor with navigation actions. Do not introduce new coolitem for "Build" or "New".
Released code for the feature. In build > 20020218. Still waiting on 31963 to be fixed. This bug only applies when multiple action sets add to the same coolitem. Since the workbench changes for combining coolitems do not include multiple action sets contributing to the same coolitem, the changes for the workbench can be put in. - changed plugin.xml for External Tools. - reassigned [Bug 28741] to Kai to make the plugin.xml change in org.eclipse.ui.workbench.texteditor - need to ping jdt and update the spec on how to combine items
Created attachment 3558 [details] spec on how to specify toolbarpaths for the coolbar
Erich, To add the OpenType action to the toolbar for the search action set, change the toolbarpath to be as follows: toolbarPath="org.eclipse.search.searchActionSet/Search" This will add the OpenType toolitem after the Search toolitem. If you want the two items to be separated by a separator, specify the toolbarpath as follows: toolbarPath="org.eclipse.search.searchActionSet/OpenType" Specifying a new group will create a separator. See the spec for more information.
Note, the first time a workspace is run with this fix the coolbar layouts will be reset. This is because the ids for the workbench toolbars were changed, which will lead to the toolbars being positioned at the end of the coolbar. So the layout will be reset.
Lynne, we don't like the external tools button grouped with the save and print actions. We either want it with the run/debug buttons or the build button. I've played with trying to change the button's position, but I can't quite figure out where you got the current value that you're using as the toolbar path. The string you reference "org.eclipse.ui.workbench.file" doesn't appear in any of the plugin.xml files. Can you please explain where this value comes from? A patch showing how we can move our button to the debug group would also be appreciated if you have time. :)
Jared, The change I released to plugin.xml for external tools does put the toolitem with the build button. The build button appears on the workbench file toolbar (when activated). Anyway, this is where Nick wanted the button. If you want it elsewhere (I think it makes sense to put it with the launch items) you will have to okay it with him. The spec attached to this bug report describes how to specify a toolbarpath. In short, to add your item to the debug launch action set you would define the toolbarpath as follows: org.eclipse.debug.ui.launchActionSet/externalLaunch
Jared, Actually one disadvantage of putting ExternalTools with the Launch action set is that it will not show up on the Resources perspective by default. Is that important?
done for jdt ui patch (the 1 liner :)) submitted for bug 28741
Jared, clarification of my statement above. For the resources perspective the item would appear by itself without the launch items.
I'm OK with the external tools icon going wherever the Debug/External Tools team thinks best. I just want to reduce the number of cool items where possible.
Thanks, Lynne. Specifying the toolbar path as you suggest makes the external tools launch button show up with the run and debug launch buttons. However, this has the side effect of making the Run and Debug buttons show up in the resource perspective.
Jared, I didn't see that behavior. Let me try your scenario out before you change anything. For now and the next build, back out the change I made to the plugin.xml. In your scenario, were you starting with an existing workspace or a new workspace?
Existing workspace. I tried doing "Reset Perspective" but that didn't help.
Unable to reproduce Jared's problem. The Launch actions are considered to be on by default for the perspective for some reason in his workspace. This is why Reset Perspective will not clear them away. You could get this behavior if you used Save Perspective, but he did not do this.
I don't get the problem with a new workspace. I should mention that I use an *old* workspace when selfhosting... A workspace I made a couple months ago using 2.0.
Jared/Darin - fixed the ordering issues with your scenario. Please catch up to most recent org.eclipse.ui.workbench code and try out adding external tools to the launch toolbar. It should always appear at the end now as the spec states.
Created attachment 3611 [details] updated spec
Thanks, Lynne. It seems to work fine now and I haven't had any luck creating reproducible steps to get to the Run and Debug buttons showing up in the resource perspective with a new workspace. I've tried creating new workspaces on Eclipse 2.0 and migrating them, but I'm not seeing the problem again. My only thought is that I may have customized the perspective (I usually customize the "Show View" menu) in some way that caused this side effect. Bug 32419 covers the change in placement of the External Tools launch button.
Closing. Opened [Bug 32489] for order issues when multiple action sets contribute to the same coolitem.
Created attachment 3631 [details] updated spec
Created attachment 3632 [details] updated spec
Since there is no immediate need for beforeGroup specification, removing the capability for now. Updated spec to reflect the current behavior.
Created attachment 3832 [details] spec without beforeGroup explanation
Changed behavior to work like menus when it comes to ordering. Changed spec.
Created attachment 3910 [details] updated spec
