View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005983 | ardour | features | public | 2014-10-08 13:21 | 2016-09-12 11:39 |
| Reporter | colinf | Assigned To | timbyr | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Summary | 0005983: Dragging takes no account of user's preferred drag threshold | ||||
| Description | Most 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. | ||||
| Tags | No tags attached. | ||||
|
|
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". |
|
|
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? |
|
|
"...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... |
|
|
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. |
| 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 |
