Community
Participate
Working Groups
Originally for Gtk2/Gtk3, dragDetect() method blocked until drag was detected or mouse was released. For DnD on Wayland, we made dragDetect() non-blocking and all drag logic was moved into gtk_motion_notify_event(..). While this enabled DnD on Wayland, it caused a series of regressions: - Bug 514419 - [regression][GTK3] DND is broken in staging view - Bug 514659 - [regression] Double-click and drag doesn't work in java editor - Bug 514531 - [GTK3][regression] Launch config is not opened after creation - Double click & then clicking on keyword moved cursor to top of screen - Tree selection issues (?) - etc... there may be more that we haven't seen. After investigation, we found that common/external widgets (for example styledText) as well as a lot of internal widgets heavily rely on dragDetect() having blocking behaviour. This blocking behaviour is what Win32/Cocoa does as well. As such, I suggest to implement blocking behaviour in dragDetect(..), (while still utilizing gtk_motion_*_even() for actual drag detection. I'll submit proof-of-concept patch shortly.
New Gerrit change created: https://git.eclipse.org/r/95207
This change is too risky at this stage in 4.8. Need to wait till after release.
(In reply to Leo Ufimtsev from comment #2) > This change is too risky at this stage in 4.8. Need to wait till after > release. Why wait? Every next release will be in 3 months, so it's not like from now on we will have more time than now.
(In reply to Alexander Kurtakov from comment #3) > (In reply to Leo Ufimtsev from comment #2) > > This change is too risky at this stage in 4.8. Need to wait till after > > release. > > Why wait? Every next release will be in 3 months, so it's not like from now > on we will have more time than now. That's a good point.
*** This bug has been marked as a duplicate of bug 541635 ***
