Community
Participate
Working Groups
Improve support for multi-page editors. The current Workbench mechanisms for managing multi-page editors are not sufficiently flexible to support several known use cases. Also, the workbench part/site model (where a part's services are provided by its site) does not lend itself well to nesting, since each service needs to be "virtualized" for nested editors. Eclipse should provide a more flexible framework for multi-page editors, and perhaps based on a service model that supports nesting. [Platform UI]
Dani, it would help to know exactly which patterns break the text editor when nested, or rather, what extra context does the text editor need that is not being provided by the API on its site? Any time the text editor assumes it's the outermost editor, e.g. seeing if it's the active one using page.getActiveEditor(), then nesting will fail. This seems to be the case for bug 42919, and could be rectified by adding an isActiveEditor() method to IEditorSite What is the issue for bug 38166?
A question of interest, are Multi-Page-Editors bound to only one resource, or could each page have a different? I ask this though maybe CDT can incorporate a Multi-Page-Editor to view corresponding files in one place instead of cluttering the workspace with editors for each file. Say I have a Class ClassA, we have a ClassA.cpp and a ClassA.h file (and maybe an ClassA.idl file). They could be opened in a Multi-Page-Editor if possible.
An editor is opened on an IEditorInput. See the openEditor methods on IWorkbenchPage, and IEditorPart.setInput. Note that the input is also used to determine what to show in the editor tab (its name and tooltip). Usually for workspace-based applications like the Eclipse SDK, this is a FileEditorInput (pointing to an IFile in the workspace), or a variant like CompilationUnitEditorInput used by JDT. The Workbench itself does not require that an editor input be a FileEditorInput, nor does it prevent the editor from opening other files even if the input is a FileEditorInput. However, views like the Navigator and Package Explorer do make assumptions about the kind of editor input, e.g. Navigator uses a FileEditorInput. So, it would probably be simplest if your editor could process FileEditorInputs (check for the interface IFileEditorInput) and be able to map from one of your files to the others. However, this will have the downside of showing ClassA.h in the editor tab if you opened the file on ClassA.h, even though it's editing the whole group of files. If you typically use your own views to open files, though, you could define your own kind of editor input which represents the whole group of files, and which provides an appropriate name and tooltip. For 3.0, we're considering adding an open, extensible mechanism to map from an arbitrary object (e.g. file selected in a view) to the appropriate editor input. I would also suggest posting to the eclipse.platform newsgroup to see how others have handled this.
deferred.
see bug 68082: how do you plug-in extensions for an editor part which is a subpart of a multipage editor, e.g. fonts.
How do you look up the font now? The site of a nested editor returns "" for getId(), so if you're trying to use the editor extension id to look up the font, that will not work. That is because nested editors are added programmatically -- the extension point is not used. This is an inherent problem in the way we do multi-page editors currently.
The font is looked up by getting the configuration element (IWorkbenchPart#getConfigurationElement) and looking for the symbolicFontName attribute. And like Nick said, since nested editors are added programmatically, there is no extension point for the nested editors.
Minor point: getConfigurationElement() is on WorkbenchPart, not IWorkbenchPart. The configuration is remembered in its implementation of IExecutableExtension.setInitializationData(...), which is only called if the part is instantiated via the registry, not directly.
This is no longer a plan item.
Sigh ... I have a dream where Multi-Page Editors are actually first class editors, and the workbench page slaps a second set of tabs at the bottom that allow the editors to be linked together conceptually. PW
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.
