<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Regression: LibO 6.2.x|6.3.0beta1 draw with KDE5 vcl: wrong visual feedback when dragging objects in the gallery" href="https://bugs.documentfoundation.org/show_bug.cgi?id=125809#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Regression: LibO 6.2.x|6.3.0beta1 draw with KDE5 vcl: wrong visual feedback when dragging objects in the gallery" href="https://bugs.documentfoundation.org/show_bug.cgi?id=125809">bug 125809</a> from <a class="email" href="mailto:glogow@fbihome.de" title="Jan-Marek Glogowski <glogow@fbihome.de>"> Jan-Marek Glogowski</a> <pre>I had a look into this. I put SAL_DEBUG into all DnD functions I could find. I even added slots to the QDrag signals. The only thing that fires, when starting the drag operation by holding the mouse button, is QDrag::actionChanged with action=Qt::IgnoreAction. The result is the forbidden icon. Nothing else happens. LO calls drag->exec(toQtDropActions(sourceActions), getPreferredDropAction(sourceActions)), which defaults to Qt::MoveAction, so would be correct. Master Qt5 code has: Qt::DropAction QBasicDrag::drag(QDrag *o) { m_drag = o; m_executed_drop_action = Qt::IgnoreAction; m_can_drop = false; startDrag(); m_eventLoop = new QEventLoop; m_eventLoop->exec(); delete m_eventLoop; m_eventLoop = nullptr; m_drag = nullptr; endDrag(); return m_executed_drop_action; } So if we start a Drag and Drop operation, the default is set to Qt::IgnoreAction and our explicit Qt::MoveAction default to QDrag::exec is ignored. I think the following diff would be correct: - m_executed_drop_action = Qt::IgnoreAction; + m_executed_drop_action = o->defaultAction(); That code is from 2012. Eventually this was fixed in Qt 5.15 by the following commit, which would at least generate some more events on DnD start, but my Qt version is too old to check: commit 7a7c722782a435f7c01b94f48df7a5f4ff4d599e Author: Gatis Paeglis <<a href="mailto:gatis.paeglis@qt.io">gatis.paeglis@qt.io</a>> Date: Tue May 22 16:33:53 2018 +0200 dnd: send DragEnter and DragMove on DnD start That is actually more correct, as it would ask the drop target (which is the same then the drag source at the start), if it would accept a default drop action. That is a fix for upstream bug QTBUG-34331 (<a href="https://bugreports.qt.io/browse/QTBUG-34331">https://bugreports.qt.io/browse/QTBUG-34331</a>) Which removed the following hunk from QBasicDrag::drag, which would change the cursor to Qt::IgnoreAction. -#ifndef QT_NO_CURSOR - qApp->setOverrideCursor(Qt::DragCopyCursor); - updateCursor(m_executed_drop_action); -#endif The same happens for examples/widgets/draganddrop/fridgemagnets (in Debian in qtbase5-examples), when you just hold the left button to start a drag of a magnte, while the code has: if (drag->exec(Qt::MoveAction | Qt::CopyAction, Qt::CopyAction) == Qt::MoveAction) so it should start with the Qt::CopyAction as a default action. My current conclusion is NOTOURBUG and I don't see a way for a sensible workaround in LO. Can someone with a Qt 5.12 version test, if this is fixed? I tested it with qt5 in a Ubuntu focal chroot (kf5 didn't work), but that had some many other problems, like no changed cursor at all, that I can't say it is fixed or not.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>