Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #128066 +++ I'd like to request backporting the Fix for bug 128066 into Eclipse 3.6.2+. No API is involved, and the fix is necessary for Debugger View Management to be usable in any perspective other than the Debug perspective. It's also required for the View Management to operate as suggested by the Text in the View Management Preference Page ("don't auto-close/open if manually opened/closed before").
Hi Martin, I thought of targeting this fix for 3.6.x, but then I thought that the risk of this change may be greater than what we want in a maintenance release. One problem is that the view management logic is especially complicated and we don't have a unit test suite for it. So we have to rely on the manual tests which is not the greatest. The other problem is that this change modifies the behavior of view management slightly. The change is in how we handle views that are manually opened/closed by the user are handled. Previously if a view is closed after a debug session has terminated is considered, not it is not. I don't feel comfortable making such change in a maintenance release.
Ok here is my understanding: - The feature affects "Debug related views" only, by default Breakpoints and Variables. - The feature works as expected in the "Debug" perspective due to some hardcoding but not in other perspectives. - As of 3.6 I cannot configure a custom perspective (other than Debug) in which I want to use Debug View Management in order to perform all my development tasks in my one-and-only perspective. The following is broken: 1. Open Java Perspective. 2. Open Breakpoints View. 3. Save Perspective as "MyJava". 4. Preferences, enable auto-view-mgmt in the "MyJava" perspective. 5. Preferences, choose to not switch Perspective when debug suspends. 6. Switch to MyJava perspective. 7. Set a Breakpoint that will be hit. 8. Debug Java. On BP hit, the "Variables" and "Breakpoints" views open. 9. Continue (debuggee terminates) --> The Breakpoints view is auto-closed which is unexpected since it's configured to be part of the "MyJava" perspective. Pawel can you explain again (by an example) in what respect your change impacts existing functionality? Is the Debug Perspective impacted?
(In reply to comment #2) > Pawel can you explain again (by an example) in what respect your change impacts > existing functionality? Is the Debug Perspective impacted? Sure. It does impact Debug perspective. Scenario steps: 1. Start a debug session. 2. Terminate debug session. 3. Close Breakpoints view. 4. Start debug session. Old behavior: Breakpoints view not opened. New behavior: Breakpoints view auto-opened. Another scenario: Steps: 1. Start a debug session. 3. Close Breakpoints view. 2. Terminate debug session. 4. Start debug session. Behavior (same old and new) breakpoints view not opened. It's a subtle change and I believe it should make the feature more intuitive. Still I think it's possible that some users out there may have an expectation based on current behavior and could be surprised by it. Perhaps I'm being overly conservative though. Anyone else have an opinion on this?
BTW, we discussed view management in our monthly meeting last week and we couldn't identify who this feature was implemented for originally and the only known users are ourselves. Still as a platform feature it does potentially have wide exposure.
Ok thanks, the example helps. Regarding the feature itself, I think one can argue both ways. - Old behavior: By manually closing the auto-opened breakpoints view I told the tool I don't want it so I'm glad it doesn't come up again. I'd hate that manually closed view to reappear in spite of my choice. - New behavior: View management explictly associates some important views with the debug context, so they are always expected to show up regardless of perspective. User probably closed the breakpoints view accidentally and will be glad if it's brought up again. I can see how with the new behavior views potentially fight for attention / focus and user has no control over the views that are auto-opened. The tool tries to be smarter than the user which probably isn't good. On the other hand in the old behavior, not auto-opening seems like an unexpected side-effect of the feature more than deliberate. Perhaps the ideal expected behavior is: When I manually close a view that had been auto-opened, I see a dialog saying "This view is assigned to auto-open when debugging. Do you want to no longer auto-open the view and manage it manually from now on [Yes] [No]" along with a Preference page for selecting what views to auto-open such that the dialog choice can be reverted if need be. I personally wouldn't see any issues with backporting the fix since there isn't any official 3.6.2+ release so any adopter of 3.6.2+ will likely hand-pick fixes in that stream anyways. To me, fixing the problem has more value than preserving the old behavior. But I don't have a strong opinion and I'm also fine with _not_ backporting this. What do others think?
(In reply to comment #5) > Ok thanks, the example helps. > Regarding the feature itself, I think one can argue both ways. > > - Old behavior: By manually closing the auto-opened breakpoints view I told > the tool I don't want it so I'm glad it doesn't come up again. I'd hate > that manually closed view to reappear in spite of my choice. > > - New behavior: View management explictly associates some important views > with the debug context, so they are always expected to show up regardless > of perspective. User probably closed the breakpoints view accidentally and > will be glad if it's brought up again. To clarify. The new behavior will still remember that the user closed a view and not re-open it. But this "remembering" is only active during a debug session. I made this change based on my own experience of using view management. When I'm debugging in non-Debug perspective i want relevant views to appear. When I'm done debugging, some views stay open. When I'm really done debugging I want to close those views and go back to editing. When I'm ready to start debugging again I want those views to appear again. This is something of in-between from completely ignoring user's manual open-close actions, but more useful IMO.
Since it seems that there's no objections to this fix, I committed and release the change. Mike please check that I didn't screw up the tagging releasing stuff.
changes + tagging looks fine
