On 04/10/2015 02:29 AM, Carlos Garnacho wrote:
However the
compositor could send state along with A to the dest.
This could also work,
Thanks I think I finally made it clear what I am asking for.
So "intersection" is now f(A,B,state), and what I propose is:
source sends A to compositor
compositor sends A to dest
compositor sends state to dest
dest does C = f(A,B,state)
dest sends C to compositor
compositor sends C to source
"compositor sends state to dest" could very well mean that the dest gets
events for the seat, as though it was temporarily focused. This would
also allow the dest to make a popup menu to let the user choose an action.
I however think it makes sense to abstract this a
bit wrt the devices involved. Generally, wl_data_device nicely
abstracts from the pointer/touch/device being used throughout the
operation. It makes sense to me to do the same here, if what we are
pursuing is a DnD action. Also, this IMO gives some degree of liberty
wrt form factors, testing...
Any such concerns like this apply to *all* events, there is nothing
special about the events during a DnD, and the clients must already have
code to "abstract wrt the devices involved". The DnD should indicate
which "seat" is doing the drag however.
It's true that the modifier mapping becomes compositor-dependent (It's
been traditionally on toolkit domain), but then so is every keycombo
the compositor wants to implement.
That seems completely different, as compositor bindings do actions
without communicating with any client (ie a key that launches a
particular client will work when there are no clients).
But I won't be as hard positioned on this one, if the consensus is
that we better send pressed buttons/modifiers to the dest, it can be
made to work.
Anybody else want to say anything?
I am VERY much in favor of moving as much logic as possible from the
compositor to the clients. And f(A,B,state) is a very complicated
function. B may not be a list, it could be, in effect, infinite in size
(a client conceivably could ask the user to type a filename that the
drop should go to), can vary quickly (as the user moves across widget
boundaries), and can contain items the compositor has no business
knowing about (a paint program may ask how to tile a dropped pattern).
The list A does not vary much and is much shorter IMHO. I think it is
really move vs copy in almost all cases. Even file linking could be
considered a "copy" as far as the source is concerned (it does not have
to know that a link was made rather than the data copied).
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
