| === JanC is now known as Guest42627 | ||
| === JanC_ is now known as JanC | ||
| === chihchun is now known as chihchun_afk | ||
| 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.) | 12:44 |
| === dandrader is now known as dandrader|afk | ||
| anpok | alan_g: hm do we keep sending input events if there are buttons pressed? | 13:07 |
| anpok | to the window | 13:07 |
| === dandrader|afk is now known as dandrader | ||
| === hikiko is now known as hikiko|bbiab | ||
| alan_g | anpok: SurfaceInputDispatcher.gestures_persist_over_button_down says "yes" | 13:41 |
| alan_g | But I don't get why. | 13:43 |
| 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:44 |
| 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:45 |
| anpok | the why is probably about menues.. and existing x11 behavior.. | 13:46 |
| anpok | you dont want mouse interactions to directly end when you accidently leave the window .. the accidently here is identified through button state.. | 13:47 |
| alan_g | That makes sense. But so does "drag" leaving. | 13:48 |
| alan_g | Hmm... I guess I need to introduce another case. | 13:49 |
| anpok | hm so a different state from in-guesture to in-drag with different rules for pointer dispatch | 13:50 |
| alan_g | yeah. Feels messy but what choice is there. | 13:52 |
| === hikiko|bbiab is now known as hikiko | ||
| === dandrader is now known as dandrader|afk | ||
| 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:20 |
| 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:25 |
| 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:29 |
| alan_g | I mean initiate a resize gesture | 16:31 |
| attente | alan_g: oh. ok, yes please to that too :) | 16:32 |
| anpok | just another drag state | 16:56 |
| anpok | *states | 16:57 |
| === 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 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!