Community
Participate
Working Groups
3.1 M5 KH reports: Editors that implement their own EditorInput do not fully integrate with Eclipse. For example when closing a project that has dirty editors a specific check on the editor input is performed. Here is the code from CloseResourceAction: List getDirtyEditors(List projects) { List dirtyEditors = new ArrayList(0); IWorkbenchWindow[] windows = PlatformUI.getWorkbench() .getWorkbenchWindows(); for (int i = 0; i < windows.length; i++) { IWorkbenchPage[] pages = windows[i].getPages(); for (int j = 0; j < pages.length; j++) { IWorkbenchPage page = pages[j]; IEditorPart[] editors = page.getDirtyEditors(); for (int k = 0; k < editors.length; k++) { IEditorPart editor = editors[k]; IEditorInput input = editor.getEditorInput(); if (input instanceof IFileEditorInput) { IFile inputFile = ((IFileEditorInput) input).getFile(); if (projects.contains(inputFile.getProject())) { if (editor.isDirty()) { dirtyEditors.add(editor); } } } } } } return dirtyEditors; } One option , would be to include dirty editors in the list when they don't have FileEditorInputs. It might be confusing but it would avoid the chance of losing work? Is there a better solution? The next problem is the implementationof GotoMarker. Again it only works if the editor input is files. (see. ActionOpenMaker in MarkerView)
We should be using input.getAdapter(IFile.class) instead of the explicit check for IFileEditorInput (in both places you mention, and probably others). I'll fix this up. Would this work for the client? Does their custom editor input still know about which resource(s) it's dealing with (I hope so)? Are they dealing with a single resource per editor input, or multiple?
(cc'ing John as he should be aware of these changes)
These are also potentially places where IResourceMapping could be used. I'll consider this as I go through them.
Nick, for dirty checking, wouldn't you just need to do a getAdapter (ResourceMapping.class) instead of using IFile.class? I'm not sure how this would translate to the marker case though.
There are a couple of checks being done: 1. Is the editor's file in a given project (e.g. to close the editor when the project is being closed, or checking for unsaved changes when building a project) 2. Is a given marker in the current editor's file (used for goto marker). This essentially just compares whether the editor's file equals marker.getResource(). Could you outline how I could do these checks using ResourceMapping?
1. This one is easy. You would check to see if the project being closed matches one of the projects of the mappings (ResourceMapping#getProjects). If it does and the editor is dirty, you would probably want to prompt to indicate that there may be unsaved changes. 2. In this case, you want to know if the mapping contains a specific file. To do this, you can check to see if the file was contained in the traversals of the mapping (either by calling getTraversals or visiting the mapping using the accept method). If you have a match, you could activate the editor. I think you would need some sort of editor part API to pintpoint the marker location further though (i.e. logical model editors may be showing the file in an entierly different way). Another complication is that a file may contain multiple model elements which means there could be several editors open that are editing separate parts of the file. We don't have anything that helps in this case.
I've filed a separate bug for the ResourceMapping work: bug 88085.
Changed all occurrences of casts to [I]FileEditorInput to use ResourceUtil.getFile(IEditorInput) instead, which uses getAdapter(IFile.class). Changes reviewed by Michael Valenta.
There is a limitation in how the mappings from IFile to an existing open editor is done (used for Link With Editor in the Navigator). Previously it was doing: page.findEditor(new FileEditorInput(file)) Now, in addition to this, it iterates over the editors checking whether: file.equals(ResourceUtil.getFile(editor.getEditorInput()); However, in order to avoid forcing materialization of editors restored from the previous session, it skips those that haven't been materialized. So for IFile-based editors not using [I]FileEditorInput, editor linking will not work properly for unmaterialized editors. I don't see a better approach to this at this time.
The Package Explorer and other views supporting Link With Editor will have the same problem. I'm filing separate PRs against other components that have similar dependencies on [I]FileEditorInput.
I've filed bug 88451 for the linking problem.
To simplify the changes for downstream components, I've made ResourceUtil API in org.eclipse.ui.ide. I recommend people use this as it will likely be improved to support ResourceMapping (see bug 88085).
In bug 88453, Dani asks: > Nick, I fully agree regarding references to FileEditorInput. > > What is the reasoning/benefit behind having an editor input provides > an IFile (via getAdapter) but does not implement IFileEditorInput? I'm not exactly sure. Kevin, can you get more info from the client? In any case, I think using the adapter mechanism reduces coupling to a specific editor input subtype, and is worth doing, particularly when we start addressing ResourceMapping.
Georg, could you please provide more details on whether you're implementing IFileEditorInput (see comment 13). Was it just a problem for cases where we were checking for FileEditorInput instead of IFileEditorInput, or are you actually providing an IFile-based editor input that does not implement IFileEditorInput? If the latter, what is the rationale?
Georg asked me to answer the question. The described problem was observed for Editors working on multiple files. They use a model object based EditorInput. Though these EditorInputs would be able to provide the information which files might be touched during the save operation, adapting IFile would mean that the editor has to determine a kind of master file. So ResourceMapping seems to be the more appropriate choice. A short remark regarding the marker problem. Logical models might use IResources only as “carriers” for their problem markers. From usage point of view double clicking a marker in the problem view should navigate the user to the place where the problem can be solved. Seeing the IGotoMarker interface (which was extracted from the EditorParts with 3.0) not strictly Editor related, but as a “Navigation handler” the responsibility of recreating an appropriate EditorInput related to a given Marker can be delegated to them.
>might be touched during the save operation, adapting IFile would mean that the >editor has to determine a kind of master file. So ResourceMapping seems to be >the more appropriate choice. Nick, if they don't adapt IFile switching to getAdapter(...) won't solve the problem, or did I miss something?
I guess not. Sounds like they're more interested in bug 88085. I still prefer to use getAdapter(IFile.class) rather than instanceof IFileEditorInput checks (and instanceof FileEditorInput checks are still wrong). But I guess this one is not as significant as I thought. I'll make a note in the dependent PRs.
From comment #15: > Seeing the IGotoMarker interface (which was extracted from the EditorParts > with 3.0) not strictly Editor related, but as a “Navigation handler” the > responsibility of recreating an appropriate EditorInput related to a given > Marker can be delegated to them. Please see bug 88085 comment 1.
