[PATCH wayland v4] protocol: Add DnD actions

[Carlos Garnacho]

On Thu, Oct 1, 2015 at 9:47 PM, Bill Spitzak <spitzak at gmail.com> wrote:
> I really do not like the idea that the compositor is responsible for
> matching up modifiers with actions.
>
> Still trying to figure out why the destination cannot pick one of the
> actions, rather than the compositor doing this. If the modifiers are needed
> then either the destination gets the modifiers, or the source gets them and
> uses them to alter the list of offered actions.

Because DnD could be carried out by a pointer+keyboard, accessibility
technologies, or a gravity gun for that matter. It introduces the
unnecessary concept of keyboard modifiers to something that's agnostic
of the input device, when actions must be already present and carried
around.

>
> My best guess is that you are having trouble emulating XDND. I think that is
> a poor excuse for a non-optimal api however, and I really doubt it cannot be
> worked around.

I'm not going down this rathole again. It is not emulating, but being
able to interoperate with, plus not requiring gratuitous major changes
on toolkits and clients. I'm not going to implement something I know
broken for cases I immediately have to fix next, you're free to flesh
out your criticism on an alternative patch if you want.

>
> My overall opinion is that the destination needs a lot more control over
> this to get a proper modern ui. The destination may want to show a preview
> of what the drop will look like, which means the destination MUST be able to
> control the cursor image. I don't care if this somehow violates any
> principles of grab. It can revert to the cursor image from the source when
> the destination refuses the drag.

What kind of preview to you want to show *on the cursor*? if it's
"preview" what you want, it should surely happen on the dest surface
itself.

>
> The destination must also be able to pop up a menu of actions that the user
> chooses from. Therefore it must be able to get the list from the source and
> respond with a chosen one. The reason the destination must do this is
> because the drop target may be ambiguous, and the destination needs to be
> able to ask the user which to do. The user does not see any difference
> between this and deciding whether move/copy needs to be done, so any api
> that does not allow the user to select both simultaneously with a single
> push is broken.

Although I'd like to see mimetype/action in a single request too,
nothing prevents such menus either with these patches, set "ask" as
first action, and issue a late .action() request when it's been
picked. I'm most certain because I've seen it working on current apps
with patched gtk+.

  Carlos