D16643: Correct the accept flag of the event object on DragMove

[Fabian Vogt]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190131/312d4da7/attachment.html>