Community
Participate
Working Groups
Created attachment 176400 [details] split editor area in 3.7 (I'm using this bug to document the issue for the visual designer, so this is going to be a lot more detail than usual in a bug:) We need visual indication for the editor area, so the user knows what they are maximizing or minimizing when working with a split editor area. The first attachment shows what we have been doing in 3.x. When an editor area is split, the min/max buttons show on only one of the editors, yet the buttons operate on the entire area. This is not ideal, but users can learn it because the editor area is "special" in other ways: - it is the only place where one can put an editor - views cannot be placed there - it is shared between perspectives whereas other stacks are not. The screenshot shows an editor area next to an outline view. Note that the outline view stack has min/max buttons. The editor area only has min/max buttons on one of the splits. The user is presumed to figure out that the min/max on "TaskItem.class" actually applies to the area that includes both AbstractDeltaStep and TaskItem.
Created attachment 176401 [details] split editor area in 4.0 In 4.0, it is possible for the user to drag views into the editor area, so it's getting harder to tell that the editor is "special." This screenshot shows an editor area that actually contains (and splits) the problems view. (It is a bug that both DataDeltaNode and Problems have a max button, and currently using the max button from either will max both of them. We'll fix that.) The important thing to note is that there is no visual to indicate that the DataDeltaNode and Problems are contained in the same editor area and can be maximized together. So the design questions are: - what is the affordance for the editor area? - is it only shown in the split state or even shown in the normal state? - we previously discussed considering new visual feedback for the drag/drop operations. We might want to consider visuals that tie the look of the editor area to the look of drag feedback. For example, to "suggest" that a split would occur rather than moving something to its own stack. Some work was done by Kelvin Chan and Kevin McGuire several releases ago regarding editor area visuals. However, since then, we have the new look. It's worth revisiting their work, but I'm not sure it will apply.
(In reply to comment #1) > So the design questions are: > - what is the affordance for the editor area? > - is it only shown in the split state or even shown in the normal state? I think the answer to this second question will be that it's always shown. Bug 321864 discusses behavioral differences of the editor area that are not associated with split scenarios.
per discussion with Linda, we'll have a bug for her design tasks that is assigned to her (I'll be QA contact)
Just an update that there is now a specifically modeled MArea that we use for the Editor Area. At this point it's a naive implementation that uses a CTabFolder with the SINGLE style bit set with one CTabItem whose control is a Composite...
AFACS this bug is outdated.
