<div dir="ltr">On Thu, Jun 25, 2015 at 9:38 PM, Jonas Ã…dahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This version adds support for changing the lock/confine region after the<br>
lock was created.<br>
<br>
For pending wl_confined_pointer lock, the effect is the same as for<br>
wl_locked_pointer. But for an already activated confinement, it affects the<br>
pointer, i.e. warps the pointer to somewhere within the region.<br></blockquote><div><br></div><div>You do realize you have provided exactly what I have been requesting. The client can now move the cursor arbitrarily around by sending 1x1 confinement regions. IMHO it would make more sense to fix the "hint" call to do the same thing so you reduce the size of the code.<br><br></div><div>I am primarily concerned with reusing this api for "slow sliders", and for more complex transformation of 2d movement to screen position, such as locking the cursor to the surface of a rendered trackball. I believe it can be done with the following changes:<br><br>- Replace set_cursor_position_hint with set_cursor_position. The result is identical to setting the confine region to a very tiny one such that the cursor cannot move. Note that this will not break anything: your current api requires the client to hide the cursor, so the fact that this actually moves it will not be visible!!!<br><br></div><div>- Add a third method to _wl_pointer_lock of making a lock that expires when the mouse button is released (it is destroyed by exactly the same rules as the automatic grab is expired). It takes an event identifier to indicate which mouse button press it is for. Creation of this immediately activates it (I'm not sure if the activation event should be sent or implied), then deactivates it when the button is no longer pushed.<br><br></div><div>You should also merge the _wl_locked_pointer and _wl_confined_pointer objects since they are nearly identical. The result has both "set_cursor_position" and "set_region" methods. set_cursor_position is exactly the same as setting a very tiny region (in case you are wondering what it should do before "activation").<br><br></div><div>A fourth type of lock may be useful, too, though I am not very sure how it should work. This is to allow the client to position the cursor in sync with it's drawing even when the mouse is not held down. The difference is that this lock is lost on an exit event, and something is done so that a client continuously warping the cursor to the middle of the surface cannot prevent these exit events. The idea is that this is somewhat less dangerous than your original locking and thus the compositor is more likely to grant it. This locking is useful for highlighting fine detail to show what will be selected on click.<br><br></div></div></div></div>