2014-09-26 19:39 GMT+03:00 Jason Ekstrand <ja...@jlekstrand.net>: > > > On Fri, Sep 26, 2014 at 7:38 AM, Jasper St. Pierre <jstpie...@mecheye.net> > wrote: >> >> >> >> On Fri, Sep 26, 2014 at 4:07 AM, Carlos Garnacho <carl...@gnome.org> >> wrote: >>> >>> Hey, >>> >>> On Thu, Sep 25, 2014 at 7:30 PM, Matthias Clasen >>> <matthias.cla...@gmail.com> wrote: >>>> >>>> On Thu, Sep 25, 2014 at 10:32 AM, Jasper St. Pierre >>>> <jstpie...@mecheye.net> wrote: >>>> >>>> >>>> >> Anyway, here's the list: >>> >>> >>> <snip> >>> >>>> >>>> >>>> >>>> >> >>>> >> 7) Root window drop >>>> > >>>> > >>>> > When is this useful? >>>> >>>> One place where it is used is when dragging tabs out of a window to >>>> create a new window. gnome-terminal, gedit, nautilus, all do this. But >>>> looking closer, the way it is implemented is not actually as a root >>>> window drop, specifically, but just any failed drop - if you don't >>>> drop on a notebook in the same app that is hooked up to accept the >>>> tab, we just treat any failed drop as a change to create a new window. >>>> So, what we need is a signal that a drop failed. Not sure we get that, >>>> currently ? >>> >>> >>> There isn't. IMO it'd be more generally useful notifying about the drag >>> being finished. The client that started the drag should already know which >>> mimetype was requested. It'd also help retrofit toolkits to wayland, how >>> higher layers in GTK+ rely on getting the full press/motion.../release >>> events in the drag source client can't be easily circumvented, having a >>> consistent ending point for the operation would help lots. >>> >>> Although... if "drag failed" animations are to be performed by the >>> compositor, I think we actually want the drag operation accepted in some >>> form, or we'd confusingly get both things happening. For root window drops >>> at least, maybe "application/x-rootwindow-drop" from XDND could be reused, >>> and have the compositor peer on the wl_data_device so it accepts that >>> mimetype. >> >> >> One of the other things we need, and was on the to-do list a long time >> ago, was to support "move" / "copy" DND emblems so that some more >> information can be transferred about the context of a drag. I'm not sure if >> this should be sent by the source, or can be done entirely by the >> destination client. >> >> How does this work under XDND? > > > It would be good to talk to Giulio Camuffo (who I just added to the CC) > about this. He was working on trying to get Qt's drag-and-drop support to > work some time ago and I think he ran in to similar issues.
Sorry for the late reply, I completely forgot about it. Yeah, I sent a few patches last year to introduce support for DnD actions, as they would be needed for Qt, and I understand Gtk+ does also need a similar thing. I can't seem to be able to find all of them, anyway the most relevant one is the new protocol [0], the other ones would need to be heavily rebased. [0]: http://lists.freedesktop.org/archives/wayland-devel/2013-March/007931.html -- Giulio > > --Jason > _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel