Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 123808

Summary:	[RCP] [WorkbenchParts] Allow app to hide actions in editor and view system menus
Product:	[Eclipse Project] Platform	Reporter:	Nick Edgar <n.a.edgar>
Component:	UI	Assignee:	Platform UI Triaged <platform-ui-triaged>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	douglas.pollock, j.king, pwebster
Version:	3.2	Keywords:	api, helpwanted
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:	stalebug

Description Nick Edgar

2006-01-13 13:53:10 EST

3.2 RC4

In the RCP newsgroup, Guide Kupper says:
"I'd like to customize the Editor Tab context menu in 3.1. Especially I'm searching for a method to remove the "New Editor" entry. I already seached eclipse.org and javadoc without results. "

This is not currently possible to do.  I think that many RCP apps will not want this menu item, any may want to hide the others.  We should add some mechanism to allow apps to hide these.

One option would be to look for a hidden preference setting of the form:
"editorMenu.hide.<actionId>"
when adding the actions in StandardEditorSystemMenu and StandardViewSystemMenu

These would all be false by default.

The prefix for the preference key would be defined as API in IWorkbenchPreferenceConstants.

Comment 1 Nick Edgar

2006-01-23 14:01:11 EST

Doug, can you think of a better way of allowing this kind of flexibility, e.g. using the new commands stuff?

Comment 2 Nick Edgar

2006-01-23 14:03:20 EST

Other examples include:
- hiding the "Show View as a fast view" action from the fast view bar
- hiding the Open Perspective action from the perspective bar
- disallowing detached and/or fast views (this probably needs a more explicit flag than just hiding the actions, e.g. to disallow DND)

Comment 3 Douglas Pollock

2006-01-23 14:40:19 EST

Nick: I would approach it as follows (will work soon, but not right now).  Go into SBar, add a TYPE_TAB_MENU and all the parsing code (MenuPersistence) to go along with it.  Change the tab so that it is drawn by the menu renderer, and make all the contributions command-based.  Alternatives: make it a real context menu and register it with the site (available now), or do the same of above but use an existing type (again you would have to wait for a bit).

Comment 4 Nick Edgar

2006-01-23 14:43:05 EST

If we switch it to use commands, how would the overriding work?

Comment 5 Douglas Pollock

2006-01-23 14:55:56 EST

As it stands right now:

    IMenuService service = 
        (IMenuService) serviceLocator.getService(IMenuService.class);
    SItem item = service.getItem("org.eclipse.ui.NewEditor");
    item.undefine();

Finer-grained control could be done with combinations or define(...) and undefine().  Control of this from XML will not be possible for 3.2.  Overriding the behaviour would be as simple as providing another handler -- perhaps specific to a particular type of editor.

Comment 6 Nick Edgar

2006-01-23 15:11:46 EST

It sounds like this is a preferable way to go then introducing random preferences for each action.  I can work with you to redefine the system menus along these lines.  Do you want to do this for M5, or post-M5?

Comment 7 Nick Edgar

2006-02-09 22:21:21 EST

Not for 3.2.

Comment 8 Nick Edgar

2006-03-15 11:24:35 EST

Reassigning bugs in component areas that are changing ownership.

Comment 9 Boris Bokowski

2009-11-26 16:15:30 EST

Prakash is now responsible for watching bugs in the [RCP] component area.

Comment 10 Paul Webster

2013-09-20 15:24:33 EDT

This should now be modelled in Luna
PW

Comment 11 Lars Vogel

2019-11-27 07:39:41 EST

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.

If the bug is still relevant, please remove the stalebug whiteboard tag.