Hi Carlos, On 12 November 2015 at 12:27, Carlos Garnacho <[email protected]> wrote: > I think it is worth to bring back some discussion on the client-side > behavior during compositor grabs which I started a few months ago, for > reference the thread started at: > http://lists.freedesktop.org/archives/wayland-devel/2015-April/021407.html > > And the first patch sent was: > http://lists.freedesktop.org/archives/wayland-devel/2015-June/022520.html > > This patch I'm sending is the result of discussion in that last thread, > it further documents leave events so it is made clear how to deal with the > cases when input is taken away from the surface, and adds a missing > wl_touch.leave event, so there's means to "cancel" individual touch points.
Thanks for revising this! > I'm however not too thrilled about reusing leave events for these > situations, my reasons: Hmm. I think it does make sense: leave means that the surface no longer has the focus. In particular, it means that events on that device (those devices) may happen without your knowledge. It's a good signal that you can no longer expect the state to be coherent with the event stream you're receiving. > - Even if these were the intended semantics, everyone (including weston) is > getting this wrong, so this is effectively a behavior change that > compositors and toolkits do need to adapt to. Hm, ouch. How is Weston getting this wrong at the moment? Is because it forwards the release events? > - The fact that this is just a footnote in docs will make it easy to miss, > so there will be a time when compositors jumping early on this will confuse > the hell out of clients that didn't adapt yet. Sure, but to be fair, we really need to do a better job of - as Peter suggested - the prose section of our documentation. Extensive notes in each protocol is all good and well, but someone writing a compositor will anyway desperately struggle with how to put everything together. > - There are grabbing situations where the focus surfaces don't really change > within the compositor (eg. dragging a window, it will probably "have" the > keyboard focus, you however don't want keypresses to trigger anything on > the client). I admit this is an implementation detail, but temporarily > unsetting focus surfaces doesn't strike me as the best solution, plus there > are other cases where you legitimately want to move the focus to another > surface. But how else do we tell clients that the device state is likely going to be changing, in a way that it cannot inspect (until focus returns)? Especially in a backwards-compatible manner ... > My suggestion for this would be to split into a separate event per input > interface, that'd make older clients as ignorant of these issues as they are > now without actively breaking them. I'm however sending a patch as it was > suggested in the previous threads. I'm not really sure what you mean by this - can you please elaborate? > Also, I would like to document a behavior meant for grabs, i.e. For most > situations I think it makes sense for the compositor to grab not only the > pointer/touchpoint triggering the grab, but all seat devices at once, > because any of these could still be triggering stuff that renders this grab > useless (eg. triggering an xdg_popup during window dragging). I can't think > though of any place to put this piece of information, besides scattering it > across the places where we expose "grabs" in wayland/xdg_shell/... protocols, > suggestions here welcome. What Peter said. Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
