[PATCH wayland-protocols v2 2/2] Introduce pointer locking and confinement protocol

[Daniel Stone]

Hi,

On 12 January 2016 at 22:28, Bill Spitzak <spitzak at gmail.com> wrote:
> There should *only* be "one shot" requests, which are very quickly accepted
> or denied by the compositor. The client creates it in response to an input
> event, and it includes the input event id.
>
> Most/all things that triggers pointer lock (the mouse entering the region,
> the mouse being pressed in the region, a press+release in the region, a
> keystroke) could be implemented by clients and it does not do any pointer
> lock protocol until after it has detected the triggering event, and thus can
> include the event id.

For what it's worth - post-hoc expansion on my reasoning - I think
Bill has the genesis of a point here. Usually, our requests have
followed one of two patterns: either you request activation in
response to a specific event (button or key event allows you to create
a selection), or retained state (creating a wl_data_device gets you
selection/etc events on that seat until you destroy it).

The proposed one-shot-but-delayed request to me felt like a really
awkward compromise between the two, and not really one backed up by a
strong enough usecase to justify a third (delayed but not retained)
model for requests taking effect.

It's entirely possible that there's something I'm missing here, but
for consistency if nothing else, having the split instead be between
these two classic methods (oneshot-immediate vs. fully-retained,
rather than oneshot-delayed vs. fully-retained) could be good for
future versions.

Cheers,
Daniel