Bug 425258

Expected behavior would be mouse cursor being in the middle of the item.

IIRC this is done on purpose to improve the UX. Having the mouse cursor in the center of the drag pixmap would make harder to see where to drop it.

Agreed.

*** Bug 425760 has been marked as a duplicate of this bug. ***

Commenting here, since my bug report was marked as a duplicate of this.

If this really is a duplicate, then the behavior is pretty unexpected and annoying to me. When I want to drag something to another window on the task manager it feels like I have to drag to the icon next to the actual one.

Created attachment 131538 [details]
Offset when dragging to the icons only task manager

Notice that I drag the file on the Gwenview icon while the task manager highlights Firefox instead.

Might be a different bug, though.

Reopening. Maybe my bug was falsely marked as a duplicate, but currently this is the bug where it is tracked at. Please see my attached screenshot. The behavior is most likely not intended. I mentioned that before, but probably because this is marked as resolved, I got no reply in between.

Can you please attach a mockup that shows how you expect this to look in various situations?

Created attachment 132448 [details]
Mockup based on previous screenshot showing the expected behavior

(In reply to Nate Graham from comment #8)
> Can you please attach a mockup that shows how you expect this to look in
> various situations?

Starting from my previous screenshot I created a mockup showing my expectations.

I think other situations should behave similarly:
If the cursor that drags the file icon is over a surface that a file can be dragged then highlight that surface.

Currently the surface gets only hightlighted if the cursor is offset by a decent space from the surface. This is not how this works on any other operating system or desktop environment I know, thus I am rather sure, this is a bug. Maybe better tracked in a different place, but since my old report was marked as duplicate of this, I am using this one for now.

Forgot to set status to reopened.

I see. Your bug report is indeed something else. Un-duping.

I have written about a very similar issue in dolphin under
https://bugs.kde.org/show_bug.cgi?id=385054

If this is supposed to be intentional, why doesn't this happen on X11 and why do something that obviously harms the user experience?

(In reply to Nate Graham from comment #11)
> I see. Your bug report is indeed something else. Un-duping.

Thanks!

(In reply to Alexander from comment #12)
> I have written about a very similar issue in dolphin under
> https://bugs.kde.org/show_bug.cgi?id=385054
> 
> If this is supposed to be intentional, why doesn't this happen on X11 and
> why do something that obviously harms the user experience?

As you see above, this issue is now tracked under https://bugs.kde.org/show_bug.cgi?id=425760 again, since this bug report is apparently about something different. Sorry to have to forward you again, but probably best to followup there for the future progress.

(In reply to Matej Mrenica from comment #0)
> Created attachment 130822 [details]
> Screenshot
> 
> See the screenshot
> 
> SOFTWARE/OS VERSIONS
> KDE Plasma Version: 5.19.4
> KDE Frameworks Version: 5.73.0
> Qt Version: 5.15.0

Looking at the screenshot, the vertical offset seems to be pretty extreme. I cannot reproduce this, can you add more details (Wayland, which application did you drag from...)? - Reopening for now since it is most likely a bug.

I actually cannot reproduce the issue depicted in the screenshot. In Plasma's Folder View, dragging a file causes it to be dragged from wherever the cursor was actually located at, unlike in Dolphin, where it gets shifted down (this is an inconsistency!!!!)

Where did this file live? On the desktop? Dolphin? Somewhere else?

TBH I cannot reproduce this either right now. The only issue remaining is the dragged item being blurred on X11 or being twice as big on Wayland.

Arch Linux, Plasma 5.20.0, Kf 5.75, Qt 5.15.1

(In reply to Nate Graham from comment #15)
> I actually cannot reproduce the issue depicted in the screenshot. In
> Plasma's Folder View, dragging a file causes it to be dragged from wherever
> the cursor was actually located at, unlike in Dolphin, where it gets shifted
> down (this is an inconsistency!!!!)
> 
> Where did this file live? On the desktop? Dolphin? Somewhere else?

IIRC it was from Dolphin to desktop but now it looks reasonably.

(In reply to Matej Mrenica from comment #16)
> TBH I cannot reproduce this either right now. The only issue remaining is
> the dragged item being blurred on X11 or being twice as big on Wayland.
> 
> Arch Linux, Plasma 5.20.0, Kf 5.75, Qt 5.15.1

Maybe it got fixed in between.

Regarding blurred or twice as big dragged items on X11: This sounds like a different bug, is there already a bug report for it? Else can you open one (and link it here so we can follow up)?

(In reply to Matej Mrenica from comment #17)
> IIRC it was from Dolphin to desktop but now it looks reasonably.

Hm, the cursor looks different when I drag an image from Dolphin (no hand symbol, just the normal arrow). That might have changed in between or have something to do with my setup, though.

(In reply to Claudius Ellsel from comment #19)
> (In reply to Matej Mrenica from comment #17)
> > IIRC it was from Dolphin to desktop but now it looks reasonably.
> 
> Hm, the cursor looks different when I drag an image from Dolphin (no hand
> symbol, just the normal arrow). That might have changed in between or have
> something to do with my setup, though.

Also no hand symbol here.

I have accidentally re-discovered this issue in Gwenview. To trigger it simply open a folder of pictures in Gwenview and start dragging one of them. You should see:
1. the dragged item is quite far from the cursor
2. the item is exactly half the size of the original
3. the item will have white "areas" added to it
The bottom thumbnail panel in Gwenview has this issue too. I will try to post a screenshot.

(In reply to Claudius Ellsel from comment #18)
> (In reply to Matej Mrenica from comment #16)
> > TBH I cannot reproduce this either right now. The only issue remaining is
> > the dragged item being blurred on X11 or being twice as big on Wayland.
> > 
> > Arch Linux, Plasma 5.20.0, Kf 5.75, Qt 5.15.1
> 
> Maybe it got fixed in between.
> 
> Regarding blurred or twice as big dragged items on X11: This sounds like a
> different bug, is there already a bug report for it? Else can you open one
> (and link it here so we can follow up)?

There is a report for that: https://bugs.kde.org/show_bug.cgi?id=421395

Created attachment 132478 [details]
From Gwenview to Desktop

As I mentioned before the white areas aren't parts of the file.

(In reply to Matej Mrenica from comment #22)
> There is a report for that: https://bugs.kde.org/show_bug.cgi?id=421395

Thanks for the link!

(In reply to Matej Mrenica from comment #21)
> I have accidentally re-discovered this issue in Gwenview. To trigger it
> simply open a folder of pictures in Gwenview and start dragging one of them.
> You should see:
> 1. the dragged item is quite far from the cursor
> 2. the item is exactly half the size of the original
> 3. the item will have white "areas" added to it
> The bottom thumbnail panel in Gwenview has this issue too. I will try to
> post a screenshot.

Hm, that might be yet another bug. Notice that on your original screenshot here has not been the white surrounding for example. Maybe also related to https://bugs.kde.org/show_bug.cgi?id=385054.

I cannot really reproduce by the way (Wayland, no scaling). Do you use fractional scaling?

(In reply to Claudius Ellsel from comment #25)
> (In reply to Matej Mrenica from comment #21)
> > I have accidentally re-discovered this issue in Gwenview. To trigger it
> > simply open a folder of pictures in Gwenview and start dragging one of them.
> > You should see:
> > 1. the dragged item is quite far from the cursor
> > 2. the item is exactly half the size of the original
> > 3. the item will have white "areas" added to it
> > The bottom thumbnail panel in Gwenview has this issue too. I will try to
> > post a screenshot.
> 
> Hm, that might be yet another bug. Notice that on your original screenshot
> here has not been the white surrounding for example. Maybe also related to
> https://bugs.kde.org/show_bug.cgi?id=385054.
> 
> I cannot really reproduce by the way (Wayland, no scaling). Do you use
> fractional scaling?

Yes, that is probably another bug. Regarding the other bug you linked, it's similar but likely not the same because I don't use multiple monitors. I do use fractional scaling at 125%

(In reply to Matej Mrenica from comment #26)
> Yes, that is probably another bug. Regarding the other bug you linked, it's
> similar but likely not the same because I don't use multiple monitors. I do
> use fractional scaling at 125%

Alright. What I would suggest is to open another bug report for the things you experience with Gwenview (including that you use fractional scaling at 125%). This bug report can probably be closed as fixed then.

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

(In reply to Matej Mrenica from comment #28)
> Done: https://bugs.kde.org/show_bug.cgi?id=427878

Thanks, I subscribed there.

I will leave the (possible) resolution of this to Nate, since I didn't set the NEEDSINFO state.

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

Looks fixed, unfortunately Nate did not react in the meantime to my request to triage this, so marking as resolved fixed before the bot does something else.