First step towards drag and drop protocol

1 files changed, 45 insertions, 2 deletions

diff --git a/TODO b/TODO
index 820288a..5cb6ab4 100644
--- a/TODO
+++ b/TODO
@@ -1,7 +1,7 @@
 Core wayland protocol
 
- - generate pointer_focus on raise/lower, move windows, all kinds of
-   changes in surface stacking.
+ - generate pointer_focus (and drag focus) on raise/lower, move
+   windows, all kinds of changes in surface stacking.
 
  - glyph cache
 
@@ -9,10 +9,53 @@ Core wayland protocol
    pass an fd through the compositor to the other client and let them
    sort it out?
 
+ - 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
+      drop at the drag_focus/drag_motion position.  Root window will
+      send a NULL type or x-wayland/root-something type if the source
+      offers that.
+
+   Races between pointer motion, ending the drag, the target sending
+   accept request and the source receiving the target event.
+
+    - We've sent a drag focus or motion event to the source, but
+      haven't received an accept request corresponding to that event
+      and now the button is release.  The compositor could wait for
+      the source to reply to outstanding focus/motion events before
+      sending the finish event to the source.  Or we could send the
+      finish event through the source so that it needs to reply to the
+      finish event too.  Either way, the state of the drag blocks on
+      the client.  What if we drag to a client that doesn't doo dnd?
+
  - copy-n-paste, store data in server (only one mime-type available)
    or do X style (content mime-type negotiation, but data goes away
    when client quits).
 
+ - Optional pointer images.
+
  - Discard buffer, as in "wayland discarded your buffer, it's no
    longer visible, you can stop updating it now.", reattach, as in "oh
    hey, I'm about to show your buffer that I threw away, what was it