Hi,
On 30 November 2015 at 03:25, Peter Hutterer <peter.hutte...@who-t.net> wrote:
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index f9e6d76..370fafc 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -1350,6 +1350,24 @@
> This is emitted whenever a seat gains or loses the pointer,
> keyboard or touch capabilities. The argument is a capability
> enum containing the complete set of capabilities this seat has.
> +
> + When the pointer capability is added, a client may create a
> + wl_pointer object using the wl_seat.get_pointer request. This object
> + will receive pointer events until the capability is removed in the
> + future.
> +
> + When the pointer capability is removed, a client should destroy the
> + wl_pointer objects associated with the seat where the capability was
> + removed, using the wl_pointer.release request. No further pointer
> + events will be received on these objects.
These are good! (Except the last sentence - see below.)
> + If a seat regains the pointer capability and a client has a pointer
> + object obtained previously, that object may start sending pointer
> + events. This behavior is implementation-dependent and must not be
> + relied upon.
Urgh, I don't really like having this there as a bit of a get-out
clause. Can we just strengthen the 'client should destroy the
wl_pointer objects' to a 'must'? Especially since this paragraph
contradicts the immediately previous one ('No further pointer events
will be received on these objects'). Maybe we could fold bits of this
paragraph in to replace that problematic sentence, but couple with a
recommendation that compositors should not send events to stale
objects - and bump that to a must for compositors advertising whatever
our next version of wl_seat ends up being.
The rest looks good though.
Cheers,
Daniel
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
