[PATCH weston 14/17] Introduce pointer locking and confinement protocol
spitzak at gmail.com
Mon Dec 8 11:55:29 PST 2014
On 12/08/2014 06:07 AM, Jonas Ådahl wrote:
> On Tue, Dec 02, 2014 at 02:39:21PM -0800, Bill Spitzak wrote:
>> - Does this need some id of the triggering event? Mostly to determine if the
>> surface had the pointer focus at the time the request was made.
> It does not, and the lock is postponed until that trigger event happens.
> For example a surface can lock the pointer, but the lock may not
> activate until the user clicks the surface. It should not be hard coded
> exactly what type of event should trigger a lock.
Okay I think a lot of my confusion was that I figured the pointer lock
was created in response to an event such as a button press. It sounds
like it is instead some kind of setup that a client would create asap
that means it will get the pointer lock on click.
Though I am still rather confused that the only way to "release" a
pointer lock is to destroy this object. Is the client supposed to
immediately recreate it in preparation for the next click?
Can you explain how a client would use this to make a slow scrollbar
that works like this:
1. User presses the mouse down on the scrollbar
2. Until the release the mouse it acts like it is moving much slower,
and the cursor and scrollbar move together
3. When user releases it, the cursor either continues to move at normal
speed relative to where it was, or it may jump to an absolute position
sending the correct enter/exit/move events. This can be chosen by the
compositor, perhaps depending on the input device type.
Also an explanation of exactly how an FPS shooter program will work, as
this seems to be your primary goal. It is not very clear how the game
can request that the user be allowed to click on another client, and
what the game has to do to regain pointer lock.
> Don't think it's very beneficial to add various kinds of locks that
> unlocks at specific events. The client can simply unlock on mouse
> button release. Not sure what round trip you are talking about here
The round trip is that after the mouse-up, the compositor cannot send
enter/move to the surface the mouse is over until it receives the
destruction notify from the client.
I agree this is not very important but it is how the mouse works
normally on mouse press (it's called "grab" then, but it basically is a
form of this pointer lock in that all events are sent to the first
client until release).
> Do you have a suggestion for a better wording?
Make it clear that this object is not in *response* to the lock-causing
event, but instead a setup that, I guess, a client does immediately
after creating the surface and immediatly after any release.
Examples of the slow scrollbar and fps shooter would help a lot.
> The pointer is only potentially warped when unlocking
Your docs claim the cursor is moved when locking.
> We don't want clients to control the cursor position. If the client
> really wants to be in control, it should lock the pointer, hide the
> cursor, and then draw its own cursor sprite, either as part of its own
> scene, or as a subsurface.
That will blink unless api is added to lock a change in cursor image to
the showing of another surface. Seems really complicated.
I also find it rather incredible that clients can assume they can change
the cursor image, including hiding it, but are not allowed to assume
they can move it!
More information about the wayland-devel