Community
Participate
Working Groups
Created attachment 192544 [details] Code and tests Hello all, I would like to contribute Eclipse preferences mechanism to e4 incubator. The description of the capabilites can be found in the Eclipse Labs http://code.google.com/a/eclipselabs.org/p/e4preferences/
The code was criticized in various places (blog, wiki, forum) for introducing new API, because there were earlier attempts to improve preference handling mechanism, and the service is still far from perfect, mainly because of issues described in bug 334016 comment 15: > Exporting all preferences does not mean that all significant > preferences are exported(only the initialized ones), and even if they are, they > can overwrite preferences that should not be overwritten (like local paths). > Manual modifications of epf files also may fail due to implicit dependencies > between them. As you probably know, two GSoC project related to the preferences mechanism has been accepted this year and I will mentor them. I together with students would like to address major concenrs and remove as much new API as possible. This means practically starting from scratch. The list of requirements is following: - Meta attributes for each preference Current prefernce holds only the value. It is not enough, as some additional information should be also stored, like if the preference is exportable, if it is default, if it was discovered or what group it belongs to. - Preference groups/tags Currently preferences during export are flat. It should be possible to annotate them with a tag, and then the user would be able to export all preferences with a certain tag. Groups/tag will not be dependent on plugins. - Exportability metatag Some preference are not supposed to be exported ever (f.e. 'Do not ask me again' checkboxes). It should be possible to declare it during preference - Advanced export/import Since the preferences will be organized into tries/categories, it will be possible to import/export only certain preferences. It will be also specified if during import the preferences should be merged or overwritten from a particular group. - User and Enterprise scopes (optional) A user will be able to store the preferences which will be shared across various eclipse instances. - Moving preferences across scopes (optional) It should be possible to move particular preferences/groups from one scope to another one (at least to move certain preference from (local) instance to (shared) user). Any comments are welcome.
There is nothing platform-specific, am I right?
(In reply to comment #2) > There is nothing platform-specific, am I right? Currently EPreferences provides patch to Eclipse 3.7 introducing extended preferences import / export gui mechanism. However we plan to integrate this with Eclipse e4 soon. The comprehensive description of both GSoC proposals and chosen comments from the Google Melange system can be found at: https://docs.google.com/document/d/1Oycdp3N1V6_jM2H633sMUWVb141J5_dAreoNgZsMlYI/edit?hl=en&authkey=CIKb1ZsC We invite everyone to read and discuss about the proposals. All comments are welcome. We hope to begin a discussion that will enable us to clarify the functionality that would be beneficial to the Eclipse e4 project.
IPreference is marked as @noimplement but IPreferenceService is not. Do you actually intend to allow alternate implementations of IPreferenceService to exist or not?
Our intention was to enable developers to create their own implementations of provided services - e.g. different IPreferencePersistenceService that would store preferences in a database instead of file. In that case IPreference shouldn't be marked as @noimplement, because when the whole IPreferenceService is reimplemented, in some cases providing another IPreference implementation would be desired. However I am not sure if anybody would need to reimplement the whole IPreferenceService so maybe this specific service should be marked as @noimplement and the IPreference should stay at it is. (In reply to comment #4) > IPreference is marked as @noimplement but IPreferenceService is not. Do you > actually intend to allow alternate implementations of IPreferenceService to > exist or not?
I think that certain requirements like the ability to group/tag preferences require more sophisticated API then the existing one. One idea that we have already tried was to come up with a new API, which is a lot of work to do, and even more work to propagate. Curretnly I think rather about patching IEclipsePreferences and adding new functionality there (as long as pure preferences are regarded). Import/Export is less controversial - it is just UI :). Adding Thomas to CC.
(In reply to comment #5) > Our intention was to enable developers to create their own implementations of > provided services - e.g. different IPreferencePersistenceService that would > store preferences in a database instead of file. I think that if it's possible for a client to swap in an alternate methods of storing and retrieving preferences then there is probably not a need to do more stuff.
Hi, certainly a better API for deal with preference is welcome but wouldn't be better to extend the OSGi Preference Service (http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.equinox/compendium/bundles/org.eclipse.equinox.preferences/?root=RT_Project) as the base API for E4 ? At least would be nice to have a generic UI page to show preference data from OSGi Preference Service.
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 and remove the stalebug whiteboard tag. 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. --
