[PATCH v3 weston] Introduce pointer locking and confinement protocol

[Bill Spitzak]

On Sun, Aug 23, 2015 at 8:19 PM, Jonas Ådahl <jadahl at gmail.com> wrote:

>
> 1. the pointer "attaches" to the UI element.
>
> One would create a lock region on the scroll handle. When enabled one
> would hide the cursor, create an identical cursor surface and add it as
> a subsurface positioning relative to the scroll handle. One would now
> listen for events from wl_relative_pointer, update the subsurface
> position and the scroll handle widget under it. When done, one would
> unlock the lock, destroy the subsurface, and reset the pointer cursor.
> During the moving, one would set the cursor position hint so when
> resetting the cursor position would be updated.
>

This is the first sign that you have actually thought about this. However
you seem blind to the trivial solution. Here is my rewrite of the above
paragraph with the set_cursor_pos proposal:

"One would create a lock region on the scroll handle. When enabled one
would now listen for events from wl_relative_pointer, update the cursor
position and the scroll handle widget under it. When done, one would unlock
the lock."

This is the only way to guarantee the "attachment" effect. There is one
> unsolved issue which is that the cursor sprite and the subsurface might
> be visible at the same time, and we'd need some kind of "transaction"
> protocol to solve this. There has been ideas to have a "set_cursor_pos"
> but this method would never give us any guarantees about "attachment".
>

WTF???. Your proposal is that the client draw a fake cursor in a subsurface
and setting that to some x,y position to move the cursor. I propose that
the same x,y are sent to set_cursor_pos. THE EXACT SAME NUMBERS!  It is
impossible for "attachement" to be different between the two proposals!!!!

All I can guess is that you think that there is going to be synchronization
between subsurface positioning and the surface image, but for some reason
such synchronization will be missing for set_cursor_pos. But why? The
cursor surface belongs to the locking client just as much as any
subsurface, so any rules for subsurfaces can be applied to it as well. I'd
also like to know why suddenly this is important, when you have repeatedly
claimed that avoiding latency is more important that sync image updating.

If the client wants to control the activation, it can simply request the
> lock exactly at the point it wants it to be activated. resize.c in
> weston is an example of this - it activates the lock on a pointer button
> event.
>

This is great if it works, however I hope you realize that this will be the
ONLY way that any clients with small lock regions will turn on pointer
lock. Having to update the "activation region" for every widget on every
layout change is extremely bad, it will send large amounts of data to the
server for no reason, kind of like old X11 toolkits that sent every widget
as a subwindow. This was known to be a mistake back in the mid 80's when
lightweight widgets were added to x intrinsics.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20150824/986c4104/attachment.html>