Summary: | [Preferences] ScopedPreferenceStore should also work for ProjectScopes | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Martin Aeschlimann <martinae> |
Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P5 | CC: | dj.houghton, mober.at+eclipse |
Version: | 3.0 | Keywords: | helpwanted |
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Martin Aeschlimann
2004-12-07 11:46:26 EST
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). 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. |