xdg shell status and gaps

[Giulio Camuffo]

2014-09-26 19:39 GMT+03:00 Jason Ekstrand <jason at jlekstrand.net>:
>
>
> 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.

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
>