Bug 58559 - [ViewMgmt] [EditorMgmt] [RCP] If views and editors look the same, they should behave the same
Summary: [ViewMgmt] [EditorMgmt] [RCP] If views and editors look the same, they should...
Status: RESOLVED DUPLICATE of bug 37719
Alias: None
Product: Platform
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.0   Edit
Hardware: PC All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Nick Edgar CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-04-14 16:47 EDT by David J. Orme CLA
Modified: 2004-04-15 14:16 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David J. Orme CLA 2004-04-14 16:47:53 EDT
An outside-the-box, but potentially-useful idea toward potentially resolving the
view look-and-feel debate:

If views and editors are supposed to all look the same (as they practically do
in M8), then maybe we should get rid of the UI concept of an editor altogether
and make views and editors the same thing.  Editors could just be views that
happen to take an IEditorInput and allow multiple instances.

In order to do this, off the top of my head, we would need:

- The ability for a view optionally to accept an IEditorInput.

- The ability for a view that accepts an IEditorInput to be instantiated more
than once--have more than one instance.

- To change the perspective-definition code so that instead of having an "editor
area," you just have a "root view area", which happens to contain the "editing
views" within the IDE perspectives.

- To change the workbench-state-saving code so that it knows how to deal with
this change.

This would simplify the UI in several ways:

- All UI elements inside the workbench would behave the same way.

- RCP developers would no longer be forced to resort to using editors in order
to get a view that can have multiple instances.

- Special-case code for editor handling would go away in the perspective
management code.

- It's a simpler overall design.
Comment 1 Nick Edgar CLA 2004-04-15 11:53:56 EDT
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).


*** This bug has been marked as a duplicate of 37719 ***
Comment 2 David J. Orme CLA 2004-04-15 14:16:45 EDT
Regarding the notion of the "active editor", this can be implemented
semantically as the "part that contributes the global selection."  Looked at
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.