Resending from the right address... Hi Bill,
On Mon, Feb 16, 2015 at 10:17 PM, Bill Spitzak <[email protected]> wrote: > I would think the drop target client can figure out what action to perform, > there is no need to communicate it's set of actions to the compositor or for > the compositor to have any of this logic to "determine the action both parts > agree on". I unfortunately think such simple approach won't cover all usecases I'm intending to, most notably the user role in action selection. On XDND, it is the DnD source app which keeps keyboard/pointer grabs, and orchestrates all DnD message interaction with the DnD destination, all it must do there is updating the "suggested action" based on the currently pressed modifiers. On wayland, it is true that the semantics of compositor-side device grabs are mostly up to the compositor, but delegating this on the destination client means we need to start sending wl_keyboard.modifiers to random unfocused clients. Compositors may also want, for accessibility reasons, to let DnD to be driven by keyboard (eg. cursor keys), so you end up performing selective treatment of key events, I hope you see why I think this soon becomes irksome. With my proposed action system, in exchange for having the compositor play a minimal role in this (basically ANDing the options and picking one), we get the compositor doing all of this, and clients sticking to wl_data_[source|offer] events/requests, which I find more consistent. > > The drop target will have to say what action it did. It also sounds like you > are concerned that the source may want to know the action on drag events so > the source can update the cursor or redraw the source location to show the > result of the action. But this is only one action, not a list. Yes, the "action" events must have just one bit set, after the compositor picked the current action. The cursor icon would be something that changes during the DnD operation, say attempting a drop on local vs remote drives on the file manager (with different move vs copy preferred actions), or user modifications. > > So basically it seems like any lists from the drop target can be avoided. > The drop target would only send a single action. It could, if it were to know the available actions from the drag source. Given my concerns with the move/copy/ask semantics, I preferred to keep both isolated in that regard. Matching the actions in the compositor also gives a solid place where you can just emit wl_data_source.cancelled on failed drags, which is not as clear if the compositor is merely the carrier here. > > The compositor can throw a protocol error if the client sends an action that > is not in the list. Or it could just convey it right through and let the > drag source client ignore it. On this proposal, the drag source would recevice wl_data_source.action with 0, it may also want to set the pointer surface to a "forbidden" sign or somesuch. Carlos _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
