Hey Bill,
On mié, 2015-03-18 at 19:40 -0700, Bill Spitzak wrote:
> This is still bothering me as being much too complicated.
The bad news is, DnD is complex, there's plenty of prior usecases here
that won't be fair/possible to have "simplified".
>
> I think a list of actions can be sent from the DnD source to the
> target,
> and the target selects one. There is no need for the compositor to
> do
> any intersection of the sets and there is no need to communicate the
> set
> of target actions to the compositor.
>
> Your concerns about shift state being handled by the source are
> misplaced. This would not change at all under what I am proposing,
> the
> source could still use the shift state to change the list of actions.
I see several issues with this:
* How are actions conveyed? do we encode these in the mimetype
string? how do we standardize on the actions? how do we make
that backwards compatible?
* How do drag destinations react to unhandled options? Say a
drag source appends "?action=ask" when you press Alt and the
drag destination only knows copy/move, how does this fallback
to an action that both parts recognize?
* Additionally to modifier state, there's other
keyboard/accessibility features as DnD is done in GNOME/GTK+
(eg. DnD driven by cursor keys), these must be implemented on
the compositor, this sounds like conflicting with the
expectation in your proposal to have the drag source receive
key events [1].
>
> My proposal is basically to take yours, and remove the ability for
> the
> target to send a set of actions that the compositor then interesect
> with
> the source list. Instead this "intersection" is done by the target,
> and
> the target sends *one* action (or "none") indicating the result of
> the
> intersection.
>
> Unless you want the compositor to draw user interface to allow the
> user
> to choose the action, which seems very much a bad idea, I cannot see
> what your proposal will allow to happen that this simplified version
> would not.
IMO, it kind of misses the point that DnD is a negotiation.
I was suggesting that the "ask" action were implemented completely by
the drag destination BTW, that wouldn't change much compared to XDnD.
>
> I do believe any kind of popup (like a menu for choosing "move or
> copy")
> would have to be done by the target. This is because the target may
> have
> extra actions that the source does not care about or does not know
> about, such as "insert" verses "replace". The popup would grab the
> keyboard focus but when dismissed it may go back to a different
> client
> than the target.
>
Agreed about the grabbing behavior, I'm unclear though on how would
the actions in such popup work in your proposal:
Say you start a drag with the special "ask" modifier, and the drag
source changes its action list to convey "ask" (how exactly? is this
the only option exposed?). When the destination shows the popup, how
does it tell the source of the chosen action, so that eg. the
selection is deleted after "move"?
Cheers,
Carlos
[1] I'm actually meaning to propose some doc updates with more
consistent guidelines for grabbing behavior, IMO how do keyboard/touch
devices behave during the various pointer "grabs" is somewhat
underdocumented...
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
