On 01/03/2016 08:21 PM, Peter Hutterer wrote:
On Fri, Jan 01, 2016 at 04:54:14PM +0000, 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.
you get a much less expressive API, less checking, etc. for a fairly minimal
benefit. Furthermore, any extension to *either/or* the lock/confine
interface would need to handle the appropriate NULL cases for the other
interface. Right now we can easily add a locking-specific request without
messing up the logic of the confinement, and vice versa.
You have a confinement protocol where the client updates a region to
move the cursor.
You have the lock protocol where the client updates an x/y and it moves
the cursor (though you call it the "hint" and it does not move the
cursor until after the lock is destroyed, but since this is useless
unless the client hides the cursor, the behavior would be identical if
it moved the cursor immediately).
An x/y position is a degenerate region.
Therefore the two are the same, provided you let the lock version
actually move the cursor, rather than it being a "hint". Which would be
incredibly useful, too!
Also, for symmetry with wp_relative_pointer, should this take a
wl_pointer instead of wl_seat?
you'd be restricting locking and confinement to a pointer device, with a
wl_seat you can confine and lock devices that are not wl_pointer devices,
e.g. a wl_tablet tool in relative mode.
I'm pretty certain that would provide a wl_pointer. Absolute mode maybe
I could understand, but not relative.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
