Summary: | Package Explorer does not persist expansion state | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Randy Hudson <hudsonr> |
Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
Status: | RESOLVED DUPLICATE | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | daniel_megert, markus.kell.r, martinae |
Version: | 3.2.1 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Randy Hudson
2006-11-02 15:48:19 EST
This was taken out for 3.0 for performance reasons, see bug 65896. Restoring at least working set and perhaps project expansion state would help a lot. Expanding a project can already cause the resolving of the classpath or a classpath container. All we can safely do is to restore the expansion state of the working sets. Would that make a diffence? Yes Actually, a working set can also consist of single files (not only projects) that would, when shown, release the classpath resolving and block the UI. Yes, I guess this could be detected before persisting the expanded state, but it feels to me that this just adding complexity and isn't really a benefit. No plans here, setting to WON'T FIX. Why is it that the Hierarchy View can restore its state completely on restart, but not the Package Explorer? Couldn't the same approach apply here? I guess a main difference is that type hierarchy is an input driven view, it also has an 'not yet set' or empty state. But also restoring the type hierarchy view can be a pain. It is done in the background, but if you're really not interested in a recovered state it's slowing you down. If the type hierarchy view would be as prominent as the package explorer we might also have skipped the restore. *** This bug has been marked as a duplicate of bug 130083 *** |