On vie, 2015-04-10 at 12:44 -0700, Bill Spitzak wrote: > 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.
In fairness, your proposal started as something quite different, we happened to find the middle ground. > > 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. DnD can be driven by mouse, touch, and stili when wl_tablet arrives. There's however no exposure of this on the events sent by data_device, everything happens in its own semantics rather than wl_pointer's or wl_touch's. I'm not sure why the actions derived from keyboards deserve a different treatment. > > > 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 Are you maybe folding mimetypes and actions as A/B/C above? The only thing that can grow "unbounded" is the mimetype list, the possible actions are always a fixed set, and resolved after the mimetype is negotiated. AFAICS "B" corresponds to the dest side, which confuses me, because both the picked mimetype and action will always be a subset of A's. > (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). Ah, I see, perhaps it's rather "varying over time" than "infinite"? TBH I don't see how this is different to how mimetypes are dealt with, you definitely don't have to calculate all possible states at once, just for the position you're in. > > 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). Cheers, Carlos _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel