[11:34] <alan_g> duflu_: @scene-can-identify-surface-under-cursor would you be happy if I renamed the function surface_visible_at()?
[11:35] <duflu_> alan_g: Don't think so. Because the answer is incorrect if that point has transparent pixels (which are meant to be communicated via input_area_contains in theory)
[11:35] <alan_g> But for click select, drag and resize I want to include decorations - not just the input area
[11:36] <alan_g> Or do I misunderstand "input area"?
[11:37] <duflu_> alan_g: You mean the usual Alt+mouse?
[11:37] <alan_g> yes
[11:38] <duflu_> alan_g: Unfortunately I think tiling would require the rectangle and free floating windows should honour the shape properly, maybe
[11:42] <duflu_> alan_g: I think input_area is meant to follow the non-transparent shape of the surface. If so use that. But it might be meant for something else...?
[11:42] <duflu_> You can't automate keeping them in sync because that would involve reading all pixels on every frame
[11:42] <duflu_> So the client is meant to do it traditionally, somehow
[11:46] <duflu_> OK, that's late enough
[13:16] <alan_g> anpok_: got your answer now? https://code.launchpad.net/~mir-team/mir/add-keymap-change-support/+merge/248719
[13:34] <anpok_> alan_g: yes
[17:08] <racarr> text standup: Moving pointer enter/exit event synthesis from input dispatcher to pointer controller.
[17:08] <racarr> to fix 2 remaining bugs
[17:09] <racarr> one of which includes...emittingpointer enter/exit events in response to sce3ne changes
[17:09] <racarr> instead of input changes
[17:09] <racarr> the input dispatcher doesnt even track the location of the cursor as it stands though
[17:09] <racarr> so decided to go for thissplit rather than add another input dispatcher responsibility