fvogt added a comment.
I tried to understand what this change does both by trying to reproduce the issue and reading Qt code. Here the symptom was more drags not getting accepted at all than flipping back and forth, but this patch fixes that as well. What might cause confusion is that the `DeclarativeDropArea::enabled` property is unrelated to `QQuickItem::enabled`. If the latter is set to disabled, events don't get delivered at all (== rejected) and this should work directly (so I wonder why this has a custom property at all). From what I can tell this patch actually does two independent changes: - Not actively ignoring an event if the move didn't change position (this is enough to fix my case, but apparently not for @trmdi, can you clarify?) - Actively rejecting an event if the area is "disabled" or "temporarily inhibited" to prevent stealing of the event by any parent areas IMO the first change is absolutely correct - actively reejecting a move breaks the drag. The second change seems to be necessary because DragMove events are considered to be accepted by the current drag target item by default. So it needs to be rejected actively if "disabled" or "inhibited". This is normally done by Qt itself for disabled items, but as this reimplements a custom enabled property it needs to be done manually. I suggest to wait until Monday whether @bruns has something to add, but if there's no objection this can IMO be landed. REPOSITORY R296 KDeclarative REVISION DETAIL https://phabricator.kde.org/D16643 To: trmdi, mart, broulik, #plasma, hein, bruns Cc: fvogt, aacid, bruns, dkorth, ngraham, kde-frameworks-devel, michaelh
