Community
Participate
Working Groups
20041107 For project settings you would use the lookup order 'project', 'instance' and 'default'. Using the ScopedPreferenceStore with a ProjectScope as input would currently result in ProjectScope (=getStorePreferences), DefaultPreferences (unless you override the lookup order) see ScopedPreferenceStore.getPreferenceNodes Note that it would be very convenient if you could create the ScopedPreferenceStore with a project: ScopedPreferenceStore(IProject project) // project to look in scope or null for InstanceScope
One problem is that we don't know where to store the values when the client calls the #set methods. Which scope to store them in? A couple of ideas: - always store them in the "top" scope. - create the store with the "main" scope and then have a lookup list which is separate I think this might be already covered with the creation of the store and then the #setSearchContexts method. But... Another problem is that not all keys within the same plug-in have the same look-up order. So specifying a search order for the plug-in as a whole (e.g. #setSearchContexts) is not fine enough granularity. Is it possible for us to make ScopedPreferenceStore work on a per-key basis? In the preference service, we have a registry where the look-up order can be on a per-key or per-node basis. But this requires passing in the ScopeContext every time you want to search for a value and that's not a good option at the IPreferenceStore level.
There are currently no plans to work on this although we would be happy to review a patch
A constructor ScopedPreferenceStore(IProject) is likely not possible in terms of dependencies because it would create a dependency into core.resources that's likely not desired in ui.preferences. Perhaps a subclass could provide such a constructor, which would simply call #setSearchContexts() as needed. I find the idea interesting in the context of a wider discussion about additional levels beyond project level (sharing settings among projects, user-private settings to override projects: see bug 194414 and bug 70683).
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
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. If you have further information on the current state of the bug, please add it. 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.
