First of all, great job! really looking forward to this one!
Second, just a one thing that bothered me on the example you just gave.
It’s unclear what will happen with the Outliner and the Timeline. The docking editor doesn’t highlight all the affected Areas; it only highlights the Areas that interact with the cursor (? I think, I didn’t look at the code), and sometimes you feel confused as to what will happen to the other Areas.
You should try it if you haven’t, its pretty intuitive when using it.
Here, as the mouse drags the area out into other areas, it comes to a point where the original area will dissapear. That’s what’s being represented by the darkened area.
If you look again at the gif, the first docking layout that gets previewed is this one:
In here there are two darkened areas, and one with the oversized icon (the one you are actively moving around).The two dark ones will be replaced by the lighter ones that are adjacent to them. In the case of your screenshot, the dark part will be moved to the left side of the screen, and the darkened space will be replaced with the outliner thats above it.
I find it fairly well represented…although it’s a bit weird to write the explanation for it (it sounds complicated), when using it is really quick and easy to understand.
It really is intuitive!
One QOL thing - is it possible to remember the width of the window if moving to a side region or the height if moving to a top or bottom region? For example, I like to move my Outliner to the left when working on big scenes, and when I do that here it takes up half the screen. Not really a problem, but some editors like that and Properties are kinda built to work at a certain width and it would be extra nice if the resizing step could be skipped.
Well, I had a chance to try it, and I still find it very unintuitive.
But judging from the amount of like you got compared to mine, I guess my way of thinking is not the “blender way”, and it’s going to be that way moving forward.
Well, it’s is what it is.
Jonathan,
Funny is that there is a very slight adjustment to this that entirely removes the resizing step. If I can get this out of being an Experimental feature then I will probably later propose such a change for testing. This was removed from this initial implementation to keep it as simple as possible.
Right now you move your mouse and you get target areas of specific proportions. For example, have your mouse anywhere within the right portion and you get an area that is the right half. But if we allow your mouse position to set the target size based on where in the right portion it is then you are able to set the size and position in one fluid motion. Hard to describe, but shown in the first comment of this thread: More Evaluation Required for Screen Area Docking
This was removed from this initial implementation
Would it be fast/easy to test the custom resize be done while holding a modifier? Have it as it is now by default. And when holding Shift (the usual key for ‘precision’), have it adjust like it used to in your patch:
Maybe vice versa, for consistency? Only split to half when Ctrl is held, because that’s kinda like snapping increment
It wouldn’t be trivial in that a lot of code was ripped out to remove it. But I could probably redo that simpler this time. I hesitate a little to experiment with this now in that it might make it harder to get out of Experimental. I was asked to remove this resizing feature specifically to uncomplicate it a bit.
But of course I do love the feature and mourned its loss. There is a design issue with it though in that we’d have to make changes to the feedback. The area icon now shown in the middle of the target area looks okay now as it stays static while your mouse moves around. But with this dynamic resizing the icon would be moving with the mouse, but not exactly; might look odd. But we could also not have the icon at all. Edit: Or I could hide the mouse cursor and draw that area icon at mouse position.
I don’t think the icon is needed, it is not providing any useful information.
this is a great feature, but this corner stuff is just out of this world.
a special spot for this in the header would be much more human friendly. i know some apps that have that, and works wonderfully 
Agreed that it does not provide much. It certainly doesn’t tell you anything you don’t already know. But I do think it helps slightly in that it anchors and highlights the target area and reinforces the action. But it could be removed. But I think I’ll make a PR that makes this look more like a drag and drop operation to test.
The possibility of taking these operations out of the corners only occurs after this. This docking stuff makes it possible to do any operation from any single location so that could happen later. Without this we are stuck with four zones that are slightly different from each other. So this is the path out of the thing you don’t like.
nice. ill be waiting for the hamburger button in the header 
@pablovazquez, @jonlampel , et al. I have submitted a patch for testing that style of interaction here: #126447 - UI: Docking Interactive Resizing - blender - Blender Projects
In a nutshell you select both the location and the size of the target area in one motion:
Hello! A bit late to the party, but here’s my feedback.
First, the feature is great! Being able to do all these operation with just one click-drag, and finally not being bound anymore to the corner that you chose, is fenomenal!
Some thoughts:
I think that the reason the icon might feel too much is that when we move the cursor to select our target, the icon jumps a lot, becoming distracting. If you don’t want to rely only on the edge highlighting, maybe a visual feedback that is less prominent could improve.
I feel too much the difference between the dedicated icons for splitting and joining, and the ones for moving/creating a new area and swapping:
These should follow the same style of the others.
I think that holding Ctrl for swapping areas should be possible anytime, and not only if I hold Ctrl before clickndrag.
Finally, it’s weird to me that if I drag an area for splitting into another area, and there is an editor below, the area doesn’t split but disappears:
Do you have a suggestion on how they should look?
Your video doesn’t show anything that is introduced or changed here. What it shows has been Blender behavior since 3.0
Gosh, embarrassing I didn’t notice before this 
… Now that I encountered this, I can only say that the behaviour would feel more predictable if it’d just split instead of merge, but I guess is for another discussion.
I’ll try to cook up a mockup, even though I’m not very strong in UI design.
Thanks for your work!
It really wouldn’t be, as I have tried every permutation an uncountable number of times. To help with predictability it does show you which area will be closed by darkening them before you do so.
In your particular example, if those darkened areas did not close it leads to a frustrating asynchronicity in area creation versus deletion. In a nutshell you are starting with a layout that contains four areas. Then you join one of those to another. With current behavior you end up with four areas, so the same number that you started with. But with yours you end up with five. If joining two areas adds complexity then you just end up having to clean up more afterward.
If you really want to keep 3D View and move Properties below it, then just dock it there.
Yes, it is.
I briefly tested this after running into a related crash and discovering the new experimental feature through that report. I think it’s fantastic. My only wish is for there to be a default shortcut, or at least make the operator compatible with creating a custom shortcut, so that we don’t have to click on the magic invisible corner zones.
I’ll have that fixed shortly. That was an assert for Outliner trying to do a partial update when only a full one would do. Makes sense. Thanks for spotting this
That might be possible. I was just playing with local code that seemed to work like that but will need more testing. If I get something working well enough I might have to conscript you into testing.
I noticed you updated this feature with a new visual to denote what’s going to happen (The icon of the editor on the cursor). I’m not sure how I feel about it (only been using it for a few minutes), but I discovered a bug/limitation with it.
When dragging the cursor from one Blender window to another, the cusor goes invisible. And depending on factors, the cursor can sometimes appear in the window you’re dragging too, but is stuck to a edge/corner.
OS: Windows with 100% scaling.
Example of stuck cursor issue:
