Lifetime of wl_seat objects (was Re: [PATCH wayland-protocols 1/2] Introduce wp_relative_pointer) interface

[Daniel Stone]

Hi,

On 24 November 2015 at 06:39, Jonas Ådahl <jadahl at gmail.com> wrote:
>> > Meh. This just spells out what weston does, and then asks clients not to
>> > rely on it. Spelling it out that it might work I suspect will just
>> > confuse users.
>>
>> I'm aware of that, but the important bit here is that *it spells it out*.
>> without this blurb, handling of capability events is left open for
>> interpretation. with this blurb, you get exactly two options for each case
>> and one is listed as "don't rely on it" (but we can't remove it for client
>> breakage).
>
> I see your point, but don't we have these two options just because we
> looked at two implementations only? Anyway, if we're to spell out these
> two possibilities, I think we should make it more clear that
> object-may-wake-up-again case really is an unreliable implementation
> detail.

As you say, this is the situation we're stuck with today, so we have
to acknowledge it, but also guiding both sides (clients and
compositors) towards the best compromise behaviour. Which, in this
case, is the most restrictive, i.e. Mutter-style.

> It might be a matter of taste, but I consider writing things like below
> makes it more clear that reusable pointer objects are unreliable and
> should not be used:
>
>
>         When the pointer capability is added, a client may create
>         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. The client cannot on rely ever receiving
>         any pointer events on existing wl_pointer events at this time.
>
>         Whether an existing wl_pointer will start emitting events when
>         the pointer capability is added to the corresponding seat is an
>         implementation detail and should not be relied on.

Sounds a bit too tempting to clients: please see my bikeshed to
Peter's separate patch.

Cheers,
Daniel