Time based threshold for mouse drag

Hello dev community,

In a recent Blender Today by @pablovazquez with Vaughan Ling (Heavypoly) they talked about a time based threshold for drag events. I think that is a brilliant idea that is worth a shot.
I was animating recently, and I love that i can just select stuff that is behind the rotate gizmo. But the drag threshold drives me insane. (I’m using Left click select. Don’t know if this is even an issue on Right Click Select)
Lowering it helps, but it doesn’t really solve the problem. That’s why I’d like to try to implement the time based drag activation.
I was wondering if there is anything that speaks against this, or if this has been tried already.
I think @billrey might be able to help there?

2 Likes

after a busy month I found the time to dig into this a bit
so far I was able to add this change in wm_event_query.c but the drag doesn’t trigger when WM_event_drag_test returns true. Need to search further

bool WM_event_drag_test_with_time_delta(const wmEvent *event, const double time_delta)
{
  printf("%f\n", time_delta);
  return time_delta > 1;
}

bool WM_event_drag_test(const wmEvent *event, const int prev_xy[2])
{
  bool time_based = true;
  if(time_based)
  {
    const double time_delta = PIL_check_seconds_timer() - event->prevclicktime;
    return WM_event_drag_test_with_time_delta(event, time_delta);
  }
  else{
    const int drag_delta[2] = {
        prev_xy[0] - event->x,
        prev_xy[1] - event->y,
    };
    return WM_event_drag_test_with_delta(event, drag_delta);
  }
}
3 Likes

ok after debugging this for ages trying to understand what’s going on I found out I need to add only a few lines…

Working really nicely now. Check out the linux build on graphicall

Obviously the time delta is hardcoded atm. I haven’t figured out how to add it to the settings yet

bool WM_event_drag_test_with_delta(const wmEvent *event, const int drag_delta[2])
{
  const int pixel_drag_threshold = WM_event_drag_threshold(event);
  const bool pixel_drag_test = abs(drag_delta[0]) > pixel_drag_threshold || abs(drag_delta[1]) > pixel_drag_threshold;

  const double time_delta = PIL_check_seconds_timer() - event->prevclicktime;
  // const float time_drag_threshold = U.time_drag_threshold;
  const bool time_drag_test = time_delta > 0.1;

  return pixel_drag_test || time_drag_test;
}
2 Likes

This is such a good idea. The drag threshold with gizmos is annoying, I concur. How does your time-based solution alleviate the problem ? What happens when you click-drag on a gizmo now, does it activate instantly ?

1 Like

it doesn’t activate instantly. If you let go of the mouse button before the 0.1 seconds or before you’ve moved the threshold defined in settings then it registers a click. That means you can still select through the rotation gizmo for example which I find very useful.
However it will change to a drag if you hold down for longer than 0.1 seconds even if you didn’t move out of the pixel threshold. So it only makes a difference for slow mouse movement

2 Likes

Ok that’s what I thought I understood. Sounds like a definitive improvement over the distance threshold, but I can’t test it, I’m on windows. Any chance you get a windows build cooking, I’ll be happy to test it out.

Hadrien

Nop, right click select doesn’t have this issue because it does not need a condition to select or activate.
A nice combo if you are doing a lot of object movement its select with RMB, index finger on the G middle finger on the R (use what you need) and thumb to apply transform after move or rotate with the space bar, its quick fluid and less work on the mouse finger if you dont want to use LMB to apply transforms.

thought so.
Unfortunately even though I am a long time Blender user I really prefer left click select
and using g r s doesn’t make sense when animating. It’s just a lot slower because you usually want to transform in local space on a specific axis and you’d need to remember the local axes of each bone

Ok I’ll try to get a windows build running. I’ll see how it goes

Also I thought about this yesterday and it might be a good idea to implement a “Long Press” event type. atm the drag only activates on mousemove. So after you waited 0.1 seconds you still need to move the cursor 1 pixel to activate the drag. I think it would be better if it activated straight away after the time threshold. Not sure if I can do that though. That is probably a lot more change than a few lines of code

1 Like

Indeed when selection and activation are on different clicks there isn’t a problem. Unfortunately right-click select is basically unusable on a tablet… I actually used to use right-click select before moving to a tablet years ago, but since then it’s been a no-go. :confused: Thanks for sharing your method too. Other software I know of simply don’t allow selecting through a gizmo, which is definitely a limitation, even over the current situation in Blender.

Thanks for the effort ! -right now I can’t even think about doing this myself, which is why I asked. The long press thing sounds like a good idea. If I understand well, currently there is no feedback on whether or not the user pressed for long enough to trigger the time threshold ?

Here’s the windows build.
let me know if it works for you

yes at the moment there is no feedback when the user triggered the time threshold

Actually a lot of people complained about this a long time ago & there is a thread here about it too, When you hold shift over an axis Blender constraints on the other two axis so you can’t extend your selection when the gizmo is over components, i removed that so i can select behind the gizmo using the press event instead of the default single click, also had to make many changes to the keymap to make it work as good as right click select.

Tablet? do you talk about ipad kind of tablet or wacom? i wasn’t aware that blender worked on Ipad’s or android tablets.

EDIT:
Ok i just google it, this is crazy ^- ^ and really cool at the same time, https://www.youtube.com/watch?v=F1N9OnqHyuo

Unfortunately, this will completely disable the long click. Which looks a bit buggy if you performed a ordinary click, just slowed it down a bit, but nothing worked.

So after you waited 0.1 seconds you still need to move the cursor 1 pixel to activate the drag.

Is there any difference from setting the Drag Threshold at 1 pixel in this case?

No, wacom tablets. Or Xp-pen or whatever

Yes because if your click is slightly jittery you won’t activate a drag. That may not be that much of an issue with a mouse but when using a tablet, your cursor drifts quite easily

interesting i started using intuos in 2010 and have been working with it since then, and its working perfectly for me for several reason, a matter of getting used to i guess.

Larger drag thresholds would be nicer to use in general if it sent the crossing location instead of the initial location to modal handlers.

I uploaded a linux build where you can tweak the drag time threshold in the user prefs

I think it is an improvement over the default behavior, but I think it will be quite confusing to the user as to what the setting actually does. I couldn’t find a clear wording that would describe it properly

I think “time-based drag threshold” (the topic name) is fine. Or maybe “timer drag threshold” ? As long as the user understands what the drag threshold is, adding “time-based” before it seems pretty clear. Also maybe clarify it in a tooltip ? Something like “activates dragging after a certain time, rather than at a given distance from the initial click”

The windows build works very well here, thanks for providing !

By the way, I think this does not affect “motion threshold” ? (used for selection cycling when several elements are under the cursor) In that case it might be better to place it just above, as a hint that they’re unrelated ?

You’re right. It doesn’t affect “motion threshold”. I’ll move it up.
I think the feature should be off by default anyway. That way when they enable it they know what they are getting themselves into. Otherwise it might be confusing when the drag distance changes without understanding why.

Sorry to get back to this so late, but do you mean to say that there is a long click in Blender already? If yes that would be interesting to me, but I couldn’t find a hint of that anywhere