Dev:Ref/Proposals/UI/Area Splitting

Area Splitting

Currently a user cannot join an area that contains other areas with another equally sized area.

For example, if you tried to merge the text editor in this example to cover the whole screen, nothing would happen:

I suggest a new behavior where in the above situation the text editor would replace the equally sized parent area (in this case the 3D view) and all the sub areas (the two python consoles) with the joining area (the text editor), resulting in the text editor being full screen:

Currently to get the same result the user must perform three actions:

1. Join the python console areas
2. Join the 3D view and the remaining python console areas
3. Join the text editor to the 3D view area

For the reverse, (splitting a larger area with a smaller area) the area being split could be automatically split.

For example, if a user tried to split the text editor with the right hand python console, nothing would happen:

I suggest that the text editor could be automatically split so that the result is:

To get the same result with the current design, the user must:

1. Split the text editor and align the split to the console
2. Join the console into the top text editor

I think this system would be more intuitive and faster to use.

Blakenator

There is a huge logical stump here. Let's take your original image: when you drag it over, how is the program supposed to know which window to expand into, and, as a result, which boundary is correct? It could be the bottom one and expand to fullscreen, or the top right console and expand to that width but resize the others, or the top left console and expand to fullscreen. The trouble is that this gets even worse the more windows you have, and this is probably why it hasn't been implemented yet.

Jonim8or

Blakenator has a good point there. I would consider a non-ambiguous and easy-to-implement behaviour for joining areas: When you drag the corner outside of the area you expect a join (removing one or more areas). I would not suggest re-organising or splitting areas in that case. Instead I would suggest finding the common container region for the drag-source and the drag-destination, and to handle the join at that level. In this example I assume the areas are organised as a tree structure, where each branch node is an area that is split one or more times in a certain direction, and a leaf node is an area. The children of a node are sorted according to their order in the window.

In the next example, you'll see that five areas will be removed, because they make up the smallest region next to the area that is being expanded

gandalf3

Blakenator I was thinking it would take the largest adjacent area in the merge direction. Since the 3D view is larger, the consoles are "contained" inside the 3D view and will get merged along with it. If that's undesirable, then you could have even more control by merging into the area under the mouse cursor. For example, if you drag the corner of the text editor over the 3D view, it would merge all the areas as shown in the example. But if you drag the corner over the console, it would merge that console into the text editor and resize the 3D view to fit in the remaining space below the other console.