On 01/01/2016 08:54 AM, Daniel Stone wrote:
I almost wonder if we couldn't make peoples' lives easier by merging
locking and confinement into a single interface, adding a bool for
whether or not to allow pointer movement (confine) or not (lock). Or
perhaps, rather than a bool, we could add an allow-null
wp_relative_pointer argument instead: gives you lock if non-null, or
confine if null.
Yes please merge these two almost-identical apis into a single one. Base
it on the confinement version. This already allows the client to update
the confinement region as often as wanted. A zero-sized region can force
the cursor to be at a particular point, which is what the pointer lock
does (with my oft-requested enhancement that the normal cursor-setting
code can be reused to set the cursor image).
If you want to duplicate the almost-useless current pointer-lock, the
client can just hide the cursor, and make a fake one using a new
surface. Setting the region also sets the "hint" as he calls it.
Also, for symmetry with wp_relative_pointer, should this take a
wl_pointer instead of wl_seat?
Seems like a good idea
+ If the compositor decides to unlock the pointer the unlocked event is
+ sent. The wp_locked_pointer object is at this point defunct and should be
+ destroyed.
Egads. :( This is a bit hostile - what's the harm in allowing latent
objects to remain?
I think he is just trying to say that the object is now useless. The
client does not have to destroy it, but it probably should.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
