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 763387 - Make window creation hooks in tab DnD work on wayland
Make window creation hooks in tab DnD work on wayland
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Wayland
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2016-03-09 17:58 UTC by Carlos Garnacho
Modified: 2016-09-24 14:33 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtkdnd: Check whether the target is handled by the widget (1.44 KB, patch)
2016-03-09 17:59 UTC, Carlos Garnacho
rejected Details | Review
GtkWindow: Make it an application/x-rootwindow-drop destination (1.44 KB, patch)
2016-03-09 17:59 UTC, Carlos Garnacho
committed Details | Review
GtkNotebook: Make tab DnD use application/x-rootwindow-drop again (4.85 KB, patch)
2016-03-09 17:59 UTC, Carlos Garnacho
committed Details | Review

Description Carlos Garnacho 2016-03-09 17:58:55 UTC
For wayland, I propose we go back to using the application/x-rootwindow-drop mimetype so tabs are detached if drops happen on a destination accepting this target.

For this scheme to work, there has to be destinations accepting this mimetype first. In bug #762104 I've attached patches for mutter to do its part in the rootwindow. Also, one of the patches I'm attaching here turn GtkWindows into drop destinations accepting this mimetype. In practical terms, these two make the whole desktop area accept application/x-rootwindow-drop, triggering the window creation hook unless the drop happens anywhere accepting GTK_NOTEBOOK_TAB.

NB: Obviously, the newly created window positioning is broken in wayland, I haven't done anything yet about it.
Comment 1 Carlos Garnacho 2016-03-09 17:59:36 UTC
Created attachment 323532 [details] [review]
gtkdnd: Check whether the target is handled by the widget

This avoids widgets from "managing" drag and drop (eg. returning TRUE
in their handlers) for mimetypes they're even not meant to handle. This
makes the DnD machinery work in a similar way to event bubbling, the
first widget found (from bottom to top) that manages the target and returns
TRUE in their handlers will win.

This eg. avoids cases like textviews in notebooks, which are both
capable of DnD, yet the textview will be returning TRUE for the
GTK_NOTEBOOK_TAB target used by notebooks, this would make it ignore
the textview and let the notebook handle the target.
Comment 2 Carlos Garnacho 2016-03-09 17:59:41 UTC
Created attachment 323533 [details] [review]
GtkWindow: Make it an application/x-rootwindow-drop destination

This makes toplevels pseudo-transparent wrt this mimetype, so if
the drag source offers this mimetype and not another that was
managed by the destination-side widget hierarchy, the window will
be an acceptable target for this mimetype, allowing it to trigger
whatever is meant to in the source side.
Comment 3 Carlos Garnacho 2016-03-09 17:59:47 UTC
Created attachment 323534 [details] [review]
GtkNotebook: Make tab DnD use application/x-rootwindow-drop again

Besides the ::drag-failed handling in order to trigger the window creation
hook, add some handling of the application/x-rootwindow-drop mimetype, so
the same effect is achieved if the tab could be dropped in a destination
accepting this mimetype.
Comment 4 Matthias Clasen 2016-03-09 18:36:57 UTC
Review of attachment 323532 [details] [review]:

There's a very old bug where the problem of drag site propagation was discussed a bit: bug 118100
Comment 5 Matthias Clasen 2016-03-09 18:59:13 UTC
Review of attachment 323534 [details] [review]:

::: gtk/gtknotebook.c
@@ +1289,3 @@
   priv->switch_tab_timer = 0;
+  priv->source_targets = gtk_target_list_new (src_notebook_targets,
+                                              G_N_ELEMENTS (src_notebook_targets));

I wonder: Can we actually set this unconditionally as target ? Will this make it so that we always allow tabs to be dragged away, even if they aren't detachable ?
Comment 6 Matthias Clasen 2016-03-11 15:44:36 UTC
> I wonder: Can we actually set this unconditionally as target ? Will this
> make it so that we always allow tabs to be dragged away, even if they aren't
> detachable ?

Answered on irc: no
Comment 7 Matthias Clasen 2016-03-11 15:46:01 UTC
Review of attachment 323532 [details] [review]:

My suggestion for this is that we not change drop site propagation semantics for 3.20, but revisit this next cycle, perhaps a topic for discussion at the hackfest
Comment 8 Matthias Clasen 2016-03-11 15:46:38 UTC
Review of attachment 323533 [details] [review]:

This would be ok with me, but I think Carlos is currently working on a different approach
Comment 9 Matthias Clasen 2016-03-11 15:47:40 UTC
Review of attachment 323534 [details] [review]:

discussed on irc
Comment 10 Carlos Garnacho 2016-03-14 15:18:17 UTC
(In reply to Matthias Clasen from comment #8)
> Review of attachment 323533 [details] [review] [review]:
> 
> This would be ok with me, but I think Carlos is currently working on a
> different approach

This one didn't pan out in the end. I'm pushing the a-c-n patches.
Comment 11 Carlos Garnacho 2016-03-14 15:19:06 UTC
Attachment 323533 [details] pushed as 83cc7f7 - GtkWindow: Make it an application/x-rootwindow-drop destination
Attachment 323534 [details] pushed as 160a4fe - GtkNotebook: Make tab DnD use application/x-rootwindow-drop again
Comment 12 Stephen 2016-09-24 14:33:46 UTC
Does this fix tab tear-off not working under Wayland (as referenced in https://bugzilla.gnome.org/show_bug.cgi?id=771913)?