Community
Participate
Working Groups
An extension that allowed a plugin to intercept an IEditorInput before the editor opens would be nice. something like: public IEditorInput checkInput(IEditorInput) The use I see would be valuable in the case of a MultiEditor. A plugin could intercept an input, and potenially return a MultiEditorInput to take its place. So the interception would need to occur before the editor is created. this bug is releated: https://bugs.eclipse.org/bugs/show_bug.cgi?id=42641 Geoff
actually I believe the best spot for this kind of interception would be in the method: private IEditorPart openEditor(final IEditorInput input,final String editorID,final boolean activate,final boolean useEditorID,final IFile file,final boolean forceInternal) throws PartInitException in org.eclipse.ui.internal.WorkbenchPage Geoff
MultiEditor was a late addition to 2.0 to address a specific use case in WSAD, and could have been better designed if we had been given more time. It's unfortunate that MultiEditor requires a special kind of editor input, MultiEditorInput, and that the workbench internals know about this relationship. However, adding an editor input interceptor would just be propagating the problem, in my view. It would help if you could describe what you're trying to do at a higher level. Note however that the MultiEditor is not a priority for us right now, so there will be a limit to how much we can do here in the short term.
Understandable. Here's a more concrete example of what I'd like to be able to do... My plugin provides support for the Tapestry Web Components framework. (http://jakarta.apache.org/tapestry/) Each component (or page) consists of: An xml spec An html template (optional) A java class I'm playing around with MultiEditor, and it would be nice to be able to double click on any of the three above and see all three opened in a MultiEditor. WorkbenchPage.openEditor with all of its permuations takes at least an editor input and an editor id. Would be nice to have the option of examining the input and perhaps substituting a MultiEditorInput before a concrete editor is created. Geoff
Do they need to be visible all at the same time. Seems like screen real- estate would be tight. If not, a tabbed multi-page editor would be a better choice (and MultiPageEditorPart, which supports this, is less of a hack than MultiEditor).
I've gone down the MultiPageEditor route before but I like the first class (even if its incomplete) support for MultiEditor in WorkbenchPage and the EditorManager. In fact I've already altered the sample MultiEditor to be a paged editor (CTabFolder). Just working on getting the key bindings to work right. If its not a priority to improve MultiEditor support in the short term that's fine. I can work around it for now and wait. Geoff
So could you enumerate advantages are there to you in continuing to use MultiEditor vs. MultiPageEditor?
I'm implementing a side by side comparison, albeit a quick/rough one. stay tuned
I will attach a modified example project containing one each of a TiledEditor, a TabbedMultiEditor and an MPEP implementation. Now, of course I'm just starting to get into MultiEditor but here are a few things I've noticed already building the side by side comparison.. 1) IEditor parts in MultiPageEditor parts are not "first class" as far as the WorkbenchPage/EditorManager are concerned. these classes are aware of MultiEditors and so calls like IWorkbenchPage.getActiveEditor() returns the embedded editor part and not the MultiEditor part (if an embedded was the active, of course). In the MPEP implementation I would get the MPEP back from getActiveEditor() and it would be up to me to determine that its an MPEP, cast, and ask it for the active editor. 2) Closing Eclipse almost works right with a MultiEditor. I get the "Save Resources" dialog with the MultiEditor *and* any dirty embedded editors in it. In my case that's wrong as the MultiEditor itself has no savable state (I can fix that though). With a MPEP the list would only show the MPEP, saving/not saving embeded editors is not under user control. I expect that many of the "just works" features of Eclipse managing Editors would work the same with MultiEditors. If they don't...sounds like a bug! 3) Opening multiple embedded editors (genericly) is cleaner (to me) in the MultiEditor than in the MPEP. Currently any action can create a MultiPageEditorInput and call IWorkbenchPage.openEditor(). Doing this in an action with MPEP means I basicly have created my own MultiEditorInput (an input that only my impl of MPEP would understand) and recreate the logic to instantiate the editors that I get for free in MultiEditor. Although, having done all that I get none of the features described in #1 and #2 above. The MPEP implementation was built to duplicate the TabbedMultiEditor. I've noticed some things so far: - how do you create an IEditorPart from an IEditorDescriptor without casting the descriptor to org.eclipse.ui.internal.registry.EditorDescriptor? - As noted above, closing the workbench prompts us only to save the MPEP, there is no choosing from the embedded editors. - can't add the editor label (gradient) shown in the MPEPImpl as CTabItem createItem(Control control) in MPEP is private.
Created attachment 6102 [details] modfied MEP example containing TiledEditor, TabbedMultiEditor, and an MPEP implementation
Geoff, is this still an issue for Spindle? I'm looking at the general area of editor opening as part of our work on support for logical models. I'm not so much interested in the use of MultiEditor at the moment, but rather the mapping from logical elements (like a Tapestry page) to physical files, and how to provide consistent treatment for editor opening, whether from the logical element or the physical files. Maybe you could describe at a high level how this works currently in Spindle, and what issues you have in this area, if any. For more details, see http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm-home/docs/online/team3.2/model-integration-proposals.html although note that this describes the general problem and other specific issues, not so much about editor opening.
(In reply to comment #10) > Geoff, is this still an issue for Spindle? No, I gave up on MultiEditor as the acrobatics needed (and maintenance commitment) were beyond my limited time resources. > I'm looking at the general area of editor opening as part of our work on support > for logical models. I think that's a great idea. ME should be able to play on a level footing with other editors in the workbench. > > I'm not so much interested in the use of MultiEditor at the moment, but rather > the mapping from logical elements (like a Tapestry page) to physical files, and > how to provide consistent treatment for editor opening, whether from the logical > element or the physical files. The model I build keeps a reference to the resource so that's how I map. The model also keeps references to any other resources (usually html template files) that would make up a Tapestry page. > > Maybe you could describe at a high level how this works currently in Spindle, > and what issues you have in this area, if any. Right now, there are two instances in Spindle where an editor needs to be opened: 1. User selects the resource and editor opening works as per all other editors (double clicking on Markers also falls into this category of course). 2. User selects an interesting bit of stuff in an already open editor and invokes an "Open Declaration" action. In this case my model is used locate the model object in the source and to locate the resource that the model is built from so we can open the appropriate editor and scroll. (one thing that is a pain BTW in case 2 occurs when the Tapestry spec is shipped in a jar. I have not been able to avoid referencing an internal class JarEntryFile - but that's another story altogether. I've yet to give the proposal a read but I will and add any thoughts here. > > For more details, see > http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/platform-vcm-home/docs/online/team3.2/model-integration-proposals.html > although note that this describes the general problem and other specific issues, > not so much about editor opening. >
(In reply to comment #11) Ok, I've read the proposal. Sorry it took so long. To be honest, it was hard to "get into it" as the proposal is heavy on Team and Team isn't really something that turns my crank. You are right, there isn't much in the proposal as pertains to opening of editors. So little that there isn't much for me to comment on. But, I just noticed the links in the proposal the requirements document which at first glance looks much more interesting. What I don't see is what is and is not committed to in either the proposal or the req doc. Any pointers? G
So far we're committing to addressing the team operations, and issues around maintaining workspace consistency (e.g. if I try to delete the template file for a Tapestry page from the Navigator, Spindle should have the chance to warn me that this may corrupt the page). This issue about editor opening and other editor lifecycle only came up again recently (this PR notwithstanding) and I'm still working on defining the requirements. Any input you can give to make the requirements more concrete would be helpful. Here are my current requirements for editor opening. These are backed up by concrete scenarios from some of the IBM products (not included here). If you can elaborate on these items based on Spindle scenarios, or if you think there are missing requirements, please comment. Editor lifecycle - pick the most appropriate editor when opening a logical model element - whether from model-specific view or generic view - pick the most appropriate editor when opening a file - whether from model-specific view or generic view - handle case for shared resource (e.g. WSDL file) - handle case for 1 file : N model elements - consistent and predictable treatment of Open (or double-click) and Open With - consistent and predictable treatment of icons for elements (consistent with default editor choice) - for files, content types are not taken into account for performance reasons - consistent and predictable treatment of both initial case, and case where editor is already open - navigation from marker (e.g. in Problems view) to appropriate editor - selecting element within target editor - remembering last choice (for both resources and model elements) - sort order in Open With - treatment of platform default items in Open With > Text Editor, System Editor, In Place Editor, Default Editor - should only show or enable ones that apply - Text Editor may not make sense - revealing mapping from logical to physical as needed
Here is anothr usecase for interception of editor opening: bug 117746 [EditorMgmt] Editors should be able to treat large files specially (e.g. deny opening huge files)
I've released the first cut of the support for custom editor opening strategies to HEAD. The Open With menu is now populated from an OpenWithInfo created by merging the OpenWithInfo objects obtained from IEditorOpenStrategy objects associated with model providers. There's a default ResourceOpenWithStrategy associated with the resource model provider, which encapsulates the previous content-type and file association-driven strategy in the IDE.
I'm having second thoughts about the current approach, and will rethink this for M5.
sorry I haven't been much help. The day job is becoming all consuming and I have not been able to give this or Spindle much thought in the last 6 weeks or so. Geoff
No problem Geoff, we have other use cases besides Spindle's that are likely either identical or very similar.
The model-provider-driven IEditorOpenStrategy approach did not pan out well, mainly because IEditorOpenStrategy required complete knowledge of all applicable editors, which goes against Eclipse's open-ended philosophy. I'm going to have to back out of this for 3.2.
(In reply to comment #19) > The model-provider-driven IEditorOpenStrategy approach did not pan out well, > mainly because IEditorOpenStrategy required complete knowledge of all > applicable editors, which goes against Eclipse's open-ended philosophy. > I'm going to have to back out of this for 3.2. > Sorry to hear that and that I wan't able to contribute. I'm glad though that you were able to experiment with the idea even if the resulting implementation wasn't the right one. Geoff
Created attachment 34453 [details] Removed code, captured here for posterity's sake.
*** Bug 127437 has been marked as a duplicate of this bug. ***
Bug 127437 has an interesting use case. A workaround is to define an external editor launcher, which can then do whatever it wants with the file. In the editor extension, specify launcher= instead of class=, where the referenced class implements IEditorLauncher. The IEditorLauncher is given the file system path, which can be mapped back to IResource using ResourcesPlugin.getWorkspace().getRoot().findFilesForLocation(IPath). See also the Javadoc for IWorkspaceRoot.getFileForLocation for why findFilesForLocation is preferred. Note that this workaround interacts poorly with the editor navigation history though (Navigate > Back / Forward).
> A workaround is to define an external editor launcher, which can then do > whatever it wants with the file. Thanks for a quick reply! I tried this workaround but like you said there's some nasty problems with navigation related features. E.g. in java editor following features do not jump to a correct place if the target editor is not open: - ctrl-t navigation - ctrl-1 quick fix when creating a new method - etc.. Is there any workround to enable better navigation? Thanks again!
Joni, I didn't think navigation would get messed up -that- bad. Can you clarify with specific steps? What does your launcher do? I was assuming you'd just turn around and open the appropriate internal editor (bean editor or Java editor) using one of the IDE.openEditor methods.
> Can you clarify with specific steps? What does your launcher do? I was > assuming you'd just turn around and open the appropriate internal editor (bean > editor or Java editor) using one of the IDE.openEditor methods. Yes, that's basically what i do: public class WicketEditorLauncher extends TextEditor implements IEditorLauncher { public void open(IPath file) { IFile[] files = ResourcesPlugin.getWorkspace().getRoot().findFilesForLocation(file); String editorId = "org.eclipse.jdt.ui.CompilationUnitEditor"; if (isTypicalMarkupContainer(files[0])) { editorId = WicketEditor.ID; } try { FileEditorInput input = new FileEditorInput(files[0]); WicketPlugin.getDefault().getActivePage().openEditor(input, editorId); } catch (PartInitException e) { throw new RuntimeException(e); } } Now, normal java classes are opened correctly with CompilationUnitEditor but navigation is broken unless the file happens to already open in an editor. I'm using eclipse 3.1.1.
> navigation is broken unless the file happens to already open in an editor. I'm sorry, typo. "unless the file happens to be open in an editor"
WicketEditorLauncher should not extend TextEditor, but that shouldn't cause the navigation problem.
Using a similar launcher that just opens a Java editor, I was unable to reproduce the problems reported in comment 24. The code is: public class Launcher implements IEditorLauncher { public void open(IPath location) { IFile file = ResourcesPlugin.getWorkspace().getRoot() .getFileForLocation(location); String editorId = "org.eclipse.jdt.ui.CompilationUnitEditor"; try { FileEditorInput input = new FileEditorInput(file); PlatformUI.getWorkbench().getActiveWorkbenchWindow() .getActivePage().openEditor(input, editorId); } catch (PartInitException e) { throw new RuntimeException(e); } } }
I still can reproduce the problem using the code you provided. The exact steps are: 1. Make wicket editor as a default editor for java files from preferences -> file associations. 2. Create new class Foo 3. Create new class Bar 4. Close the editor for Bar 5. Open Foo and add following constructor for it: public Foo() { new Bar().test(); } 6. Go to the problem marker, press <ctrl>-1 and select 'create method 'test()' for type Bar' 7. The method is correctly created but the cursor is not moved over the created method 'foo()'. All works correctly if I repeat the steps when the editor for Bar is open (i.e. if I skip the step 4). This is how I have configured the editor launcher in plugin.xml: <extension point="org.eclipse.ui.editors"> <editor id="wicketbench.eclipse.editorLauncher" name="Wicket Editor Launcher (set as default)" icon="icons/javaclass.gif" launcher="wicketbench.eclipse.editor.WicketEditorLauncher" extensions="java"> </editor> </extension>
Thanks, I'll look into it some more.
Some of the scenarios here can be addressed using the IEditorMatchingStrategy support, which is intended to handle the case where one editor handles multiple files. E.g. - open File A - get editor E on files A and B - open File B - activate existing editor E and show info for B In the the editor extension for E, you can specify matchingStrategy="SomeClassImplementingIEditorMatchingStrategy". When opening file B, the editors' matching strategy gets a chance to say "I can handle that". If the editor also implements IShowEditorInput, it can switch tabs, or whatever, to show whatever is relevant for the second file.
Thanks Nick, I've been thinking about using the IEditorMatchingStrategy but can't figure out how it could help solve my issue. WicketEditor is a MultiPageEditorPart which embeds CompilationUnitEditor (or whatever Java editor the user prefers, e.g. aspectj editor) + editors for other related resources (html, properties). Since CompilationUnitEditor is not designed to be embeddable, there's a few features which I haven't been able to enable for embedded CompilationUnitEditor. The users of the plugin could live with that if non-wicket related java files could be opened with "real" java editor instead of non-feature complete embedded java editor. So, this issue is currently a blocker for me since I haven't been able to find a satisfactory solution without major drawbacks.
(In reply to comment #33) You need the MultiEditor which would allow you to embed the CU editor with all of it's features enabled. BTW - working with MultiEditor was the reason I opened this issue in the first place :-)
Thanks Geoff, I just examined this but the problem with MultiEditor seems to be that it is not possible to associate MultiEditor with a file extension. Instead, it needs to be opened using a custom action, as done in an attached example. So, I propably won't go further that road since you already went there and turned back :)
Hi! Has any progress made related to this issue? The navigation problems got even worse with eclipse 3.2. Now debug view can't locate the current line if the editor has been opened using IEditorLauncher. So, any news on these issues would be greatly welcomed: - improved MultiPageEditor support (make it easier to embed existing editors, like java editor, html editor etc.) - improved mechanism to intercept editor opening (so that navigation etc. works) Thanks!
(In reply to comment #36) > Has any progress made related to this issue? There are currently no plans to address this for 3.3.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
