Hi, On 12 January 2016 at 22:28, Bill Spitzak <spit...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
