Community
Participate
Working Groups
Created attachment 185084 [details] screenshot Title in Eric's words :) See screen shot The Min/Max buttons in the editor area could be moved down to the same level as the tabs and that whitespace could be eliminated.
In essence the shared area should not 'grow' its own CTF until it contains a sash...
Created attachment 185340 [details] Interim work
So, we discussed this. The purpose of visually displaying the area is to indicate that it behaves differently than other stacks (i.e. it's shared). This is true whether or not there is one view/editor in it or multiple stacks, and it is more important than it was in 3.x because it's not just editors that can go there. My preference would be to invest in the styling support to reduce the amount of wasted space in the area, rather than hiding it -- particularly, if we only *sometimes* hide it.
Created attachment 192778 [details] Initial implementation...only show the area if it is split Initially creates a simple composite for the MArea If it's asked to render an MPSC (indicating a split area) then it wraps a CTF with a CTI containing the initial composite If it's asked to render an MPartStack then it ensures that the MArea's widget is the simple Composite. Adjusted the MinMaxAddon to take this into account There is currently at least one known issue when the (un)split happens in that the CTF's buttons are not managed correctly (switching the perspective brings everything back to a good state.
Committed in >20110407. Applied the patch. I'm committing this now so that Bogdan and McQ have it for their CSS styling meeting tomorrow...
Created attachment 193193 [details] Clean up button display and management
Committed in >20110413. Applied the patch.
*** Bug 342734 has been marked as a duplicate of this bug. ***
1. Open an editor. 2. Drag the 'Outline' view to the right of the editor so it goes inside the shared area. 3. Close the editor. 4. Close the 'Outline' view. 5. The shared area is gone.
Same problem happens if you perform the same operations using two editors instead of an editor and a view.
Created attachment 193293 [details] More stack management... 1) Prevent dragging the last stack out of the shared area (so it doesn't go empty) 2) Change the way we locate where to 'site' editors (the 'primaryDataStack' tag approach wasn't working and would be very difficult to maintain... NOTE: We still have issues with having views in the shared area since closing them results in still having a sash container as the child of the area, even though there's only one visible stack (i.e. this does *not* fix the scenario in comment #9.
Committed in >20110414. Applied the patch. I'll continue on this tomorrow...
the method "countRenderableChildren" introduced to the ModelServiceImpl is not taking detached windows into account. This might not be a problem to problem you are trying to solve here but it makes the method not following its own spec (well we can argue what children in the sense of the JavaDoc means here - if children really MElementContainer-children then ok but why does the method then not get a MElementContainer?). I've filed bug 343034 which request to use EMF-Utilities to walk the Object-Graph. In this case using EMF-API i think we can make the method by simply invoking "eo.eContents()" which returns all direct children and so the method can accept any MApplicationElement.
1. Open an editor. 2. Open another editor. 3. Split the shared area into two stacks. 4. Ctrl+Shift+W 5. The shared area is destroyed. Restarting Eclipse does not help, you must remove your deltas.
Created attachment 193754 [details] Patch that handles views in the shared area
Committed in >20110420. Applied the patch. I see an odd effect where the CTF in the shared area doesn't show the min / max buttons unless there's at least one tab... Remy's Ctrl-Shift-W scenario still fails but this isn't directly related to this work. It may be an 'asynch' issue since this is the only scenario where we can end up emptying multiple stacks without having the event loop spin...
Created attachment 193839 [details] Handle double clicking on a non-split shared area
Committed in >20110421. Applied the patch.
Created attachment 194008 [details] Screenshot depicting the state in question. 1. Open two editors. 2. Split the shared area vertically. 3. Drag a view to the top stack (see attached). 4. Close the parts in the order specified in the attached screenshot. 5. The shared area is now gone.
Created attachment 194018 [details] Patch to the CleanupAddon to better handle checks for 'lastEditorStack' I already had this code in place but didn't commit it since it wasn't fixing the Ctrl-Shift-W case (but it does fix this scenario).
Committed in >20110425. Applied the patch.
Created attachment 194022 [details] Screenshot depicting the problem in question. The problem is fixed by attachment 194018 [details] but now the attached state shows up when bringing the view back.
I20110426-0200 1. Open two editors. 2. Drag the second one to the right, splitting the two stacks. 3. Close the left one. 4. Close the remaining one (what used to be the one on the right). 5. Open two editors. 6. Drag the second one to the bottom. 7. The shared area disappears.
(In reply to comment #23) > 7. The shared area disappears. It comes back if you resize the window. Guess there's another layout problem here.
If you drag a stack to split the shared area, it won't change its rendering to have a global tab folder.
Created attachment 194368 [details] Rearranged debug perspective I encountered an interesting problem where the shared area seemed to disappear when I closed all editors in a perspective. I rearrange my debug perspective to look like the attached image: 1. I drag the Debug, Breakpoints, and Variables views towards the Outline 2. I drag the console to appear under the editors (providing more room for the Variables view) To do this under the E4 SDK, I have to ensure an editor is open: I could not get the console to appear underneath the editor area otherwise. But I didn't realize that dragging the console in then opened a new part stack in the shared area. Closing all editors (Cmd-Shift-W in MacOS X) then leaves the console fully maximized (next screenshot).
Created attachment 194369 [details] After a close-all-editors: the editor area seems to disappear The result of having closed all editors: the shared editor area seems to have disappeared.
Created attachment 195074 [details] Fix uses of 'isLastEditorStack' We were missing a check in the renderingChangeHandler as well as incorrectly not caching the value of 'isLastEditorStack' in the childrenHandler (we were calling the method twice but if the first instance returned 'false' we'd set the stack's TBR to false, leading to the second call to return 'true' incorrectly).
Committed in >20110509. Applied the patch. Ctrl+Shift+W no longer results in an empty Shared Area...
Removing outdated target milestone.
The current handling for the Editor Area has been in place for a long time with no other defects being reported against it...
