Community
Participate
Working Groups
I have an editor in my plugin registered against .java. JDT supplies its own (CompilationUnitEditor) so there are two of them. In the resources perspective the last saved editor is used if the file is double clicked. Also, in the resources perspective if there is no last saved editor and the file is double clicked the first alphabetic editor name is used. The JavaPerspective never reads the last saved editor and always opens with the first editor assigned to .java. Also, this is the first editor returned from the EditorRegistry's map which is not necessarily the first alphabetic label so the behavior is inconcsistent with the resources navigator. The code to be changed is org.eclipse.jdt.internal.ui.javaeditor.EditorUtility This is the current code which never checks the last saved editor public static String getEditorID(IEditorInput input, Object inputObject) { IEditorRegistry registry= PlatformUI.getWorkbench().getEditorRegistry(); IEditorDescriptor descriptor= registry.getDefaultEditor(input.getName()); if (descriptor != null) return descriptor.getId(); return null; } It could be be changed to public static String getEditorID(IEditorInput input, Object inputObject) { IEditorRegistry registry= PlatformUI.getWorkbench().getEditorRegistry(); // Look to see whether the file has an editor it was last saved with if (input instanceof IFileEditorInput){ String id = ((IFileEditorInput)input).getFile().getPersistentPropert(EDITOR_KEY); if (id != null){ return id; } } // Get the default editor for the mime type IEditorDescriptor descriptor= registry.getDefaultEditor(input.getName()); if (descriptor != null) return descriptor.getId(); return null; } Not as important, but nevertheless inconsistent, is that if no editor has been used and neither claims to be the default use the first alphabetic label to be consistent with the resources perspective. The code to change is org.eclipse.ui.internal.registry.FileEditorManager This just grabs the first editor which is in a collection and has no guarantee or order public IEditorDescriptor getDefaultEditor() { if (editors.size() == 0) return null; else return (IEditorDescriptor)editors.get(0); } This needs changing to use a sorter, which is what the resources perspective classes such as OpenWithMenu or OpenFileAction do public IEditorDescriptor getDefaultEditor() { if (editors.size() == 0) return null; else { // To be consistent with the resource editor, open the first alphabetic one Object[] editorsArray = editors.toArray(); editorsArray = sorter.sort(editorsArray); return editorsArray[0]; } } private Sorter sorter = new Sorter() { private Collator collator = Collator.getInstance(); public boolean compare(Object o1, Object o2) { String s1 = ((IEditorDescriptor)o1).getLabel(); String s2 = ((IEditorDescriptor)o2).getLabel(); //Return true if elementTwo is 'greater than' elementOne return collator.compare(s2, s1) > 0; } };
More thoughts - the EditorUtility should definitely respect the persistenceProperty(EDITOR_KEY), but if there is not one how does it decide then ? The resource perspective OpenFileAction uses the first alphabetic label, but this is incorrect as it does not carry forward over different NLS. The CompilationUnitEditor does not specify default=true in the extension points against .java, however we specify default=false. Maybe weight it so if someone is default=true they win, but if not then get the list of available editors and put ones that have no default setting ahead of default=false. Alternatively make CompilationUnitEditor be default=true, which is really should be as it is the de-facto java source editor
Because of WSAD 5.0 coming up where the Java Visual Editor is included this is causing a lot of problems. Users who are editing EJBs or .java files that they wish to open the JDT editor for are seeing the Java Visual Editor. I have therefore put it up to critical and Prioriry 1 and included Paula Cox ( the WSAD 5.0 release manager ) on the cc list.
We should honor the EDITOR_KEY attribute and also set the default attribute to true (not rely on sorting etc).
The EDITOR_KEY property key is not public. After having determined the editor input, we now check whether it's a file editor input. If so, we use the workbench support for opening files rather then trying to mimic the workbench. I.e. if opening files, we are now consistent with the workbench behavior, independent of how this looks. Build > 20020508.
Gili (gmendel@us.ibm.com) has tested this and it appears that the last used editor is now the one that is opened, but if there are none then the CompilationUnitEditorPart is not flagged as default="true" in the plugin.xml. Therefore our plugin that also registers a .java editor and is called "com.ibm..." comes alphabetically before "org.eclipse..." and we are the default. This means that after doing a Create Class with the wizard, or if you just double click on a .java file that hasn't even been opened ( i.e. one that was generated by a wizard such as an EJB or one that was imported ) then the Java Visual Editor comes up by default. Given Erich's comment that the editor should be the default one, is this an oversight, or is this working as designed that the Java Editor is not registered as the default one. Thanks - JRW
1) A product can specify the default editors for each extension or file name by setting "org.eclipse.ui/defaultEditors" in the file plugin_customization.ini. e.g., org.eclipse.ui/defaultEditors= *.ext1:editorId1;*.ext2:editorId2;fileName:editorId3 So the product can resolve the conflicts if none or more then two editors are set as default. 2) Once a file is opened using another editor, it will allways use that editors. E.g. a) Double click in a .txt file will open the DefaultTextEditor. (close it) b) Open it with Notepad (close it) c) Double click on it and notepad will open instead of DefaultTextEditor.
The JDT contributed Java editor is now tagged as the default editor for .java files. OK to close?
Yep. tks.
closing
