Community
Participate
Working Groups
Products often need direct control over the presence and arrangement of UI elements. Similarly, end users expect to be able to customize the UI to better match their workflow. Eclipse should enable both products and end users to have more control over the user interface. For example, better control over the presence and ordering of menu and toolbar items should be provided. Similarly, the workbench layout should be made more flexible and configurable. [Platform UI]
Strangely enough I just opened a Bug 106238 that might relate to this item (ordering of object contribution groups and actions). Not really from an end user necessarily, but at least from a plug-in level.
More control over the presence of UI elements would be really important. For enterprise applications user roles and rights is a key requirement. In order to implement this you need to filter workbench contributions. Some users may not be allwoed to display perspective a and button b, so a and be should not be displayed at all.
Please consider bug 75934 as an item that falls under this request.
I would love to see customizable mouse settings as in bug 47099
wrt comment #2 have you looked at Capabilities support in the UI to filter/hide elements?
Yes, we had evaluated that. We need two filtering levels: - application controlled (user permissions) - user controlled (like capabilities support in eclipse today) Using capabilities it is currently (3.0.1) impossible to ensure that a capability which is disabled by the application really stays disabled. - The perspectives/views menu can always activate triggerpoints that reenable the activity. - The capabilities dialog allows to reenable all disabled capabilities. So you would have to code your own capabilities dialog and you would have to replace the views and perspectives menu with your own version. Additionally you would have to be very carefully to avoid any trigger points that could reactivate the feature (dont know if thats really possible). The capabilities support is not designed to be used for role based filtering. And future changes to the architecture could introduce new trigger points.
Sorry, I meant Eclipse 3.1.1 not 3.0.1
You can also hook into the triggering mechanisms and veto them or provide different prompters. I believe this is what you need when mentioning unwanted triggering.
oops did not mean to close this bug. Items addressed in 3.2 are: - control over precense and arrangement of trim bars (such as fastview/progress) in the workbench - improved key binding customizations for Ctrl+L key binding popup
Marking FIXED See comment 9 for the details of our fixes.
