Community
Participate
Working Groups
Improve UI scalability. Despite efforts to ensure UI scalability with a large base of available tools, the Eclipse workbench still intimidates many users with long menus, wide toolbars, and lengthy flat lists of preferences. This problem is acute in large Eclipse-based products. The Platform should provide additional ways for controlling workbench clutter, such as further menu and toolbar customizability, distinguishing between novice and advanced functions, supporting different developer roles, and more specific object contributions for particular file types. [Platform UI, Platform Debug, JDT UI] [Theme: User experience]
*** Bug 36954 has been marked as a duplicate of this bug. ***
Hi, I am glad after reading the Eclipse Project Draft 3.0 plan that in eclipse 3.0 that this bug going to be addressed, but I also want the people who is going to address this bug to provide api's to do the menu and toolbar customization(i.e, allow us to remove unwanted menu items programmatically).If you are just providing the option to customise the menubar,toolbar manually like how you do in customising perspective then it won't be useful because when we want to develop non-ide applications we should not give it to the hand of end user for the customisation rather we should remove the burden of the end user by removing unwanted menu item programmatically. MorPheus
MorPheus, a better plan item to track for what you want is: Bug 36967 [RCP] [Plan Item] Enable Eclipse to be used as a rich client platform
I have made some comments on this issue in other bug reports. They focused on specific instances of the scalability/plugin co-existance problem relating to action contributions and help contributions. But the problems are more generic. I mention a possible approach to solving the problem which is based on perspectives that should be able to handle many of the problems. Here are links to the other PRs: bug #36968 and bug #36964.
I also commented about how improved action contribution support can help the UI scalability story in bug 36968.
Central to the UI scalability problem is that there are various places in the UI where too many "irrelevent" choices are shown. Several of these are listed in the initial comment above: * toolbar / menu actions * preferences pages Perhaps the "abstract task" idea I described in bug 36968 could also be applied to preferences pages to help group preferences or even to hide them. One idea: - Suppose we have an option to display preference pages only for abstract tasks that have been used in a particular session. - Another way would be to have a filtering mechanism that could filter the default list of preferences according to the user's preferred set of tasks.
Additional issues relevent to UI scalability can be found in bug 36967 (Enable Eclipse as a Rich-Client Platform).
FYI: A draft proposal for 'Contexts' has been posted to the Platform UI proposals page at: http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-ui-home/docs.html. It is expected that contexts will form *part* of the solution to this plan item.
Please also look at coolitem "bloat". For example, in 3.0 M3, "Add CVS Repository" appears by itself in a coolitem. that action should have a way of placing itself after the "New.." dropdown. (Or better yet, it should be a new wizard, but that's another topic). In general, toolitems should be grouped by function, not by which plug-in contributed the action.
Please consider bug 21652 as a bug this bug depends on because it is also a UI scalability problem.
A copy of the posting to platform-ui-dev malinglist to explain why bug 21652 is an UI scalability issue can be found in bug 21652 comment 3: https://bugs.eclipse.org/bugs/show_bug.cgi?id=21652#c3
I find the Workbench->Colors, Workbench->Fonts, and Workbench->KeyBindings preference pages lacking in innovation. These pages are not going to scale well for large application. But, besides scaling, it's unintuitive. If I want to change the colors Internet Explorer uses for web pages, I don't open up the OS control panel and bring up some global list of colors. I go to the localized preference dialog for that application. Fonts, colors, and keybindings should be the same way. Each application (e.g. Java Editor) should show its subset of fonts, colors, and keybindings which apply to it, in the place where the user would most likely expect those settings to be. I am not commenting on the services that are available in the workbench, just on the UI presentation of those services. They should not be directly served up to the user in a single complex UI. The "Syntax" tab on the Java Editor preferences page is a great example of what applications should do. Fonts and keybindings should be done the same way whenever possible. For keybindings, the workbench could provide a reusable preference page which would be scoped to the editor's context. The other pages would probabaly be up to the client to create so that an editor preview could be shown. thanks.
agree - the workbench has added base support for color and font management and overriding and should not force downstream users of this to have to edit their colors in the workbench preferences. this is optional, and you may want to use but it is more likely that you would put your color+font editing in a localized place as mentioned
I have to disagree with you Randy. The initial drive for this color page was in fact from our downstream customers who were attempting to reduce the number of preference pages they had to ship. Putting all colour settings in a single place seems far more scalable to me than a preference page per app. And for me personally, knowing I can go to one place to change my colors instead of spelunking through hundreds of preference pages is a relief. Having said this... the place for this page is not under the Workbench page. I'm not sure where the right place is...
Kim, allowing the editor to get rid of its appearance preference page is an unrealistic goal. How close are you to allowing the Java Editor to delete their appearance preference Tab? <tongue in cheek> Is there to be a global "Displayed Tab Width" preference page? print margin column? Show line numbers? </tongue in cheek> The user does not think in terms of "let me change colors/fonts everywhere", but instead "how can I change the Java Editor look&feel"? I actually agree that it is sometimes nice to be able to view all colors in one place. But, especially with keybindings, there should be a way to filter what I am seeing. Perhaps limit the keybinding to a "context hierarchy" (or colors to a specific editor). For example, just show me keybindings for when I am "Editing Java Source". Or perhaps even allow plug-ins to *reuse* the entire keybinding preference page under their editor's preferences branch, and have it "rooted" at the appropriate context for that editor.
You've got a good point - we can't eliminate all of a plugins preference pages. The idea is reduction, not elimination. The colors/fonts page currently can be limited to showing the colors of one editor... provided the implementor of that editor puts all of the colors and fonts used by that editor into their own category. This is the intended use of categories. Carve up the font/color space into reasonable chunks and yet keep them all in one spot.
Categories sound great and they are needed in the keybindings page too. I don't foresee any reductions taking place. The JDT team would be making a mistake if they removed the color portion of their preference page simply because those settings appear in the global color page. Users will look at the Java Editor page first, especially 2.1 users.
See also Bug 58713 (Colors and fonts preferences inconsistent). If you have colors for the Java editor in two places, which takes precedence? Also, if you have 1000 plug-ins installed, each needing their own color settings, putting them all in one big tree or list seems like a very non- scalable solution to me.
Added support for Activities, more flexible object contributions, exspression language support (from Dirk), content types (from Platform Core) and contexts Marking as fixed.
