After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 765695 - DND doesn't work for GtkOverlay on Wayland
DND doesn't work for GtkOverlay on Wayland
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Backend: Wayland
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-04-27 20:51 UTC by kritphong
Modified: 2018-04-15 00:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test case (817 bytes, application/gzip)
2016-04-27 20:51 UTC, kritphong
Details

Description kritphong 2016-04-27 20:51:32 UTC
Created attachment 326893 [details]
test case

DND doesn't work for GtkOverlay on Wayland as demonstrated by the test case. The exact same program works properly on X11.

Steps to reproduce:
1. Compile and run the test program.
2. Drag and drop a file or text onto the test program's window.

Actual Results:
On X11, the file/text will be accepted by the program. Its string representation will be displayed in the GtkEntry and printed to console. On Wayland, the test program will not accept the file/text at all.

Expected result:
The program should behave identically on both X11 and Wayland.
Comment 1 Olivier Fourdan 2016-05-09 15:19:01 UTC
Changing GDK_ACTION_LINK to GDK_ACTION_MOVE in gtk_drag_dest_set() allows for DnD from Nautilus here.
Comment 2 Matthias Clasen 2016-05-09 15:21:42 UTC
How does the action cause different behaviors on different platforms ? Are we doing something different in the backend ?
Comment 3 Olivier Fourdan 2016-05-09 15:34:35 UTC
Not sure, the backend deals with context actions as seen in gdkdnd-wayland.c, adding Carlos...
Comment 4 Carlos Garnacho 2016-05-09 17:00:15 UTC
Wayland has no "link" action, both GDK_ACTION_LINK/PRIVATE are translated somewhat into "copy" at the protocol level. I guess there's some more translation missing somewhere.

But generally, I think link/private shouldn't be recommended for any cross-client DnD, the semantics are largely undefined unless source and destination agree on what "link" means, and due to the low level translation to "copy" there's a good chance the pointer cursor will be visually wrong...
Comment 5 Matthias Clasen 2016-05-09 17:07:14 UTC
Link is pretty much file-manager-only territory, no ?

I agree that we should put some recommendations in the docs
Comment 6 Carlos Garnacho 2016-05-09 17:26:48 UTC
(In reply to Matthias Clasen from comment #5)
> Link is pretty much file-manager-only territory, no ?

Yeah pretty much, that's the only place where it has a clear meaning. Nautilus doesn't use it, but "ask" instead in order to popup the menu with the "link here" option, dolphin uses it though (IIRC bound by default to middle button).

> 
> I agree that we should put some recommendations in the docs

Will cook a patch, same for "fixing" the testcase.
Comment 7 kritphong 2016-05-09 17:46:44 UTC
I just found that this is not specific to GtkOverlay after all. Not sure why I thought it was...
Comment 8 Matthias Clasen 2018-02-10 04:59:00 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 9 Matthias Clasen 2018-04-15 00:09:07 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new