Hi, On Thu, May 3, 2018 at 10:53 PM, <l...@protonmail.ch> wrote:
> I propose removing the concept of persistent pointer constraints and > lifetimes in the pointer constraints protocol. > > This would vastly simplify the implementation of the protocol in the > compositor, but slightly increase the complexity in the client. > > > Benefits: > > The compositor wouldn't have to keep track of pointer constraints for each > valid surface, > since only one pointer constraint could then exist per seat. > > The compositor would also not have to actively check the position of the > pointer on the surface, since if it is inactive, it does not exist, and can > therefore not be reactivated, so it is not needed to check if the pointer > is in the region of a pointer constraint. > > This would also allow the removal of regions for locked pointers, since > then only confined pointers would make use of them. > > Detriments: > > The client would have to recreate the pointer constraint each time the > pointer enters the valid region, instead of just making a persistent > pointer constraint. > This is very simple for previously NULL regions, since you can just > recreate it on each pointer enter event, although it's a bit more complex > for complex regions, since the client will have to handle that itself now. > So if I understand correctly, you'd keep only “oneshot” and that would be implicit? The concept of “lifetime” appeared in v3 of the protocol review as found here: https://lists.freedesktop.org/archives/wayland-devel/2016-January/026520.html That explains why there are two different “persistent” modes and which kind of race condition each one induces. Cheers, Olivier
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel