Compiled this, I really like it. The preview is elegant and helpful, and so are the results. I haven't looked further at the code yet though

/home/hans/Blender-Git/blender/source/blender/editors/screen/screen_draw.c:244:12: error: ‘return’ with a value, in function returning void [-Werror=return-type]
  244 |     return false;
      |            ^~~~~

In D8084#281952, @Campbell Barton (campbellbarton) wrote:

• The area type switcher changes color of the
  

I think this is related to T86450

In D8084#281959, @Alaska (Alaska) wrote:

In D8084#281952, @Campbell Barton (campbellbarton) wrote:

• The area type switcher changes color of the
  

I think this is related to T86450

Ah, seems so. No need to worry about it in this patch then.

@Campbell Barton (campbellbarton) - Currently this allows joining areas not part of where the drag starts, this would allow accidental joins on drag.

So far not finding a way to stop that in way that doesn't make it worse or add confusion.

Its actually very old behavior that we just don't notice much because currently we can't join as many areas. But if you line things up nicely you can see the exact same behavior in current master. In fact here you can see it working the same in 2.79:

Will keep experimenting to see If I find any solution that is nice.

Same behavior in 2.57 so this was introduced with the new window system for 2.5 series.

@Campbell Barton (campbellbarton) - ...it's just that before this patch it's not possible to click-drag merge an area outside of the one that was clicked on, after this patch it is.

Not trying to be difficult, but I'd like to know what you mean specifically so I can investigate. The following animated gif capture, using 2.57.1, shows "click-drag merge an area outside of the one that was clicked on" so AFAICT exactly the same.

I realize that this patch makes it far easier to do so, since it does not require areas to be perfectly aligned. So only wanting to clarify in the small case we are talking about different things.

When testing this initially I noticed it was possible to accidentally join regions compared to the current logic.

Joining areas not connected to the region dragged on.

Accidental mouse motion joining an area unintentionally seems like a more likely issue though.

In both cases I think this can be resolved by only joining areas connected to the first edge the cursor crosses over.

@Campbell Barton (campbellbarton) - In both cases I think this can be resolved by only joining areas connected to the first edge the cursor crosses over.

Yes, I am also pretty sure that will work. But there is a still a fair chance it might suck, so needs some testing. The spoiler will be the ability to change directions...

You drag from A to B. That is implying that you like A and don't want B. With above rule that would mean that you could then change your mind and drag from B to any neighbor. But that makes B the source (the one that will remain). And you can change your mind and move back to A (the one you initially preferred), but then from there cannot do much else. Why you get more stopsign cursors at A than B might seem confusing.

Might have to be when the operation starts A->B that you can allow any join to or from either of those two, but nobody else.

The last time I was looking in there (it is not touched by this patch) there it might be non-obvious how to show "stopsign" icon properly, just because of the way that area_getorientation() now works. I'd say leave it to me for a bit and I'll do it nicely.

Joining areas not connected to the region dragged on.

Thanks for making this. This does seems like a potential for confusion. Slowly, it looks like this. And not addressed by rules above.

Accidental mouse motion joining an area unintentionally seems like a more likely issue though.

Thanks. Yes, for good or ill this looks like my intended behavior. But I can see how shallow angles like that could weird. And this solution, assuming any area can join with any neighbor doesn't lend itself to changing behavior depending on drag angle.

I still think we have the bones for something better here. But it is possible that in end this will be a wonderful thing for experienced users who like using corner action zones, but the people who find them sucky will still find them sucky.

In case anyone comes here to say “this sucks!” there are a couple changes planned.

It is now too easy to change direction and target. This is most obvious at shallow angles: you intend to drag down yet wander too far left and it will guess that you are now wanting to join to the left. This can be addressed in a few different ways that ultimately makes it easier to continue at current direction at the expense of making it harder to change direction. End result is that it should feel more forgiving and work better for users with movement precision issues.

Second issue is a bit less important. Joining code (for 10 years) allows you to reverse direction and change area target while dragging. The combination of the two means you can start a join, reverse, change target, reverse, change, and in the end join areas far removed from the initial two areas. This was hard to experience before this patch, but easy to do now. W’ell probably limit this, probably so that the final two join areas must include one of the two initial areas. As long as that can work without feeling constraining or confusing.