Bugzilla – Full Text Bug Listing
| Summary: | [launch] If multiple launchers are available but none selected, all launcher's tabs are shown. | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Pawel Piech <pawel.1.piech> | ||||||||
| Component: | Debug | Assignee: | Platform-Debug-Inbox <platform-debug-inbox> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | chanskw, darin.eclipse, miwako.tokugawa | ||||||||
| Version: | 3.5 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | stalebug | ||||||||||
| Attachments: |
|
||||||||||
Created attachment 124104 [details]
Proposed fix.
The fix is fairly simple. BTW, this problem is much more dramatic when there is more than one tab being contributed (unlike in the test example).
I see that there was some discussion about this in the original bug, but there's no record of a positive conclusion being reached: (comment #25 - Samantha) > If the user has selected this new tooling as the default launch delegate to > launch when launching in debug mode, then it makes sense to show the new > "profile" tab in the launch configuration dialog. However, if the user has > selected to use the "Debug Only" launch delegate by default, then having this > new "profile" tab visible in debug mode becomes distracting. I agree :-) (comment #26 - Darin) > I guess the question is, how does the user generally "turn on" "debug & > profile". We envision that the additional "profile" tab would have the option > to turn on profiling. If we remove the tab because profiling is not on, then > the user has to go to preference pages to access the function. This comment suggests that the tabs should be visible even before their delegates are selected. It seems that the test example accomplishes this behavior somehow, though it's not obvious how. (comment #28 - Michael) > 1. I think we should definately support filtering of tab contributions based > what "tooling" the user has expressly selected. If no tooling is selected do we > show all tabs and filter after, or show none and wait till the user selects > some tooling? This is the last positive reference to the issue, and it seems like the feature was implemented to show all. But was this intentional? Created attachment 124478 [details]
Screenshot of multiple tabs in CDT launch config.
BTW, the only reason I'm bringing up this issue is because currently trying to use the multiple launch delegates in CDT is yielding this beauty.
Pawel, would the fix to bug 263307 be a workaround for this? I.e. if a product sets a default launcher then the dialog is properly configured first time it is opened? The other optoin would be to force the user to use choose a launcher before displaying tabs... but that is a bigger change. (In reply to comment #4) > Pawel, would the fix to bug 263307 be a workaround for this? I.e. if a product > sets a default launcher then the dialog is properly configured first time it is > opened? Yeah, I think as far as CDT, fixing bug 263307 would effectively take care of the problem. It would also take care of bug 262850. > The other option would be to force the user to use choose a launcher before > displaying tabs... but that is a bigger change. In the original bug (bug 157059), which I now realize I haven't properly referenced before, there is mention of a tab which appears in place of the optional tabs: (bug 157059 comment #36 - Darin) > When a configuration has more than one launcher available, a tab will be added > to that configuration's tab group - called "Launchers". The tab will have > similar controls to the "Default Launchers" preference page - i.e. lists > labeled "Mode" and "Launcher" allowing the user to override workspace > defaults. There will be a description on the top of the tab describing why the > tab is there, something like - "More than one launcher is available for this > configuration. Select the launcher to use." There should also be a check box > specifying whether to "Use workspace default preferences". The check box should > provide a hyperlink to the "Default Launchers" preference page. > > When no default launcher has been selected by a user, the first time a launch > is performed, they will be prompted to choose a default launcher. I agree though that this is too big a feature to add in 3.5M5, and I also don't have time to work on it in the short term. So I'm fine with dealing with putting this off, I was mostly just trying to understand what was the intended behavior when the original work was completed. *** Bug 262850 has been marked as a duplicate of this bug. *** I no longer think that adding the "launchers" tab is a good idea. This extra UI would only add a new UI to accomplish the same task as the Select Launchers dialog performs today. I will re-open bug 262850 to add an error icon to the launchers link when user has to select one, and I'll re-name this bug back to what I originally opened it for: _Whether tab extensions for all launchers should be shown when a launcher needs to be selected_. I guess this could really be a non-issue if no-one depends on it, but since this is how the dialog works now, changing it could be breaking for somebody out there. To be completely safe, I propose that we add a new "visible" parameter to the launchConfigurationTabs/tab extension point API. The visible parameter could have the following values: - selecting - tab is shown when multiple launchers are available and none yet selected (default) - selected - tab is shown only when its delegate is selected - always - tab is always shown (even when another delegate is selected). Maybe this is an overkill, but it would allow a tab (e.g. "Profile") to always be always visible so that the user could enable profiling in a more friendly UI. Unfortunately, since this would be an API change I guess it's too late to try to fix in in 3.5. (In reply to comment #7) >To be completely safe, I propose that we add a new "visible" > parameter to the launchConfigurationTabs/tab extension point API. The visible > parameter could have the following values: > - selecting - tab is shown when multiple launchers are available and none yet > selected (default) > - selected - tab is shown only when its delegate is selected > - always - tab is always shown (even when another delegate is selected). > Maybe this is an overkill, but it would allow a tab (e.g. "Profile") to always > be always visible so that the user could enable profiling in a more friendly > UI. We could consider some sort of "org.eclipse.core.expression" to tab visibility. This would make the visibility support more extensible, and it could be applied to other aspects of launch. > Unfortunately, since this would be an API change I guess it's too late to try > to fix in in 3.5. Agreed. This will have to be post 3.5. *** Bug 270334 has been marked as a duplicate of this bug. *** 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. If the bug is still relevant, please remove the "stalebug" whiteboard tag. |
Created attachment 124101 [details] Screenshot of multiple tabs. When there are multiple launch delegates registered for a given launch configuration, and there are different tabs which are contributed to the various delegates, all these tabs can appear in the launch configuration dialog at once, if the preferred delegate is not selected yet (see screenshot). This is be confusing because it adds to the UI clutter and it presents the user options he may never care about. From what I can tell this behavior may be intentional, so I'm curious what's the reasoning behind it.