diff options
| -rw-r--r-- | TODO | 39 |
1 files changed, 0 insertions, 39 deletions
@@ -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). |