[dolphin] [Bug 495594] New: Different drag cursor states when moving through various Dolphin's ares, cause different sites not accepting the drop

[Michał Dybczak]

https://bugs.kde.org/show_bug.cgi?id=495594

            Bug ID: 495594
           Summary: Different drag cursor states when moving through
                    various Dolphin's ares, cause different sites not
                    accepting the drop
    Classification: Applications
           Product: dolphin
           Version: 24.08.2
          Platform: Manjaro
                OS: Linux
            Status: REPORTED
          Severity: normal
          Priority: NOR
         Component: general
          Assignee: dolphin-bugs-null at kde.org
          Reporter: michal.dybczak at gmail.com
                CC: kfm-devel at kde.org
  Target Milestone: ---

Created attachment 175368
  --> https://bugs.kde.org/attachment.cgi?id=175368&action=edit
Drag-directions

***
I've been managing images on various Google Drive accounts for work and
discovered several issues with drag-drop feature.

This requires some background info to understand the problem.

There are two various type of GDrive accounts:

1. Google Drive on Gmail account (can be free or paid, any person can have it,
there are no requirements aside having Google personal account) - causes the
least amount of issues. Drag-drop works there fairly OK, although I discovered
that it is not enough to drag the file outside the Dolphin's window to the drop
area. You need also to STOP while holding over the drop area and do another
move to make see the drop cursor, which in this case is indicated with a HAND
ICON. See the attached screenshot. This is however a weird mechanics on the
site and KDE cannot do anything about it.

2. Google Drive on own domain (company's paid account) - is way harder to work
with and causes more issues, because, as I discovered, the drag-drop works
only, when moving earlier through other droppable areas in Dolphin where drag+
cursor appears (hand cursor as in previous case is not accepted by the site's
mechanisms). See the screenshot with plus cursor.

Drag-drop does not work when:
- dragging over the below edge of the Dolphin
- dragging over the file info area
- dragging over the top edge of the Dolphin
- dragging over the areas with images where there is only drag-stop cursor (you
cannot drop on files)
- dragging directly from Dolphin to the site over any edge of Dolphin

Drag-drop works only when:
-  it passes over the Dolphins droppable area (like other pane, locations
panel) before descending to the draggable surface of the GDrive side. When
there is two pane view, and you have location panel on the one side and file
info panel on the other one, and the dragged file passes over the other pane on
empty areas or over the location area (both are droppable areas in Dolphin
where drag-plus cursor appears). However, sometimes, in rare cases even that
doesn't work, so there is some unclear condition here.
In my case, as presented on the screenshot, in only works when I drag to the
left. I assume, if the panels were reversed, only drag to the right would work.

Since the only difference between working is the kind of GDrive account, it has
to mean, that there are various ways of creating droppable areas and which
determines, how they interact with drag-drop feature.

1. On Gmail Gdrive the cursor double move (move, stop, move) is enough to
trigger the droppable area on the site, the cursor is shown as hand. However,
the fact that we see a hand cursor but dropping works, means that Gmail GDrive
is more lenient and accepts this form of not refreshed drag state.

2. On company's account it happens, that the droppable area is more sensitive,
and needs plus cursor, which doesn't shows automatically, when interacting with
site's droppable area. The plus cursor most be activated before by passing over
droppable Dolphin's areas like location panel. The site's surface accepts only
this kind of cursor.

The various acceptable cursor icons suggest, that while dragging, there are
various states and Gmail GDrive accepts first one (when cursor shows a hand),
while Domanin (company's) Gdrive requires condition to be changed into drop,
which is indicated as plus icon. So there are at least two states of the link
when dragging file, which are shown by different cursor's icons.

I posted the screenshots to explain it visually.

Obviously, the site's droppable area seems to have different mechanisms on
various accounts, and in the second case is not accepting the drag in a hand
form. I don't know, how many ways are there to have droppable areas interacting
with the cursor, but clearly, Plasma must improve the dragging states, so it
would be robust and worked on all sites equally, without a long and confusing
process of finding out, which moves work and which don't.


***

SUMMARY


STEPS TO REPRODUCE
1. Use Wayland.
2. Have Dolphin in two panel mode.
3. Have file info panel on one side.
4. Possibly have multiple monitors (not needed but helps to have Dolphin on one
screen and browser's window on the other).
5. Possibly have various Google Drive accounts, especially important is to have
company's drive with verified own domain. Without it, it would be impossible to
test it. However, I hope that the fact that cursor icons are different, it is
enough to discover what internal mechanism on KDE's side is causing the issue.

OBSERVED RESULT
Draging and dropping does not work consistently, because of the various areas
that are crossed over when dragging a file. Most probably, the properties of
drag are not correctly updated.

EXPECTED RESULT
Drag-drop works reliably, no matter if we drag over the left, right, upper,
down edges or various areas.


SOFTWARE/OS VERSIONS
Operating System: Manjaro Linux 
KDE Plasma Version: 6.2.2
KDE Frameworks Version: 6.7.0
Qt Version: 6.8.0
Kernel Version: 6.6.58-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 16 × AMD Ryzen 7 7840HS w/ Radeon 780M Graphics
Memory: 30.6 GiB of RAM
Graphics Processor: AMD Radeon 780M
Manufacturer: TUXEDO
Product Name: TUXEDO Sirius 16 Gen1

ADDITIONAL INFORMATION

I am aware of other drag-drop issues like this one:
https://bugs.kde.org/show_bug.cgi?id=483645
I had it not so long ago, but was fixed.

Another problem, a different one, is that repeating unsuccessful drop,
sometimes something breaks and dragging stops being possible. The only way is
to either restart Dolphin or change the directory and back. I noticed that some
breakages carry over to the other location, and only Dolphin's restart fixes
it. The clear tell that the dragging broke at this moment is the lack of the
cursor changes.

In this bug report, I want to focus on those dragging transformations showed by
different cursor states and how various sites can accept one or only the other.

Also, I tested it only on Dolphin. I'm not sure if this is a general issue and
if it can have different facets when interacting with various File Managers
GUIs like Krusader.  I'm reporting it as a Dolphin's issue, because moving
through Dolphin's UI causes the drop cursor to have different states, which
influence the reaction of droppable surface on the site.

DRAG PROCESS SHOULD BE MORE RESILIENT AND WHEN CURSOR IS OUTSIDE OF DOLPHIN'S
WINDOW, IT SHOULD BE UPDATED TO DROP-PLUS state, so the droppable surfaces on
the sites recognized it correctly all the time - at least that is the theory.

I hope that someone who understand how the process is happening internally, can
understand what I meant here and will be able to find the solution to this
problem. Currently, working with Dolphin professionally is a pain, because of
that drag-drop problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.