View Issue Details

IDProjectCategoryView StatusLast Update
0005983ardourfeaturespublic2016-09-12 11:39
Reportercolinf Assigned Totimbyr  
Status assignedResolutionopen 
Summary0005983: Dragging takes no account of user's preferred drag threshold
DescriptionMost desktop environments provide some sort of configuration for the minimum distance the mouse needs to move with the button pressed to be considered a drag. Ardour doesn't take any account of this setting, but rather hard-codes different drag thresholds for different kinds of drag.

It would be nice if Ardour respected the user's preference in this, either by removing the hard-coded thresholds entirely and using the user's preferred setting, or (if the different thresholds for different kinds of drag turns out to be helpful) by at least scaling all the thresholds proportionally to the user's preferred threshold.
TagsNo tags attached.


related to 0007024 feedbacktimbyr Horizontal drag movement threshold is specified in audio frames instead of pixels. 



2016-02-05 17:19

updater   ~0017884

Also, Ardour's move thresholds for horizontal drags seem to be given in audio frames rather than screen pixels, so that (I think, from a cursory glance at gtk2_ardor/ even the tiniest horizontal movement is considered a drag when you're zoomed out further than "move threshold number of frames" == "1 pixel".


2016-02-11 11:31

developer   ~0017908

I have a fix for the issue that the x movement is in audio frames rather than pixels. I have pushed the change temporarily to the 5983-drag-threshold branch if you want to test it.

It seems like there must be a valid reason for it to have been like that in the first place so I'll wait and see if there are any comments/feedback before committing.

From a quick look through the code it looks as though the only classes where the overridden Drag::move_threshold() method that has any affect is the in RegionMoveDrag and RubberbandSelectDrag classes. The other classes are currently used.

I'm not sure about having a user preference but if we do implement it then what other drag movements should adhere to the drag threshold? All of them?


2016-02-11 16:40

reporter   ~0017911

Last edited: 2016-02-11 16:44

"...if we do implement it then what other drag movements should adhere to the drag threshold?"

Perhaps not relevant, but there's been some discussions fairly recently that you might find interesting:
  - bug 0006659 : magnetic/snap/dead-zone/detent around 0 on mixer trim knob
  - bug 0005758, 0005759, 0006406, 0006647, 0006660 (probably others) : various issues with dragging automation points/lines and faders -- many of these have been fixed or improved, and most of the details there are probably not related, but perhaps some things to keep in mind about snapping to special values like 0 dB, that may not align exactly with pixels, and dragging near borders (eg, -inf). Most of this relates to the vertical axis, but still...

Just thought I'd mention these in case there's any similarities to move thresholds, or interaction with them - if nothing else, something to be aware of, for the sake of consistency, if that's seems appropriate...


2016-09-12 11:26

developer   ~0018610

Last edited: 2016-09-12 11:39

I submitted issue 0007024 based on the first comment.

As far as using the drag threshold from the Desktop, I'm not sure that is something we want to support considering the variety of DE's and complications of doing so. It would be much easier to just add a preference for the user to adjust if they feel it is necessary. Considering the drag threshold implementation isn't currently working correctly(IMO), it would be worth getting that fixed first.

Issue History

Date Modified Username Field Change
2014-10-08 13:21 colinf New Issue
2016-02-05 17:19 colinf Note Added: 0017884
2016-02-11 11:31 timbyr Note Added: 0017908
2016-02-11 11:33 timbyr Assigned To => timbyr
2016-02-11 11:33 timbyr Status new => assigned
2016-02-11 16:40 don3 Note Added: 0017911
2016-02-11 16:44 don3 Note Edited: 0017911
2016-09-12 11:17 timbyr Relationship added related to 0007024
2016-09-12 11:26 timbyr Note Added: 0018610
2016-09-12 11:39 timbyr Note Edited: 0018610