commit 3ba7df63994d8cf308a7dde930738fe87a55badf
author Ian Pun <ipun@redhat.com> Fri Apr 07 17:09:36 2017 -0400
committer Leo Ufimtsev <lufimtse@redhat.com> Wed Apr 19 15:41:52 2017 -0400
tree 22fb88949c4973f851bf37b94094447bf650d83b
parent de6fda754f39abc5ff635b244e93dee8e547c7c8

Bug 510446 - [wayland] StyledText DnD not signalling, move drag
detection to mouse_move

Resolve DnD glitches for external widgets by ensuring
SWT.MouseDown/MouseMove/MouseUp is sent in the correct order.

In gtk2 DnD architecture, Drag detection was done in mouseDown.
For Wayland support, Drag detection is now done in mouseMove (as does
gtk internally).

However, traditionally external widgets (e.g StyledText or non-SWT
widgets) expect to know if a drag has started by the time mouseDown is
sent.
As such, for backwards compatibility with external widgets (e.g
StyledText.java), we delay sending of SWT.MouseDown and
SWT.MouseMove until we know if drag started or not.

To do so we queue up mouseDown/Motion events until a drag or
a mouseUp occurred.

Tests:
1) Open StyledText, try Tripple click on a line in StyledText.java. Then
click on a keyword in
the same line.
  With fix: correct keyword is selected.
  Without fix: short drag starts.

2) Try dragging parts in Eclipse several times.
  With fix: Works as expected
  Without fix: sometimes eclipse thinks you're still moving a part
  even though mouse is released.

It probably also fixed a bunch of other custom widgets's DnD.

Known issues:
Because of how our queue works, the events are only sent out on either a
mouse_up event or if a drag threshold has been met. This causes the case
where if you try to do a drag highlight, it may cause a slight delay
before the first "block" of characters is highlighted. This is dependent
on the gtk_drag_threshold.

Patchset: 9 [Leo]
- Refactored
- Implemented logic to deal with post/events.

Change-Id: I66506a375e2dddf80bd6573d277595be235334b0
Signed-off-by: Ian Pun <ipun@redhat.com>
Signed-off-by: Leo Ufimtsev <lufimtse@redhat.com>