<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 30, 2015 at 3:32 PM, Peter Hutterer <span dir="ltr"><<a href="mailto:peter.hutterer@who-t.net" target="_blank">peter.hutterer@who-t.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Nov 30, 2015 at 09:46:36PM +0000, Daniel Stone wrote:<br>
<br>
> > +       If a seat regains the pointer capability and a client has a pointer<br>
> > +       object obtained previously, that object may start sending pointer<br>
> > +       events. This behavior is implementation-dependent and must not be<br>
> > +       relied upon.<br>
><br>
> Urgh, I don't really like having this there as a bit of a get-out<br>
> clause. Can we just strengthen the 'client should destroy the<br>
> wl_pointer objects' to a 'must'? Especially since this paragraph<br>
> contradicts the immediately previous one ('No further pointer events<br>
> will be received on these objects'). Maybe we could fold bits of this<br>
> paragraph in to replace that problematic sentence, but couple with a<br>
> recommendation that compositors should not send events to stale<br>
> objects - and bump that to a must for compositors advertising whatever<br>
> our next version of wl_seat ends up being.<br>
<br>
</div></div>if the per-version behaviour works correctly we can add this, otherwise we<br>
still have to keep this paragraph in, otherwise we're retroactively<br>
disallowing current working implementations. The same goes for the<br>
should/must, we already have implementations doing this.<br></blockquote><div><br></div><div>I don't think you want this text. An existing implementation that sends pointer events after the loss/gain is broken. People wrote lots of other bugs into existing implementations, that does not mean all descriptions have to allow any existing bug.<br><br></div><div>A more practical reason for being more insistent is that if a popular compositor does this, it is quite likely to be relied on by some clients (due to the fact that it is much easier to write a client that relies on this), quickly leading to this being a required behaviour of all compositors. Explicitly saying that is wrong may encourage the compositors to not do this, though of course it does not guarantee it.<br><br></div></div><br></div></div>