Again this seems excessively complicated, requires lots of communication
long before the lock happens, makes the methods used to trigger the lock
very limited and dependent on compositor features, and it does not look
like it is possible to avoid an unwanted blink in the cursor.
- Client must sent the lock_pointer immediately on startup, but also
resend it after each lock is lost. This just seems strange and unbalanced.
- Client has to destroy the (unused) locked_pointer object and send a
new lock_pointer request when the widget layout changes. This is a lot
of overhead, and also somewhat painful for some toolkit designs, and it
just seems wrong for clients to have to send widget layout to the
compositor.
- Client has no choice about what triggers the lock other than the
region sent with the lock_request. In particular shift keys or different
mouse buttons cannot change it.
- I think there are race conditions when new lock_pointer requests are
sent. Probably solvable by allowing them while the previous
locked_pointer object still exists (it just cancels it) but this is
worrisome.
- The client must hide the cursor and draw a fake one. This will blink
as there is no synchronization between changing the cursor image and
mapping another surface. And it means that the client cannot take
advantage of any hardware acceleration the compositor applies to the
cursor. Toolkits have to implement two different methods of changing the
cursor image, too.
- I am utterly mystified about the "confine" object as it appears it
does nothing that cannot be done with your "lock" object and the client
moving a fake cursor, restricting the position to being inside the
confine region.
Here is my variation, this is identical to what I have suggested several
times before but I will try to update the terms to match what you have:
- The lock_pointer request is sent in response to a triggering event,
such as a mouse-down inside the region. It does not have a region
argument, but does have an event serial so the compositor can identify
the triggering event. The compositor can then decide to grant or refuse
the lock, or even popup some user interface to allow the user to choose.
- There is no "locked" event, only an "unlocked" event. If the
compositor refuses the lock it sends the unlocked event immediately.
- Remove the "_hint" from the name of "set_cursor_position" request, and
make it actually move the cursor. The mouse x/y events reported to the
client are the same as you have them, they do not jump to this position
until the lock is destroyed (and only if the device is relative). Note
that if the client hides the cursor they have EXACTLY the same api as
you are proposing, perhaps that will make it clear what I am requesting.
- Remove confine_pointer request and confined_pointer object. Instead
the client uses lock_pointer and locked_pointer, and uses
set_cursor_position to place the cursor inside the confine region. This
allows the region to be arbitrarily complicated (like have holes in it
or have a slower-motion area near the edge or restrict the mouse to the
surface of a 3D tumbling sphere).
- (Maybe) Add an argument to lock_pointer to reuse the normal grab
machinery such that release of all the mouse buttons will automatically
cancel the lock. The reason for this is to avoid round trips by reusing
code that is in the compositor anyway.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
