<div dir="ltr"><div><div><div>I really do not like the idea that the compositor is responsible for matching up modifiers with actions.<br><br></div>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.<br><br></div><div>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.<br></div><div><br></div>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.<br><br></div><div>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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 30, 2015 at 4:02 PM, Michael Catanzaro <span dir="ltr"><<a href="mailto:mcatanzaro@igalia.com" target="_blank">mcatanzaro@igalia.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockquote></div><br></div></div>