Community
Participate
Working Groups
Looking on the misery with webtools "Validate" menu (see bug 540499), I think we should provide a generic way for users to hide any "unwanted" contributions (or at least menu/toolbar/view/editor contributions). I'm thinking on a dynamic contributions of "capabilities" similar to "General -> Capabilities" preferences, but on a much finer level. Currently those capabilities are static (AFAIK) and need to be declared in plugin.xml. So one have to find out offending contribution id, create a bundle with proper defined capabilities filter and deploy this into the current platform, hoping that this somehow will work. Not usable at all. I imagine something like "Customize Perspective" preference page, where user can select menu/toolbar/view/editor contributions to hide. We would then automatically add "User Hidden" capability and link selected id's to it. The rest will be hopefully done by already existing code (a restart probably will be needed). This sounds too simple to be doable, because if this would be that simple, why don't we have it for a long time? Probably I miss something obvious => may be there is already a bug explaining why it is not possible, I have not checked that.
(In reply to Andrey Loskutov from comment #0) > This sounds too simple to be doable, because if this would be that simple, > why don't we have it for a long time? Simple solutions are often the result of a hard process. All ideas seem easy once they've been discovered ;) I don't see how this is so different from Window > Perspective > Customize Perspective... that already partly allows what you describe here. The goal is to have it IDE-wide instead of perspective-wide, and to dynamically implement this with capabilities as backend?
(In reply to Mickael Istria from comment #1) > (In reply to Andrey Loskutov from comment #0) > > This sounds too simple to be doable, because if this would be that simple, > > why don't we have it for a long time? > > Simple solutions are often the result of a hard process. All ideas seem easy > once they've been discovered ;) > > I don't see how this is so different from Window > Perspective > Customize > Perspective... that already partly allows what you describe here. Yes, *partly*. It doesn't allow to hide such things like "Validate" menu from bug 540499, appearing at all possible, mostly unexpected contexts. I guess this applies to all "modern" contributions, done with the "new" menu/toolbar architecture. > The goal > is to have it IDE-wide instead of perspective-wide, and to dynamically > implement this with capabilities as backend? Exact. If I don't care about XML "Validate" menu, I don't care in any perspective, I just want to hide this forever. So basically I always have a set of plugins which I avoid to use because they add some buttons/menus in the places where I don't want to have them to appear at all. For example if I have CDT+Ruby installed in the SDK (just for code syntax, not for debugging), I have tons of buttons/menus everywhere in the debugger related UI's which do not work in Java context at all, but are visible and distracting me a lot. The *have* some meaning for Ruby/C++ developers, but for me I don't really want to see any C++/Ruby extensions anywhere in the debugger.
+1 for the idea. Our product has something similar, where any UI element (action, view, perspective) can be hidden for specific users. To implement that, we have patched the activity framework to allow registration of ActivityDefinition and ActivityPatternBindingDefinition at runtime. An official API to replace that would be great. (In reply to Andrey Loskutov from comment #2) > So basically I always have a set of plugins which I avoid to use because > they add some buttons/menus in the places where I don't want to have them to > appear at all. For example if I have CDT+Ruby installed in the SDK (just for > code syntax, not for debugging), I have tons of buttons/menus everywhere in > the debugger related UI's which do not work in Java context at all, but are > visible and distracting me a lot. The *have* some meaning for Ruby/C++ > developers, but for me I don't really want to see any C++/Ruby extensions > anywhere in the debugger. Is that something the user should have to configure? I think out of the box most CDT actions should not be available when editing or debugging java code (and vice-versa). Maybe separate debug perspectives would help. Or even better, project-specific activities based on the active launch configs. I.e. when debugging an eclipse application, only "add java exception breakpoint" should be available, not PHP exception.
(In reply to Julian Honnen from comment #3) > we have patched the activity framework to allow registration of > ActivityDefinition and ActivityPatternBindingDefinition at runtime. > > An official API to replace that would be great. Seems like you're a good candidate to contribute it then ;)
+1 Excessive contributions is the problem for nearly any Eclipse-based product. Currently I'm using the mix of e3/e4 (activity/processor) approach to workaround this for the most annoying contributions. It could require a lot of changes to fix it for "general" case since not every "UI representer" (menu/toolbar/whatever) cares about ability to filter things out.
