View Issue Details

IDCategoryLast Update
0005983features2016-09-12 11:39
ReportercolinfAssigned Totimbyr 
Reproducibilityalways 
Status assignedResolutionopen 
Product Version 
Fixed in Version 
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.

Relationships

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

Activities

colinf

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/editor_drag.cc) even the tiniest horizontal movement is considered a drag when you're zoomed out further than "move threshold number of frames" == "1 pixel".

timbyr

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?

don3

2016-02-11 16:40

reporter   ~0017911

Last edited: 2016-02-11 16:44

View 2 revisions

"...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...

timbyr

2016-09-12 11:26

developer   ~0018610

Last edited: 2016-09-12 11:39

View 2 revisions

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 View Revisions
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 View Revisions