<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 1, 2015 at 1:59 PM, Carlos Garnacho <span dir="ltr"><<a href="mailto:carlosg@gnome.org" target="_blank">carlosg@gnome.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, Oct 1, 2015 at 9:47 PM, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote:<br>
> I really do not like the idea that the compositor is responsible for<br>
> matching up modifiers with actions.<br>
><br>
> Still trying to figure out why the destination cannot pick one of the<br>
> actions, rather than the compositor doing this. If the modifiers are needed<br>
> then either the destination gets the modifiers, or the source gets them and<br>
> uses them to alter the list of offered actions.<br>
<br>
</span>Because DnD could be carried out by a pointer+keyboard, accessibility<br>
technologies, or a gravity gun for that matter. It introduces the<br>
unnecessary concept of keyboard modifiers to something that's agnostic<br>
of the input device, when actions must be already present and carried<br>
around.<br></blockquote><div><br></div><div>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.<br><br></div><div>Once again, your proposal is:<br><br></div><div> 1. Source sends list A of actions<br></div><div> 2. Dest sends list B of actions<br></div><div> 3. Compositor does f(A,B,modifiers) to  produce action C<br></div><div> 4. Compositor sends C to source and destination<br><br></div><div>My proposal, which IS EXACTLY THE SAME EXCEPT THE LOCATION OF f():<br><br></div><div> 1. Source sends list A of actions<br></div><div> 2. Compositor sends A to dest<br></div><div> 3. Compositor sends modifiers to dest<br></div><div> 4. Dest does f(A,B,modifiers) to produce action C<br></div><div> 5. Dest sends C to compositor<br></div><div> 6. Compositor sends C to source.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
plus not requiring gratuitous major changes<br>
on toolkits and clients.</blockquote><div> </div><div>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.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>What kind of preview to you want to show *on the cursor*? if it's<br>
"preview" what you want, it should surely happen on the dest surface<br>
itself.<br></blockquote><div><br></div><div>This requires the ability to turn off the preview that the drag source is doing, therefore it must be able to change the cursor.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>Although I'd like to see mimetype/action in a single request too,<br>
nothing prevents such menus either with these patches, set "ask" as<br>
first action, and issue a late .action() request when it's been<br>
picked. I'm most certain because I've seen it working on current apps<br>
with patched gtk+.<br></blockquote><div><br></div><div>The current proposal for "ask" requires the source to have the list of actions. This has two really serious problems:<br><br></div><div> 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".<br><br></div><div> 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.<br><br></div><br></div></div></div>