Community
Participate
Working Groups
Eclipse Forms add support for multi-page editors where some pages are forms, but one or more pages are source editors. Here is the scenario that will represent a significant problem for PDE: Imagine a multi-page editor based on MultiPageEditorPart that has more than one source editor as tabs. Each source editor opens a different file in the project. Example: new PDE manifest editor will open plugin.xml, META- INF/MANIFEST.MF and build.properties in their corresponding tabs all the time. The same editor is registered for all three files - the only difference is that different pages are initially selected for each file. Imagine that you opened plugin.xml. Since there are source editors in MultiPageEditorPart, some have editor input for files opened by the editor itself (not by the user). Now imagine that while the editor is still open, you select 'build.properties' and open it as well. Today: a new instance of the multi-page editor is opened Desired behaviour: editor manager should detect that an instance of MultiPageEditorPart is opened and that one of its nested editors has the matching input. The editor should simply be brought to front (ideally, a suitable page should also be shown but we can think about it later). The UI team has all that is needed to achieve this behaviour - MultiPageEditorPart belongs to the UI team and it can do something like this: if (editorPart instanceof MultiPageEditorPart) { MultiPageEditorPart multiEditor = (MultiPageEditorPart)editorPart; for (int i=0; i<multiEditor.getEditorCount(); i++) { IEditorPart nestedEditor = multiEditor.getEditor(i); if (nestedEditor!=null) { IEditorInput nestedInput=nestedEditor.getEditorInput(); // if the nested input matches the desired file to open, // just activate the multi editor intead of creating a new instance. } } } I am marking this as major because it will be a serious usability issue for the incoming multi-source PDE editors.
Dan, please look at this request and check if it will cause problems with your editors that extend MultiPageEditorPart. If you are for it, please add your vote - it is very important for PDE editors that handle multiple files.
Marking this as an enhancement. Just to get a feel for priority: how many people have complained about this besides Jeff? Is this something that is needed for 3.0.x, 3.1 or beyond?
This will become a big problem as more and more people start creating plugins with the new format (i.e. with the OSGi manifest.mf file). I can easily see people open the manifest.mf file (pde editor #1) and then, out of habit or curiosity, they would want to see what goes into the plugin.xml file(editor #2). Bring in the build.properties file into the equation and now you have three editors open on the same file. It has happened me a hundred times. So it's not of those only-Jeff scenarios (and believe me there exists several only-Jeff scenarios :-), it will be a common source of confusion as we move into 3.1 when users would have become more educated about the new runtime and PDE tooling will start "promoting" the creation of plug-ins with manifest.mf instead of labeling this option as "for advanced users only" as it is for 3.0.
cc my good friend Jeff as I referenced his name several times in my previous comment and I don't like to talk about people behind their backs.
Glad to see it was used accurately... ;-) some points. - This should be a 3.1 issue. - The current situation is quite confusing and will only get worse - Other scenarios include any multi resource model objects (e.g., elements in the web space etc etc) - This may impact usecases in the logical to physical world (BTW, Wassim, you should likely talk to Jean-Michel about PDE as a use case for the logical- physical work)
See also bug 74263. Note that the workbench proper currently has no knowledge about MultiPageEditorPart. MultiPageEditorPart was designed to use public workbench API as much as possible (there are some exceptions in that it needs to implement site interfaces which are currently internal), and without the workbench having to have special case support for it. While we want to expand the support for nesting parts, this should be done through more general API rather than adding special case hacks for MultiPageEditorPart.
>I can easily see people open the manifest.mf file (pde editor #1) and then, >out of habit or curiosity, they would want to see what goes into the >plugin.xml file(editor #2). Bring in the build.properties file into the >equation and now you have three editors open on the same file. It has >happened me a hundred times I don't see what the problem is. These three editors should be sharing the same in-memory document. What is the difference to the user if a file is opened as a page in a multi-page editor, or as a new editor? The only difference should be where the Tab appears which allows you to switch to that file. How is the proposed change going to address multiple WorkbenchWindows? If I do the above steps, but I open each file in a different WorkbenchWindow, then you still have the same problem that a file will be edited by 3 different editors. The live document must be shared across editors anyway, so that makes this proposal not so critical.
See bug 64763 comments 6 and 7.
Moving Dougs bugs
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
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.
