Community
Participate
Working Groups
I saw few enh. requests concerning the breakpoints view, and I thing that the best would be to have an arborescent view, permitting to group them logically and enable only some groups. Groups would have to be 3-state for the view to be really efficient, internal selection should be kept when the parent group is enabled/disabled. The view could provide a global toggle action to enable/enable all the breakpoints, without needing to put them under a top level root node. By the way, when a breakpoint is disabled (maybe because its parent group is), its font should be grayed (more user friendly). Tell me if you need nore info on that, but it is something I would really be happy with ! --Steve
*** Bug 1545 has been marked as a duplicate of this bug. ***
Marking as 3.0 candidate. However, due to current resources setting as P4. Contributions welcome.
Trying to invent the 36 hours day, so I know what it is ;-) I will first fix one I promised on the win32 SWT Tree, then check my priorities, and possibly work on it. I'll tell you anyway. (Except if someone else wants to work on it) -- Steve
*** Bug 52518 has been marked as a duplicate of this bug. ***
Note we intend to add a toggle to enable/disable all breakpoints without losing their state (effectivele enables/disables the breakpoint manager). However, we will not have support for breakpoint groups in 3.0. See bug 10078. Deferred.
*** Bug 71375 has been marked as a duplicate of this bug. ***
*** Bug 41565 has been marked as a duplicate of this bug. ***
*** Bug 69088 has been marked as a duplicate of this bug. ***
Open for 3.1
*** Bug 23279 has been marked as a duplicate of this bug. ***
*** Bug 26857 has been marked as a duplicate of this bug. ***
There should be implied groups, such as all of the breakpoints within a given Resource. Changing the groups state to disabled should effectively disable the children, but not change their individual enablement state when the group is enabled again. To indicate this, maybe tri-state checkboxes could be used, or graying the text as suggested above.
Randy, how hot are you really on the notion of automatically created groups versus user created? Do you find yourself wanting to disable all/only the breakpoints in a specific file very often? My intuition says that it would be cleaner and more useful to just provide for user-defined groups. For switching between problems, user-defined groups would provide a two-click (turn one group off and another one on) context switch. Auto-grouping would be more clicks and more work - you have to find and disable/enable every file that's involved in a problem. I just don't see the auto-groups being what you want most of the time.
So if I'm looking for a breakpoint in some plug-in X, I may have some breakpoints defined in plug-in Y that I want to disable. So I want to turn off that group "Plug-in Y". Turning off things at the resource level is not as common, but it does help in managing the number of breakpoints and finding the one you want. With manual groups, could a breakpoint/exception be added to multiple groups or just one? Could groups be nested? Group control sounds like a nice feature, but what I suggested isn't mutually exclusive. You could still support implied groups when the explicit group is set to NULL. For example, when I double-click in the ruler and set a breakpoint, it doesn't belong to any manually defined groups. So such a breakpoint could be auto- grouped according to Project, then Resource. At least until the user drags it under another group.
first choice: all manual, with drag and drop. autogroup if available, should have option to turn off. reason: the break point view is often very small, 3-6 lines at most, 400 pix wide. Any excessive indent or scrolling is not exactly welcomed, hence my desire for grouping.
I don't remember what the default debug perspective looks like. My view displays ~15 lines and is stacked on Variables View. The grouping and indentation would be flattened whenever possible. So if there was just 1 breakpoint in a resource, it could be: + My Project - ThisIsMyType [line: 40] someMethod(int) - ThisIsAnotherType [line: 60] someMethod(int) So we're talking about a one indentation. Once you get to 2 breakpoints in a resource, the horizontal space requirements go down, not up: + My Project - ThisIsMyType - someMethod(int) [line: 40] + anotherMethod [multiple lines] - thirdMethod - line 90 - line 92 To reduce indentation, the user could configure three boolean preferences: -Group by project -Group by resource/type -Group by method I'm just throwing out ideas. Just like the Properties View, there could be a toggle action to show/hide groups.
Instead of doing auto-groups, I'm now thinking about new selection actions. Something like: Select All (we already have this) Select Same Type Select Same Resource This way, you'd get the ability to perform operations like "disable all the breakpoints in this file" or "delete all my exception breakpoints" without disrupting your user-defined groups.
I think we should consider allowing a breakpoint to be in more than one group. For example, if I have groups set up for different applications or different problem scenarios in the same application, it might be common to have an NPE breakpoint in each group. If I can only enable this in one group, it seems rather limiting.
Allowing breakpoints in multiple groups would be a problem. Disabling one group would have the possible side effect of turning off a breakpoint on another group. This creates a situation where the user has to wrestle the UI to get reasonable behavior. In the NPE example, the NPE breakpoint doesn't belong in either group if you want it to be independent.
It can also work to your advantage. For example - I create a group for all exception breakpoints, and I also have exception breakpoints in other groups of application specific breakpoints. If I decide to turn off all exception breakpoints, but still want my other application specific breakpoints, it's easy to do.
Selection actions might be useful for creating groups, but it's not equivalent to having group support. With groups, you can disable the group, and still retain the individual enablement states (for example half of the breakpoints within a file are enabled). A regexp feature would be welcome too.
Core support for breakpoint groups implemented with UI in place for experimentation. Please verify base support, DW. I'll be filing separate bugs for UI features as we come up with ideas.
Verified.
hmm... actually now that I'm trying it out, I would have thought it makes more sense to group the breakpoints by launch config. I.e. "when I launch this app, turn on the following breakpoints and not all the other ones I happen to have set" .. this seems to be in line with the way one would program and not want all breakpoints constantly being hit when in fact you have moved on and are debugging a different problem. My debugging and launching efforts often cross the same file (esp. in Platform UI) so grouping by file or project is not useful.
You can group breakpoints manually into launch config groups. Generally, the debugger cannot infer which breakpoints are for which config.
Agree, that works. The support could exist however to allow you to (when creating a custom group) associate it with a launch config so that it is turned "on" when that launch occurs.
I see, I'll enter that as a new feature request.
