Summary: | [MPE] [EditorMgmt] MultiPageEditorPart should be supported better by editor manager | ||
---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Dejan Glozic <dejan> |
Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | bokowski, danberg, hudsonr, jeffmcaffer, n.a.edgar, wassim.melhem |
Version: | 3.0 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Bug Depends on: | 46207 | ||
Bug Blocks: | 64763 |
Description
Dejan Glozic
2004-03-03 21:03:30 EST
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.
Moving Dougs bugs 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. |