Hi, On 20 November 2015 at 03:47, Peter Hutterer <[email protected]> wrote: > On Thu, Nov 12, 2015 at 01:27:05PM +0100, Carlos Garnacho wrote: >> - 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. > > as for pointer and keyboard leave events, afaict the ship has sailed on this > and this has been the behaviour for long enough that your additions just > document the current behaviour. Any change will likely break things, so > documenting the cases where a button or key release event gets left hanging > seems the only solution.
Regurgitating Bill's suggestion in a more constructive manner: If this does pan out for touch events, are we able to encode leave/enter/frame grouping for keyboard and pointer, so clients can discover focus transitions? I think it's a pretty elegant solution to the problem. Cheers, Daniel _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
