These areas are really small for a frequently used UI element

Only some more pixels would make it perfect.
When the Editor Type Panel is centered above the toolpanel it would even look more symmetrical.
(Of course only when in single column)

@Daniel Paul (DaPaulus) i think something like that would probably be fine.

@Brecht Van Lommel (brecht) ?

@Harley Acheson (harley) submitted patches for these recent changes, so maybe he wants to work on further changes here.

The wider clickable edges seems fine. The extra empty space everywhere is not ideal but I guess acceptable.

Maybe we should get rid of this dragging from 4 corners, and only allow dragging from the top right, with an icon and a bigger clickable area instead of this quite hidden behavior. Part of the reason accidents are more like is also that we changed from 2 to 4 corners, before it wasn't as likely to misclick diagonally

What I'd really like to do is discuss this a little bit. So I'd love someone to correct my following assumptions:

Step one: Make it so that the "move" zone does not bisect the splitter zones. The "resize area" zone is 3 pixels wide and is the full extent of every window edge. But that means that at a joint corner there is a move area between the splitter zones. So obviously splitting and joining cannot be done if your mouse is too close to the corner. This change would make it so that you couldn't *resize* an area at the corner, but I can't see that as an issue since the corners are for splitting/joining.

Step two: Increase UI_HEADER_OFFSET slightly, so moving the Editor-type menu to the right by a small amount. I can therefore make the splitter area slightly wider.

Step three: Increase the vertical size of the splitter azone. It is now square, but can be taller without interfering with anything.

Step four: Increase the width of the "resize area" zone. It is currently exactly the same as the visual gap between areas, which is 3 pixels. After step one we can increase this by one pixel on each side without interfering with anything. But that change from 3 to 5 will make resizing much easier using imprecise devices.

A rough visual of what I mean:

Note that I do not (currently) know how to achieve step one: giving precedence to the splitter over moving. Was looking at that this morning a bit...

And about the general behavior itself:

Right now we are using the drag direction in the azone to determine whether to do a split or merge. Because this area is so small there is no resting space in this action. This makes it really easy to do the wrong operation. We do immediate splits, but only do a join after a confirmation. So the end result is that errors will almost always result in unintended splits.

By making the split zone much larger, and without the bisecting move zone, we might be able to allow for some resting space. So only start a split/merge operation if the mouse moves more than some delta.

@Harley Acheson (harley) This makes sense to me. And a nice idea to make the action zone take precedence over the resize zone in the corners.

@Harley Acheson (harley) Best solution so far. The resting zone does really not exist at the moment, you have to move immediately while clicking to define the direction.

The resting zone does really not exist at the moment, you have
to move immediately while clicking to define the direction.

It does seem like that, but isn't really the case once I dived into it. You actually do have a fairly wide resting area if you were to initially touch down in the dead center of the defined zone. But the closer to the edge of that zone (like closer to the corner, for example) the less dead space you have. This is because the action is initiated the very moment that your mouse leaves the zone you touched down in.

I have submitted a patch here:
https://developer.blender.org/D4227

It makes it so that "resting space" is the same regardless of where you touch down. Basically you have to drag for half the width of the zone even if you touched down at the very edge of it.

It also makes it so that up/down/left/right drag must be a bit more precise, but still not very. With this patch dragging at a 45 degree angle will do nothing, instead of what it does now which is to incorrectly guess your intention half the time and give you an unwanted split. This should result in less accidental messes.

The patch also increases the zone by 50%. I have kept it the same width (the entire space between the edge and the change-editor menu) but have increased the height a bit. It feels a bit more like it properly takes up that corner. And does not interfere with other interface items as I had previously moved scrollbars and such away from the corners.

Give it a try (if you compile on your own) and let me know what you think...

Just to clarify my comment about limiting the allowed angles for drag. This patch will make it so that the drag illustrated below will be less likely to create a vertical split of the Properties menu, which is what it does now. The patch makes it so such a drag does nothing, rather than treat it as if you had dragged perfectly horizontally.

I am now testing a patch that pushes those corner action zones right into the corners, as I mentioned earlier. It does make it much easier to do these split/join operations when the two adjoining areas are not separated by the "move" area.

I'll wait until after my earlier patch is either accepted or rejected though as I am trying to keep these changes as atomic as possible.

Okay, the patch was accepted that added a (small) threshold of movement before action is taken, regardless of where in that corner zone you start at. It also makes the zone slightly taller.

And it restricts the angles of the drag so you have to be a more precise, which addresses the accidental split you can get as I illustrated above.

The next step is an optional patch I just submitted, which moves those corner zones right into the corners and so they are not bisected by the "move" edge. This makes it much easier to use since you no longer have a hidden area in the middle to avoid.

Whether or not that is accepted, the next step is probably to make the movement threshold longer as that in probably the nicest change. Right now it is half the width of the zone, but it gets much nicer as it approaches the full width. At slightly more than full width it then eliminates the chance of the type of accidental split that I mention earlier, so I can remove the angle restrictions. As the threshold gets just a bit longer there is then opportunity to make some cursor changes that can indicate direction and type of operation about to be performed. Ideally, you could start dragging into your own area and the mouse could change from the "+" to an arrow showing that direction, and then as soon as it left the corner zone it could change into a cursor indicating vertical split. Pull your mouse up and it would change into a join cursor, but move a bit further and that action would be taken.

@Harley Acheson (harley) Great. However, I though you included that already in your patch? Seems confusing to me to make the patches to atomic - I get a bit confused certainly of what is in which patch here. But in any case, nice improvements.

Can you clarify which patches are now needed for review on top of what was already committed?

Hey @William Reynish (billreynish)!

I've just been making comments on this task because I didn't know where else to comment since patches get closed.

The patch committed today just added made the corner slightly taller, restricted the angles a bit so you have to drag a bit straighter (a 45 degree drag will do nothing), and made it so that there is a threshold that is required before any action is taken. This last bit is the most important. Until this patch the behavior was that action was taken the moment your mouse left an action zone, regardless of how far that move was. Now there is a small amount of movement required, so this means that the drag can extend out of the action zone.

This patch is on its own because it really does work on its own. Making that threshold zero will give us the old behavior exactly.

The patch I submitted this morning, as far as a user is concerned, does only one thing: it moves the corner zones right into to corner so adjoining ones actually touch, rather than be bisected by the "resize" edge. But this patch is entirely optional. It can be accepted or rejected as a separate thing without affecting prior work or future plans. So it was easier for these to be two different patches rather an one big one then have us argue about the corner zone placement.

Once this patch is accepted or not, then I have some future plans to investigate. The first is evaluating the behavior of this as the threshold is lengthened. How long it can be can affect what kinds of things I can do. At one point I can actually remove the earlier angle restriction because the errors it was avoiding will be similarly avoided this way. And there might be some feedback I can add through custom cursor change, depending on how long that threshold value is.

Forgot to mention @William Reynish (billreynish), that if things work out how I hope they will, then I might be making some new custom cursors.

Are there any other cursor-related issues? Are we missing any or could any existing ones be improved? I ask because it doesn't look trivial to make them so might as well do other things while I am there...

@Harley Acheson (harley): Haha, I actually was also working on this. The issue is that our system for this is quite limiting because it's a 2-bit system. You only get transparent, black and white. It's quite hard to make nicer cursors using this system.

But yes, we could use many more custom cursors. Many of the active tools could use special cursors, for example.

Ideally, any tool that stays active, or any modal operation (such as color picker etc) should have own custom cursor.

I think we could generally use this approach. A small arrow for accuracy and a symbol below:

@William Reynish (billreynish): I haven't found a cursor editor that directly supports this older format. Not that I mind the lack of color though.

Many of the active tools could use special cursors, for example.

I think I am just not very creative, as I can't really think of many times when a standard pointing cursor wouldn't work best. I do like when the cursor changes to indicate a status or state that we can't otherwise. Which is why I want one for "split vertical" and "split horizontal".

Somebody on a thread asked for a simple "dot" cursor for when sculpting.

Blenders source code itself includes a cursor editor. We should take this to Devtalk. Can you make a post there for cursors? Thanks.

Not to pedantic but there might be some things to think through with cursors...

Your example above make a few things spring to mind:

Color:

We are generally using icons that are white with black outlines for contrast. Were yours black on purpose or just to illustrate the "pointer plus state" idea?

Do we want to have black cursors as an alternative set for themes that are light? This might be not work as well as it sounds since (at least on windows) we use system-supplied cursors most of the time and we don't have control over those.

In cursors I have come across lately, they seem to be either all black (and no outline) or white with black outline. Our dark themes seem to preclude changing all to black.

Sizes:

It looks like the blender source supports having a small and large version of each cursors (although not many have a large version). I haven't yet examined when and how one is selected over another. Would we be making small cursors that try to fit well within 16 x 16 and then make a second version that is basically twice as wide and tall for the large version?

I don't have a retina display but when using one I imagine the system gives us a usable size, but then are our custom blender ones really small (assuming there isn't a large version)?

The 16x16 size is extremely hard to get something white with a black outline and then do what you have illustrated above. In essence you end up working with cursor parts that are 3 or 4 pixels wide at the narrowest so you run out of space quickly

My lack of some of these details and background are why I hesitate to start a devTalk post about it.