Bugzilla – Full Text Bug Listing
| Summary: | [view management] Don't auto-close views that exist in a perspective by default | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Darin Wright <darin.eclipse> | ||||
| Component: | Debug | Assignee: | Pawel Piech <pawel.1.piech> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | aleherb+eclipse, chanskw, eclipse, Michael_Rennie, mober.at+eclipse, pawel.1.piech, wbprio | ||||
| Version: | 3.2 | Keywords: | helpwanted | ||||
| Target Milestone: | 3.7 M6 | Flags: | Michael_Rennie:
review+
|
||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 128065 | ||||||
| Bug Blocks: | 339209 | ||||||
| Attachments: |
|
||||||
|
Description
Darin Wright
For now, the debugger keeps track of the base/default views in the debug perspective in a hard coded list. This will, of course, fail when a user or tool creates their own debug perspective. Pending workbench API. As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you. Reopening. I am experimenting with view management for a non-default Debug perspective, but it is practically unusable because of this bug. An option to only auto-close views that were auto-opened, might mitigate the problem a little. CQ:WIND00198284 Wouldn't it also work to remember what views have been auto-opened, and auto-close exactly those views only? This should result in the same desired behavior of restoring the previous state of a perspective after the auto-open / auto-close cycle, without any need for new API. Or am I missing something? (In reply to comment #5) > Wouldn't it also work to remember what views have been auto-opened, and > auto-close exactly those views only? > This should result in the same desired behavior of restoring the previous state > of a perspective after the auto-open / auto-close cycle, without any need for > new API. > Or am I missing something? I think this suggestion would also work. Created attachment 189869 [details]
Proposed fix based on Martin's suggestion.
This fix should accomplish what Martin suggested: i.e. avoid closing a view that was opened prior to the launch. This modification also improves somewhat on the "do not auto open/close views that were opened manually".
The user auto open/close tracking is active even when user is not debugging but only after the debug UI plugin is loaded possibly leading to inconsistent behavior. With this patch, the tracking of user opening/user closing of views applies only to the debug contexts that are currently active.
Hi Samantha, Do you or someone you know cares about the proposed tweak I would like to make to the view management logic. I would like to head off any negative surprises. Thanks, Pawel I've run through the view management manual test script and I didn't encounter any problem. Although, I'm still not happy with the overwhelming number of preference settings for configuring perspective and view activation that we have. Sometimes these settings override each other's behavior. For example, user can select "Activate debug view when breakpoint is hit", which will cause the Debug view to be opened in any perspective when a debugger is suspended. However, the view management will also auto-open the Debug view if view management is enabled in a given perspective. There is a conflict between the two features though: the view management which should auto-close views when debugging is finished, will not auto-close the Debug view because it was auto-opened by another framework. OTOH, if the activate debug view feature is turned off, and view management auto-opens the debug view, it will not necessarily bring it to the front in a view stack... since it doesn't have an API for that. Anyway, maybe I should create a bug to simplify these settings and handle it separately. P.S. This is the oldest bug I've fixed in a long time. The patch works fine for me. verified *** Bug 336496 has been marked as a duplicate of this bug. *** |