Community
Participate
Working Groups
Unify editors and views. The Workbench currently makes a strong distinction between editors and views. The editor area has "pride of place" placement within a perspective. Editors support an open/edit/save/close lifecycle (supported by actions such as File > Save, Save As... and Save All), whereas views are intended to support navigation or the presentation of information, and do not participate in Save commands. Eclipse should provide a more flexible model of Workbench parts. [Platform UI]
Editors seem to be first class citizens and take preference over views. By default, every perspective reserves space for an editor (although this can be turned off, Window > Hide Editors, at least until a resource is opened). There are cases where a perspective simply doesn't need any editors, but this is not supported by Eclipse. Maybe a solution would be for all editors to reside within a view, which would then make them equal citizens with other views. My only concern here is that views are fairly real-estate greedy due to all their decoration. Views already consume a large amount of the screen real- estate and I'd hate to lose any more. Using Eclipse in 1024x768 is becoming harder, but perhaps that discussion should be saved for another PR.
I think Simon makes a great suggestion with being able to contain editor parts within a view. This is also a good use case for the view modifications (hide titlebars, disable dragging, and other attributes) that were proposed in bug 29179. So the view that parents the editors could hide it's titlebar and disable dragging etc... How about using the retargetable pattern to allow for this. Editors or the editor area can be retargetable, such that they are created within the body of the specified target view. A perspective would be responsible for defining the targets. It might also be nice to make any workbench part retargetable, so that Views or a collection of Views may be parented by one View. Their titlebars would be turned off and the views would be separated by a sash form. Actions maybe consolidated into the one parent titlebar. -m@
Matthew, see bug 46207 on composing workbench parts and editors.
*** Bug 58559 has been marked as a duplicate of this bug. ***
From bug 58559: This is something we had been considering in the RCP space, but it's not going to happen for 3.0. The general idea is not a bad one, though. I know of one app that avoids using editors simply because they want to mix and match views and document panes in the same space. Note that multi-instance views are now supported. See IWorkbenchPage.showView(String id, String secondaryId, int mode), and bug 31612 for background. Aside from the space usage, there are other differences between views and editors. There's the notion of an active editor (IWorkbenchPage.getActiveEditor()), independent of the active part (IWorkbenchPage.getActivePart()). For example: - open a Java editor - the Outline view shows the outline - activate the Package Explorer - the Outline view still shows the outline for the editor Editors also have an open/edit/save lifecycle, views generally do not (although this was loosened in 2.1 with the addition of ISaveablePart, which views can implement in addition to editors).
Regarding the notion of the "active editor" in comment 5, this can be implemented semantically as the "part that contributes the current global selection." Viewed this way, anything, including a view, could behave like an editor. And as you said, the open/edit/save life cycle isn't necessarily unique to editors any more.
I don't think it's the same. In my example above, the Package Explorer's selection is used by the selection service, but the outline should still track the editor. Another difference: editors get to contribute to the main menubar and toolbar, views don't (currently).
Okay, you have good points and obviously know the code base better than I do. :-)
deferred
Is anything planned for this in 3.1?
No, there is nothing concrete planned here for 3.1. As part of our investigations for improved support for nesting parts, and an improved service model, this may get reactivated.
Reassigning bugs in component areas that are changing ownership.
This is no longer a plan item.
Remy is now responsible for watching the [ViewMgmt] category.
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.
