[PATCH] protocol: Add DnD actions

[Bill Spitzak]

On 04/16/2015 03:55 AM, Carlos Garnacho wrote:

> In gtk+/gnome we currently have the following keybindings active during DnD:
>
> - Cursor keys move the drag point, modifiers affect speed
> - Esc key cancels drag
> - Modifiers alone pick an action from the offered list

The user has to hold the mouse button down during these? That does not 
sound very useful. Or is it possible to start DnD with a keystroke? 
What happens then if the user moves the mouse or pushes the mouse button?

I really need a clearer explanation of these keystrokes. I suspect some 
requirements of implementing things on X are leaking into your 
description, and you are talking about a global handicapped-assistance 
api (which I agree would be done by the compositor, but applies 
everywhere, not just DnD).

> So ok, the latter is dubious to punt to compositors, but there's
> basically no other choice with the 2 first ones.

It can be handled by either the source or dest getting a grab and 
responding to the key events with some new api that manually moves the 
drop target. In fact there is a lot of proposed things for the grab to 
be able to completely control the cursor position, this would be another 
one.

I do agree that making Esc cause the compositor to cancel a grab 
unconditionally is an acceptable idea. If you don't have to hold down 
the mouse to do DnD, or if there is no position on the screen that you 
can drop without anything happening, then this is necessary.

It does seem like the source getting the keyboard drag is consistent, 
and match how dragging any other part of the source's ui works.

However I think it will work better for the destination to get the grab. 
This is because the destination has a more complex job, including 
actions that the source does not need to distinguish (insert vs replace, 
link vs copy), and if there is a popup menu to let the user choose the 
action they will think it is part of the destination and it would look 
far better if it was drawn with the destination's style, and user 
preferences for it are set on the destination.

So during a DnD the keyboard focus should be (in effect) point-to-type. 
I don't think it should get mouse enter/exit/move events, instead the 
drag enter/exit/move would replace them. There will unfortunately have 
to be a keyboard focus-in event as that is the only way to communicate 
the current keymap to the client (it may be useful to add an event for 
that as there already is the problem where the compositor eats 
keystrokes, but can't tell the client about the new keymap without a 
fake exit/enter).

I think both the source and destination should be able to modify the 
cursor. If the destination says it will accept the drop then it is it's 
job to update the cursor, as it may modify it to show clearly what will 
happen (for instance it may update it's own display to show the result 
of the drop, and change the cursor to just the pointer). If it says it 
won't, then the source sets the cursor to it's default version. Race 
conditions with this idea need to be solved...