Community
Participate
Working Groups
Build Identifier: M20100909-0800 The "Deselect Working Set" setting should be remembered. Following a restart of Eclipse however, the setting reverts to "Window Working Set". This affects the following views: - Navigator - Package Explorer - Project Explorer Observed in Eclipse 3.6.0 and 3.6.1. It worked fine for me in 3.5. Reproduced on two computers, using existing and fresh workspaces. Implications: While working I leave a Window Working Set enabled to filter other views (Problems, Tasks). Therefore I need to Deselect the Working Set after every restart before being able to use the Navigator-like views. Reproducible: Always Steps to Reproduce: 1. (optional) Have a custom working set selected as the "Window Working Set" 2. From the Navigator view's View menu, select "Deselect Working Set". 3. Restart Eclipse.
Similar tickets: - 161299 - 122758 (quite old, so perhaps has a different cause to this regression)
*** Bug 122758 has been marked as a duplicate of this bug. ***
From bug 122758 comment #3 This is actually a preference: <eclipse>\plugins\org.eclipse.sdk_4.4.0.v20140120-2000\plugin_customization.ini contains a preference called USE_WINDOW_WORKING_SET_BY_DEFAULT, which is set to true. This causes the Windows Working Set to be selected by default at Eclipse startup, if no other working set is selected. After setting it to false, the issue is not reproducible anymore. Please let me know if this preference is something a user should change directly in the ini file, or should there be a commit to change the default value to false.
This appears to be a preference to allow RCP apps to opt-in or opt-out of using working sets. The IDE as an RCP app opts in. I can't find any way to set this pref from the Preferences dialog. PW
Thanks Piotr & Paul for a workaround! Having tested for a few days, it seems to resolve the issue in my workflows: the 'Deselect' setting remains put. (And with bug 385592 fixed, I'm back in happy-WorkingSet-land.) Curious as to what downsides there are if that preference is set false? What else changes? Do other workflows break? (Is there any clue in the history of the config file/code?) If the intent is merely convenience, then could I suggest considering a change to the default for the Eclipse IDE? It would seem less magical. IIRC, a user has to opt-in to configure Window Working Sets, under [Window -> Customise Perspective... -> Command Groups Availability] - which in my books makes this an advanced feature. Surely advanced users are comfortable to configure each view independently, and probably would expect their settings to stick(?)
I prepared a commit in case someone decides to change the default behavior back to not using Window Working Set as default https://git.eclipse.org/r/21274
Setting that value to true was done a while ago, to make sure every view that cared about working sets would at least consume the window working set by default. I'm not inclined to change it as a default without understanding how it effects the regular users, which I don't see. PW
(In reply to Paul Webster from comment #7) > Setting that value to true was done a while ago, to make sure every view > that cared about working sets would at least consume the window working set > by default. > > I'm not inclined to change it as a default without understanding how it > effects the regular users, which I don't see. > > PW Changing the default does not fix the problem, just work around it. A client can use 'true' and hence would run into this bug again.
I think I suffer from the same (or very similar) issue but for "Type Hierarchy" view. When I press F4 (Open Type Hierarchy) on, for example, Exception class, the following is displayed in the view: 'Exception - java.lang' - in working set: Multiple Working Sets. I want to search in JDK as well, so I need to go to popup menu and click "Deselect Working Set". However after I restart Eclipse, "Multiple Working Sets" is active again. Unfortunately I could not locate "USE_WINDOW_WORKING_SET_BY_DEFAULT" in Eclipse 4.6.2 folder. Any ideas what is the actual location?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
