Community
Participate
Working Groups
Use case: In my plug-in I need to open an editor on any file, regardless of whether it's in the workspace or not. I also need to seek to a specific line number (for example for compiler error messages). So I looked at the code for OpenExternalFileAction (again - this is kind of a long running pet peeve of mine) to see how it does it. In 3.2 it does over 200 lines of code, invoking the new EFS functions, handling linked resources, handing in place and system editors, and more. I'm tired of having to implement this functionality over and over and trying to keep up with new Platform features like EFS. Please consider this a request to make a public API for opening an editor on any arbitrary filename, and use the public APIs in OpenExternalFileAction instead of all the internal code. I'll also need the ability to seek to a specific line number in that file, so one possible signature might be: public static void openFile(String fileName, int lineNumber) throws CoreException; Possible enhancements would include returning the IEditorPart created, and supporting specifying a specific editor type (like the Open With menu does). The ability to force a new editor to open even if there is already one might also be handy. But for my use case just the basic functionality would be fine. See also bug 138652 for an internal API I ran into while simply trying to copy the new 3.2 implementation of OpenExternalFileAction. Feel free to defer this post 3.2.
*** Bug 151420 has been marked as a duplicate of this bug. ***
Created attachment 59077 [details] Fix This patches moves the OpenExternalFileAction to the API space of the IDE plug-in. Note that I renamed 'external' -> 'local' because that's what it does. We could have labelled it OpenFileStoreAction but currently we do not have a generic open dialog (see bug 116414). If Platform UI plans to provide this in the near future then we might already prepare this by giving the open action a corresponding name. NOTE: This fix also needs the additions to IDE.java from this patch: https://bugs.eclipse.org/bugs/attachment.cgi?id=59046
Created attachment 59078 [details] Combined Patch This version contains the IDE additions plus additions to the doc plug-in.
Thanks Dani - the patch looks great. The only issue is that we are trying to get away from writing new actions right now as we move to commands (especially if they are API). This means that adding OpenLocalFileAction as API is not the best idea as we will be deprecating it and converting it to a handler before we ship 3.3. If you have no reason to depend on OpenLocalFileAction I'll move it to org.eclipse.ui.internal.ide.actions when I apply the patch with the idea that we will make an API handler during 3.3. Mike I will need API approval to add /** * Opens an editor on the given IFileStore object. * <p> * Unlike the other <code>openEditor</code> methods, this one * can be used to open files that reside outside the workspace * resource set. * </p> * <p> * If the page already has an editor open on the target object then that * editor is brought to front; otherwise, a new editor is opened. * </p> * * @param page * the page in which the editor will be opened * @param fileStore * the IFileStore representing the file to open * @return an open editor or <code>null</code> if an external editor was opened * @exception PartInitException * if the editor could not be initialized * @see org.eclipse.ui.IWorkbenchPage#openEditor(IEditorInput, String) * @since 3.3 */ public static IEditorPart openEditorOnFileStore(IWorkbenchPage page, IFileStore fileStore) throws PartInitException { //sanity checks if (page == null) { throw new IllegalArgumentException(); } IEditorInput input = getEditorInput(fileStore); String editorId = getEditorId(fileStore); // open the editor on the file return page.openEditor(input, editorId); } /** * Get the id of the editor associated with the given <code>IFileStore</code>. * * @param workbench * the Workbench to use to determine the appropriate editor's id * @param fileStore * the <code>IFileStore</code> representing the file for which the editor id is desired * @return the id of the appropriate editor * @since 3.3 */ private static String getEditorId(IFileStore fileStore) { IEditorDescriptor descriptor; try { descriptor = IDE.getEditorDescriptor(fileStore.getName()); } catch (PartInitException e) { return null; } if (descriptor != null) return descriptor.getId(); return null; }
Dani we will also need to synch this one as there are changes to editors too.
Re comment 5: That's fine with me. Re comment 6: as soon as you got the approval for the API addition via pmc-list we can coordinate to do this. Note that this bug depends on bug 174272: if that bug isn't fixed and we commit this one, external editors will no longer be restored. I suggest to compile one PMC change request with this bug, bug 174272 and eventually bug 165172.
Created attachment 59368 [details] Patch with internal action class Here is a patch with the action moved to an internal package so that we can make it a command instead in 3.3
+1.
Tod and I have committed this code.
Verified in I20070319-1005
