Page MenuHome

Corner Action Zones Not Bisected by Move
ClosedPublic

Authored by Harley Acheson (harley) on Jan 23 2019, 6:55 PM.

Details

Summary

This patch moves the corner action zones right into the very corners, which makes them much easier to use.

In the image below, the left shows how it is now. If you move your mouse into the gap between areas then a split/join/swap cannot happen.

This patch makes it as seen on the right, where the actionzones slightly overflow their areas and meet in the middle. So there is no longer an area in between that you have to avoid.

This does make the splitting/joining/swapping much easier to do. But it does, obviously, make it so you cannot do resizing at that spot in the edge. I personally don't see an issue with that but you might have different ideas.

Patch details:

The only complication with this is that for all these actions we need to know which areas were are intending to affect, but the space between areas is not an area. So some of the existing code would not support a drag starting from a gap position.

The first part of the patch simply alters one side of each corner zone to go into the corners a bit so they touch in the middle.

Then there are two little helper functions added. One that finds an actionzone by position, regardless of area. And the other returns the area that an azone belongs to.

actionzone_area_poll - check if we are inside any actionzone, not just current one
actionzone_invoke - need to save actionzone to sad.sa1, even if current mouse position is in gap
actionzone_modal - check for actionzone regardless of mouse position

When the operation turns into a possible join we call area_join_invoke. It would save the original mouse down position, and current mouse position, so that area_join_init knows what to work on. That would fail if either mouse position was in the gap. However, in that same section of code we already know the two areas we are joining so I just pass the positions of those areas instead, which makes more sense and covers this problem.

Diff Detail

Repository
rB Blender

Event Timeline

Harley Acheson (harley) edited the summary of this revision. (Show Details)
William Reynish (billreynish) accepted this revision.EditedJan 23 2019, 10:28 PM

Another nice improvement. Tested - this really helps.

I think this is totally the correct tradeoff - it favours the corner splitters in the corners.

Thanks for this.

This revision is now accepted and ready to land.Jan 23 2019, 10:28 PM

Ah, such a nice improvement! Thanks for taking the time to work on this.

+1

@Brecht Van Lommel (brecht): Will you check on this? Just we it doesn't fall between the cracks. I think it's a real nice improvement.

IMHO by itself this actually makes the current situation worse, as now you'll have the appearance of one single active area across both regions where the cursor changes to the + and the user has no way of knowing which of the two they're actually going to be clicking in. I made some suggestions around this in the Paper Cuts thread:

https://devtalk.blender.org/t/blender-ui-paper-cuts/2596/1589?u=zoot

Hey Gavin!

In practice, this change does make these operations easier to do.

But there is still the problem of people not knowing where to click. What I'd like to do is change that "+" cursor at the corner with something that evokes the old corner graphics. So a solid triangle that points at the corner. So you would see it change as you move your mouse around that area. A rough image to illustrate:

But that would be something I would so as part of (probably just after) the commit of the following, since it also involves feedback and custom cursors. Assuming it does get committed:

https://developer.blender.org/D4264

Yes, I think something like that would be perfect.

This revision was automatically updated to reflect the committed changes.