Community
Participate
Working Groups
Being able to move views into the editor stack and editors into the view stack is one of the most visible/hyped change in the 4.0 SDK. This was not something I had anticipated we would actually be going for when I was reimplementing the 3.x APIs. As such, the code was not written in a way to handle these scenarios which makes the current interaction of views and editors in "alternate" stacks inconsistent and ultimately unpredictable. Scenario A: 1. Open a file. 2. Drag the editor to a view stack. 3. Switch perspectives. 4. Open the same file. 5. Switch back to the original perspective. 6. Should the user see two editors or just one in the editor area? Scenario B: Editors that are no longer shared needs to have their references extracted appropriately so that they won't be found when invoking getEditorReferences() on a workbench page. This is slightly akin to IWorkbenchPage's showEditor(IEditorReference) and hideEditor(IEditorReference) that was introduced with bug 11001. Scenario C and D: There are some conflicting expectations about what should happen with views in the editor area (see bug 320298 and bug 320336). Scenario E: It is absolutely critical that dirty parts that are not currently visible in the presentation, be it because it's in another perspective or because of divine intervention, participate in a window's shutdown cycle so that no data is lost on those dirty parts.
In the case of editors existing *outside* the EA the case is (at least code-wise) simpler since all editors are 'multi-instance' to support the 'New Editor' command. This means we can simply choose to allow the two instances to exist if we so desire. The question of re-opening the file for an editor that has been moved out of the EA still exists though; should we 'find' the editor in the current UI and show it regardless of whether it's in a PartStack or should we just search in the EA? How does the current implementation deal with multiple instances of 'dirty' editors/views ?
(In reply to comment #1) > The question of re-opening the file for an editor that has been moved out of > the EA still exists though; should we 'find' the editor in the current UI and > show it regardless of whether it's in a PartStack or should we just search in > the EA? Might as well just show the existing one. I see no reason to spawn another one personally. > How does the current implementation deal with multiple instances of 'dirty' > editors/views ? Can you rephrase/elaborate on this?
(In reply to comment #0) Those are very good points; I think we need to first settle on what the editor area is/does in e4. A number of logical problems seem to be caused by the "invisible" nature of the editor area: it is clearly a special area as it is shared between perspectives, yet there is no indication to the user of there this area is. How about we say that we have a "shared area" (containg both editors and views) that stays constant as we switch perspective and is decorated in a way that makes it obvious?
Part of this exercise must be to provide a *visible* container for the editor 'area'. This must not only show a visible affordance of some type (border...) to indicate that it's an area but should also have the min/max affordances. I've already talked to Bogdan about this but we haven't come up a solution yet (perhaps a specialized form of CTF? a new custom control?). Note that this will likely entail a change to the model (a sub-type of PSC? a 'tag' on a PSC that the SashRenderer understands?)
(In reply to comment #4) > Part of this exercise must be to provide a *visible* container for the editor > 'area'. This must not only show a visible affordance of some type (border...) > to indicate that it's an area but should also have the min/max affordances. > I opened bug 322432 to track the design work for the editor area - what the visual should be. I don't think we'll get any design work from Linda before Oct/Nov, but she'll be available to comment on anything we try to implement...
Editors are not affected when a user resets the perspective... Scenario F: What happens to an editor that is outside of the shared area? When the perspective is reset, is that editor removed? Scenario G: What happens to a view that is inside the shared area? When the perspective is reset, does that view stay inside the shared area?
Scenario H: Does the pinning of editors outside the shared area make sense? Should opened editors outside of the shared area be automatically closed?
Scenario I: Ctrl+E is called 'Quick Switch Editor'. How should it behave if editors are not all in one set place? Should the command just be renamed with its functionality intact for cycling through parts within the shared area?
Scenario J: After a view has entered the shared area and it has closed, should the next request to open it be in the shared area or not?
I've captured a fair number of issues related to mixing views/editors...whatever answers we come up with have to cover all of these cases in some manner.
I think we should keep the shared area as constant as possible. The User had to make a specific gesture to get the view into the shared area so why would we change that? Here's some specific comments based on the given scenarios: A) Two editors (perhaps we need a 'Close other instances' on the tab?) B) We should handle this the same way as we do 'hidden' editors. Editors that are only visible in a particular perspective should be considered hidden when not in that perspective. C & D) Given the comment above we should alter open/reset perspective to respect that the view is in the shared area. This would include removing it from any existing perspective's layout. E) Surely true. Operations like Save All (as well as shutdown...) should operate against all dirty parts (be they editors or views). One finesse point might be to, when closing a perspective, to only prompt to save views/editors that are *not* in the shared area (unless it's the last perspective). F) Yes. Keep the shared area as is but reset everything else. G) Yes. The user put it there. H) Not sure on this one. What's the effect of pinning an editor? I) See my answer for B). If the editor is visible in the perspective anywhere then it should show up in the QSE list. Ones only in other perspectives should not appear. J) Yes. The user put it there. There are just my take...the 'reset' cases are truly problematic in that we may way to have a 'full reset' capability that will remove the view from the shared area, guaranteeing a view layout that would match a fresh workspace.
Scenario K: How should Ctrl+W work? Should it only work on content in the shared area including views? Or should it only interact with editors? If it only explicitly works on the _last_ active editor, then we can get into the strange scenario described by bug 326081. The same question will need to be raised for how Ctrl+Shift+W should function with regards to views in the shared area and editors outside of the shared area.
*** Bug 320336 has been marked as a duplicate of this bug. ***
The actual behavior when moving a view to a shared part is unsuitable. If you just move a view to the shared part and back to a view stack it has an affect to other perspectives. Because the same view is still hidden in other perspectives. The user does not really know about this thing and does not expect this. I have created a fix that does revert hidden views when user is moving the part back to view stack. The patch is a simple listener (processor) that: - listens on adding a placeholder on a shared area - tags the every placeholder with same elementId with a "MovedToSharedArea" tag - when a placeholder is dropped back to a view stack, every placeholder with "MovedToSharedArea" tag is made visible again
Created attachment 232577 [details] Fix for moving view to shared area
(In reply to comment #15) > Created attachment 232577 [details] > Fix for moving view to shared area Matthias, this is an umbrella bug. Could you please open a bug against Platform/UI with the specific usecase you are trying to solve (you can mark it blocking this bug) and we can discuss your patch on that bug. PW
(In reply to comment #16) > (In reply to comment #15) > > Created attachment 232577 [details] > > Fix for moving view to shared area > > Matthias, this is an umbrella bug. Could you please open a bug against > Platform/UI with the specific usecase you are trying to solve (you can mark > it blocking this bug) and we can discuss your patch on that bug. > > PW I came from Bug 320336 which describes my problem very well, but it's a duplicate to this. Shall I reopen it?
(In reply to comment #17) > > I came from Bug 320336 which describes my problem very well, but it's a > duplicate to this. > Shall I reopen it? Yes please, let's discuss that specific scenario on that bug. PW
Closing this umbrella bug.
