diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 47 |
1 files changed, 45 insertions, 2 deletions
@@ -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 |