[PATCH] protocol: Add DnD actions
spitzak at gmail.com
Thu Apr 16 13:14:36 PDT 2015
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
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
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...
More information about the wayland-devel