GNOME Bugzilla – Bug 763387
Make window creation hooks in tab DnD work on wayland
Last modified: 2016-09-24 14:33:46 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.
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.
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.
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.
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
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 ?
> 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
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
Review of attachment 323533 [details] [review]: This would be ok with me, but I think Carlos is currently working on a different approach
Review of attachment 323534 [details] [review]: discussed on irc
(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.
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
Does this fix tab tear-off not working under Wayland (as referenced in https://bugzilla.gnome.org/show_bug.cgi?id=771913)?