Update TODO

TODO

@@ -21,12 +21,6 @@ Core wayland protocol
  - configure should provide dx_left, dx_right, dy_top, dy_bottom, or
    dx, dy, width and height.
 
- - surface.set_grab_mode(GRAB_OWNER_EVENTS vs GRAB_SURFACE_EVENTS), to
-   make menus work right: click and drag in a menubar grabs the
-   pointer to the menubar (which we need for detecting motion into
-   another menu item), but we need events for the popup menu surface
-   as well.
-
  - glyph cache
 
     - Needs a mechanism to pass buffers to client.
@@ -45,32 +39,6 @@ Core wayland protocol
       cache.retire: buffer /* cache has stopped using buffer, please
 			    * reupload whatever you had in that buffer */
 
- - DnD issues:
-
-    - Drag should not be tied to a source surface, just the client.
-      the grab will break if the surface goes away, but the wl_drag
-      struct doesn't need to hold on to the source surface.
-
-    - Root window must send NULL type (to decline drop) or
-      x-wayland/root-something type if the source offers that.  But
-      the target deletes the drag_offer object when drag.pointer_focus
-      leaves the surface...
-
-    - How do we animate the drag icon back to the drag origin in case
-      of a failed drag?  Client should set drag icon separately,
-      compositor can do it then.
-
-    - How to handle surfaces from clients that don't know about dnd or
-      don't care?  Maybe the dnd object should have a
-      dnd.register_surface() method so clients can opt-in the surfaces
-      that will participate in dnd.  Or just assume client is not
-      participating until we receive an accept request.
-
-    - Selection/copy+paste issues: is it sufficient to only introduce
-      the selection offer when a client receives kb focus?  Or maybe
-      it is actually a security feature?  Clipboard manager in server
-      for retained selections?
-
  - Pointer image issue:
 
     - A direct touch input device (eg touch screen) doesn't have a
@@ -108,13 +76,6 @@ Core wayland protocol
 
 Destkop/EWMH type protocol
 
- - Add protocol to let applications specify the effective/logical
-   surface rectangle, that is, the edge of the window, ignoring drop
-   shadows and other padding.  The compositor needs this for snapping
-   and constraining window motion.  Also, maybe communicate the opaque
-   region of the window (or just a conservative, simple estimate), to
-   let the compositor reduce overdraw.
-
  - Protocol for specifying title bar rectangle (for moving
    unresponsive apps) and a rectangle for the close button (for
    detecting ignored close clicks).