Community
Participate
Working Groups
I find it confusing to the user that the launch shortcuts shown on the "Run >" context menu do not match those that appear in the "Run As" on the toolbar button. One is selection based, where the other is perspective based, which means you get different lists in each perspective. I'd like to see the two lists always match, and preferrably using what is currently in the "Run >" context menu. Since the menu is dynamic, it is "correct" much more often and is based on the selection. The two options can share the selection context, so it should not require additional computation to (e.g.) show the Run As after using the context menu.
Would this mean scrapping the perspective-based idea? This would be good for me, because my perspective uses the run and debug toolbar launch icons, and is not defined in the list of perspectives in the the platform's shortcuts(e.g. Java application, applet, etc). The only way I see I can get the launch shortcuts is to completely redefine and implement them myself just for my perspective, which is bad. Or, am I just missing something?
We do not intend to change this in 3.0. Since contextual launch shortcuts (i.e. context menu in navigator) are optional, the "Run As >" menu in the drop- down provide a way for all shortcuts to be present in the window. Deferred for post 3.0 consideration.
The Run on Server, Debug on Server, Profile on Server shortcuts will not appear in the "Run As >" (or Run toolbar) unless they are specifically included in the current perspective's plugin.xml (regardless of context, such as a JSP file selected in the Navigator). So in some perspectives, the "xxx on Server" shortcuts will not be included in the "Run As > " menu, but will only be available via the "Run>" context menu. So the "Run As >" menu in this scenario, does not actually present all relevant shortcuts. This is a fairly significant usability issue as many users (especially users of the WSSD product) do not use context menus but rather use the main menu (and therefore the Run menu) to run. The user might use the "Run As >" menu and then be unable to "Run on Server". A possible solution would be to truely make the "Run As >" menu display all shortcuts and have it display all shortcuts the Perspective is aware of as well as all context-sensitive shortcuts (for the currently selected object). Is this something that could be done for 3.0?
But.... the whole reason we have the context menu is to present only the run actions that make sense for the selection (to avoid having all possible lanuch config types appear).
I did not mean to suggest the "Run >" context menu include all shortcuts. Rather, I meant to suggest that the "Run as >" under the main "Run" menu (at the top of the window) should include all launch shortcuts, including the ones that are in context for the selection. So the "Run->Run As >" from the main menu would display all shortcuts relevant for the perspective plus all shortcuts relevant to the selection. For example, if a JSP was selected in the Web Perspective, the "Run->Run As >" would display all shortcuts relevant to the Web Perspective (as defined in its plugin.xml) and all shortcuts relevant to the JSP file (that would include the Run on Server, etc. launch shortcuts in the "Run->Run As >" menu). If the user was to use the context menu on the selected JSP file ("Run >" menu) the user would only see the launch shortcuts that make sense for the selection.
I see - are there many use cases where there are contextual launch shortcuts that do not already exist for the perspective?
Hi Darin, Yes, I've seen this several times. A typical case would be in a new perspective that did not exist in the product that the launch shortcut was defined in. For instance, Java launch shortcuts would not appear in any new perspectives in WebSphere Studio, even if the perspective shows Java artifacts or resources.
I'm not certain of all of the cases where contextual launch shortcuts do not already exist for the perspective. However, some examples where it should be possible to perform a launch using the "Run->Run As >"include: 1) Server tools (to run on server from various perspectives) 2) launching XSL Transformations (it should be able to run an XSL Transformation from any perspective where the user can access the XSL resource, such as the Resource Perspective, Java Perspective, or others) 3) launching tests (e.g., Hyades or tests based on Hyades). It should be possible to launch a test both in the Hyades Test Perspective and potentially other Perspectives that may not be aware of Hyades.
Are there plans to re-open this bug for 3.0?
We do not intend to address this for 3.0.
We've had several usability concerns come up over this, from shortcuts not appearing in the right perspectives, items from the Run > menu not appearing here, etc. Given how pervasive this is becoming and the number of people concerned about this issue, I'm raising the priority/severity and reopening. Sorry Darin :)
(adjusted priority. priority field is set by committers.)
Adding e-mail conversations to bug report history, so community may benefit: (Darin Wright) (1) Since "contextual" launch shortcuts are new in 3.0, we must be backwards compatible, and allow launch shorcuts to appear in the "Run As" (top level) menu even when they do not provide context launch information. (That is, we cannot only support contextual launch, since implementors are not required to provide the contextual information). (2) Computing the contextual information takes time (we've had a few complaints about this). Thus displaying in "Run As" (top level) menu is fast (since the information is statically computed), whereas displaying the "Run >" context menu can be sluggish. I believe the only real problem may be that an appropriate shortcut may be missing from the top level (static) menu, in perspectives that the shortcut definition does not know about. (i.e. new perspectives added on top of the shortcut definition). Thus, it has been suggested that we could add an "Other..." menu option to the top level "Run As" menu, that would allow the user to choose from all shortcuts (similar to the "File > New > Other..." option). This would mean that all shortcuts would be available from all perspectives, in the event that a shortcut has not been added to all relevant perspectives. It does not address the issue of making the context "Run" menu and top level "Run As" menu match. However, changing the rules now (i.e. perspective vs. context based filtering in the top level menu), would be a breaking API change (i.e. the contract we presented in 2.1 and 3.0 is perspective based filtering in the top level menu). We want to avoid any API changes.
Reply from Wayne Ho: "Agreed. We were only asking to add to the menu (or even create a new one), not remove. Performance of the dynamic menu is always going to be a concern, but I think you've done a really good job of minimizing this (e.g. via checking whether the plugin is loaded, static info to enable only on certain file types, etc.), and providing very fast support in the basic contributions. If this is a concern, then the offending contributions should change their code to perform simpler checks (possibly at the expense of being enabled too often) instead of reverting back to the static menu. This will break down in products like WSAD or IE. Do we really want a submenu with 20+ items on it, 18 of which don't apply to the selection? I don't think adding the static information in more places is the right way to go. You've come up with a much better and more powerful solution with the dynamic menus - lets make use of it here. How about even adding the Run > menu into the Run menu? It's ugly, but would get us past the current issue."
Darin Wright: "My proposal would be to do the following: combine the "static" with "dynamic" in the top level "Run As >" menu. The "Run As >" menu would be filled as follows: * For any shortcut that has a relevant "perspective attribute", it will be added to the menu (i.e. just as before) * For any shortcut that does not have a relevant "perspective attribute" (i.e. missing, or not the same as current perspective), context information will be used Effectively, this adds any shortcuts that have context information claiming that the current selection is valid for the shortcut. Old shortcuts containing the "old" perspective attributes would remain visible. Note, this means the menu can be large when plugins have not yet been activated (since we do not fully evaluate context conditions when a plug-in is not active). Would this be sufficient/happy?"
Wayne Ho: "Combining "static" with "dynamic" in the top level "Run As >" menu is good and resolves the problem where some relevant shortcuts may not appear on the Run As> menu. So your proposal is an improvement. So the solution will ensure the "Run on Server" (or other relevant shortcut) will be available in the Run pulldown, but we still have the usability issue that the user may encounter a very large Run As> menu. Users of RWD (Web Developers) often make use of the pulldown menus (rather than context menus) and discovering the "Run on Server" shortcut is still a usability problem. Especially considering in most cases the user is only interested in the Run on Server shortcut. The "Run>"context menu does an excellent job in filtering irrelevant shortcuts, and it would be great to leverage this filtering in the Run pulldown as well. I propose that we follow your proposal to combine the "static" and "dynamic" in the top level "Run As >" menu, but consider organizing the menu so that users first see the "dynamic" context-filtered shortcuts, and then see the "static" shortcuts in a additional cascade menu. For example: Run As> Run on Server Other> Java Applet Java Application Java Bean JUnit Test WebSphere v5.0 Application Client WebSphere v5.1 Application Client WebSphere v6.0 Application Client Ideally, "static" and "dynamic" menus would not be duplicated. This proposal would provide the improved usability enhancement of filtering, while still displaying shortcuts added to the perspective (but may not be relevant to the current selection). Thoughts? Comments?
I like the proposal in that the contextual launch options will appear first in the menu, but I have a couple concerns: (1) A shortcut such as "Runtime Workbench" that does not supply context info will never appear in the first cascade, which is important to plug-in developers. It seems bad to hide this as in a second level cascade menu (and might be a usability issue). (2) Deep menus (but, perhaps this is OK since the usability has actually improved to have relevant shortcuts first)
The following technical issues remain: (1) A top-level shortcut is designed to launch a selection or an active editor. Context shortcuts work only with a selection. The issue is, what do we do when an editor is active, and the top level "Run As >" menu is displayed? (2) Top-level shortcuts can also provide "enablement" XML, which we could interpret as context information. For example, the PDE shortcut provides an enablement expression that makes it appear even when the selection is empty.
*** Bug 28885 has been marked as a duplicate of this bug. ***
I have experimented with a the "Run As >" cascade menu, combining the context & static (perspective) entries into a context menu and a "other > " menu. In general it works, but for 3.0.1, it has the following problems: 1) It requires the introduction of a new NLS message "Other". TVT testing & translation has ended today. 2) The menu layouts for 3.0 and 3.0.1 would be different (doesn't seem like a good incremental patch) 3) There are corner cases that need work: a) when there are no applicable context entries, b) when there is one "other" entry, etc. Looking forward to 3.1, I would suggest we just do as the bug report suggests, and make the top level menu the same as the context menu. As well, I would move the "Run..." and "Debug..." actions into the cascasde menu, and do away with the "other >" option. Thus, if there is no appicable context shortcut, "Run..." can be chosen to create a launch config of the appropriate kind. I also suggest this change wait for 3.1, as it is a behavior and UI change.
Thank you for doing the experimentation with the "Run As >" cascade menu. I understand your concerns with the "other >" menu alternative. However, addressing the usability issues related to the bug is very important for the Atlantic timeframe and products such as RWD that will sit on top of 3.0.1. Is it possible to step up to resolving this issue in time for 3.0.1? Keeping in mind your 3 concerns with the "other >" menu alternative, would it be possible to step up to the following alternative? Alternative 2: The "Run As>" menu to be organized so that users first see the "dynamic" context-filtered shortcuts first followed by a separator, and then see the "static" shortcuts below. Launch shortcuts should not be repeated in the static list, if possible. Run As> Run on Server ------------- (separator) Java Applet Java Application Java Bean JUnit Test WebSphere v5.0 Application Client WebSphere v5.1 Application Client WebSphere v6.0 Application Client The above alternative would help "bubble-up" the important context-sensitive / relevant launch shortcuts. It would not require the introduction of a new NLS "other" message. It resolves the problem of the corner cases you discussed. It also removes our concern about the "Run-time Workbench" launch shortcut appearing buried under the "Other>" menu for plug-in developers. With respect to making changes to the menu between 3.0 and 3.0.1 my feeling is this is justified when considering the Atlantic products will be building on top of 3.0.1. If we do not address the issues, we will continue to have a serious usability issue for launching within products such as RWD.
I have experimented with the suggested approach, which works as follows: * Any applicable shortcuts that have context information and *NO* perspective information are placed in the "Run As >" menu * Any shortcuts that have relevant "perspective" information are placed in the "Run As >" cascade (after a separator), irrelevant of context infomation. This approach has the smallest impact on the menu - performance wise and appearance wise. The Eclipse SDK does not appear any different, as the shortcuts provided by the SDK have perspective information. Implementors wishing to take advantage of the "context" support in the top level "Run As >" menu should contribute the shortcut with no perspective infomration, and its context information will be used to determine when it appears in the menu. Does this meet the needs of the products? (i.e. can the shortcuts avoid using perspective attributes - which will override the context information?)
Created attachment 13849 [details] proposed patch to org.eclipse.debug.ui
After more experimentation, we find that the "context sensitive" solution in the top level run menu is not ideal for the following reasons: * items in the menu change order, making the accelerators assocaited with an item (number) dynamic * a seperator appears in the menu, but the user does not understand what the seperator means For this reason, we propose a temporary fix for 3.0.1 that allows the shortcuts to control oder in the Run menu by specifying a "path" attribute in the launch shortcut extension. Shortcuts are grouped by the path attribute, and then sorted alphabetically within each group. The "null" (default) group is sorted last. This ordering will apply to the top level "Run As" menus as well as the context menu.
Created attachment 13912 [details] patch for "path" attribute group & sort
Released to 3.0.1. Do not intend to release to 3.1.
Please verify, Kevin. Changes in LaunchConfigurationManager and LaunchShortcutExtension.
verified
Verified, closing old bug.
I mean it this time. :)
