https://bugs.kde.org/show_bug.cgi?id=371229
--- Comment #5 from Matthias Fauconneau <matthias.fauconn...@gmail.com> --- Thank you for the information. So I guess it would need either an X server hack, or the application (toolkit) should only start drags when the mouse move is after a mouse press on its window. Actually that's what I do in my app, I wonder why is it not the normal way applications (toolkits) handle drag starts ? maybe some interaction with inter application drags ? On Fri, Oct 28, 2016 at 1:04 PM, Martin Gräßlin <bugzilla_nore...@kde.org> wrote: > https://bugs.kde.org/show_bug.cgi?id=371229 > > Martin Gräßlin <mgraess...@kde.org> changed: > > What |Removed |Added > ------------------------------------------------------------ > ---------------- > Resolution|WAITINGFORINFO |INVALID > Status|NEEDSINFO |RESOLVED > > --- Comment #4 from Martin Gräßlin <mgraess...@kde.org> --- > Well on X11 the window manager is not involved in that. The first drag is > handled inside the application - the second drag as well. For the second > application there is no chance to know what was going on. > > In fact as far as I understand the problem from an X11 protocol point of > view > everything seems fine. A pointer enter is supposed to be sent to the window > below the cursor as soon as the other window crashes. And the window then > reacts. > > On Wayland the compositor has a little bit more choice, luckily: > > case QEvent::MouseMove: { > if (event->buttons() == Qt::NoButton) { > // update pointer window only if no button is pressed > input()->pointer()->update(); > } > > -- > You are receiving this mail because: > You reported the bug. > -- You are receiving this mail because: You are watching all bug changes.
