| Summary: | Review TrimStack data model (formerly context menu available on restore button of minimized empty editor stack) | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Curtis Windatt <curtis.windatt.public> |
| Component: | UI | Assignee: | Curtis Windatt <curtis.windatt.public> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | minor | ||
| Priority: | P3 | CC: | daniel_megert, emoffatt, Michael_Rennie |
| Version: | 4.3 | Flags: | Michael_Rennie:
review+
|
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
| Bug Depends on: | 407377 | ||
| Bug Blocks: | |||
|
Description
Curtis Windatt
Works fine Eric, are you going to be able to review this? Curtis, we'll defer this to 4.3.1 since this isn't at all dangerous to leave in place and see if we can just clean up the TrimStack code for 4.3.1. *** This bug has been marked as a duplicate of bug 407377 *** Reopening. The simple fix proposed here solves the incorrect menu, but Bug 407377 and others indicate that the TrimStack code is in need of some updating. The use of the data slot of the tool item and trim item is inconsistent, leading to many assumptions of the content being made. Eric's comment in Bug 407377: Aside from the menu handling there are also a fair number of inconsistencies around how the minimized shared area is handled, likely the result if it being 'bolted on' to the existing code that was originally meant to handle stacks. For example opening the shared area when its minimized should activate *something*, at the moment it doesn't. We should also looks at the activation history logic to see whether we need to change the search logic based on whether a minimized stack is showing or not... Thanks Curtis... While the model still needs a review, I will not have time to do so in 4.4. The important information from this bug is already captured in Bug 407377 so I am closing as WONTFIX. |