Bugzilla – Full Text Bug Listing
| Summary: | [debug view][menu] support for top level debug toolbar | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Franz Wong <franzwong> |
| Component: | Debug | Assignee: | Pawel Piech <pawel.1.piech> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | curtis.windatt.public, dalexiev, daniel_megert, darin.eclipse, eostroukhov, g.watson, marc.khouzam, Michael_Rennie, mober.at+eclipse, pawel.1.piech, pchuong, pwebster, Randy.Rohrbach, remy.suen, swanj, WilliamRSwanson |
| Version: | 3.5 | Flags: | Michael_Rennie:
review+
|
| Target Milestone: | 3.8 M3 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 359151 | ||
| Bug Blocks: | 264485, 372032 | ||
| Attachments: | |||
|
Description
Franz Wong
Funny enough, I tend to think there's already way too much in Debug view toolbar. One way to handle this would be to add a Debug top-level toolbar, which I've proposed to enable Debug view-less debugging, and put all the debug icons there. With the new toolbar configurability feature (bug 182714), users could prune the actions they don't want. P.S. Why is the version set to 4.0? (In reply to comment #1) > Funny enough, I tend to think there's already way too much in Debug view > toolbar. I would agree with that. For run to line I use the keyboard shortcut or hyperlink debugging. It isn't as helpful to have an action for run to line in the debug view because you would have to have a stack frame selected, move to the editor to select a line, then move back to the debug view to hit the action. > P.S. Why is the version set to 4.0? > See bug 243417, bugzilla defaults to the highest version available. (In reply to comment #1) > Funny enough, I tend to think there's already way too much in Debug view > toolbar. One way to handle this would be to add a Debug top-level toolbar, > which I've proposed to enable Debug view-less debugging, and put all the debug > icons there. With the new toolbar configurability feature (bug 182714), users > could prune the actions they don't want. As a stupid user like me, the debug view ""implicitly"" tells me that it provides all the available "stepping". Until yesterday, I looked at the menu and discovered the "run to line" feature. I agree that if a debug toolbar exists, that would be better. > > P.S. Why is the version set to 4.0? > I just selected the latest. Mine should be 3.4.1. Created attachment 156298 [details]
Implementation of Debug Toolbar.
Maybe this is the release when we will address the Debug View toolbar clutter:
This patch adds a new "Debug Toolbar" action set with run control actions in the top level toolbar. It also adds logic to the Debug view to hide the corresponding toolbar actions from the view when the action set is active.
Our users have complained about the odd lack of run control actions in the top level toolbar from the start. Also, recent upgrades to the menu framework enabled the users and products to show or hide individual icons in the top-level toolbar. This makes the use of top-level toolbar in products much more appealing.
My only concern is that products which currently contribute actions to the Debug view toolbar will need to adjust, but they will not be able to reproduce the dynamic Debug view toolbar behavior very easily.
Darin, do you think there would be any objections to this change from the UI team? Hmm, I just noticed a side effect: whenever any modal dialog is opened, the run control buttons are added to the Debug view, they are then removed when the dialog is closed. Created attachment 156299 [details]
Updated implementation.
I updated the implementation to avoid flickering when model dialogs are opened.
Are users intended to enable/turn on the debug toolbar themselves? (That's what I had to do to get it to display). However, once it was displayed, the key bindings for step actions no longer worked. It was also confusing that I had to enable the command group, rather than the toolbar. When I hid the toolbar, the debug view actions did not return until I disabled the associated command group. When I disabled the toobar/command group, key bininding worked again. I guess I don't see a large win in terms of screen realestate, since the debug toolbar space is used up (empty or with buttons) either way - and you still have to have the debug view open to debug. (In reply to comment #8) > Are users intended to enable/turn on the debug toolbar themselves? (That's what > I had to do to get it to display). Yes, or at the product level with a preference customization. This would keep it out of most user's way... for better or worse. > However, once it was displayed, the key > bindings for step actions no longer worked. I hadn't noticed that, I'll have to check. > It was also confusing that I had to > enable the command group, rather than the toolbar. When I hid the toolbar, the > debug view actions did not return until I disabled the associated command > group. Yes, the disabling of icons in the DV is on per action set level, so it doesn't recognize when individual actions are hidden. IMO, this is not necessarily bad, as some users may want to have some unused actions hidden completely (e.g. step filters). But I agree that this is confusing. > > When I disabled the toobar/command group, key bininding worked again. I guess I > don't see a large win in terms of screen realestate, since the debug toolbar > space is used up (empty or with buttons) either way - and you still have to > have the debug view open to debug. I got motivated to look at this again because I've been involved lately in creating a version of our product dedicated for the task of debugging. One of the very common complaints about our IDE (and Eclipse) is that the number of icons and menus are very overwhelming to new users and even for experienced users what's not used is simply cutter. To address this complaint I've streamlined the IDE UI as much as I could. I've been very happy with the ability to customize the menus and toolbars which has helped greatly to streamline the product. However, the view toolbars especially in DV) seem exceptionally cluttered. So that's the background. I agree that the change in toolbar location would probably be jarring to users and the option to do so confusing. I suppose I should put this request to rest and hope that someday Workbench will let us customize view menus/toolbars in the way that it lets us customize the top level ones. *** Bug 332784 has been marked as a duplicate of this bug. *** Created attachment 185360 [details]
patch that handles command framework contribution (used as basis for current active patch)
Hi Pawel, I wasn't able to try out your patch, I am getting compile errors in LaunchView.java.
For the actions, I think it would be valuable to have a set predefined command (separator) using the new command framework, so that other command handler can contribute to the debug toolbar action set.
I also worked on a patch such that command framework can contribute to the legacy action set.
(In reply to comment #11) Thank you Patrick. I like the top level toolbar very much. I think the next step is to deal with the backward compatibility problem. As you heard in the multi-core call, many vendors out there are concerned about overcrowding the top level toolbar, and many users will be frustrated about missing icons in the regular toolbar. My attempt at solving this problem (in this bug) turned out to be too complicated so it created some bugs (see comment #8). As a simpler alternative I suggest: 1) Create a preference accessible from the Debug view, whether to add the run control actions to DV toolbar. 2) Hide the run control toolbar buttons from the default layout in Debug perspective. You can do this with a customization to the plugin_customization.ini for the org.eclipse.ide product with a following entry: org.eclipse.ui.workbench/org.eclipse.debug.ui.DebugPerspective_persp=\ <?xml version\="1.0" encoding\="UTF-8"?>\ <perspective editorAreaTrimState\="2" editorAreaVisible\="1" fixed\="0" version\="0.016">\ <descriptor class\="org.eclipse.debug.internal.ui.DebugPerspectiveFactory" id\="org.eclipse.debug.ui.DebugPerspective" label\="Debug"/>\ <hide_toolbar_item_id id\="(action ID)"/>\ ... To get the exact syntax, customize a the perspective, save it, then export preferences. I'm not sure if this would be acceptable in a product. But we can try, then take screenshots and pass this around to Platform UI gurus for comments. (In reply to comment #12) This makes sense. I am not sure if you are going to implement these two issues? Otherwise, I'll try to take a look at it tomorrow if I get a chance. FYI, I'm trying to figure out how to angle this feature. Either as: 1. UI layout option that a user could choose. 2. A product-level customization option. I think the obvious option: a simple move of the debug action from the Debug view to the main toolbar is out of the question as it would upset too many users. I thinking having #2 is something that I would like to see it get done. Product can customize whether the toolbar exist in the workbench and/or Debug view. I would also like #1 as well, but this is a lower priority for me. If we want this to happen for 3.7, I guess this should be done before M6. Right? Why don't you provide an action set that's off by default (see e.g. 'Java Editor Presentation')? Users could then go and enable the action set and also configure the contents of the action set itself. I think products could enable it if desired (not 100% sure on that one). (In reply to comment #16) > Why don't you provide an action set that's off by default (see e.g. 'Java > Editor Presentation')? Users could then go and enable the action set and also > configure the contents of the action set itself. I think products could enable > it if desired (not 100% sure on that one). Yes, products could add the action set with a perspectiveExtension. There's two parts to the feature. a) Add the debug toolbar in main toolbar area. b) Remove the duplicated actions from the debug view toolbar. For part a), adding a separate action set is easy enough. For part b), what I tried implementing in my patch from a year ago was to automatically hide the debug actions from Debug view when the toolbar action set is on. Unfortunately, using the action set in this context is problematic as Darin pointed out in comment #8. One alternative I could explore is to create a hidden preference to show/hide these actions in the debug view. This preference could also be configured at the product level. (In reply to comment #17) > For part b), what I > tried implementing in my patch from a year ago was to automatically hide the > debug actions from Debug view when the toolbar action set is on. I don't think this makes sense and would be unexpected UI inside the SDK. I would expect that the tool bar actions are used in a mode that you outlined in comment 1, i.e. "Debug view-less debugging" and hence the Debug view is closed. If a user opens the Debug view, then the actions should be as close to the view as possible. > Unfortunately, using the action set in this context is problematic as Darin > pointed out in comment #8. Which part of it? The key binding one? That can be fixed. I have a suggestion how to hide the actions in the debug view instead of removing it from the toolbar. One can set an override to the toolbar manager to control the visibility of the IContributionItem, and the visibility can depends on a property or preference or actionSet. Although this method works, but there is no public API in the IToolbarManager interface to set the overrides. With this approach, I can still perform the action when it is hidden. Is this something worth the effort to prototype? I can provide a patch to see how it work. Can someone first provide some user scenarios where it makes sense to show the Debug view but no view toolbar? there are at least two scenarios that I know of on top of my head. - Our customers have been asking to not have the Debug view open and be able to step. Currently, you can't step without the debug view open. However, they can workaround this by putting the Debug view to the back of a group or set as a fastview. - For CDT multi-core group, we would like to introduce a graphical debug view. And would like to have common debug toolbar at the main window. Both of these scenarios should be able to control the visibility of the toolbars by the vendor through branding or other mechanism. (In reply to comment #21) > - For CDT multi-core group, we would like to introduce a graphical debug view. > And would like to have common debug toolbar at the main window. This is the case I was also thinking of to answer Dani's question. In this scenario the user may still want to use the Debug view, but interchangeably with a graphical view. So having the debug actions in both the Debug view and the top toolbar would be rather silly. BTW, the PTP project already has a graphical version of the Debug view, where they clone the debug actions. I'm not sure if they considered making a request for a top level toolbar though. My question was: "Can someone first provide some user scenarios where it makes sense to show the Debug view but no view toolbar?" (In reply to comment #21) > there are at least two scenarios that I know of on top of my head. > > - Our customers have been asking to not have the Debug view open If the view is not open then there's no need to hide any view toolbars ;-) > - For CDT multi-core group, we would like to introduce a graphical debug view. > And would like to have common debug toolbar at the main window. Again, I assume that in this case then normal Debug view would be closed and hence no need to fiddle around with the view Debug view's toolbar. >This is the case I was also thinking of to answer Dani's question. In this >scenario the user may still want to use the Debug view, but interchangeably >with a graphical view. So having the debug actions in both the Debug view and >the top toolbar would be rather silly. I disagree. The closer the actions are to the view (or context in general) the better. If - in addition - they are also available in the global toolbar, so that they can be invoked without the Debug view being active (or open) then that's fine. Note that it's not only actions from the Debug view that I'd like to see in a global toolbar. The one I currently miss most is 'Skip All Breakpoints' from the Breakpoints view. Created attachment 189627 [details] Screenshot of double toolbar. (In reply to comment #23) > My question was: "Can someone first provide some user scenarios where it makes > sense to show the Debug view but no view toolbar?" My mistake :-) > I disagree. The closer the actions are to the view (or context in general) the > better. If - in addition - they are also available in the global toolbar, so > that they can be invoked without the Debug view being active (or open) then > that's fine. I attached a screenshot of what the user would likely see with both toolbars enabled. We get many user requests for reducing visual clutter, this kind of thing would definitely not help that cause. > Note that it's not only actions from the Debug view that I'd like to see in a > global toolbar. The one I currently miss most is 'Skip All Breakpoints' from > the Breakpoints view. I agree. Adding more actions to global toolbar may please many users. However, in the past Darin expressed concern about crowding the top level toobar. I'm not sure if it was for JDTs or commercial products though. Since commercial products can now hide specific actions at the product customization level, IMO we should add more of them by default. (In reply to comment #23) > I disagree. The closer the actions are to the view (or context in general) the > better. .... Additional point is that run control actions apply to the whole window context, not just the Debug view. For example, when stepping, you're more likely to be looking at the editor or the data views than the Debug view. In fact most of our users migrating from other tools find the placement of these actions in Debug view counterintuitive. Having both toolbars on by default doesn't really make sense to me, however we shouldn't prevent the user from enable both due to whatever reason. I hope no product will enable both toolbars by default! When adding top level actions, the visbility of these actions should be customizable either through actionSet or through the menu extension point that can be control by extender. I have spend a lot of times cleaning up actions in views and main level menus and toolbars in our product, to minimize the number of actions. The number of toolbar actions, menu actions, context menu actions, and view local menu actions are just too many in eclipse. It is overwhelming to the end user. I have to agree with Dani on this one, if one the main reasons for the global toolbar is for 'debug view-less' debugging, than worrying about hiding the debug view toolbar is a moot point since it won't be open or visible anyway. If however, you do like using the debug view while debugging (like I do), than you could simply turn off the global toolbar or customize it to hold the actions that you commonly do use (like Skip All Breakpoints, etc). (In reply to comment #27) > I have to agree with Dani on this one, if one the main reasons for the global > toolbar is for 'debug view-less' debugging, than worrying about hiding the > debug view toolbar is a moot point since it won't be open or visible anyway. The use case that is currently triggering this discussion is the Visualizer view: (http://wiki.eclipse.org/CDT/MultiCoreDebugWorkingGroup/VisualizerView). An excerpt from the page: > This Visualizer View should not be viewed as a replacement for the Debug View, > but rather as a complementary perspective on the same application. To give an > analogy, in writing a technical article one does not dispense with the text of > the article and merely present a graph; one uses the graph to cogently present > an overview of the details discussed in the article. Similarly, the Debug View > might still serve as the "main view" of a debugged application, but one might > also use the Visualizer View to get a different, high-level perspective on the > same application. > The use case that is currently triggering this discussion is the Visualizer
> view: (http://wiki.eclipse.org/CDT/MultiCoreDebugWorkingGroup/VisualizerView).
Looked at that, but could not find an argument for removing toolbar items from the Debug view. Also, I can't see what the benefit for new users would be if we remove the toolbar actions from the Debug view. Making the view toolbar actions dependent on whether the action set is shown seems overkill and not bringing any additional value.
(In reply to comment #24) > I attached a screenshot of what the user would likely see with both toolbars > enabled. We get many user requests for reducing visual clutter, this kind of > thing would definitely not help that cause. I share Pawel's concern about visual clutter. Compared to other "built for purpose" debuggers, having the buttons in the debug view is unintuitive from what I hear. Sure we don't gain much in terms of screen real estate by removing buttons, when the toolbar has to remain. On the other hand, every button removed may reduce confusion, especially for new users. From my point of view, the discussion might be more of a product builder's concern than an end user's concern. So if the product builder can turn on the toplevel toolbar while trimming the debug view toolbar that might be sufficient. Let me summarize where the discussion is so far, and hopefully we can come to an agreeable compromise: 1) There is a precedent and logic for having run control toolbar in the Debug view. 2) There is a desire on part of users and vendors to customize the run control toolbar, which is currently only possible in the top level toolbar. 3) There are use cases for having views share run control toobar between views. 4) There is a precedent against having a top-level debug toolbar. Breaking this precedent may upset many products that fine tune the top-level toolbar. 5) There is a desire to avoid having duplicate toolbars in the IDE, as to avoid visual clutter. Please add if I missed anything. It seems that only point 5 is under contention right now. Correct? If so, it seems to me that a reasonable compromise would be to make the Debug view toolbar visibility a product level customization option and a user preference. I have to admit though that there are other complications to this. Most importantly, the Debug view gets many contributions from other plugins. E.g. CDT adds disassembly and reverse stepping actions, JDT adds "drop to frame". A good solution should allow for any of these contributions to adjust as well. Since I'm being quoted, let me add a clarification/opinion here. :-) First, clarification: the Visualizer View design doesn't make a case either for or against having a toolbar on the Debug View, or even on the Visualizer (graphical) view itself. It merely asserts that the same debugging actions want to be available for the Visualizer View's selection as well. At present (at least in the case of tile-eclipse's Grid View) this is done by having toolbars on both views, since that's the current Eclipse pattern. If the debug actions can be applied to the selection provided by _either_ view, then they could just as easily be located on a top-level toolbar. The view toolbars could then be hidden _if_ -- and this is the important thing -- that's what the app designer and/or user _wants_. Next, opinion: having used a number of IDEs, including both Visual Studio and Eclipse, I do agree that Eclipse's "toolbars near the selection" pattern feels odd at first, but I do agree that for _some_ users it can be helpful to have a few important, often-used debugging commands (suspend, resume, step, terminate) on a view toolbar close to the selection they affect, so long as the entire set of debugging commands is easily discoverable elsewhere, like on a top-level toolbar. In particular, for users who prefer mouse-clicks to remembering which keyboard shortcut to hit, this reduces visual search time and mouse travel time. This doesn't say one _has_ to present both a top-level debug toolbar and a per-view debug toolbar all the time. It's saying that it's up to the app developer and the user to decide what suits them, and up to us to allow the choice to be made easily by both. It's equally an application developer issue and a user preference issue. In short, per-view toolbars may be helpful for some users, and ultimately which toolbar(s) -- top-level or per-view -- are displayed should be configurable by the developer and the user. (P.S. I just saw Comment 31, Pawel -- I'm basically agreeing with you, just noting that visibility of _both_ toolbars wants to be configurable/selectable.) I'm fine (and actually encourage) adding a main toolbar for Debug which can also be visible out of the box in the Eclipse SDK's Debug perspective. I can also live with Debug adding some hooks so that products can tweak the Debug view toolbar but when it comes to customizing the view toolbar via UI by the user, this something that has to be done/offered at the Platform UI level and be made available for all views. Personally I would hate if a product dynamically enables or disables the toolbars of my views. Also note that users can use every (Debug) view in other perspectives. Removing toolbar icons from a view might render the view unusable in that context unless the user manually enables the Debug action set. *** Bug 242720 has been marked as a duplicate of this bug. *** Created attachment 199366 [details]
Path to add debug toolbar as a separate action set.
This is the next iteration of the toolbar effort: It just adds the toolbar under a new action set. It does not remove the view toolbar actions.
I think this much we all agree on :-)
The next step is to provide a hook for a product to optionally hide the view toolbar.
Created attachment 203180 [details]
Fix with a menu in Debug view to select toolbar.
I made another version of this fix that I think everyone will like. The change adds the Debug Toolbar as its own action set. It also adds a sub-menu to the Debug view menu which select the desired Debug toolbar setup: "View", "Window", or "Both".
The setting whether to show the Debug toolbar in view is set per-perspective and is stored in a preference so that it can be customized by a product's plugin_customization.ini. Also showing the toolbar in Debug view sets a system property so that org.eclipse.menus contributions can control their visibility together with the standard debug action.
The default of course is to show the toolbar in Debug view only.
I will plan to commit this change shortly after M2 unless anyone objects. (In reply to comment #36) > Created attachment 203180 [details] > Fix with a menu in Debug view to select toolbar. > > I made another version of this fix that I think everyone will like. The change > adds the Debug Toolbar as its own action set. It also adds a sub-menu to the > Debug view menu which select the desired Debug toolbar setup: "View", "Window", > or "Both". I tried it and I think it is very nice! But now that I see it live, I wonder if there is be a way to contribute new buttons to the Debug toolbar so that they can also be shown either in "view" or in "window" according to the preference? (In reply to comment #38) > But now that I see it live, I wonder if there is be a way to contribute new > buttons to the Debug toolbar so that they can also be shown either in "view" or > in "window" according to the preference? Great :-) The contribution to the view can be made conditional on the system property: IDebugUIConstants.DEBUG_VIEW_TOOBAR_VISIBLE. So it'll disappear and appear as needed. For the window toolbar, the items should be contributed separately to the Debug toolbar action set. I'll try to make a patch for some of the CDT actions before I commit. Created attachment 203431 [details]
Updated fix with a menu in Debug view to select toolbar.
I updated labels in the Debug view sub-menu.
While testing, I found that the problem that Darin pointed out in comment #8 affects the latest patch as well: the keybindings don't work when top-level toolbar is present. The problem seems to be that when two actions sets contribute actions with the same definition ID, the keybindings get confused (I think that's the correct technical term :-)). One option would be to not specify the definition IDs for the toolbar actions, but then the accelerator keys won't show up in the toolbar tooltips. I'll investigate implementing command handlers next. > While testing, I found that the problem that Darin pointed out in comment #8
> affects the latest patch as well: the keybindings don't work when top-level
> toolbar is present.
I found a way around the problem, although I ended up adding default command handlers for the run control actions as well.
I pushed the commit to repo and I'll attach an updated patch.
Mike, please give it a try. Created attachment 203868 [details]
Updated patch that corrects the keyboard shortcuts.
The 'Run to Line' action does not work - it does not enable or disable as I debug, and trying to use it fails and leaves the breakpoint manager disabled.
Steps:
1. use the snippet:
package a;
public class TeSt {
public static void main(String[] args) {
System.out.println("foobar"); //bp
}
}
2. debug it and step in a couple of times when you hit the bp [OK]
3. F8 to resume [OK]
4. the launch is terminated but the 'Run to Line' action is still active and trying to press it leaves the bp manager in a disabled state.
(In reply to comment #45) It appears that Run To Line enablement was broken before the top-level toolbar. I.e. I can reproduce the bug with M2 by using the menu. Although in either case I can't reproduce the inconsistent BP manager state. Is it OK if we track this issue as a separate bug? (In reply to comment #46) > (In reply to comment #45) > Is it OK if we track this issue as a separate bug? No, as it is included in the main toolbar, and is really noticeable as not working, it should be fixed with this issue. (In reply to comment #47) > No, as it is included in the main toolbar, and is really noticeable as not > working, it should be fixed with this issue. Fair enough the toolbar does look broken. I investigated the run to line at length and it appears that the current enablement behavior goes back to bug 180441. I think we can refine it and avoid this ugliness (now bug 359151), but that bug carries some of its own risk as it affects all RegargetActions and it may subtly affect performance. So rather than having this feature hinge on the run to line bug, I'd rather take out the run to line action from the toolbar until it's resolved. Would that be OK? However, another problem I found is that in E4, ALL the run control actions are enabled when not debugging! This was also true in the run menu before the toolbar introduction. I haven't investigated it yet, but I'm not sure how much of a big deal it is. Could it be some sort of performance enhancement? (In reply to comment #48) > So rather than having this feature hinge on the run to line bug, I'd rather > take out the run to line action from the toolbar until it's resolved. Would > that be OK? That sounds like a good idea. > However, another problem I found is that in E4, ALL the run control actions are > enabled when not debugging! This was also true in the run menu before the > toolbar introduction. I haven't investigated it yet, but I'm not sure how much > of a big deal it is. Could it be some sort of performance enhancement? Could be, Paul would be the one to ask about E4 / action contributions. (In reply to comment #49) > That sounds like a good idea. Done, I removed the run to line action from toolbar and added it to my bug359151 local branch. > Could be, Paul would be the one to ask about E4 / action contributions. I follow up on this separately. As you can see one can add menus and toolbars to the same action set. Hence you should use the existing 'Debug' action set and hide the toolbar items by default using the 'org.eclipse.ui.perspectiveExtensions' extension point.
Example from JDT UI:
<extension
point="org.eclipse.ui.perspectiveExtensions">
<perspectiveExtension
targetID="*">
<hiddenToolBarItem
id="org.eclipse.jdt.ui.actions.OpenProjectWizard">
</hiddenToolBarItem>
</perspectiveExtension>
</extension>
And I'm missing my most wanted reason for the debug toolbar: from comment 23:
> Note that it's not only actions from the Debug view that I'd like to see in a
> global toolbar. The one I currently miss most is 'Skip All Breakpoints' from
> the Breakpoints view.
(In reply to comment #51) > As you can see one can add menus and toolbars to the same action set. Hence you > should use the existing 'Debug' action set and hide the toolbar items by > default using the 'org.eclipse.ui.perspectiveExtensions' extension point. I considered using this method but rejected it based on a few reasons: 1) I didn't know you could use a wild-card as in your example since it's not in the docs (very handy though). 2) Unlike with whole action sets, there's no programmatic way to show/hide individual items, so I couldn't implement the user-friendly feature in Debug view. 3) The hideMenu/hideToolbar extension has a warning in docs that it's a product-level extension. If we used in the platform plugin, wouldn't we create a conflict for any product what wants to customize this feature to show the toolbar by default? > > Note that it's not only actions from the Debug view that I'd like to see in a > > global toolbar. The one I currently miss most is 'Skip All Breakpoints' from > > the Breakpoints view. Bug 264485. I thought we would let the dust settle on this one first, so if need be there's less changes to back out ;-) Works fine now, except for the noted issues. > 2) Unlike with whole action sets, there's no programmatic way to show/hide > individual items, so I couldn't implement the user-friendly feature in Debug > view. Ah, I now see your feature. The problem with it is that it does not mirror the toolbar 1:1. As soon as the user modifies the top-level toolbar (removes some items) it becomes strange because the Debug view does not reflect that but on the other hand gives the impression that it's the same toolbar for which I can simply choose where it shows up. I'm not convinced that a feature like this should be implemented outside Platform UI if not offered as general feature by them. We should at least get the approval from them for adding this new UI metaphor into the SDK. > 3) The hideMenu/hideToolbar extension has a warning in docs that it's a > product-level extension. If we used in the platform plugin, wouldn't we create > a conflict for any product what wants to customize this feature to show the > toolbar by default? Yes, but is this the case here? I would assume that a product would also want to modify some of the views then. Which means it needs to code that part anyway. >Which means it needs to code that part anyway.
So, what we would need is API to control the visibility of the individual items in a working set.
(In reply to comment #54) > I'm not convinced that a feature like this should be implemented outside > Platform UI if not offered as general feature by them. We should at least get > the approval from them for adding this new UI metaphor into the SDK. I agree about UI team's blessing. Can you add the appropriate person to the "review ?" list. I guess that'd be Paul, but I'm not really sure. Personally, I'm rather torn about this bug in general. IMO, the debug toolbar should have been on the top from the beginning. But it's a rather subjective thing. > Yes, but is this the case here? I would assume that a product would also want > to modify some of the views then. Which means it needs to code that part > anyway. I'm not sure what you mean here. If you're referring to the fact that a product integrator should be able to turn off the Debug toolbar, that is the case with this implementation: there's a preference which specifies if Debug view toolbar should be hidden, and it's set per-perspective. It'd be great if there was an API/UI to hide view toolbar contributions, but it seems like a complicated problem. (In reply to comment #56) > (In reply to comment #54) > > I'm not convinced that a feature like this should be implemented outside > > Platform UI if not offered as general feature by them. We should at least get > > the approval from them for adding this new UI metaphor into the SDK. > I agree about UI team's blessing. Can you add the appropriate person to the > "review ?" list. I guess that'd be Paul, but I'm not really sure. I'll mention the bug in today's UI meeting. Paul is on leave. A new 'Debug Toolbar' or an extended 'Debug' action set makes perfect sense for the view-less debugging scenario but I'd vote -1 that Debug introduces new UI concepts like switching the Debug toolbar from view to top-level via view menu. I think I mentioned that before already ;-). Either Platform UI introduces this for all views or a product decides to introduce it by its own for some/their views. Regarding Platform UI: I think a new command/API to hide/show the local toolbar could make sense as we already have this for the global toolbar. I'm also fine with adding an API to the Debug view(s) so that a product can toggle it. > Personally, I'm rather torn about this bug in general. IMO, the debug toolbar > should have been on the top from the beginning. But it's a rather subjective > thing. If we (the Debug team) think that the current Debug view is not good and we should change/move local toolbar items then that's a different thing. Would be a good topic for our next Debug call. We could modify the Debug view (remove [some/all] items) and the Debug perspective accordingly (enable the toolbar items in the 'Debug' action set). A preference could be added for people that like the old mode. This would not be a new UI concept and hence not be problematic. > > Yes, but is this the case here? I would assume that a product would also want > > to modify some of the views then. Which means it needs to code that part > > anyway. > I'm not sure what you mean here. If you're referring to the fact that a > product integrator should be able to turn off the Debug toolbar, Yes, the Debug view toolbar. > that is the > case with this implementation: there's a preference which specifies if Debug > view toolbar should be hidden, and it's set per-perspective. I don't see a clean way how a product would be able to do this. Browsing the code and then use the string which is used by internal code isn't really working (well it works, but...). But as mentioned above: we could add such an API. > It'd be great if there was an API/UI to hide view toolbar contributions, but it > seems like a complicated problem. Yep, hiding individual items won't be possible since they are contributed by a view's code but API to hide the whole view toolbar is feasible. What needs a bit work is to remember the state per perspective. The global toolbar actions stay enabled after closing the Debug view and do nothing. The Debug view must disable the actions when it gets closed. The bug can already be seen in 3.7 when using the menu but there the bug is less prominent.
This brings me to the question: should the Debug Toolbar also contain the current launch in a drop down (aha: breadcrumb ;-)? If so, one would really get Debug view-less debugging.
> Either Platform UI introduces this for all views
With "this" I only mean the ability to hide the local toolbar. Moving a local toolbar to the global area and back is not something what one normally wants since most of the local toolbar actions are indeed local.
(In reply to comment #58) > The global toolbar actions stay enabled after closing the Debug view and do > nothing. The Debug view must disable the actions when it gets closed. The bug > can already be seen in 3.7 when using the menu but there the bug is less > prominent. The actions will disable if there's no active debug context. So I should be able to fix this. > This brings me to the question: should the Debug Toolbar also contain the > current launch in a drop down (aha: breadcrumb ;-)? If so, one would really get > Debug view-less debugging. I've coded this for the original breadcrumb implementation: bug 252677, though I put it in the status trim. I personally liked it but it wasn't well received by the UI team, unfortunately I can't find any record of the feedback I received. The only workflow problem was that the breadcrumb control couldn't be resized. I could prototype this pretty easily again... just a matter of merging the patch to head. > > Either Platform UI introduces this for all views > With "this" I only mean the ability to hide the local toolbar. Moving a local > toolbar to the global area and back is not something what one normally wants > since most of the local toolbar actions are indeed local. I see, and I agree that it we should as the UI team to review. So who should I reach out to? (In reply to comment #57) I'm sorry, I somehow missed this comment yesterday! > (In reply to comment #56) > I'll mention the bug in today's UI meeting. Paul is on leave. > > A new 'Debug Toolbar' or an extended 'Debug' action set makes perfect sense for > the view-less debugging scenario but I'd vote -1 that Debug introduces new UI > concepts like switching the Debug toolbar from view to top-level via view menu. > I think I mentioned that before already ;-). Either Platform UI introduces this > for all views or a product decides to introduce it by its own for some/their > views. Regarding Platform UI: I think a new command/API to hide/show the local > toolbar could make sense as we already have this for the global toolbar. I'm > also fine with adding an API to the Debug view(s) so that a product can toggle > it. I can agree about the new paradigm and how it can be confusing to users to see this feature in this one view. I can covert it to an programmatic API as you suggest. Although as a user of the SDK, I think I'll miss it myself. > If we (the Debug team) think that the current Debug view is not good and we > should change/move local toolbar items then that's a different thing. Would be > a good topic for our next Debug call. We could modify the Debug view (remove > [some/all] items) and the Debug perspective accordingly (enable the toolbar > items in the 'Debug' action set). A preference could be added for people that > like the old mode. This would not be a new UI concept and hence not be > problematic. Sounds good, let's talk about it tomorrow. In the past we though that changing such a big default behavior would be too disruptive, but maybe with e4... > I don't see a clean way how a product would be able to do this. Browsing the > code and then use the string which is used by internal code isn't really > working (well it works, but...). But as mentioned above: we could add such an > API. Yes, it's a hidden preference string right now. In the least it needs to be added to IDebugUIConstants. > Yep, hiding individual items won't be possible since they are contributed by a > view's code but API to hide the whole view toolbar is feasible. What needs a > bit work is to remember the state per perspective. This is probably a separate topic. However, even in Debug view we want to keep some items in the view toolbar such as "remove all terminated" and CDT's "refresh". So I'm not sure if such an all or nothing feature would actually be desirable. > The actions will disable if there's no active debug context. So I should be > able to fix this. Maybe they should even be removed when the view closes. This would be aligned with the top-level menus which also appear and disappear with the view (actually they even disappear when the view looses focus, but that wouldn't be useful in our case). > I personally liked it but it wasn't well received by the UI team. The Eclipse UI team or your own? > I see, and I agree that it we should as the UI team to review. So who should I > reach out to? If mentioned this bug in this weeks UI meeting and told interested parties to chime in. Paul and Susan are on leave and the rest of the team is pretty busy with lots of other stuff. (In reply to comment #61) > > I personally liked it but it wasn't well received by the UI team. > The Eclipse UI team or your own? Darin and Mike were luke warm to how useful it may be, while the UI team objected to the new use of status bar. I'll open a new feature request to re-explore the idea of breadcrumb or other control in toolbar. > > I see, and I agree that it we should as the UI team to review. So who should I > > reach out to? > If mentioned this bug in this weeks UI meeting and told interested parties to > chime in. Paul and Susan are on leave and the rest of the team is pretty busy > with lots of other stuff. Sorry, I hadn't seen your previous comment Based on today's meeting we will do the following: - Turn on debug toolbar action set by default in Debug perspective. Actually. If we turn it on by default, we may as well add it to the standard debug action set. I'll target that for M3. We'll take in the feedback to M3 and decide whether to revert it. - Turn off debug view toolbar by default and add a view setting to turn on view toolbar. - Add toggle skip-all breakpoints action (Bug 264485). - Run-to-line action fix too (Bug 359151) - Add a breakpoints view breadcrumb to toolbar Nah just kidding :-) (In reply to comment #63) > - Add a breakpoints view breadcrumb to toolbar > Nah just kidding :-) That is just mean. (In reply to comment #63) > Based on today's meeting we will do the following: > > - Turn on debug toolbar action set by default in Debug perspective. > Actually. If we turn it on by default, we may as well add it to the standard > debug action set. Don't we want the user to be able to disable the debug toolbar if they so choose? Will that be possible if it is part of the standard debug action set? Won't they be turning off a bunch of other debug things? (In reply to comment #65) > Don't we want the user to be able to disable the debug toolbar if they so > choose? Will that be possible if it is part of the standard debug action set? > Won't they be turning off a bunch of other debug things? The Customize Perspective dialog allows hiding individual actions from toolbar and menu, so user is still in control. Having single action set gets around the command/action mapping problem mentioned before and it actually makes the action set more consistent with others in SDK. I committed the changes agreed to in comment #63, with exception of run control. I'd like to fix that in JDT first. I'm going to be optimistic and mark this bug as fixed now. http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=73c7f0938b112a86bd588ca329071f285d829490 (In reply to comment #39) > (In reply to comment #38) > > But now that I see it live, I wonder if there is be a way to contribute new > > buttons to the Debug toolbar so that they can also be shown either in "view" or > > in "window" according to the preference? > > Great :-) The contribution to the view can be made conditional on the system > property: IDebugUIConstants.DEBUG_VIEW_TOOBAR_VISIBLE. So it'll disappear and > appear as needed. For the window toolbar, the items should be contributed > separately to the Debug toolbar action set. Just wanted to confirm that the above instructions are still valid for the latest solution? > I'll try to make a patch for some of the CDT actions before I commit. I can open a bug in CDT to hopefully have someone (doesn't have to be you), do this done for Juno. Do you think we should wait until the dust settles after M3 is out, to make sure platform is not asked to revert the defaults back to what they used to be? (In reply to comment #68) > > Great :-) The contribution to the view can be made conditional on the system > > property: IDebugUIConstants.DEBUG_VIEW_TOOBAR_VISIBLE. So it'll disappear and > > appear as needed. For the window toolbar, the items should be contributed > > separately to the Debug toolbar action set. > > Just wanted to confirm that the above instructions are still valid for the > latest solution? Yes, this is still the case. > > > I'll try to make a patch for some of the CDT actions before I commit. > > I can open a bug in CDT to hopefully have someone (doesn't have to be you), do > this done for Juno. Do you think we should wait until the dust settles after > M3 is out, to make sure platform is not asked to revert the defaults back to > what they used to be? Yes, I think it'd be wise to hold off a little bit to see what kind of feedback this change kicks up. The toolbar works ok. I do find it a cumbersome to use if the debug view is not directly below it. Also the addition of the 'Skip All Breakpoints' action feels really out of place. I personally never disable all of my breakpoints (only individual ones) - perhaps we could have that action not shown by default? (In reply to comment #70) > The toolbar works ok. > > I do find it a cumbersome to use if the debug view is not directly below it. > Also the addition of the 'Skip All Breakpoints' action feels really out of > place. I personally never disable all of my breakpoints (only individual ones) > - perhaps we could have that action not shown by default? Interesting, I'm really curious how people from outside the team will react. I'm fine with turning off the skip breakpoints actions by default, though it'd also I'd like to hear what people outside the team will think of it. I was even considering adding the toggle-breakpoint action to the toolbar. Often times I can't tell when the toggle action is enabled (e.g. when in outline or variables views) and opening the Run menu just to check enablement is cumbersome. (In reply to comment #70) > The toolbar works ok. > > I do find it a cumbersome to use if the debug view is not directly below it. > Also the addition of the 'Skip All Breakpoints' action feels really out of > place. I personally never disable all of my breakpoints (only individual ones) > - perhaps we could have that action not shown by default? I disagree here. I do it all the time since I normally always launch in debug mode and then toggle all breakpoints. If we go towards the global toolbar then this must be there. Otherwise we leave all as it was in 3.7 (meaning we introduce the Debug Toolbar but it remains hidden). (In reply to comment #72) > I disagree here. I do it all the time since I normally always launch in debug > mode and then toggle all breakpoints. If we go towards the global toolbar then > this must be there. Otherwise we leave all as it was in 3.7 (meaning we > introduce the Debug Toolbar but it remains hidden). While I also use the skip all breakpoints toggle, I don't understand the need for it to be in the main toolbar. How do you currently toggle it? The action is available in the Run Menu (where I typically use it) or as a command which you can assign a key binding to for quick access. There are many actions in the run menu that I think are used more often (inspect, toggle breakpoint), but are not being placed into the toolbar. I don't see how this action is so critical that its removal justifies hiding the entire feature. I echo Pawel's sentiment that comments from outside the committers would be very helpful. I'll throw in my personal opinion too: I don't use the skip all very much, but when I do I find it helpful to see the actions state on the toolbar because it can be confusing when breakpoints are being skipped for no apparent reason. BTW, I do use run-to-line a lot and I would like to add it to the toolbar. Would either of you have a sec to review and commit the patch for bug 360172? I partially agree with Mike: I would also suggest to remove it form perspectives other than 'Debug' (e.g. remove it from 'Java' perspective). > While I also use the skip all breakpoints toggle, I don't understand the need > for it to be in the main toolbar. How do you currently toggle it? The action > is available in the Run Menu (where I typically use it) or as a command which > you can assign a key binding to for quick access. I'm a mouse/click user. I currently do it via Breakpoints view, but that's mostly the only thing I really need from that view, hence it is hidden in a view stack. Every time I want to enable/disable all breakpoints I first have to bring that view to front and then of course bring the other (Variables in my case) to front again later. That's why I originally filed bug 242720 which got marked as duplicate of this one. > There are many actions in the run menu that I think are used more often > (inspect, toggle breakpoint), but are not being placed into the toolbar. I > don't see how this action is so critical that its removal justifies hiding the > entire feature. I was not talking about hiding the "feature" entirely - just hiding the new toolbar by default. This is something we might have to do anyway for 3.8. The current state is an experiment to gather feedback. (In reply to comment #74) > I don't use the skip all very much, but when I do I find it helpful to see > the actions state on the toolbar Agree, "Skip all Breakpoints" affects run-control and has a global state, so having it visible on a global toolbar makes sense. > BTW, I do use run-to-line a lot and I would like to add it to the toolbar. I disagree - run-to-line is a very context-sensitive operation (first select the line to run-to, then perform the operation). I find it confusing to have such very context-sensitive operations on a global toolbar and prefer having it in a contextmenu only. I tend to agree with Martin regarding run-to-line. We could add it to the toolbar but hidden by default, so that interested users can enable it. > There are many actions in the run menu that I think are used more often
> (inspect, toggle breakpoint), but are not being placed into the toolbar.
I agree, we could provide the bulk of the actions in the lower half of the Run menu as actions that *could* be shown in the toolbar; for example All Instances, All References, Inspect, Display, Execute, Toggle breakpoint, etc, etc - these would not all be visible by default but could be offered as choices to add.
Other global state actions I find useful are the 'Show Breakpoints Supported by the Selected Target' from the breakpoints view and 'Show Monitors' from the debug view menu.
(In reply to comment #76) > I disagree - run-to-line is a very context-sensitive operation I agree. The action is too context-sensitive and should be left out by default. (In reply to comment #78) > Other global state actions I find useful are the > 'Show Breakpoints Supported by the Selected Target' Just confirming what this is really meant to do, since you've mentioned it. When selecting a Java target, only java breakopoints should be shown; when selecting a C/C++ target only C/C++ breakpoints should be shown, etc. Is that right? (In reply to comment #80) > (In reply to comment #78) > > Other global state actions I find useful are the > > 'Show Breakpoints Supported by the Selected Target' > > Just confirming what this is really meant to do, since you've mentioned it. > When selecting a Java target, only java breakopoints should be shown; when > selecting a C/C++ target only C/C++ breakpoints should be shown, etc. > > Is that right? Basically: the viewer filter simply calls IDebugTarget#supportsBreakpoint(..) for each breakpoint in the view when a debug context is selected. Having 'Drop To Frame' only available in the context menu is very annoying for me. Unless you want to tell me I should make a keybinding for it? (In reply to comment #82) > Unless you want to tell me I should make a keybinding for it? This doesn't seem to be working. I've tried both 'Suspend' and 'Drop To Frame', see bug 361448. (In reply to comment #82) > Having 'Drop To Frame' only available in the context menu is very annoying for > me. > > Unless you want to tell me I should make a keybinding for it? I'll add it back in, since it's in the Debug view it should be in the top toolbar as well. Let me know if anyone objects. (In reply to comment #84) > I'll add it back in, since it's in the Debug view it should be in the top > toolbar as well. Let me know if anyone objects. I added back the Drop to Frame action and the Run to Line. Run to Line is hidden by default. Thanks Remy for pointing out the drop to frame issue. Now we'll just have to see about wider feedback once M3 rolls out. http://git.eclipse.org/c/platform/eclipse.platform.debug.git/commit/?id=2c9488da649bd0f8a92dcc07ce314f109dc20622 (In reply to comment #85) > I added back the Drop to Frame action and the Run to Line. Run to Line is > hidden by default. Thanks Remy for pointing out the drop to frame issue. Thank you for the quick turnaround, Pawel. My rudeness in comment 82 was uncalled for and I apologize for that. (In reply to comment #86) > My rudeness in comment 82 was uncalled for and I apologize for that. No offense taken :-) I need to be able to turn on the debug view toolbar (and turn off the debug toolbar actions) when my perspective is active. Is this possible with the new changes? Thanks. (In reply to comment #88) > I need to be able to turn on the debug view toolbar (and turn off the debug > toolbar actions) when my perspective is active. Is this possible with the new > changes? Thanks. The debug view toolbar visibility is set per-perspective and it is stored in a preference (org.eclispe.debug.ui.Debug_view.debug_toolbar_hidden_perspectives). So you can customize it at a product level to show in your perspective. The top-level toolbar is just an action set so it can also be customised at a product level or through perspective extensions. (In reply to comment #89) > The debug view toolbar visibility is set per-perspective and it is stored in a > preference (org.eclispe.debug.ui.Debug_view.debug_toolbar_hidden_perspectives). > So you can customize it at a product level to show in your perspective. Hmmm, so I add my perspective to this preference and it shows the toolbar. The preference seems a bit mis-named if this is the case. Also, I had some trouble getting it to work because the preference name misspells eclipse as "eclispe". (In reply to comment #90) > Hmmm, so I add my perspective to this preference and it shows the toolbar. The > preference seems a bit mis-named if this is the case. Also, I had some trouble > getting it to work because the preference name misspells eclipse as "eclispe". Good point, i opened 382638 |