Please try install latest master build or LO 6.3 beta 1 and retest it

Same in LO 6.3 beta 1

Created attachment 152181 [details]
Screencast with upcoming LO 6.2.5

I cannot reproduce, s. attached screencast taken with

Version: 6.2.5.0.0+
Build ID: c98b7c9e75a951012d6693f5adecb1ff0e1f8f6b
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

(I clicked and waited a while before starting the drag action.)

Can you attach a screencast that shows how it behaves for you?

What desktop environment is this, and what version?

(In reply to Michael Weghorn from comment #3)
> Created attachment 152181 [details]
> Screencast with upcoming LO 6.2.5
> 
> I cannot reproduce, s. attached screencast taken with
> 
> Version: 6.2.5.0.0+
> Build ID: c98b7c9e75a951012d6693f5adecb1ff0e1f8f6b
> CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; 
> Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
> Calc: threaded
> 
> (I clicked and waited a while before starting the drag action.)
> 
> Can you attach a screencast that shows how it behaves for you?
> 
> What desktop environment is this, and what version?

Setting to NEEDINFO

Sorry, I have not been clear enough.

The issue is not in dragging an object from the gallery to the canvas (as tested in the screencast). The issue is in dragging an object from the canvas to the gallery, to add a new object to a gallery.

Created attachment 152192 [details]
Drag the other way around

(In reply to sergio.callegari from comment #5)
> Sorry, I have not been clear enough.
> 
> The issue is not in dragging an object from the gallery to the canvas (as
> tested in the screencast). The issue is in dragging an object from the
> canvas to the gallery, to add a new object to a gallery.

Can you be please give (or link to) a detailed step-by-step description how to do this?

Trying just the reverse steps from my previous attempt doesn't put the object into the gallery after all, but places it at the place "below" the sidebar, s. new screencast. Same happens with SAL_USE_VCLPLUGIN=gtk3.

Here are the instructions:

1) Open draw with an empty canvas
2) Go to the gallery, click on New Theme to create a custom gallery (so that you have a gallery to place your drawing into). Suppose you call it TEST
2) Select that gallery. Should appear as empty. 
3) Draw something little and simple (e.g. a circle, a box, a circle and a box, etc.). If it is made of multiple objects, group them.
4) Place the mouse on that object, select it by clicking and releasing. Now, click and keep the mouse button pressed without moving the mouse for about 2-3 seconds until the cursor changes, to show you that the object has been copied into memory and is ready for being dragged onto the gallery.
5) Keeping the mouse button pressed, now drag the object into the gallery

(see also https://help.libreoffice.org/Common/Adding_Graphics_to_the_Gallery)

At point 4) the mouse cursor should change into something sensible, to indicate that the object is actually ready to be dragged. With the KDE5 VCL, unfortunately the mouse cursor changes into a forbidden sign, though.

Thanks, I can reproduce now. Needs a closer look why it behaves as it does, which may even be technically correct (the "forbidden" symbol probably indicates that dropping at this place is not allowed, since dropping an object at the exact same location might be "forbidden" for some reason?).

Anyway, I'm confirming this for now (can still be closed as WORKSFORME in case it should turn out this is the correct behaviour, though unexpected).

Version: 6.4.0.0.alpha0+
Build ID: f270bd15fed87a9cb0f8dfa73b34c617d66f59c2
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: kde5; 
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded

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 <gatis.paeglis@qt.io>
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 (https://bugreports.qt.io/browse/QTBUG-34331)

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.

The previous comment has a typo: from the Qt bug it's fixed in 5.12, not only in 5.15+. I changed the 2nd occurrence, but missed the first.

Created attachment 158887 [details]
Screencast with Qt 5.12.5 on Debian testing

(In reply to Jan-Marek Glogowski from comment #10)
> 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.

Indeed, this works on current Debian testing, which has Qt 5.12.5, s. screencast: attachment 158887 [details]

-> closing as NOTOURBUG

Version: 7.0.0.0.alpha0+
Build ID: 3eb14808495fc930c481ee6842574abf8f8608ab
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-03-21_17:20:22
Locale: en-GB (en_GB.UTF-8); UI-Language: en-US
Calc: threaded