Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 71124

Summary: [plan item] Overhaul preferences
Product: [Eclipse Project] Platform Reporter: Jim des Rivieres <jeem>
Component: UIAssignee: Tod Creasey <Tod_Creasey>
Status: VERIFIED FIXED QA Contact:
Severity: enhancement    
Priority: P2 CC: amanji, bogofilter+eclipse.org, daniel_megert, dev, dj.houghton, eclipse, eclipse, eclipse, ed.burnette, goerge, gunnar, hudsonr, jean-michel_lemieux, jeffmcaffer, johnsmith1492, kpeter, lindawat, nikolaymetchev, peter.schaich, tjbishop, vimalvachhani
Version: 3.0Keywords: plan
Target Milestone: 3.1 M7   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on: 43506    
Bug Blocks: 69093    

Description Jim des Rivieres CLA 2004-07-29 17:45:01 EDT
The way that Eclipse deals with preferences should be improved. The workbench 
presentation of preferences generally uses a component-oriented hierarchy, 
which is not always the best choice for users. The UI should present 
preferences in such a way that users can readily discover them. Some 
preference settings have scopes (e.g., workspace-wide vs. per project). The UI 
should help the user to visualize these scopes. For team-wide uniformity, some 
preferences settings (e.g., compiler options) need to be shared (or imposed) 
across teams. The UI should also facilitate this. [Platform Core; Platform UI; 
Text; JDT UI; JDT Core]
Comment 1 Jim des Rivieres CLA 2004-07-29 17:46:09 EDT
See also bug 59258.
Comment 2 Randy Hudson CLA 2004-08-03 12:00:10 EDT
Preferences should be reachable from the Part or UI which they affect. The
Synchronize View is a good example of this in 3.0. Instead of having a hidden
page in the global list of preferences, they chose to have a dialog displayed
from an action in the view's local menu.

Comment 3 Peter Schaich CLA 2004-08-09 08:26:06 EDT
I have a general enhancement request related to this plan item: How is the
official way to bring it into discussion for 3.1 or later? Should I post this
to eclipse-dev@eclipse.org?

Extend Preference Framework to enable global validation of preferences

When using Eclipse as a Rich Client Platform preferences like a database-url,
external file locations, internet-urls etc. are commonly used. The status of
these preferences not only depend on the internal work with the eclipse platform
but also on external changes, e.g. changes of file locations etc.

!!!! In order to check, if all preferences are valid (i.e. after the
installation of a rich client) today one has to open every preference page with
a preference likely to have "external dependencies" and see if there is an error 
reported by eclipse when changing to the next preference-page. !!!!

Enhancement: for every preference there should be a validation interface, that
can be implemented for a specific preference like a db-url. additionally there 
is a global action for checking all preferences of an installation.
Comment 4 Tod Creasey CLA 2004-08-18 11:19:04 EDT
*** Bug 70683 has been marked as a duplicate of this bug. ***
Comment 5 Randy Hudson CLA 2004-08-18 11:39:34 EDT
See also bug 10966. "Duplicate" Bug 70683 talks about configuration-wide 
preferences, which isn't mentioned in this bugzilla.  (Well, now it is I guess 
<g>).

I don't think marking everything as duplicate of this bug is the best 
approach.  Using "depends on" would make it easier for us to see progress, for 
the team to prioritize/delegate tasks, and allows items to be deferred.
Comment 6 Tod Creasey CLA 2004-08-27 11:04:43 EDT
*** Bug 36965 has been marked as a duplicate of this bug. ***
Comment 7 Jean-Michel Lemieux CLA 2004-09-08 10:01:05 EDT
Does this plan item include porting FieldEditors to be usable with the new
runtime Preferences? Currently you are forced to use an IPreferenceStore with
FieldEditors  which means that all preferences are taken from the default scope.
Comment 8 Jean-Michel Lemieux CLA 2004-11-04 11:11:33 EST
It would be cool to be able to search the preference pages and allowed to
navigate the result set as a filtered set of pages with highlighted labels on
the page that show the preferences that matched.
Comment 9 Randy Hudson CLA 2005-02-07 11:15:39 EST
Here are some ideas for overhauling prefs.  BTW, if there is anything 
happening behind the scenes, it would be great to see some proposals or 
preview of what is to come.

- I'd like to see the preferences for the editor I'm using right now.  So for 
JDT's CU editor, show me its keybindings, syntax highlighting, quick diff 
settings, fonts, etc.

- Some preferences allow flexible, hierarchical configuration. Fonts for 
example. For text-based editor, I can either inherit the basic text editor 
font, or override it for a specific editor type. The same for keybindings. I 
can override "Delete Line" in the Java Editor to be something different, or I 
can have it inherit the more general value. *Every* preference should be like 
this: Tab Width, Print Margin Column, etc. Of course, I don't want 100 
more "Colors and Fonts" preference pages. I want a page which slices 
orthogonally to the way colors and fonts does. It would probably have to be 
populated dynamically similar to the propertysheet.
Comment 10 Tod Creasey CLA 2005-04-25 10:51:12 EDT
We have done the reorganization for M7.
Comment 11 Randy Hudson CLA 2005-04-25 11:03:48 EDT
Perhaps the title of this bugzilla should have been "Reorganize preferences".
Comment 12 Tod Creasey CLA 2005-05-10 14:39:40 EDT
Verified in 20050510