=== JanC is now known as Guest42627
=== JanC_ is now known as JanC
=== chihchun is now known as chihchun_afk
[12:44] <alan_g> anpok: another question about SurfaceInputDispatcher. In drag&drop was expecting a leave event when the cursor drags out of the source target. But AFAICS that only gets sent if no buttons are pressed. Is there a valid reason for that behaviour?
[12:44] <alan_g> (I know you didn't write this code but racarr isn't about to ask.)
=== dandrader is now known as dandrader|afk
[13:07] <anpok> alan_g: hm do we keep sending input events if there are buttons pressed?
[13:07] <anpok> to the window
=== dandrader|afk is now known as dandrader
=== hikiko is now known as hikiko|bbiab
[13:41] <alan_g> anpok: SurfaceInputDispatcher.gestures_persist_over_button_down says "yes"
[13:43] <alan_g> But I don't get why.
[13:44] <anpok> alan_g: so afaiu when you press a button the window owns the guesture until release.. hence the leave is only sent when all buttons are released
[13:44] <anpok> so it keeps receiving the motion events even when you leave the window..
[13:45] <anpok> when there is no owner because the button was not pressed it should sent the leave event the instant you leave the window..
[13:46] <anpok> the why is probably about menues.. and existing x11 behavior..
[13:47] <anpok> you dont want mouse interactions to directly end when you accidently leave the window .. the accidently here is identified through button state..
[13:48] <alan_g> That makes sense. But so does "drag" leaving.
[13:49] <alan_g> Hmm... I guess I need to introduce another case.
[13:50] <anpok> hm so a different state from in-guesture to in-drag  with different rules for pointer dispatch
[13:52] <alan_g> yeah. Feels messy but what choice is there.
=== hikiko|bbiab is now known as hikiko
=== dandrader is now known as dandrader|afk
[16:20] <attente> alan_g: hi, i'm looking at https://bugs.launchpad.net/ubuntu/+source/gtk+3.0/+bug/1669524 (and https://bugs.launchpad.net/mir/+bug/1420334 by extension). sorry i didn't reply to your original question, but can we still get the necessary client api to help implement those functions (always on top, client-side move/resize)?
[16:20] <ubot5> Ubuntu bug 1669524 in mir (Ubuntu) "GTK window functions `Always on Top, Move and Resize' don't work in Mir/Unity8" [High,Triaged]
[16:20] <ubot5> Ubuntu bug 1420334 in xorg-server (Ubuntu) "[enhancement] Missing client API for relative surface movement (e.g. dragging client-decorated windows)" [Wishlist,Triaged]
[16:25] <alan_g> attente: the move API is on the "wishlist" (i.e. not yet moved to "backlog"). You want an "always on top" and "init resize" too?
[16:29] <attente> alan_g: yes please to "always/keep on top". by "init resize", do you mean initial resize event? i've worked around that so it's not as important now, just requested the size on window creation instead
[16:31] <alan_g> I mean initiate a resize gesture
[16:32] <attente> alan_g: oh. ok, yes please to that too :)
[16:56] <anpok> just another drag state
[16:57] <anpok> *states
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader