Page MenuHome

Action Zone Limits & Thresholds

Authored by Harley Acheson (harley) on Jan 20 2019, 2:29 AM.


  1. New Threshold for Resting Space

Currently the Splitting/Joining action starts the very moment that your mouse drags out of the corner action zone it started from.

If you had initially touched down in the middle of the zone then you can rest there without action starting, because it would take a movement of half the area before action is initiated. However, if you were to touch down close to the edge of the zone then action will be taken almost immediately, since the distance to the edge is obviously much smaller. This difference in behavior can result in surprising results, especially when using imprecise pointing devices. And this is made worse by the removal of the visual "triangle" indicators (which I hated), as users can not guess which areas are more forgiving of others in terms of movement after initial touch. The behavior instead seems a little random.

This patch makes it so that a movement of half the action zone width is required before action is started, regardless of where you initially touch down. So the resting space and the start of action feels much more predictable. And the lack of visual corner indicator is much less important because it will work predictably as long as you start anywhere in the zone.

  1. Drag Direction Limiting

From any single zone, you can do one of three actions: one possible join or one of two possible splits, which means if you randomly drag you are twice as likely to initiate a split than a join. We split immediately without any confirmation. But joins require confirmation and can be cancelled. These factors are the reason that new or imprecise users can be frustrated with multiple accidental splits.

We are also aggressive in always trying to do *some* action rather than do nothing. This is a great strategy for many actions, but not ones that can be accidentally destructive. Consider dragging from the center of the zone at approximately 45 degrees. In this case the system will guess your intent wrong half the time, and if that results in an unintended split you will have something that must be undone. And redone by repeating the process you just failed at.

This patch limits the angles where a drag is considered for action. So a 45 degree drag will do nothing rather than something wrong half the time. In a nutshell it requires that you drag toward a cardinal direction with at least a steepness of 2:1. This might seem odd to limit ourselves to more precisely dragging direction, but the latitude is still very wide and the result is less unintended splits. It just guesses better or you get no action. The following illustrates the angles required.

  1. Action Zone Size

This patch increases the size of the action zone, but only vertically. So the same width (the maximum space between the corner and the editor-change menu) but is now 50% taller. It is a size that feels more like the full corner but still does not interfere with any other interface items.

Diff Detail

rB Blender

Event Timeline

The amount set for threshold before action is taken is 0.2 of a widget_unit. This was the very minimum amount that I could use that would still make a noticeable difference. I wanted it to be a minimal amount so that the least amount of change occurs with this patch to keep it as atomic as possible. So we can explore later what that value should be.

Theoretically though, increasing that amount should only improve it. As the amount increases it allows for more resting, wobbling, and indecision. It also decreases the chance of one type of accidental split: wanting a join but having your mouse run off the side of the zone before you leave your screen area, and would eliminate the chance of it as it approaches .6 of a widget_unit. And any amount that allows for a drag outside of the zone would give us a chance to introduce a cursor change, which would be nice feedback.

Seems like a real nice improvement in reliability for this feature. Nicely done.

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

Hmm... I see a small error in there.

Nothing breaking at all. It just would not have my intended improvement when the drag is in a negative direction. LOL

Will submit a correcting patch as soon as I this lands. Again, no panic as this is not breaking.

I really like it as well. I was wondering, as you say it, only three actions are possible on a corner, one join or two different splits, I just wanted to know if it was in the scope of this patch to support join on the other "join direction" (would be on the left on your example) ?

There was a proposal about that for 2.8, but I can't find it, but basically it would split automatically the other editor. But don't know if it is feasible.

No, that would be well beyond this type of patch. This is just the first part (of a few?) that should make the actual drag in and off those corner splitters a bit better. I am wanting to make them easier to hit, have less precision needed to use, yield less accidental incorrect operations, and (maybe) have some feedback during operation.

But I will certainly do nothing that would hinder any future changes to the area-breaking rules that might make what you suggest possible.

@Harley Acheson (harley) The small change you intend to make - you can just update this diff. No need to add a separate patch i think.

There was a small non-breaking error.

I had set up a variable to hold the (positive) amount of the non-dominant direction, but then failed to use it when calculating if the drag was sufficient. So drags in a positive direction (x or y) would properly use the new threshold value before action. But negative drags would work as they do now without the patch. Fixed and tested.

Great - seems good to me. @Brecht Van Lommel (brecht): Will you check and commit?

This revision was automatically updated to reflect the committed changes.