Testers Wanted for Area Docking

Feature & Design Feedback
1

I’m hoping to enlist help in testing the following patch build. It is an experiment that could possibly turn into a new way to maintain Blender areas in Version 4.0

Similar to some of my earlier related patches, this extends area merging to also include docking and “tearing off”. Unlike earlier versions this one makes all of splitting, merging, and docking all operate identically.

All the operations start with a simple drag (no need to hold shift or ctrl, etc) from the corner action zone. Unlike today, all operations can be done from any corner zone (currently you can only join areas using a zone directly between them). This means we could conceivably allow these operations to start from a drag at any empty portion of an area header, which many users expect for docking operations.

The most notable change here from earlier attempts are changes to splitting. Splitting currently uses asymmetrical zones to indicate whether horizontal or vertical. This patch makes them symmetrical and operate like joining and docking. This can be jarring at first - and possibly feel backward - but your brain adapts quickly. I find the consistency really does make everything feel much more cohesive. And the fluid target sizes feels very smooth and intuitive.

Splitting

Docking is like my other patches. Just drag an area to any other location, but now you can quickly set the final size as well. This new fluid sizing allows a new area to be almost any size within the target at any position. The previous sizing was limited to 50% from an edge.

Docking

As before you can drag out of the window to tear off areas:

TearOff

Showing how all operations act the same. Transitioning from splitting to joining to docking:

AllOPs

Builds:

Patch:

All comments are welcome, as long as you actually test this.

52 Likes
2

I’ll test it later today and provide feedback.

3 Likes
3

Hi, testing at Windows 11 at moment and it work as expected when get used to it in a few minutes. Very very nice.

Cheers, mib

1 Like
4

something’s wrong with the link to the Patch - it leads to the complex text shaping patch for me.

1 Like
5

First impression after testing: It’s much more intuitive than the current implementation, would like to see this merged to master as soon as possible. Was also surprised how little code change is actually needed to get there. Great work!

1 Like
6

I think it’s meant to be this one: ⚙ D16648 WIP: Harmonious Area Docking, Joining & Splitting
:slight_smile:

2 Likes
7

Sorry some of this feedback is very similar to previous feedback on other patches.

I also don’t want to be mean, I am just sharing my personal opinion.

Closing thin editors are harder than Master. As in it’s easy to end up doing the wrong action if you’re moving too fast. I might just need to get used to it or it might be something worth investigating?

Video

I feel like this specific action shouldn’t be available (What I am referring too is the ability to pull on an editor into a neighbouring one and have the ability to fill up half the editors size. What this does is it just resizes the two editors. Which seems like a useless action for the case of two editors that are directly adjacent and sharing a full edge)

Image

Half docking neighboring editors
Half docking neighboring editors1920×1080 67.9 KB

The action of splitting an editor to create a new editor seems wrong to me.
For example, if I want to create a new editor above my current one, I have to pull from the top corner, then move my cursor horizontally towards the middle of the editor, and pull down.

And if I want to create a new editor to the side of my current editor, I need to pull from a corner, move vertically toward the center of the editor and pull horizontally to create a new editor.

The fact one of the main actions for creating a new vertical editor is pulling horizontally, and one of the main actions for creating a new horizontal editor is pulling vertically just seems wrong to me.

Maybe it can be something like this:
“If the vertical mouse movement is greater than the horizontal mouse movement, then we believe the user is trying to create a new vertical editor.”
“If the horizontal mouse movement is greater than the vertical mouse movement, then we believe the user is trying to create a new horizontal editor”

Sorry if I’m bad at explaining this.

Videos
Creating a vertical editor

Creating a horizontal editor

Sorry if I’m bad at explaining my thoughts.

8

just tried it out. it feels nice to use, but it’s kinda hard to predict how the areas will look after performing the action. maybe instead of a generic icon, it could show the icon of the editor type that will appear in the new area?

9

Testing …
I like responsiveness. Quick and useful.

Something curious happens if I try to pull out all areas of Blender Main window. The last area just gets duplicated, so there is at least one area in the Blender Main window.

Shift + Click (corner) will pull an area out into its own window. However, if there is only one area in a window, it will keep area and duplicate it into a new window.

Thinking about how discovering …
One has to ‘know’ that it is triggered with mouse-drag on a small corner. There is no icon, or other visual hint, to show that this feature exists, except that the cursor turns into crosshairs on hovering area. There is also no feedback about what keystrokes would do.

Thinking about Area Docking, I am happy about the change. It could help to quickly organize Blender across monitors.

10

Overall, I have a positive experience with new docking system. I especially like how tearing panels off works if you need something in a separate window. It’s very easy and predictable.

I have experienced some issues though.

  1. I can’t reproduce it reliably, but when I stop thinking about how I should close panels and do it more automatically there is a higher error rate in terms that the panel won’t close but a different action will happen. It feels like I need to be more careful/precise with the new system when I am closing panels.

  2. The panel splitting isn’t following the user intention well with the new system. It feels somewhat random.

With current 3.4 draggin top to bottom/bottom to top will predictably split panel horizontally. Draggin left to right/right to left will split panel vertically.

Example

With new docking system initial split isn’t following user intent. Dragging top to bottom won’t predictably start splitting the panel horizontally. The same issue is with the left to right action.

Example

  1. I don’t like that mouse cursor isn’t indicating where the splitting would happen. The overall movement feels floaty that way. But, I guess, it’s the core of new splitting design. Probably, something I can get used to.
1 Like
11

There is a lot of simplification between operations here, so 429 insertions and 287 deletions. 142 new lines

Yes, I might be able to help those cases.

So docking to the closest side of an adjacent area. On one hand I don’t want useless results, but on the other hand I want as few rules as possible to keep it as predictable as I can. Will give it some thought.

This is the most difficult change in this patch, and it is possible that this change is insurmountable. But this is really just making the splitting operation be consistent with joining and docking. It is hard to change our mental models of it.

With this patch you are no longer indicating how to cut. You are instead indicating where you want the new area to be. Point at where the new one should be made.

Yes, especially when docking since that old area will be taken over by a neighbor.

What do you want to happen when the last part of the main window is pulled out of it? I don’t think we’d want to close the app. A default area of some kind? A new “blank” area? I don’t think I could turn a child window (if there is one) into a new main window. I could disallow the moving of the last area, but hard to make that known. I could turn that into a move of the entire window?

That is sort of a part of this patch, but unaddressed…

With current code some actions have to be performed from particular corners. For example you can only join two areas by using zones that are between two areas. So we are currently stuck with having one at each corner to cover all possibilities.

With this patch all operations can be done from one place. So we could (possibly) reduce all the zones to one at the top-left. Then make it a bit bigger and add a “grab” graphic. We could (in theory) also allow a drag from any empty part of any header. This would be the first thought for new, untrained users: to just drag the header itself.

image
image719×102 2.56 KB

And all of this could fit with ideas for tabbed areas. Even this patch is made more interesting by this little change: ⚙ D16731 Experiment: Area Editor Cycling

Yes, it is a big change. You aren’t indicating the cut itself but pointing at the the location of the new area.

4 Likes
12

I would still prefer the new system to follow the user mouse gesture as an indicator for initial direction. Doesn’t matter if it’s splitting or placing. If I’m dragging in something from top to bottom, I expect it to slide in from top first. The same goes for any other movement: bottom to top, left to right, right to left. Right now it feels rather unpredictable or in reverse.

I am not against new system since itis bringing definite benefits in UI flexibility but the issue above causes discomfort when UI works against me, and its movement is not as predictable as before.

2 Likes
13

I can definitely imagine backtracking on the change to splitting. Even if there is some added consistency. An illustration of that, since it isn’t obvious. Here the split of Outliner is not different from the docking operations. All operations start at one area so they have to transition from splitting, to joining, to docking, to tearing out. So having consistent marking, selection, feedback helps a bit between them.

consistent

But the transition for users would probably be painful. I’m sure a large number of our users would not appreciate having to change how they think about it.

But… not sure I’d like to change the way that docking areas are specified in this patch. I have tried that, where the mouse indicates the division between the current area and the to-be-moved area. It works okay, but it means that you can never make a new area that is larger than 50% of the target area. Since you are indicating just the cut you can get, at most, a portion from an edge up to half. But you can’t even get that theoretical 50% because the middle has to be reserved for “replace entire area”

With the method in this patch you can get a target area that is anywhere up to about 80% from any edge. So you can move an area to take up almost all of the target, anchored on any edge. But you still get a nice “snap” at the middle for center docking.

3 Likes
14

I forgot to mention that another advantage of the splitting here is that is works equally when started from any point of the header.

As in if you think of all these operations as drags of the area, you could theoretically do all operations starting from the middle of the header, for example.

With the current method for splitting we remain stuck with multiple corner zones. Otherwise you would start at the middle of the header, pull down, and get a potential horizonal split, at first, unless you enter the left side of the diagonal from the top-left corner. Trying to indicate how to start a vertical split from the middle of the header would be tough.

I think if we stay with the current split we are stuck with multiple corner zones. Which make it hard to show them on-screen. And makes it more difficult to get to tabbed areas.

15

I have not tested the patch, but I am curious about how it would or would not fit with the drag resize operator (that I think still is not incorporated into master) of ⚙ D7946 [Scr-ops] Drag resize operator. That method of resizing windows is so intuitive and simple, and I would hope that the Blender team later incorporates it. If it does, would the proposal here interfere with that drag resizing? If so, is it possible to adjust the current patch so that Blender would have both the drag resize functionality of D7946 and also the functionality of this patch?

16

It shouldn’t interfere and might make it easier to add. Drag resize would require some modifier key to be held down, but best if that were Shift, Ctrl, or Alt. This patch could potentially free up all of them.

With this patch I don’t think we really need to reserve Shift-drag for tear out, or Ctrl-drag for swap areas since both are so much easier with the simple drags here. That could mean that shift-drag could be used for that resize.

17

Great that it would not interfere and would work well with that! Thank you for all your work, Harley!

1 Like
18

No worries. This is going to be a long process, with hopefully a nice solution found for release a year from now. I really appreciate all the feedback for the steps along the way.

I made an interesting experiment one weekend, where I show the dragged area. It looks cool but just gets in the way some time. Okay in simple situations like shown below but for complex arrangements I found the method in this patch clearer.

DragDropping

1 Like
19

I think it’s pretty intuitive once you understand that you’re placing the new area. I haven’t tested very thoroughly. I have to say I don’t feel like anything has changed functionally, if you asked me I’d say this is just a different visual feedback. If I understand correctly the idea is you don’t commit to a direction (horizontal or vertical split) until you release the click. That’s good.

1 Like
20

Correct. Not only do you not commit to split direction, but also to operation. You can start thinking about a split, change to a join, explore docking areas, then go back to pondering a split. But you are not committed until you release the mouse, or cancel with escape or right-click.

1 Like