Community
Participate
Working Groups
Allow editors to open files outside workspace. A common request is to be able to use Eclipse to open a file that is not part of the workspace, or perhaps even one on a remote system. In addition, applications would like to provide file extension associations so that double-clicking on a file in the OS desktop would open the associated Eclipse editor. The operations and capabilities available on these "outside of the workspace" files would need to be defined. [Platform UI] [Themes: User experience]
*** Bug 36949 has been marked as a duplicate of this bug. ***
*** Bug 38716 has been marked as a duplicate of this bug. ***
*** Bug 39430 has been marked as a duplicate of this bug. ***
*** Bug 39189 has been marked as a duplicate of this bug. ***
*** Bug 40661 has been marked as a duplicate of this bug. ***
*** Bug 2869 has been marked as a duplicate of this bug. ***
The Fileopen plugin does this - it open files not part of the Workspace and provides a way to do file extension associations so that double-clicking on a file in the OS desktop will open the associated Eclipse editor. You have my permission to use any of the code in Eclipse if you want. See www.eclipsepowered.org > Download area > Fileopen. It works by creating a new class that implements IStorageEditorInput and a new class that implements IStorage, similar to the way viewing CVS resources and things in zip files work. Some of the ideas were from an earlier plugin called filedrag (see the readme). However filedrag worked by creating a new top level visible project called "Desktop" and using links. Fileopen has some problems though. First, it's hard to make the file editable. Saves are controlled by IDocumentProvider instead of IStorage, and you can't always replace the document provider (Java forces its internal one no matter what). Even if you could replace the document provider, you wouldn't want to anyway because it also controls syntax highlighting. The second big problem is that annotations, markers, quickdiffs, and outlines are not functional. The edit area is flush against the left margin, and the regular context menus are not created. But it's better than nothing. A new way: It seems that the current plan for handling files outside the workspace is to not use Resources for them, but Resources are shot throughout the Eclipse API so this requires large API changes. I'm worried there might be some loss of functionality for Resource-less external files too - would all the editors work with them? Would outline managers? Markers? Resource change events? Would they suffer some of the same problems as Fileopen? I wondered if it would be possible to keep the concept of "Resource" but extend it to objects both within and without a Workspace. So I did some playing around this past week to try and find a totally different way to handle external files. This was just an experiment to see how far I could get, not a general solution. But I thought I'd share my findings here in case they would be useful. Experiment: Currently a Resource must be in the Workspace, in particular it has to be in the element tree that hangs off the WorkspaceRoot. So do all the Folders and Projects that lead down to it. Resources have an IPath, and various places in org.eclipse.core.resources make assumptions that the 0th segment of a path is the Project name. For the experiment I looked at opening files of the form //server/dir1/dir2/filename.ext (a UNC name). If I just try to get a resource for this file (workspace.getRoot().getFile(path)) it fails because no part of that path exists in the Workspace. First I tried creating a File resource with a null workspace reference, but that didn't work at all because the core code makes heavy use of that pointer. So I went back to the current Workspace but added "//server" as a Project, "dir1" and "dir2" as Folders, and "filename.ext" as a File. I made the Project a phantom project so it would not show up in the navigator and would not be saved when the Workbench closed. Now, this has obvious problems (like, what if you had a real project called "server"), but it was good enough for the experiment. Problems: The first thing I ran into was that WorkspaceRoot.getProject() only takes a string, and it doesn't want to create a project with a UNC name, so I had to call Path.makeUNC(true) on the project after creating it. I had to use an internal routine Workspace.createResource() to populate the element tree. Also, I had to explicitly call IResource.setLocal(true, DEPTH_ZERO, monitor) on the final File to make core.resources treat it as local. Although these UNC files were actually out on the network I believe it is correct to call them local in this context. There were some problems preserving that UNC flag in different routines. For example FileSystemResourceManager.localtionFor() really wanted to make the project path non-UNC and relative to the Platform location so I put a special case there. Several places called Resource.getResourceInfo() with a false phantom flag so it couldn't find my fake project. For example, PropertyManager.getPropertyStore () and setPropertyStore(), several places in File, Project, and Resource. Resource.getProject() ate the UNC flag by doing a getProject(path.segment(0)) so I had to add a special case there. Finally there was a problem with Eclipse thinking the external file was out of date. I didn't completely track that down but I managed to work around it by modifying File.getContents(). Results: I was able to view both a normal text file and a Java file (with outline) in the editor. I didn't try to edit read/write files but I'm sure that can be made to work. The usual marker and quickdiff areas were visible, as were the usual Java menu items like Search (but they complained because the current resource was not on the build path of any project). There were a few odd things but it looked better than my previous attempts that involved creating a new ExternalEditorInput class (ala fileopen). Conclusions: I've proven that it's possible to have Resource objects that don't really live in the Workspace. This could be a good way to support editing files outside the Workspace. I'm sure cleaner ways could be devised to do this, for example maybe there could be a new Resource type - currently you have ROOT, FILE, FOLDER, and PROJECT, how about EXTERNAL? Relying on the UNC file was pretty fragile so a new Resource type would be better. My experimental code is purposefully kludgy so I'm hesitant to post it anywhere. But if you twist my arm and promise not to laugh too hard at it (I *can* write better code than this, honest :) then I can.
Just a comment - I grabbed the file open plugin and it's a viable stopgap solution. But what I'd really like is to be able to create a view of part of the file system in the Navigator pane, and be able to easily navigate and open/edit files in that hierarchy. JBuilder 8 has this functionality, and it's very handy. Means you essentially never need to leave the IDE.
This generic type of support is also generally required for handling standard C/C++ support (the CDT project) which often includes source header file locations which are external to the workspace and shared in the system. Being able to _easily_ incorporate these types of resources without having to jump through many hoops would be delightful.
If this feature is available, it should be made possible with drag and drop. In JBuilder (starting from 7) you simply drag a file to the text area and it gets opened. Very handy if you have to open e.g. a configuration file or something.
With 3.0 having the Open External File menu, why not mark this one complete? There are other bugs already open for the remaining issues: - having an Open icon (bug 47486) - defining the Control-O key sequence to do an Open (bug 47485) - opening a file by dragging it onto Eclipse (bug 13221 and bug 21973 and bug 36606 - some of these might be dups) - double-clicking a file in a file explorer and have it open up in Eclipse by a file association (bug 21973) - searching on external files (bug 29389) Did I miss any?
The Text team actually did this work on this one, and I'm not up to date on whether anything else remains to be done.
*** This bug has been marked as a duplicate of 21973 ***
This bug is marked as duplicate of bug 21973 which is marked as resolved. Still I can not open a file outside my workspace :the open external file DOES NOT WORK except for Java files. I leave the bug as it is sice I am not directly involved in the project, but in my opinion this bug is not resolved.
Well, it works for me using I20040225 - just verified it again. Please help us and file a bug report with steps to reproduce.
Yes in 3.0 you can "Open external file" but after you did some editing and you want to save the file to another different location in file system by selecting "Save as", you can not do it without the workspace. So, imo, this bug is not fixed, at least not completely.
The bug is about opening the file and not "Saving as...". Please file a new feature request.
*** Bug 58944 has been marked as a duplicate of this bug. ***
This plan item has been revised. The sentence "In addition, applications would like to provide file extension associations so that double-clicking on a file in the OS desktop would open the associated Eclipse editor." has moved to a separate plan item (bug 60289).
FYI, opened bug 75472 to address comment 17.
Further to comment 11 - yes, you missed one: - "Open" always follows "New" in the file menu (bug 75483).
