Community
Participate
Working Groups
This enhancement requests that: 1. The markup for each editor and view includes an optional "properties" tag, that specifies a property page that is associated with the editor type. 2. A "properties" action be added to the system menu for all participating parts. That is, by right-clicking on the title of a view or editor and selecting "properties", the user will be shown all the options that apply to the selected type of view or editor. 3. Whenever an editor or view type is shown in the preference pages, it is given a context menu with the "properties" action. For example, the "File Associations" preference page contains a list of editor types in the lower half of the page. Right-clicking on the Build Properties Editor and selecting "properties" should open the property page for that editor. 4. Two new root categories should be added to the Preference dialog. The "Editors" category will contain all the editor preference pages (pages will be named by their editor type). The "Views" category will contain all the view preference pages.
What is the use case? During 3.1, it was my impression that we were trying to reduce the number of preferences and preference pages. This would be a facility that would encourage more preference pages. Are you proposing that the current "Editors" group in "General" become a root group? Is the distinction between views and editors necessary? If not, why do you feel that it is important to separate them? (thanks writing such a clear enhancement request)
I think all Stefan is after is the sort of thing that the Java editor does with properties in a general sort of way. I think you will find this is more useful for preferences however - properties are usually related to the resource not how the editor works.
Re: comment 1 I don't see a specific need to segregate editors and views. I only proposed doing so on the assumption that users may find this more intuitive, since they are segregated elsewhere. Presumably a well-presented UI that included both in the same list would be just as good. Re: comment 2 Yes, I was referring to preferences. The function of this enhancement is: - To improve the organization of our preference pages by moving all preferences that are specific to one part type to the same place (currently they are scattered). - To make part-type-preferences easier to find by allowing them to be accessed directly from a part of that type. - To ensure a consistent presentation for part preferences. Some parts (like the progress view and problems view) have rolled their own preferences dialog, some views (like JUnit and the package explorer) do configuration via the view menu, and other parts (like the console view and most editors) include part configuration options in global preference pages. Offering a general facility would keep the UI more consistent.
Bug 98544 has been filed about the progress view. I believe the problems view is consistent with other views: it has one or more view menu items controlling presentation. These presentation menu can be checkbox items, radio buttons or more complex presentation preference controlled via dialogs. Consistency is good, but in this case I'm inclined to feel that localized preferences are better than preferences added to some central preference dialog (even with localized access points). So, I would encourage you to file bugs against components that go against spirit of the Eclipse User Interface Guidelines: + "Use the view pulldown menu for presentation commands, not selection-oriented commands. These are commands which affect the presentation of the view, but not the objects within the view. Do not put presentation commands in the context menu. For instance, the Sort and Filter commands within the Navigator view affect the presentation of resources, but do not affect the resources themselves." + "The Preference Dialog is used to edit the global preference for a feature in the workbench" + "A preference page should not be used to expose the local options for a particular instance of a view, editor, or window. In this situation, the user will look to the menu and toolbar of the control itself to customize it. If these options are exposed in the Preference Dialog, it will blur the location of customization, and confuse the user." If we had some way to search for individual preferences in the preference dialog (i.e., as opposed to the page-granularity we have now), then I could see a stronger argument for having them in a central location. From a user's perspective, how does it help them to have view/editor presentation preferences in a central location? Would it be appropriate to add a "view" menu to editors, allowing localized control of presentation preferences?
Actually, the main intent of this PR is to provide a general framework (with a consistent API, look & feel) for localized preferences. Also including them in a global location is an additional feature. A generalized framework has the following benefits: - Possible to open the preferences for a part without opening the part itself (such as from the context menu when the part's name is shown). - Consistent look & feel - Makes it easy for programmers to "do the right thing". - Allows for the possibility of also having localized preference stores, solving several common persistence issues (ask me). Additionally including them in a global location has the following benefits: - Makes it possible to import/export localized prefs with the rest - Teams who are currently using global prefs will be more likely to adopt the new system. - Advanced users who know exactly what prefs they want to change can quickly configure a new Eclipse install without hunting through the whole UI.
Moving Dougs bugs
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
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. 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.
