Community
Participate
Working Groups
Build Identifier: 20120614-1722 If you select for the "navigator" or "package view" as the "Working Set" the option "Window Working Set" you can easily switch the view's contents by using the "Modify window working set" button. But if you quit and restart the eclipse IDE these configuration is lost and you have to reconfigure it after every restart (4.2 Juno). In eclipse 3.7.2 these settings are correctly memorized by the IDE, but in 4.2 the persistence for this feature does not work. Reproducible: Always Steps to Reproduce: 1. Create Working Sets. Configure the Navigator and Package View to use the "Window Working Set" Switch between Working Sets by using the "Modify window working set" button to ensure that it is working as exspected. 2. End the IDE. Restart the IDE. 3. Try again to switch between Working Sets by using the "Modify window working set".
Do you mean Package Explorer and Project Explorer as the views you see this in? PW
(In reply to comment #1) > Do you mean Package Explorer and Project Explorer as the views you see this in? Hello Paul - Ja, at least these two views do not memorize their "window working set" setting in juno.
The same problem exists with Open Resource dialog. I also think it's platform independent - having exact same issues on Linux (32 and 64 bit).
same problem here i primary use this in project explorer, but the crux of window working set is, that it works in many views.
Can confirm this. Running Juno (I20120608-1400) on Windows 7 64-bit with JRockit R28.2.4-14
Same issue. Eclipse Java EE IDE for Web Developers. Version: Juno Release Build id: 20120614-1722
I can confirm it for -) resource search dialog -) type search dialog -) package explorer -) project explorer a fix would be appreciated. Eclipse Java EE IDE for Web Developers. Version: Juno Release Build id: 20120614-1722
the problem still exists in juno sr1 rc3
This problem also seems to affect the "Problems" view: * In the "Problems" view click the arrow in the top right * "Configure Contents..." * Create a new "Configuration" and in the "Scope" section click "Select..." * Select "Window Working Sets" * After restarting Eclipse the "Problems" view does not filter on window working sets * Open "Configure Contents..." again * In the "Scope" section the correct option "On working set: Window Working Set" is selected * But when opening "Select..." the wrong option "Selected Window Sets" is selected * After reseting it to "Window Working Sets" it works again, until restarting Eclipse
(In reply to comment #9) > This problem also seems to affect the "Problems" view: > [...] Sorry, forgot to add the version information: Eclipse IDE for Java Developers Version: Juno Release Build id: 20120614-1722 Mac OS X 10.7.5
I am using the build with the ID 20120920-0800 and it seems to still have this issue. Please fix this as a lot of people are using filtering based on the Window Working Set. None of the views are persisting the Working Set selection, when Window Working Set is selected. Thanks
*** Bug 392883 has been marked as a duplicate of this bug. ***
If fixing, please note similar bug 328034 (which has been bugging me for years, although not as badly as this one).
yep, being bugged out by this misbehavior for months now. A fix would be much appreciated.
For anyone investigation a patch: http://wiki.eclipse.org/Platform_UI/How_to_Contribute PW
Created attachment 225248 [details] Proposal for a bugfix. The attached patch fixes the described problem (at least in my environment). The state of the fields "aggregateWorkingSetId", "workingSet" and "workingSets" in the class WorkbenchPage has not been persisted across sessions which leads to the problem described in the bug report. In Eclipse 3.7 the state has been mananged in the saveState(...) and restoreState(..) methods. These methods have been removed during the migration to e4. To solve the issue I ported the WorkingSet related content of the saveState() and restoreState() methods to the new code base. They are called in the @PostConstruct and @PreDestroy methods and save the state to the MWindow model element. I'm not sure if that is the correct way to fix the problem, but I hope the patch can help somehow. Regards, Christian
*** Bug 399608 has been marked as a duplicate of this bug. ***
http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=e296914671cd2cffd2c1a988475d1eeddaebf30d Christian, excellent patch !! (We do see all types...;-). I've committed the patch unchanged except for two things: - I changed 'restoreWorkingSets' to just *be* @PostConstruct rather than adding it to the 'setup' code. This makes the change more symmetrical, we now have both an @PostConstruct and an @PreDestroy specifically to manage working sets - Updated the copyrights to give you proper attribution (forever more you can find you name embedded directly into the Eclipse source..;-)
Eric, thank you very much for your positive feedback :-) I'm glad that I could contribute a little bit to the Eclipse platform and I'm happy to see this bug fixed.
Thank you Christian! Thank you Eric !-> Sehr schön - I'am looking forward to the eclipse 4.3 version
Verified in the build: I20130311-2000-win32-x86_64
I think we need to reopen this bug. I just had it happen to me using Eclipse Kepler (Platform version is 4.3.0.v20130605-2000) with Eclipse PDT installed o a Kubuntu 13.04 x64 machine. How to reproduce ---------------- On the PHP explorer: - Configure some working sets - close eclipse - Restart the computer - open eclipse Expected -------- The configured working sets are persisted Reality ------- All of the projects are on the "Other Projects" set. If you go to the configure working sets tab the working sets are gone. On Juno I had a similar problem. My working sets themselves wouldn't disappear, but they would be empty, and when I went to configure a given working set, the projects that were on it would be marked with a dashed instead of a full line. Now the sets are simply gone
(In reply to comment #22) > I think we need to reopen this bug. The original steps got fixed and verified. Please open a new bug with your scenario. Thanks.
(In reply to Samuel Sol from comment #22) What you describe is bug 412970.
