Bug 163255 - Package Explorer does not persist expansion state
Summary: Package Explorer does not persist expansion state
Status: RESOLVED DUPLICATE of bug 130083
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2.1   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-11-02 15:48 EST by Randy Hudson CLA
Modified: 2011-07-06 10:21 EDT (History)
3 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Randy Hudson CLA 2006-11-02 15:48:19 EST 
When restarting eclipse, The tree is completely collapsed. This is especially frustrating when only have just a few top-level treeitems displaying working sets.

This behavior differs from the Navigator View and I'm pretty sure it is a regression in the behavior of the packages view.
Comment 1 Markus Keller CLA 2006-11-03 06:03:21 EST 
This was taken out for 3.0 for performance reasons, see bug 65896.
Comment 2 Randy Hudson CLA 2006-11-03 09:44:34 EST 
Restoring at least working set and perhaps project expansion state would help a lot.
Comment 3 Martin Aeschlimann CLA 2006-11-08 10:11:24 EST 
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?
Comment 4 Randy Hudson CLA 2006-11-08 12:17:14 EST 
Yes
Comment 5 Martin Aeschlimann CLA 2006-11-10 06:00:24 EST 
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.
Comment 6 Randy Hudson CLA 2006-11-10 11:06:56 EST 
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?
Comment 7 Martin Aeschlimann CLA 2006-11-10 11:23:50 EST 
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.
Comment 8 Markus Keller CLA 2011-07-06 10:21:05 EDT 

*** This bug has been marked as a duplicate of bug 130083 ***