Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 320336

Summary: Moving a view into the editor area should not affect another perspective
Product: [Eclipse Project] e4 Reporter: Stefan Mücke <s.muecke>
Component: UIAssignee: Project Inbox <e4.ui-inbox>
Status: CLOSED DUPLICATE QA Contact:
Severity: normal    
Priority: P3 CC: bokowski, remy.suen
Version: 1.0   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description Stefan Mücke CLA 2010-07-19 17:57:36 EDT
1. Open a clean e4 workspace
2. Open the Team Synchronizing perspective
3. Switch back to the Java perspective
4. Move the Problems view into the editor area
5. Switch again to Team Synchronizing
   Result (1): Problems view is also in the editor area
6. Switch back to the Java perspective
7. Move the Problems view back to the previous position
5. Switch again to Team Synchronizing
   Result (2): Problems view has been REMOVED

Neither (1) nor (2) should happen. I guess the problem is that the editor area is shared between the perspectives.

If this cannot be fixed, I think this unexpected behavior is better than not being able to move views into the editor area at all.
Comment 1 Remy Suen CLA 2010-07-19 18:23:35 EDT
(In reply to comment #0)
> Neither (1) nor (2) should happen. I guess the problem is that the editor area
> is shared between the perspectives.

Personally, I disagree and feel that what happened in 1 and 2 is "normal".

Isn't the point of moving a view into the editor area so that it can be shared across perspectives? At least, that would be why I moved it in there.

It seems to me that you want to move it in there so that you have more screen real estate for the given view, not so that it can be shared across perspectives.

These two conflicting mindsets are a recipe for disaster. :o Well, the disaster seems to have already happened, in the form of this bug report.
Comment 2 Stefan Mücke CLA 2010-07-19 18:47:22 EDT
You don't need to move a view into the editor area to have it shared. With 3.x and the e4 compatibility platform, views are always shared (except for multiple instances perhaps).

So, yes, my intention was to manage screen estate.

Consider the following scenario with a split editor area:

  +------------------------+
  |                        |
  |    Java code editors   |
  |                        |
  +------------------------+
  |                        |
  |  Some other editors    |
  |  (e.g. input files)    |
  +------------------------+

Let's say you want to frequently use the Console view in addition:

You have several options:
(1) Move Console view below the split editor area: BAD (reduced screen estate)
(2) Minimize the Console view: BAD (must open and close frequently)
(3) Move on top of "Some other editors": GREAT

In 3.x, I several times wanted to have option (3), but unfortunately this was not possible.
Comment 3 Remy Suen CLA 2010-07-19 18:51:11 EDT
(In reply to comment #2)
> You don't need to move a view into the editor area to have it shared.

I meant shared as in shared like the editor area so it's always in that "one spot".

In any case, I'll let other people weigh in on this bug.
Comment 4 Boris Bokowski CLA 2010-07-20 17:25:30 EDT
Your theory is correct - the editor area is shared between perspectives. We won't fix this for 4.0 since it is one of the few features with which we can demonstrate the flexibility we've gained by using a model for the underlying UI state.
Comment 5 Eric Moffatt CLA 2010-09-14 09:08:20 EDT
The only concern that I have with these scenarios is that I seem to remember 3.x having the ability to have a perspective *without* an EA. What do we do with the view in this case (if the user tries to open it)?
Comment 6 Eric Moffatt CLA 2010-09-29 15:47:03 EDT
I'm +1 for the behavior as outlined by Remy...the gesture of placing a View into the 'shared area' is *intended* to share it across perspectives, meaning that it must be removed from any existing perspectives where it was outside...

I'll mark this as a DUP of bug 321864 since there are more related scenarios on it.

*** This bug has been marked as a duplicate of bug 321864 ***