Community
Participate
Working Groups
1.- I need a way to disable R3.1's "New Editor" action in the scope of my editor. My editor may perform certain adjustments (e.g., for those columns in each text line defined as 'serial numbers') on the document when it receives IDocument change notifications - having two (or more) editors with conflicting settings may create an unstable combination... 2.- My editor has its own split-window function, so another possibility would be to provide the capability for an editor to reimplement this action. I see this action in two places: - on the "Window" top pull-down menu, and - on the context menu of the editor tab. 3.- Any workaround suggestions for the current Eclipse 3.1 release version are also welcome (short of throwing an exception when the editor receives an open request for an already-opened-by-it editor input)...
Even before New Editor was added, it was possible to get multiple editors on the same input by using multiple windows (Window > New Window, then opening the same input). The recommended approach is to make the editors support a shared document model, like the text editors in the IDE. Sorry, but I don't know of a better workaround at the moment.
whatever the solution, the logic for the new editor action is duplicated in org.eclipse.ui.internal.presentations.SystemMenuNewEditor and org.eclipse.ui.internal.actions.NewEditorAction
I would also like a way to disable this action. At present I don't own the editor that I extend. The underlying editor doesn't support opening multiple views on the same document in different windows.
*** Bug 190081 has been marked as a duplicate of this bug. ***
Any help with this would be greatly appreciated. A new method on the workbench window configurer would be a good way to expose this setting for RCP apps.
I think this could be set as a preference from the products customization like the defaultPerspectiveId. That way you would not have to code anything. You just set org.eclipse.ui/SHOW_NEW_EDITOR=false Are there any RCP apps that do not use a product configuration? They would have to have a way in code to disable that. But first I would implement a patch for using a preference.
Even better would be to let the editor decide if it can handle multiple instances. This could be declared as an attribute 'allowMultiple' for 'editor' elements in 'org.eclipse.ui.editors' extensions (analog to allowMultiple for views). Default would be true for backward-compatibility, the new editor handler would be disabled if allowMultiple = false. This is bug is tedious for RCP developers because you need to be prepared for multiple editors even if you don't want to support this feature in your application.
I have to agree with Ralf. This sounds even better than enabling/disabling new editors by preference or workbench advisor.
Created attachment 129911 [details] Initial patch I added a method to the IEditorDescriptor allowMultiple() similiar to IViewDescriptor. I added a new property tester "org.eclipse.ui.editors.EditorPartTester" with the namespace "org.eclipse.ui.editors" for IEditorPart that currently only can test if a given IEditorPart supports the creation of a new editor. This new property tester is used by the enablement of the NewEditorHandler core expression. This will disable the "New Editor" in the editors system menu. I would rather prefer the entry to vanish completly if the editor does not support multiple instance. But since the action is hardcoded into EditorSystemMenu it does not take into account any enablement to make itself invisble if there is not handler. Maybe someone else can fix this. But as it is for now I can live with an disabled menu entry. That covers the UI enablement pretty good I think. However, we should also take care that its not possible to open another editor programmatically. So the methods for opening editors would have to be fixed also to take "allowMultiple" into account and activate the currently open editor in case it is tried to open a second instance of a "single" editor. We would have to discuss if in that case the already open editor is updated with a new IEditorInput.
Created attachment 129912 [details] mylyn/context/zip
(In reply to comment #9) > This will disable the "New Editor" in the editors system menu. I would rather > prefer the entry to vanish completly if the editor does not support multiple > instance. But since the action is hardcoded into EditorSystemMenu it does not > take into account any enablement to make itself invisble if there is not > handler. Maybe someone else can fix this. Maybe Paul? ;-)
Btw, thanks for the patch! Not sure if this can be put into 3.5 since we are past the API freez, but I can try to get approval once we have a patch that everybody is happy with.
(In reply to comment #9) > This will disable the "New Editor" in the editors system menu. I would rather > prefer the entry to vanish completly if the editor does not support multiple > instance. But since the action is hardcoded into EditorSystemMenu it does not > take into account any enablement to make itself invisble if there is not > handler. Maybe someone else can fix this. > But as it is for now I can live with an disabled menu entry. > That covers the UI enablement pretty good I think. The code that would be needed is in org.eclipse.ui.internal.presentations.util.StandardEditorSystemMenu.show(Control, Point, IPresentablePart) If the openAgain action contribution item was saved it could have its visibility set to false based on the action state ... although if it is already disabled, there's something to be gained by not having the menu items hop around. The other place we would have to check is org.eclipse.ui.IWorkbenchPage.openEditor(IEditorInput, String, boolean, int) and its callers because one of the match flags is #MATCH_NONE (don't check for an existing input) PW
Marking for M6. Adrian, would you be able to update your patch based on Paul's comments?
(In reply to comment #14) > Marking for M6. Err... 3.6
Remy is now responsible for watching the [EditorMgmt] component area.
*** Bug 181585 has been marked as a duplicate of this bug. ***
*** Bug 282388 has been marked as a duplicate of this bug. ***
From bug 282388 comment 6: > Hi, > > I just managed to disable the "new editor" action within Galileo by creating a > handler for command "org.eclipse.ui.window.newEditor". > The handler is active for my editors but never enabled > => expression: activeWhen/activePart/instanceof(my editors) > => expression: enabledWhen/count/value -1 > > This allows disabling the command for your editors, but not for standard text > editors. > > Maybe Paul can tell if this might be the correct way to go currently.
(In reply to comment #19) > > handler for command "org.eclipse.ui.window.newEditor". > > The handler is active for my editors but never enabled > > => expression: activeWhen/activePart/instanceof(my editors) > > => expression: enabledWhen/count/value -1 > > > > This allows disabling the command for your editors, but not for standard text > > editors. You are basically providing a higher priority handler for that command. Depending on the activeWhen you write, you can be available some of the time (your own editors) or all of the time. It will work ... until someone provides a "more specific" handler that's enabled. PW
So what are we doing with this bug now? Is there any way to solve it?
(In reply to comment #21) > So what are we doing with this bug now? Is there any way to solve it? Right now the solution is to provide a "more specific" handler that's disabled. That can be used to disable it for the app or for a specific editor type (although the original problem can be avoided using the shared buffer approach as Platform Text does). No one is working on this (hence the helpwanted, bugday). If there is more needed, then it should target the specific action (not the editor definitions themselves). PW
Here is an example plugin.xml: <extension point="org.eclipse.ui.handlers"> <handler class="DisabledNewEditorHandler" commandId="org.eclipse.ui.window.newEditor"> <enabledWhen> <count value="-1"> </count> </enabledWhen> <activeWhen> <not> <count value="-1"> </count> </not> </activeWhen> </handler> </extension> public class DisabledNewEditorHandler implements IHandler { public boolean isEnabled() { return false; } ... }
(In reply to comment #0) > 1.- I need a way to disable R3.1's "New Editor" action in the scope of my > editor. My editor may perform certain adjustments (e.g., for those columns in > each text line defined as 'serial numbers') on the document when it receives > IDocument change notifications - having two (or more) editors with conflicting > settings may create an unstable combination... > > 2.- My editor has its own split-window function, so another possibility would be > to provide the capability for an editor to reimplement this action. > > I see this action in two places: > - on the "Window" top pull-down menu, and > - on the context menu of the editor tab. > > 3.- Any workaround suggestions for the current Eclipse 3.1 release version are > also welcome (short of throwing an exception when the editor receives an open > request for an already-opened-by-it editor input)... (In reply to comment #23) > Here is an example > plugin.xml: > <extension point="org.eclipse.ui.handlers"> > <handler > class="DisabledNewEditorHandler" > commandId="org.eclipse.ui.window.newEditor"> > <enabledWhen> > <count value="-1"> > </count> > </enabledWhen> > <activeWhen> > <not> > <count value="-1"> > </count> > </not> > </activeWhen> > </handler> > </extension> > > public class DisabledNewEditorHandler implements IHandler { > public boolean isEnabled() { > return false; > } > ... > }
place the following code somewhere in your WorkbenchAdvisor postStartup method: public void postStartup() { ..... ICommandService commandService = (ICommandService) PlatformUI.getWorkbench().getActiveWorkbenchWindow().getService(ICommandService.class); commandService.getCommand("org.eclipse.ui.window.newEditor").setHandler(null);
(In reply to comment #25) > commandService.getCommand("org.eclipse.ui.window.newEditor").setHandler(null); This is not a reliable way to override the handler, as the HandlerAuthority can call setHandler(*) on the newEditor command at any time when it reconciles it's handlers. PW
Ok good to know! Although I never run into trouble using this solution i try the disabled handler solution (comment 23)
Mass move to 4.7 as M7 is approaching. Please move back in case you are planning to fix it for Neon.
