Download it now!
Bug 125809 - Regression: LibO 6.2.x|6.3.0beta1 draw with KDE5 vcl: wrong visual feedback when dragging objects in the gallery
Summary: Regression: LibO 6.2.x|6.3.0beta1 draw with KDE5 vcl: wrong visual feedback w...
Status: RESOLVED NOTOURBUG
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: All Linux (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2019-06-09 08:19 UTC by sergio.callegari
Modified: 2020-03-23 06:26 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Screencast with upcoming LO 6.2.5 (1.53 MB, video/webm)
2019-06-14 06:34 UTC, Michael Weghorn
Details
Drag the other way around (752.80 KB, video/webm)
2019-06-14 12:53 UTC, Michael Weghorn
Details
Screencast with Qt 5.12.5 on Debian testing (611.44 KB, video/webm)
2020-03-23 06:24 UTC, Michael Weghorn
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sergio.callegari 2019-06-09 08:19:39 UTC
Description:
In draw, to drag an object in the gallery, you need to select it and keep clicking for some time until the mouse cursor changes into a symbol representing the drag action. On LibO6.2 with the KDE5 VCL you get a "forbidden" symbol instead (until you start moving the object) which is very confusing.

Steps to Reproduce:
See description

Actual Results:
See description

Expected Results:
See description


Reproducible: Always


User Profile Reset: No



Additional Info:
[Information automatically included from LibreOffice]
Locale: en-US
Module: DrawingDocument
[Information guessed from browser]
OS: Linux (All)
OS is 64bit: yes
Comment 1 Roman Kuznetsov 2019-06-10 05:50:59 UTC
Please try install latest master build or LO 6.3 beta 1 and retest it
Comment 2 sergio.callegari 2019-06-10 05:55:01 UTC
Same in LO 6.3 beta 1
Comment 3 Michael Weghorn 2019-06-14 06:34:23 UTC
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?
Comment 4 Xisco Faulí 2019-06-14 10:29:20 UTC
(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
Comment 5 sergio.callegari 2019-06-14 12:07:34 UTC
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.
Comment 6 Michael Weghorn 2019-06-14 12:53:40 UTC
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.
Comment 7 sergio.callegari 2019-06-14 13:42:05 UTC
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.
Comment 8 QA Administrators 2019-06-15 03:01:34 UTC Comment hidden (obsolete)
Comment 9 Michael Weghorn 2019-06-21 13:42:36 UTC
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
Comment 10 Jan-Marek Glogowski 2020-03-22 09:20:08 UTC
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.
Comment 11 Jan-Marek Glogowski 2020-03-22 09:23:14 UTC
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.
Comment 12 Michael Weghorn 2020-03-23 06:24:23 UTC
Created attachment 158887 [details]
Screencast with Qt 5.12.5 on Debian testing
Comment 13 Michael Weghorn 2020-03-23 06:26:21 UTC
(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