Hey there, 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. I'm however not too thrilled about reusing leave events for these situations, my reasons: - 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. - 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. - 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. 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. 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. Cheers, Carlos Carlos Garnacho (1): protocol: Define further the behavior of input on the presence of grabs protocol/wayland.xml | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) -- 2.5.0 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
