| Summary: | [plan item] Overhaul preferences | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jim des Rivieres <jeem> |
| Component: | UI | Assignee: | 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.0 | Keywords: | plan |
| Target Milestone: | 3.1 M7 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 43506 | ||
| Bug Blocks: | 69093 | ||
|
Description
Jim des Rivieres
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. 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. *** Bug 70683 has been marked as a duplicate of this bug. *** 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. *** Bug 36965 has been marked as a duplicate of this bug. *** 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. 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. 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. We have done the reorganization for M7. Perhaps the title of this bugzilla should have been "Reorganize preferences". Verified in 20050510 |