Community
Participate
Working Groups
Currently settings are either scoped at the workbench/workspace level or the project level. However, there are cases where associating settings with other scopes, such as a working set or perspective, would be beneficial. Similarly, a product should be able to specify the default settings for a particular perspective. We will also look for ways to simplify how we share settings and other interesting state, such as breakpoints, bookmarks, perspectives, key bindings, etc. [Runtime, Workspace, UI]
How about settings that are scoped per configuration and/or can be more easily shared between workspaces? I tend to use a lot of different workspaces and it is somewhat annoying to modify the same settings over and over and over again. Some of these are small changes (but I never remember to do them all when creating a new workspace) such as toggling line numbers on text editors, java type decorators etc.
There already is a configuration preference scope (see the class ConfigurationScope in the org.eclipse.equinox.preferences plugin). However, the UI doesn't currently expose a way for users to put settings in that scope.
*** Bug 158307 has been marked as a duplicate of this bug. ***
Imagine that a project is composed of several sub-teams. Each of these sub-teams owns a set of plug-ins. For example, there are the core, ui, and examples teams, and they each have slightly different guidelines. If the core team decides to enable PDE compile settings to show un-resolved references as errors, someone on the team must override project settings on each of the projects. This is time-consuming and error prone. As a user, I would much prefer a mechanism to say, override these settings on a set of plug-ins.
(In reply to comment #4) I would also like something similar. Could it be done per working set or are working sets too temporary?
I understand what drives the idea in comment #4. Overriding things like warning levels seems fairly innocuous, but I wonder about doing this in general. What happens if you override a setting that actually impacts how the output is generated? Doesn't this lead to "it works when I run it, but not when you do" scenarios that are potentially difficult to diagnose?
*** Bug 160452 has been marked as a duplicate of this bug. ***
i use a dual boot (xp and ubuntu) and hope that making the preferences independent of workspaces they could also become independent of the OS and work for both.
Marking as FIXED as we are now heading into release candidates.
>Marking as FIXED as we are now heading into release candidates. Can you explain what part of this plan item got actually fixed?
Look at the dependant bugs. The main new feature was the settings transfer support added for 3.3. Bug 76850 and Bug 165690 describe the newer features.
k. Thanks. I was also expecting from this plan item that I (as a user) can share (some of) my settings amongst my workspaces automatically i.e. not just via export/import.
We have an action plan for that but it requires API and enough interest for us to be able to get it in for a plan item.
Marking VERIFIED
This bug was marked FIXED sine Eclipse now supports cloning settings when cloning a Workspace. For those who are interested in sharing settings across multiple configurations or workspaces, see bug 70683 for a follow-up discussion.
