[PATCH] protocol: Add DnD actions
carlosg at gnome.org
Sat Apr 11 03:59:48 PDT 2015
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
> events for the seat, as though it was temporarily focused. This
> also allow the dest to make a popup menu to let the user choose an
> > 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
> 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
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
> boundaries), and can contain items the compositor has no business
> knowing about (a paint program may ask how to tile a dropped
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
> 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
> to know that a link was made rather than the data copied).
More information about the wayland-devel