Community
Participate
Working Groups
Provide user preferences. It should be possible to store user preferences that are not specific to a workspace separate from the workspace, so that they can be used in any workspace. [Platform Core, Platform UI] [Themes: User experience; Rich client platform]
*** Bug 37217 has been marked as a duplicate of this bug. ***
See bug 37289 for interesting use case and related issues. I think this will be more of a core item since preferences live in core.runtime plugin.
*** Bug 37289 has been marked as a duplicate of this bug. ***
*** Bug 37799 has been marked as a duplicate of this bug. ***
This item has been generalized slightly. Revised title and description: "Provide user settings. It should be possible to store user settings (preferences, compiler settings, repositories lists, etc.) that are not specific to a workspace separate from the workspace, so that they can be used in other workspaces or by other users. [Platform Core] [Themes: Rich client platform]"
Bug 37471 also raises this issue and recommends possible solutions.
*** Bug 37471 has been marked as a duplicate of this bug. ***
The initial document describing this problem has been posted at the following URL: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm- home/docs/online/team3.0/settings.html The term "user settings" can mean different things to different people so the first goal is to ensure all of the relevant scenarios are documented. If you know of a scenario that is not covered, please let me know either by annotating this bug report or posting on the platform-core-dev mailing list. Also, a first cut at defining a solution is also included so feel free to comment on that as well.
In 'Scenario 2', the claim is that pre-configuring some settings by branded products is something that needs to be done. However, we already have that mechanism - I know for a fact that product teams can change things like the default perspective, the default editor for a type etc. by dropping their plugin_customization.ini in the primary feature plug-in.
This is a good start but I found some things that don't seem to be covered: 1. User specific settings A user may wish to have certain settings that are valid regardless of which workspace is used. Some examples: code templates, editor auto-closing options, file associations between filetypes and editors. Currently the user must pick a workspace as the 'master', make changes only to that one, export preferences, and import in all her other workspaces. 2. Organization-wide settings Some settings are common for everyone in an organization, so it is a waste of time to make everyone in the company set them. Also it is a source of tech support calls if they don't set them right. These settings change slowly over time, so the initial configuration scenario would not address it. Some examples: proxy settings, update sites urls, cvs ext connection method variables, team file content and ignored resources. 3. Policies Some settings may need to be fixed by policy and not changeable. In a large organization this is helpful to cut down on tech support problems, especially as less sophisticated users are exposed to Eclipse through RCP applications. But even for programmers, there are examples such as CVS ext connection method, C file tabs-vs-spaces setting, or CVS watch/edit setting. I believe the search order under "Determining the value of a setting" could be modified to address these by adding "user" and "organization" to the end of the list, plus adding the concept of policies that allow organizational management of settings that are and are not allowed to be changed.
Before implementing a proprietary preference store mechanism, the Java 1.4 preferences api should be looked at.
*** Bug 14024 has been marked as a duplicate of this bug. ***
See bug 39654 for an example user problem
*** Bug 39654 has been marked as a duplicate of this bug. ***
The next document describing a proposed solution has been posted at the following URL: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm- home/docs/online/team3.0/settings_solution.html If you have feedback, either annotate this bug report or post on the platform- core-dev mailing list. It is planned that the implementation will begin in 3 weeks so please provide feddback before than.
Important thing for me would be the ability to export and import the preferences (like debug, run, checkstyle setting etc) in tha fashion they can be either overwritten or merged. I know it is somewhat challenging because the absolute path in preferences might be different on export and import machine. Maybe it would require user to specify the new path or editing or ...? For example I run Eclipse on laptop, desktop, Linux box and Solaris box. And I would like to be able to move preferences like debug/run tasks, from one box to another without recreating them.
What is the API to get the platform settings location? Somoe plugins need to store platform settings as files;I am specifically thinking about help index files and update manager configuration files. My understanding of the spec suggests that we need to get a handle of an ISettingLocator and call its getSettingsPath() method, then use that location to write more files.
In Re; to Comment #16 you already _can_ share your debug/run tasks. I do this to do precisely the same thing you are wanting. Just use the "Common" tab and share it into the project (which is presumably shared with your other computers via CVS or something). Of course, some of the settings might be different, but you'll be able to duplicate the, say, linux specific launcher from a windows launcher.
From Steven Ma: Currently (Eclipse 2.0), entries under each node inside the Preference page are alphabetically ordered, when in most cases, it makes much more sense for the end users to see them arranged and clustered together in some functional order. The lack of support for programmatically arranging these entries make it time consuming for users to find what they need.
*** Bug 39948 has been marked as a duplicate of this bug. ***
As the structure of preferences becomes more complex, I believe that Eclipse should look at storing preferences as XML which is capable of expressing most reasonable structural requirements. I feel that this is a better solution than forcing users to "roll their own" complex structures embedded in strings
The IMemento interface and it's impl XMLMemento are part of org.eclipse.ui.workbench. Currently Eclipse references these types only from ui packages which is ok. But regarding this issue, wouldn't it also make sense to put it into org.eclipse.core.resources to make it available to other core plugins that don't need other ui types than this but need to easily write back any data as xml using the mememto mechanism. Perhaps an IMemento could also be used to hold preferences, while I think it should be wrapped or extended to support more types than float, int and String.
Mementos are extremely flexible and easy to use so +1 on comment #22. Perhaps they could be worked into a prominent place in the overall settings proposal. They weren't addressed in the last draft I read.
*** Bug 44047 has been marked as a duplicate of this bug. ***
*** Bug 44192 has been marked as a duplicate of this bug. ***
Reassigning to Doug who is now heading up this work.
I have a related request and will be happy to open a new bugzilla for this if that would be preferred. Preferences pages can use FieldEditor subclasses to tie user interface elements directly to the underlying preferences store. I recently had the pleasure of implementing a fairly sophisticated Launch Configuration page and it would have been nice to reuse the field editors concept there. However, preference pages use IPreferenceStore to keep their settings, and launch configurations use ILaunchConfiguration or ILaunchConfigurationWorkingCopy, so FieldEditor can't be use on a launch configuration page (*). As part of the merger of user settings and preferences into a unified api, I'd like to see the field editor classes be easily sharable in these two contexts. *: Note I found one attempt to merge the two in org.eclipse.jdt.debug.ui.launchConfigurations.JavaConnectTab but it was very kludgy looking.
I think that we must also consider : - Per-project settings which should be stored in the workspace, in a text/xml format so they can be put in source control and merged easily - Global settings, which we should also allow to be in the workspace (maybe in a specific project) so that all people within an organization can share them easily.
*** Bug 45904 has been marked as a duplicate of this bug. ***
From Bug 45904: "Certain preferences, such as many of the Java ones, do not make sense to be a per-workspace preference, as my coding style or JavaDoc templates are generally not going to change from workspace to workspace. It would be nice if a mechanism to allow preferences to be marked as "global" (i.e. not per-workspace) existed, rather than relying on exporting from one workspace and importing them into another."
NetBeans has a concept of Project, User and Default settings. Project settings apply only to the project. User settings apply to all projects by the current user. Default settings apply to anyone using the same installation (i.e., they are written to the install directory). The granularity for these preferences is per-page. So, for example, there is an "Ant Settings" page. This page specifies things like default compiler, input handler, verbosity level, etc. The user can specify all of the settings on that page to belong to one of the three levels (i.e., Project, User, Default). They cannot, however, say that the default ant compiler is a user setting, while the verbosity level is a project setting. Also, note that being able to specify something as "Default" (i.e., applying to the installation) would almost certainly violate the Filesystem Hierarchy Standard, which is part of the Linux Standard Base. Basically, we can't rely on the installation directory being writable. Other things to consider: + KDE provides a slider when KDE is first started. This slider can be used to control performance-specific characteristics of KDE. So, for example, you can slide to "slower processor, less effects" and it turns off most (if not all) of the eye candy. So, essentially, they provide a mechanism for associating values for settings with a group. The slower processor group might have an association of "animateMenus=false", while the faster processor group might have an association of "animateMenus=true". + Applications that are used by non-technical staff sometimes support a concept of "policies". These are groups of settings that are defined by the technical support staff, and can easily be exported to each configured machine. This allows the support staff to dictate a common set-up to help minimize support calls. With the move toward a Rich Client Platform (RCP), we might see our platform being used as a basis for a non-technical application (e.g., word processor, email client, etc.). Having built-in support for policies might be useful.
*** Bug 48155 has been marked as a duplicate of this bug. ***
In addition to Comment #31: I used Netbeans for a long time and I like the preference mechanisms. In my opinion it makes sense to provide different levels (default, user, project) for each properties. It would be great if you could set the level for each setting without loosing the configuration of the other levels. I.e. if you have a default severity in your logging plugin of "warning" and you change the user or project setting to debug, you should be able to undo you changes and apply the default setting. Also you should be able to share project settings via CVS (user settings shouldn't be shared, for the default settings, I can't rate the consequences).
This is what we are planning on doing for M8. This will likely be what appears in the final 3.0 product. Platform Core is providing a concept of 4 levels of preferences: user, config, instance and project. User settings apply to all Eclipse-based products for the same user. Config settings apply to all instance of a particular Eclipse-based product for a particular user. An instance is equivalent to the Eclipse IDE's concept of a workspace. Project is a discrete piece of an instance. Project settings can be local (applying only to the instance in which they were created) or shared (via CVS, for example). The majority of the current set of preferences will be moved to the "config" level (seamlessly). Preferences with absolute paths will remain in the "instance" level. Plug-ins storing absolute paths in preference will be expected to modify their code so that their reading/writing of absolute paths goes to the "instance" level. The export preferences mechanism in Platform UI will use the "config" level of preferences. The import and export dialog will also provide advanced options for exporting and importing. And both import and export, the user will be able to select the individual preferences to export or import. On export, we are also hoping to provide a mechanism such as "export from current preference page".
Pardon my ignorance but can I just ask how is it decided which preference is available at which level? Or will all preferences be available at all levels, and the lower levels overriding the higher levels.
I think that you should have the opportunity to override upper-level settings with lower-level ones. An example from my perspective as a plugin developer is the following: I've written a plugin to enforce implementation restrictions. You should be able to set up the checks which should be performed for the project at project level. But a developer should also be able to deactivate some checks through development. So I think that overriding preferences based on the hierarchy is a good idea.
The first cut of the new preferences API has been released to HEAD and can be found in the org.eclipse.core.runtime.preferences package. Doc to be updated and posted soon.
I'm currently investigating/working on a solution for layering preference stores for jdt.ui. Some preferences that are available from the workspace preference store can be overridden by the project preference stores (e.g, Task Tags, Compiler Options affecting Code Formatting). We basically want to access a single preference store for project and workspace perferences and be notified on visible changes (a project preference can hide a workspace preference change). The slightly dated document (revision 1.13) referenced by comment 15 describes in section "Default Value Determination" a mechanism that allows project settings to override platform settings. This would (as I understand it) solve the preferences layering problem above. Will this or something similar be part of the upcoming settings implementation?
Yes. I'm currently working on updating the doc but here's a brief overview. - Different preference "scopes" are defined. The Platform contributes "user", "instance" (very similar to per workspace), "configuration" and "project". - There are APIs (IPreferenceManager) which aid in the preference value look-ups across scopes. A default lookup order (e.g. "first look in the project then in the workspace") can be set. - The preference value change notification mechanism from Eclipse 2.1 remains so you will be notified of changes to your preference.
APIs have been updated in HEAD.
What seems important to me is to also start discussions about how we intend to present the new capabilities in the UI (the preference pages): Will we show the separation of user and instance settings on preference pages, do we let the user decide about where a setting is stored (like the approach in comment 31), or will we not show this difference in the UI, but e.g. only allow the user to store 'user settings' with an export so the are used with the next created workspace? If the 'preferences team' already has some ideas I would be glad if you could add them here or even to the document. Please open a new bug if you prefer to keep this bug a 'core' bug. The idea of full configurability is of course thrilling (all the power to the user!): For each setting define where is stored. Have UI to override each setting with more specific, showing the context hierarchy. I would like to add that it sounds easier than it is: Having worked on JDT.UI's project specific settings (compiler, task tags) we finally chose a UI that only supports overriding all or nothing. A per setting configurability was considered as too complicated, in terms of usability and also of development time required. Note that this was with a simple story of two scopes, but now we would have a three.
Hi Martin, sorry for the delay in response. Perhaps it was because we all agree that displaying all the information to the user is indeed a difficult task. Now we have this extensible preference mechanism at the core level but we have to be very careful how we surface this to the user so as not to confuse them. For now we are leaning towards not changing a lot in the ui for 3.0. One thing that is currently being done is work on improving the import/export mechanism by providing filters. I'd also like to try and get some teams on board with project preferences. (via the project properties pages) Check out comment #34 by Doug. It is still accurate except the one thing that we have changed is that current plug-in preferences are equivalent to "instance" preferences. We decided against converting them all to "config" preferences for free for a number of reasons, including (and perhaps most importantly) that plug-in developers orginally wrote their preferences with the intentions of the values being stored on a per workspace level. We are investigating a promotion mechanism between levels. We are open to all ideas related to user settings and their display, and this bug report is probably the best forum for discussing them. Feel free to annotate with comments. As a side note, I have put together a quick faq for the core side of the preferences work. Its available at the following link. Comments are appreciated. http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/user_settings/index.html
Copy of a post to eclipse-dev with a target audience of plug-in developers: ------------ Here is an update on the preferences work. Conversion ======= If you contribute preference pages, you should not be converting them to the new APIs yet. Continue to call Plugin.getPluginPreferences(). The backwards compatibility layer will suit your needs. If you have information which is currently not stored in preferences and not displayed in the preference pages (e.g. list of repository providers), then feel free to start using the new APIs. Also, people with project preferences that they would like to share are encouraged to look at the new APIs. Scopes ====== We have decided not to implement a User scope for 3.0. The user scope was intended to mean preferences stored on a "per user basis, across all configurations and all workspaces". (there is still the option of adding it at a later time) The class UserScope will be removed in the nightly builds and for the next integration build. The Configuration scope refers to preferences stored in the configuration location. It will still exist in 3.0 and allow users to share preferences across the same configuration. (e.g. single install, multiple workspaces) See related bug report on a proposal for the configuration location. https://bugs.eclipse.org/bugs/show_bug.cgi?id=54919 Directory Structure ============ The directory structure will change to "<scopeRoot>/.settings/<qualifier>.prefs" For instance: "/workspace/MyProject/.settings/org.eclipse.core.resources.prefs" Clients will still have access to the "scope location". (e.g. /workspace/MyProject/.settings) Documentation ========== Available at the following link (might be split across lines): http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-core-home/documents/user_settings/index.html Comments and discussion encouraged on the platform-core-dev mailing list or in the associated plan item bug report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=36965
In comment #43 you say that the user scope will be removed. I'd appreciate if you could think about that. I can imagine several appliances of such a scope - e.g. individual code formatting. If it's a matter of time, i'd suggest to implement in a 3.1 release or so.
Its important to note that we will still ship Eclipse 3.0 with the "configuration" scope. This means if you install Eclipse 3.0 and have 100 workspaces, then any preferences stored in the config area will be shared with all 100 workspaces. The scenerio of us Eclipse developers (read: having multiple Eclipse versions installed on the same machine) seems to be an odd case. We envision most products to have one version installed per machine. (e.g. how many versions of Word/Photoshop/etc do you have and run at one time?) Of course we are definately not saying that we don't ever want a user scope, we just won't be shipping with one in Eclipse 3.0. We will most certainally re-visit the subject (and perhaps come up with other scopes too) when working on 3.1.
What does this mean for an installation on the server or on a Linux box as root on a system with multiple users?
The configuration scope refers to the "user's writable config area" as described in the equinox proposal. Settings storing in the "sharable non-writable config area" will be integrated as part of the default settings and the plug-in customization story.
Tried out the sample code in the FAQ for this option: > How do I convert my project property page to use project preferences? Two items 1) This line: > Preferences node = context.getNode("org.eclipse.jdt.core"); Seems like it should be this: > IEclipsePreferences node = context.getNode("org.eclipse.jdt.core"); Mine worked that way, but that was the solutoin I stumbled on using JDT assistance before I considered the org.osgi.service.prefs.Preferences option. Maybe either is fine unless I need the API provided by IEclipsePreferences? Or restated; Should we be directly using the osgi implementation or restricting ourselves to eclipse interfaces? 2) Shouldn't the write of the .settings folder and its node.id.prefs file trigger a refresh to get these added as workspace resources? How else would they become visible to others via team sharing (my assumption on the intent of a project scope user setting). I tried it twice with two different M8 configurations, neither time is the .settings content visible in the workspace.
Like you mention, use of either interface is fine. Perhaps I was just using the osgi one because it has a shorter fully-qualified name and formats better in the html page. :-) Bug 55289 refers to project preferences and detecting changes in the file-system. This has been fixed post-M8.
User interface integration of these different preference stores is being deferred from 3.0.
We have a Eclipse preferences file in the repository. Every developer in the team uses this preferences file. This preference file is constantly updated and then every developer checks it out and imports it so that his Eclipse uses the latest preferences. Unfortunately this means all-or-nothing. If a developer for example has some uncritical custom settings like the color of current line highlight, then his setting is replaced each time he imports the preference file. Does the preference file for the whole team need to be manually maintained so that it only contains the settings for the whole team? What do you recommend?
Re Bug 36965#c51 - what you want is not so much user settings but instead customized defaults. Both 2.1 preferences and 3.0 preferences and user settings typically support the customization of defaults. This is a service supported by the branding plugin for the primary feature (2.1 mode), or the active product (3.0 mode). The file is typically called plugin_customization.ini and for the eclipse sdk it is found in the org.eclipse.platform plugin. You can change it directly, or learn to use eclipse invocation parms to identify your own. You can still share this file via the repository, but instead of importing as preferences, just net it down to only the keys you want standardized. Every workspace you open will have these as the default values. The approach is documented in http://www- 106.ibm.com/developerworks/opensource/library/os-ecfeat/ Many of the 2.1 values will be the same for 3.0, but there are new ones of course. I've started my list for 3.0 but have not gotten to far yet - I've added these so far to my own product definition have: # This entry changes the default for perspective text to no org.eclipse.ui/SHOW_TEXT_ON_PERSPECTIVE_BAR=false # new-style tabs by default org.eclipse.ui/SHOW_TRADITIONAL_STYLE_TABS=false # put the perspective switcher on the top right org.eclipse.ui/DOCK_PERSPECTIVE_BAR=topRight
re Comment 52: Wow thanks Pat. That is a big help. Now if there was only a way to do something similar with projects. I.E. whenever a new project is creted all the developers get it in their workspace. We use StarTeam 4.2 and there isn't any plug-ins that allow us to use StarTeam from within eclipse. However if the project specifications were in a version controlled file things would be a lot better.
More preferences bugs....
Reducing priority until we see where this shows up on the 3.1 schedule
*** This bug has been marked as a duplicate of 71124 ***
