Community
Participate
Working Groups
1) Open a new workspace 2) customize some UI prefs, for example, define Close Perspective action to be CTRL+F12. 3) Open a second new workspace. Bug: the keybinding does not exist in the new workspace. Keybindings should be per configuration of Eclipse, since they customize plugins and not things which are in the workspace.
This will be done as part of the preference work in Bug *** This bug has been marked as a duplicate of 71124 ***
reopening since this was never addressed
Just dropping some thoughts. - where would we save those shared preferences? If we store them in the configuration area then each time the build is switched the preferences might change - especially when switching from a newer to an older build. Of course we could add some code that only reads the preferences if the used build is not older than the previously used. - not all preferences might make sense (or want) to be shared across workspaces. We would need means to control this - most likely via extension point. How would this be displayed to the user? - will it be possible for the user to explicitly set workspace and shared preferences as he can currently do with project specific settings? - during the JDT summit we had - I think good - idea how preference handling could be improved without adding configuration settings: allow project settings to be taken from another existing project. This would allow to have different settings for different features (set of projects) in your workspace and it would also allow to share those settings via VCM.
> - during the JDT summit we had - I think good - idea how preference handling > could be improved without adding configuration settings: allow project > settings to be taken from another existing project. This would allow to have > different settings for different features (set of projects) in your workspace > and it would also allow to share those settings via VCM. This is not a good solution. Basically, one project gets misused as the user- setting configuration area. And, one user's preferences get forced on everyone in his team through CVS. And, you have introduce artificial project dependencies. If $ECLIPSE_HOME$/configuration is not the perfect place for *user* data, then there needs to be core support for $USER_HOME$/.eclipse/.settings/..... , which is similar to what every other application I have installed does. Even Yourkit gets this right.
fixing mid-air collision
> Please post comments regarding how the preference should be shared among > workspaces into bug 70683. Is this bug *just* about UI prefs, or can we consider all sorts of prefs? If the former, is there a bug related to general sharing of prefs across workspaces? FWIW, I'd like to be able to share pretty much anything: code formatter definitions, perspective settings, keybindings, user-library definitions, etc., across workspaces. I tend to use a lot of different workspaces, and it's incredibly time consuming ( and annoying ) to have to customize each new workspace the way I like it. It seems like we could use a general way to have a "global" set of prefs, with the ability to override on a per project (and maybe per user) basis. I know this functionality would make Eclipse much more usable for me. Aplogies if this is the wrong bug for this discussion.
I think this is possible to achieve with plugin_customization.ini. However that feels very much like a hack. What would be nice is to have some GUI way of editing the plugin_customizition.ini file.
What happened in 3.3M4? It seems like rather than moving preferences from the workspace location to the user location where they belong, a large band-aid has been introduced which copies workspace preferences left and right. This is going to cause the same problem already familiar in JDT project preferences. Namely, there are attempts to keep things (e.g. per-project formatter settings) in sync, but if both preferences get modified in parallel or without copying/syncing, changes get lost or some type of magical merge happens.
We didn't make any preference changes in M4 - we did work around workbench settings. The change for user preferences was going to require API changes and so we decided to defer it as the community had other items they cared more about.
> We didn't make any preference changes in M4 - we did work around workbench > settings. Pardon the lack of knowledge, but what is a "workbench setting" and how is it different than preferences (i.e. myPlugin.getPluginPreferences()). I was using JDT's project settings as an analogy to a similar problem in which key->value collections get out of sync.
They are the internal settings stored by your dialog settings. We now have a way to copy them when you switch workspaces.
(In reply to comment #11) > They are the internal settings stored by your dialog settings. We now have a > way to copy them when you switch workspaces. But, what if I've modified multiple copies? How do you avoid losing my changes when I choose to copy? I've hacked 3.2's WorkbenchPlugin by copying down the method getPreferenceStore and changing "new InstanceScope()" to "new ConfigurationScope()". It's obviously not a perfect solution, but it is better than the other way. Keybindings are automatically shared across workspaces.
Eclipse already has some Preference Levels, based on the OSGi Preferences Concept: ConfigurationPreferences, InstancePreferences, ProjectPreferences. In addition to that, through the concept of Equinox Secure Storage, settings like Passwords are already stored on a per-user (installation-spanning) scope. It looks like a more generic user level is needed, and probably (for large multi-user teams) a team level, with following priorities: (1) User Preferences, overriding everything else. (2) Project Preferences (3) Team Preferences (from common team-shared location) (4) Instance (==Workspace) Preferences (5) Installation (==Configuration, ==Product) Preferences I'm changing the Summary to reflect the broader scope, previous value was: [Preferences] Support configuration scopes In the context of http://wiki.eclipse.org/E4, UI Styling and CSS are being discussed as one example of user preferences that should be able to span multiple workspaces. Some other ideas to address parts of the issue would be bug 245399 to have user Preferences span multiple workspaces, and bug 245405 to easily import team preferences. The really tricky part is how to present a UI where it becomes obvious from what level a particular Preference is being adopted, and how to override Preferences on one level (or clear them to fall back to the base level). It might be hard to get all this done without user confusion: the current Project Preferences UI shows one example, where overriding is only possible on a Preference Page granularity, although the settings files seem to indicate a per-setting granularity possibility. Additional User Level and Team Level could be handled similarly, with a level indicator right on top of each Preference Page. Import/Export of a particular level only vs. the combined Preference tree is another challenge. One different way out of this for experts, might be to support readable text-files or scripts to apply Preferences, similar to what Firefox does. Also, for the team concept, it might be worth thinking of Policies for some Preferences, such that users are not allowed to override certain settings such as compiler warning levels, for instance. There must be a balance between flexibility and ease of use though. Where to store the actual Preferences is an implementation detail that's much easier to solve.
Just noticed that anyone can register a new Preference scope: http://help.eclipse.org/ganymede/topic/org.eclipse.platform.doc.isv/reference/extension-points/org_eclipse_core_runtime_preferences.html Could that suffice to implement user preferences as an extension? I'm not sure since I don't understand how an order of priorities of Preference Scopes is defined for the scopes. Reference documentation for the core.runtime.preferences extension point is weak since it doesn't even mention the interface type that the provided classes must implement.
See also bug 194414 for sharing prefs among multiple projects
Created attachment 117448 [details] Screenshot of Prefs with User and Site Levels Here is a screenshot of the Preferences in a former product of ours. Each setting was decorated with a little icon showing the level from which the setting came (user level or site level). Opening the context menu on the leveling indicator allowed promoting/clearing/copying between levels. In Eclipse, "site level" would translate into "workspace level". Assuming that Eclipse Preferences could be stored in the workspace _or_ a user-private _or_ team-shared location, it would be nice if field editors could provide the leveling indication (it might be interesting to experiment with this in the context of e4).
(In reply to comment #16) > Created an attachment (id=117448) [details] > Screenshot of Prefs with User and Site Levels Another way to do the same UI is just have pages for each scope. Some Users might not have permissions to modify the "Site" scope, which would be awkward to express in the above UI. Also, how would an admin configure the Site's settings without first reverting his/her own personal changes? I think we're mixing in other problems here. "Inheritance" of preferences exists today even when both are stored in one place, like the workspace. For example, "Text Font", "Show line numbers", and "Print Margin" all are (or used to be) settings for both the generic TextEditor and JDT's CU Editor. I prefer to configure them on separate pages, although communicating whether a value is set or from where it is inherited would be useful. So, what is the scope of this bug? It sounds like some API already exists for creating preference stores almost anywhere, but one place (workspace) is given special treatment in that it is available from AbstractUIPlugin#getPreferenceStore(). As a result it was and continues to be misused. Configuration scope seems prone to misuse too. Do multiple users get prompted to open each other's workspaces (on windows)? So, how much code do clients need to type to store stuff properly, assuming they will correctly ignore the convenience methods? Also, how do we deal with the consolidation of existing, duplicate preference values originally stored in lots of (wrong) places? I'd like to limit this discussion to these issues and open additional bugs for related ones.
FYI we discussed this today in the context of e4 and came up with a suggestion on bug 255371 which sounds very exciting. Comments and help are welcome though our bandwidth for this may be limited...
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
See also bug 154097, bug 158307 and bug 160452 for related discussions, which eventually lead to supporting "a Copy Settings" option to clone a workspace. The issues discussed here are different, since we try to re-use settings from a common location (i.e. user / team scope) across multiple Eclipse configurations or Workspaces. The benefit of re-using versus cloning is that - when I have several very similar workspaces and - change a setting in one of them, - the setting gets automatically transferred into the other workspaces whereas the "clone" approach keeps settings separate once they are cloned.
Bug 160736 is also related, and although it is very old (from 2006), it has a patch attached which may still be interesting for exploring options to add preference scopes. Bug 103096 is about the concrete request to share syntax coloring settings.
As Dani correctly points out, bug 112130 covers two aspects: - import/export of syntax coloring (which is resolved, thus making that bug a "RESOLVED DUPLICATE" state, and - sharing of syntax coloring, which requires work discussed here.
(In reply to comment #3) > - where would we save those shared preferences? I just filed bug 301531, requesting a commandline switch to specify a custom location for the configuration scope Preferences. This should allow maintaining common configuration scope Prefs across multiple upgrades / multiple installs. I do not think that this approach would work for workspaces though, since the granularity is too coarse. Related to storage location: by reading http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.platform.doc.isv/reference/misc/runtime-options.html I found out that OSGi already knows the concept of a user area (osgi.user.are in config.ini. or -user <location> on the commandline). This would be a natural choice for the location of user level preferences. > - not all preferences might make sense (or want) to be shared across > workspaces. We would need means to control this - most likely via extension > point. How would this be displayed to the user? The org.eclipse.ui.preferenceTransfer extension point already provides a means for defining groups of Preferences that can be looked at together. I could imagine a UI similar to the current "export preference" wizard, which would allow me to choose Preference Groups which are to be shared across workspaces. Unfortunately, in terms of API the clients code currently explicitly requests a scope in which to store Preferences. This needs to be addressed on "write" and on "read". - Writing Prefs: One way for addressing this might be a global Preference Listener which listens to the "set" operation, compares the Preference Slot against the list of groups to be shared, and updates the user-preferences with the new value when needed. - Reading Prefs: For those preferences defined as "shared", the user scope could be cloned into the instance scope on startup. Note that "lightweight workspaces", that is: multiple workspaces in one Eclipse instance (as per bug 245399) might be a completely different approach towards sharing Preferences.
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. If the bug is still relevant, please remove the stalebug whiteboard tag.
