xdg shell status and gaps

[Carlos Garnacho]

Hey,

On Thu, Sep 25, 2014 at 7:30 PM, Matthias Clasen <matthias.clasen at gmail.com>
wrote:

> On Thu, Sep 25, 2014 at 10:32 AM, Jasper St. Pierre
> <jstpierre at 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.

  Carlos


> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140926/5832227c/attachment-0001.html>