diff options
author | Kristian Høgsberg <krh@bitplanet.net> | 2010-08-25 16:34:05 -0400 |
---|---|---|
committer | Kristian Høgsberg <krh@bitplanet.net> | 2010-08-25 16:34:05 -0400 |
commit | 1d7ffd32f8cb769a2713d5f334da17a9e1f7f823 (patch) | |
tree | 31503eda7e88d0fdb7cf47e96b930ff12537b61d /TODO | |
parent | 8a4087164587b48ae34e421b5b3f90b5f6d4650a (diff) |
Set pointer image only in response to 'target' event
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 20 |
1 files changed, 0 insertions, 20 deletions
@@ -16,26 +16,6 @@ Core wayland protocol - DnD issues: - How to roboustly handle failing drag, ie the case where an - application gets a button event, tries to activate a drag, but when - the server gets the drag request, the button has already been - released and the grab is no longer active. What's the concern: - - - Application may set a drag cursor that doesn't revert back, - since a failed drag doesn't result in a pointer_focus event to - give focus back to the surface. We could just do that: if the - pointer_focus is the same surface as we tried to start a grab - for, just remove and give back pointer_focus. - - Alternatively, set drag cursors only in response to drag events, - like drag focus. But drag_focus and drag_motion are sent to the - drag target, so the source surface won't always get those. We - may also end up setting the cursor after the drag ends, but in - this case the drag started and ended and we'll get a - pointer_focus event, which will make the application reset the - pointer image. Could introduce a drag start event that - indicates that the drag active. - How to handle drop decline (accept with type=NULL) - Targets must send a NULL type in accept if they don't accept a |