[PATCH wayland v4] protocol: Add DnD actions

[Bill Spitzak]

On Thu, Oct 1, 2015 at 1:59 PM, Carlos Garnacho <carlosg at gnome.org> wrote:

> 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.
>

The DnD can eat the events it is using. All I am suggesting is that the
modifiers are sent to the destination. I see absolutely no difference what
so ever from what your proposal does.

Once again, your proposal is:

 1. Source sends list A of actions
 2. Dest sends list B of actions
 3. Compositor does f(A,B,modifiers) to  produce action C
 4. Compositor sends C to source and destination

My proposal, which IS EXACTLY THE SAME EXCEPT THE LOCATION OF f():

 1. Source sends list A of actions
 2. Compositor sends A to dest
 3. Compositor sends modifiers to dest
 4. Dest does f(A,B,modifiers) to produce action C
 5. Dest sends C to compositor
 6. Compositor sends C to source.

plus not requiring gratuitous major changes
> on toolkits and clients.


The toolkit's Wayland api can do whatever it wants if it feels it is
important to provide a back-compatible interface. There is no way that
moving the fuction f() from the compositor to the destination can cause the
toolkit to have a different api. It does allow the destination to define
f() but that is NEW api and will not break anything.


> 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.
>

This requires the ability to turn off the preview that the drag source is
doing, therefore it must be able to change the cursor.


> 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+.
>

The current proposal for "ask" requires the source to have the list of
actions. This has two really serious problems:

 1. The destination may want to define actions that the source and
compositor api don't know about. For instance it may be ambiguous what
object you are dropping on, and the destination wants to make each of those
objects a different "action".

 2. The menu will look wrong to the user, because it is drawn by the
source. All users think this menu belongs to the destination app and should
be using preferences from the dest.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151002/d1beb50b/attachment-0001.html>