QDropEvent requires QEventLoop for user interaction on decisions

There might be a design flag with QDropEvent:

the event needs some choices to be made, which sometimes are to be done by the user. Copy, Link, Move or Cancel? Which of the data variants offered to pick? Think e.g. drops on filesystem views, or all the variants QImageIOWriter offers for imageData type on drag side.

All of this user querying needs to happen while the QDropEvent object and its QMimeData object are around. So during the override of the QWidget::dropEvent() handler. To be able to set the accepted drop action on the event to reply to the request, as well as to fetch the very data blob for the data type one wants to actually get. And user querying means: dialogs, thus an event loop. While we still stay in the event loop which brought us the current drop event handler.

Now nested event loops are best to be avoided, we are told But right now, we have to for user input on a drop?

The current API documentation for QDropEvent::mimeData() also implies a wrong idea by saying "the data that was dropped", at least with X11 and Wayland DnD protocols the very data is only actually fetched when the recipient has decided and asked for a certain  data format. And one would hope (did not check) the Qt implementation does not just prefetch any possible data variant, e.g. in case of QImage that would be all the QIimageIOWriter variants .

No instant idea/proposal how to fix this, just reporting for now.

Perhaps QDropEvent could be split into further events & methods, to allow the async decision taking on the drop action and the data format to actually fetch? No expert on event loops and handlers design, just a consumer