[x11] Add movement threshold when detecting double clicks in X11

[Cammymoop]

Fixes #112
This makes double clicking in aseprite much less flakey on linux, for example when using the marque tool in tile mode, or navigating directories and opening files using the aseprite file dialogs. Without this I have to be very careful to keep the mouse still when double clicking and even then I usually have to try several times to get a double click to register.

Prevents the x11 implementation from resetting the click state on mouse movement until either x or y position has changed more than a certain radius from the last clicked position. Also checks the position again before triggering a double click action just in case the position has somehow changed in a way that wasn't captured and handled.

I set it up with a fixed radius of 8, since I'm not really sure how best to go about making it build configurable or actually dynamic. But this should be a huge improvement over the existing behavior with no threshold. For comparison with windows the default radius seems to be 2, but probably works differently for touch/tablet inputs, SDL defaults to 32 which seems a bit excessive so I picked something a bit more conservative but still hopefully useful if you happen to be using touch or tablet input.

I agree that my contributions are licensed under the MIT License.
You can find a copy of this license at https://opensource.org/licenses/MIT

[dacap]

Thanks for your patch @Cammymoop 👍 8 looks like a good threshold, at least as a first iteration to get some user feedback.

It looks like the pre-commit failed, it's just the order of #include files, if you can amend your commit I'll merge this.

[Cammymoop]

Thanks for reviewing

It looks like the pre-commit failed, it's just the order of #include files, if you can amend your commit I'll merge this.

Fixed this

[dacap]

Thanks @Cammymoop!

[est77]

Checking quickly the issue with wacom tablets on Linux it seems that in

void WindowX11::processX11Event(XEvent& event)
{
   ...
   ...

    case ButtonRelease: {
      // This can happen when the button press/release events are
      // handled in XInput
      if (event.xmotion.time == g_lastXInputEventTime)
        break;   
}

event.xmotion.time == g_lastXInputEventTime is always true, and the double click handling code is never executed.

[Cammymoop]

Checking quickly the issue with wacom tablets on Linux it seems that in

void WindowX11::processX11Event(XEvent& event)
{
   ...
   ...

    case ButtonRelease: {
      // This can happen when the button press/release events are
      // handled in XInput
      if (event.xmotion.time == g_lastXInputEventTime)
        break;   
}

event.xmotion.time == g_lastXInputEventTime is always true, and the double click handling code is never executed.

If that's the case then it should break all click event handling, not just double click logic, shouldn't it? What behavior do you get using the tablet with Aseprite?

[est77]

Tablet events (in my case with a Wacom tablet) are handled by this code:

  auto* xinput = X11::instance()->xinput();
  if (xinput->handleExtensionEvent(event)) {
    Event ev;
    xinput->convertExtensionEvent(event, ev, m_scale, g_lastXInputEventTime);
    queueEvent(ev);
    return;
  }

But convertExtensionEvent does not handle double click events.

[est77]

I opened a PR with a fix that seems to work: #169