xdg shell status and gaps

[Jason Ekstrand]

On Fri, Sep 26, 2014 at 7:38 AM, Jasper St. Pierre <jstpierre at mecheye.net>
wrote:

>
>
> On Fri, Sep 26, 2014 at 4:07 AM, Carlos Garnacho <carlosg at gnome.org>
> wrote:
>
>> 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.
>>
>
> 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.

--Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140926/1103f791/attachment.html>