GNOME Bugzilla – Bug 735831
Change current cursor on grabs
Last modified: 2014-09-01 18:49:21 UTC
gdk_device_grab() has a GdkCursor argument that specifies the cursor that will be shown during the grab operation, this is not honored yet on Wayland though. I'm attaching a couple of patches that makes the wayland backend store the cursor that applies during the current grab operation separately, so the cursor can switch back and forth to the one specified for the GdkWindow after grab/ungrab.
Created attachment 285042 [details] [review] wayland: Keep the last cursor on leave, try to restore it on enter On DnD, pointer_handle_leave may be triggered without the pointer actually leaving the window, and pointer_handle_enter() happening after intra-window DnD won't actually manage to update the cursor (it does nothing directly, and to the upper layers the cursor is still the same and consistent, so no attempt will happen). To fix this, keep the pointer cursor on leave, and ensure it is updated on enter. The pointer cursor will be updated to any current new one through the enter/motion events generated if it needs be.
Created attachment 285043 [details] [review] wayland: Store and use the current grab cursor, if any Only static cursors are supported in gdk_device_grab() so far. Obey the cursor that gdk_device_grab() specifies, which may be different to the pointer window one. As soon as the grab is gone, the pointer window cursor will be restored as usual.
Review of attachment 285043 [details] [review]: The problem with allowing animation is that we don't know when to stop the animation ? Anyway, looks good so far
Review of attachment 285042 [details] [review]: if we can't trust leave to actually mean leave, we have a problem with knowing when to stop the cursor animation, I guess ?
(In reply to comment #3) > Review of attachment 285043 [details] [review]: > > The problem with allowing animation is that we don't know when to stop the > animation ? > Anyway, looks good so far The GdkWaylandDeviceData also stores a cursor_image_index for the window cursor, so it knows the "frame" it's in, I'd have to replicate that for the grab cursor, which wasn't too clean. I think a better fix would be to store that into GdkWaylandCursor instead, and have a gdk_wayland_cursor_tick() call that bumps the current cursor frame, that way both cursors could be animatable. (In reply to comment #4) > Review of attachment 285042 [details] [review]: > > if we can't trust leave to actually mean leave, we have a problem with knowing > when to stop the cursor animation, I guess ? I at the moment made it so the animation is stopped inconditionally, you either truly leave the window, or get a different cursor used instead with the other patch. If cursor animation is always made to run dependent on the currently set cursor, and cursors are reset to their first frame when going unused, I think that should make the timer run whenever really necessary, and all cursor animations look consistent. Anyway, all of this is probably better tackled separately.
Attachment 285042 [details] pushed as 2c71b8f - wayland: Keep the last cursor on leave, try to restore it on enter Attachment 285043 [details] pushed as d5dae5b - wayland: Store and use the current grab cursor, if any