2 ms·

One extra detail, something I've learned from 20 years of working on dragging all kinds of objects around the GUI of Ardour [0]: handle ALL button press and rel

One extra detail, something I've learned from 20 years of working on dragging all kinds of objects around the GUI of Ardour [0]: handle ALL button press and release events as drag events where there is no movement. That is: press ALWAYS starts a drag that is finished by the release, and the code that handles release "special cases" the no-movement condition. [0] https://ardour.org/ https://ardour.org/

wruza 3y ago
What’s the rationale here?
- PaulDavisThe1st 3y ago
  Having separate code paths for "it's a press", "it's a release", "it's a drag" just turns into a nightmare when you actually use all 3 input events extensively. Remember that while the motion events of the drag might be the visually interesting part, for the most part the interesting stuff happens at the beginning and end of them - i.e. the press and release. It becomes massively simpler conceptually (and even in the code) to treat any button press as a potential drag, and a simple click becomes just a drag-with-no-movement.
  - 8n4vidtmkvmk 3y ago
    Minimal movement* I allow a few pixels for Shakey slow hands.
- layer8 3y ago
  This reminds me a bit of how double-click works, or originally worked: A single (first) click selects the element, and if there’s a second click within a short timeout period on the selected element, it invokes a default action on that element. Meaning, the double click is not a separate type of operation, it’s a continuation of what happens on a single click. You don’t wait after a single click to see if it becomes a double click; instead you always perform the single-click operation (selecting the element), and a second click that makes it a double click may or may not follow, and if it follows is compatible with the single-click action.
  - PaulDavisThe1st 3y ago
    Historically, it differed on different windowing systems. The two versions featured the following event sequences: A: button press, button release, button press, button release B: button press, button press, button release This subtle difference leads to a world of difference in mid-level code.
    - layer8 3y ago
      Yes. However, if you select on the first button press (which I think is the usual behavior?), then it shouldn’t matter if you get a corresponding button release or not. Option B allows to implement an “incompatible” single-click action, with the trade-off that it must be bound to the button release, not the (first) button press.
hutzlibu 3y ago
That should also work, but I did not do it this way and had no problems after I got the basics right. I have general mousedown and mouseup handlers and use a timeout(~150 ms, but configurable), to determine if we deal with a click, or start dragging (or other things). And on mouseup (or if the mouse leaves the screen) and there is dragging in progress -> stopdrag. So dragging for me ist just one of different special cases ..

wruza 3y ago

What’s the rationale here?

PaulDavisThe1st 3y ago
Having separate code paths for "it's a press", "it's a release", "it's a drag" just turns into a nightmare when you actually use all 3 input events extensively. Remember that while the motion events of the drag might be the visually interesting part, for the most part the interesting stuff happens at the beginning and end of them - i.e. the press and release. It becomes massively simpler conceptually (and even in the code) to treat any button press as a potential drag, and a simple click becomes just a drag-with-no-movement.
- 8n4vidtmkvmk 3y ago
  Minimal movement* I allow a few pixels for Shakey slow hands.
layer8 3y ago
This reminds me a bit of how double-click works, or originally worked: A single (first) click selects the element, and if there’s a second click within a short timeout period on the selected element, it invokes a default action on that element. Meaning, the double click is not a separate type of operation, it’s a continuation of what happens on a single click. You don’t wait after a single click to see if it becomes a double click; instead you always perform the single-click operation (selecting the element), and a second click that makes it a double click may or may not follow, and if it follows is compatible with the single-click action.
- PaulDavisThe1st 3y ago
  Historically, it differed on different windowing systems. The two versions featured the following event sequences: A: button press, button release, button press, button release B: button press, button press, button release This subtle difference leads to a world of difference in mid-level code.
  - layer8 3y ago
    Yes. However, if you select on the first button press (which I think is the usual behavior?), then it shouldn’t matter if you get a corresponding button release or not. Option B allows to implement an “incompatible” single-click action, with the trade-off that it must be bound to the button release, not the (first) button press.

hutzlibu 3y ago

That should also work, but I did not do it this way and had no problems after I got the basics right. I have general mousedown and mouseup handlers and use a timeout(~150 ms, but configurable), to determine if we deal with a click, or start dragging (or other things). And on mouseup (or if the mouse leaves the screen) and there is dragging in progress -> stopdrag. So dragging for me ist just one of different special cases ..