Community
Participate
Working Groups
Based on bug 194414 and bug 70683, and from a discussion on http://wiki.eclipse.org/E4/Resources/Meeting/14-Nov-2008#Discussion We should have one common (EMF-based?) model of Settings and Preferences on all levels and components: ranging from (installation/team/user/workspace) Preferences over Project Properties down to build settings and the like. Having all these in one common model would allow for advanced queries (using OQL), advanced sharing/levelling scenarios while still keeping control over where settings come from, down to allowing Policies for what users are allowed to change what settings, or even hiding unwanted/unchangeable settings by matter of installation policy from respective pages. The big trick of this will be to move more validation functionality as well as knowledge about relationship of settings between each other from the UI (property, wizard) pages into the non-UI Preferences Model. Having a model of these interrelationships should allow for less code and bloat, better control, avoidance of duplication and coding errors. Naturally, more complex levelling/sharing scenarios may need more complex UI for setting and understanding these. But having a common model would allow this effort to be needed only once. The model would allow to do reasoning ("Why is setting x set that way") in user assistance popups down to advanced merge scenarios for applying a setting to multiple components.
This is different from what Martin describes above, but another approach is for the modelled UI to have a model of each preference page, including how each button and field relates to some underlying preference storage (somewhat like FieldEditor, but for the entire page). That would allow for things like using the same preference page in different scopes (project, instance, etc), and showing/setting preferences against a multi-selection of projects. This has been discussed in the past but I can't find a relevant bug discussion. My feeling is that you can't create a model rich enough to completely automate preference page creation without getting into UI issues like labels for groups of preferences, logical grouping, hyperlinked hints, etc.
(In reply to comment #1) > My feeling is that you can't create a model rich enough to completely automate > preference page creation without getting into UI issues like labels for groups Originally I wasn't thinking about automated Preference Page Creation, there may still be some aspect of creativity when it comes to organizing items into a pleasant visual appearance, adding User Assistance hints and the like... but that's an area for the Modeled UI / Declarative UI folks to explore. What Michael and I were thinking about is a modeled representation of the functionality, validity and inter-relation of the settings. Arguably, some of the validators may be non-trivial and may have to be contributed in a programmatic fashion. But I'd still think that a model of the settings should be possible, and may be easier to maintain than programmed validators, listeners, selection/enablement updaters etc in the UI all over the place...
I like Martin's approach but such things as the interdependencies between preferences will introduce some issues but the idea of 'bundling' a preference as more than just its storage (i.e. label, description, validation rules...) sounds like an excellent idea to me. Note that there are severe issues with the current preferences story regardless of the chosen implementation...users can't -find- the preferences; there are far too many and the average user doesn't know the bundling structure enough to find the appropriate page, let alone the preference. We've tried to mitigate this with the pref page's 'keyword' search but its hit-and-miss as to whether you'll get to the right place. If we were to take Martin's approach I could see an automatically generated preference page that would simply take a list/array of preference 'descriptors'. Not only would this take a fair chunk of the UI effort devoted to creating and maintaining the actual preference 'page' out of the picture (partially, we'd still have to write the validators...) but would also allow 'context dependent' property sets to be shown. One possibility is this: We're about to open some view/editor. We set some sort of flag on the preference system that causes it to 'remember' which preferences are being asked for. Once the open is finished we get back a list of preferences that were actually *used* to create that part and we can then show a customized property editor that only shows these properties. This may have issues in that not all preferences that may be -possibly- used need be accessed on creation but it has the advantage of paring down the cognitive load and only placing preferences that do something in the users face.
On the EMF newsgroup, the "modeled Preference" approach was mentioned: http://www.eclipse.org/newsportal/article.php?id=38546&group=eclipse.tools.emf#38546 and related to the Extended Editing Framework proposal: http://www.eclipse.org/proposals/eef/
(In reply to comment #3) > Note that there are severe issues with the current preferences story regardless > of the chosen implementation...users can't -find- the preferences; there are > far too many and the average user doesn't know the bundling structure enough to > find the appropriate page, let alone the preference. We've tried to mitigate > this with the pref page's 'keyword' search but its hit-and-miss as to whether > you'll get to the right place. For me finding the right preference almost always takes more time than it should. For example on Java > Compiler > Errors/Warnings page (bug 315772).
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. --
