Details
-
Bug
-
Resolution: Invalid
-
P2: Important
-
None
-
6.3.0
-
None
Description
It seems that QWidget::mouseReleaseEvent does not get triggered after QDrag::exec. This causes the following issue that e.g. a QPushButton instance gets stuck in "pressed down" (with pressed highlight, etc) state as the attached gif shows.
I worked this around by calling
setDown(false);
after
drag->exec(...)
But this is obviously a poor workaround as it is just one state - so, this will not make event filters, etc, work the usual way. It will also ignore any other potential state. It is also just one particular widget type, but the concept is broken for all types currently.
Here is a small testbed example that I have put together that is really small and reproduces the issue. This is what I also used for the above gif to show the issue.
https://github.com/lpapp/examples/tree/main/qt-button-dnd
This is where the QDragManager::drag starts grabbing the mouse on Linux with X11 for example: https://github.com/openwebos/qt/blob/master/src/gui/kernel/qdnd_x11.cpp#L2026
I do not know the details very well, but from a user point of view, it would be good to either let mouseReleaseEvent get triggered as usual after the dragging has finished or at least not to have artifacts like the above around.
It is also fine not to emit clicked() when the drag-and-drop is cancelled by the user, but the QWidget instance acted upon must be released. It would not be good (or even fair) from Qt to expect each and every drag-and-drop customers to manage each and every QWidget* states manually.
The documentation has also claimed the behaviour that I am proposing here:
https://doc-snapshots.qt.io/qt6-dev/qdrag.html#exec
"Other events are still delivered to the application while the operation is performed."
I have also noticed several posts on Stack Overflow, Qt Centre, Qt Forum, etc, about this issue without a "real solution". E.g. this dates back to 12 years ago: https://www.qtcentre.org/threads/34539-Drag-and-drop-from-QPushButton