=== chihchun_afk is now known as chihchun [07:24] RAOF: are you about? [07:25] alan_g: Yes! [07:25] Do you have thoughts about the placement information we should share with clients? [07:27] Yes. [07:28] For the popup positioning case we need to tell them where (relative to the parent) we placed it. [07:28] Policy says we can't tell them screen position, information about avoiding edges could be used to probe this. [07:28] So they can render correctly. [07:30] So, you would send an "it's here" rectangle? [07:30] They *could* use this information to guess where their surfaces are relative to the edge of the screen, but there's nothing guaranteeing that we *only* move surfaces to avoid screen edges. [07:31] I would send a ‘here's the top-left’ relative to your parent, because they already know the size, but an “it's here” rectangle would also be fine. [07:31] @moving surfaces: lp:1616818 [07:32] Ack, we already send resize. [07:33] So a client could create a fullscreen surface, never paint it, and place everything WRT that. [07:34] And know where all its "real" surfaces are [07:35] Correct. [07:35] That is an excellent bug! [07:36] Clients can even cut holes in their input surface to let input pass through, so a client drawing on a fullscreen-transparent surface can even behave semi-reasonably. [07:37] I'm not sure The Architect would approve [07:38] Oh, a client doing that is transparently (hah!) unreasonable. [07:38] But it's not something we can easily forbid. [07:39] It's not (to my knowledge) a security problem, and it's not something normal clients would actually bother to do. [07:40] If it is not forbidden someone will rely on it. [07:41] Any toolkit that assumes absolute co-ordinates can get them by a simple hack. That's easier than doing the "right thing". [07:43] Is it simple? They need to construct a fullscreen window and then do all their drawing on it. [07:44] And then they need to handle drags themselves by rendering their window in a different place on their fullscreen surface... [07:44] No, they just need create a fullscreen window and place every other window on it [07:45] If they never paint that root window it never affects input and never gets drawn [07:45] If they never paint it they never get to attach surfaces to it? [07:45] Also, you can only attach surfaces of type tip? [07:45] And you can't morph tip→normal. [07:48] To be clear: you only get ‘here's the top-left’ when you're placing a surface relative to another, and you can't do that for most surface types. [07:49] "most" being less than half of MirSurfaceType? ;) [07:49] But I see the point [07:50] Well, you can't place normal surfaces or (I think?) anything that can morph to normal surfaces relatively. [07:50] Placement only works if there's a parent [07:50] And we have rules for that [07:51] I would also be happy to restrict placement to fully-constructed (ie: with content) surfaces. [07:52] Doesn't really help: it can have a bufferstream with a single transparent(?) pixel [07:53] It then eats input. [07:53] Unless it shapes that away, of course ;) [07:53] And bufferstreams can be lightyears from the surface [07:53] * alan_g isn't convinced by that "feature" [07:54] greyback wants them to be clipped to the surface. [07:54] * RAOF shrugs. There are arguments either way. [07:54] OK, I've got enough to start a thread in mir-devel [07:55] greyback *can* modify their placement in the window management policy [07:56] He shouldn't be able to. [07:56] streams are meant to be sub-WM. [07:57] Or, rather, streams are meant to be invisible to the WM. [07:57] Then please log a bug against MirAL to hide them there [07:57] Will do. [07:57] Thanks [08:03] alan_g: AbstractShell currently handles stream configuration itself; how does that interact with MirAL? [08:05] WindowSpecification::streams() [08:06] The WM policy see that before passing the modification request to AS [08:07] So the flow goes frontend -> MirAL -> AS? OK. [08:09] I hope bug# 1619165 is sufficiently useful? [08:09] frontend -> AS -> MirAL::BasicWM -> WM policy -> MirAL::BasicWM -> AS [08:10] Ah, in that case MirAL doesn't need to do anything. AS strips out stream configuration before passing the request on. [08:10] See AbstractShell::modify_surface. [08:11] It first checks to see if there's any stream configuration in there, then consumes and applies it. [08:11] Then passes it on to the WM. [08:11] (If there's anything left) [08:13] Hmm. That would be wrong too. I'll check later. (Must go right now) === alan_g is now known as alan_g|AFK [08:14] * RAOF → EOD. === Saviq_ is now known as Saviq === alan_g|AFK is now known as alan_g [09:57] RAOF: I know you're EOD, but, although AbstractShell::modify_surface() strips streams, AbstractShell::create_surface() doesn't. Which is inconstant at best. === hikiko is now known as hikiko|ln === hikiko|ln is now known as hikiko [11:05] greyback: attente this may interest you enough to vote - https://code.launchpad.net/~alan-griffiths/mir/support-gdk_window_move_to_rect/+merge/304474 === dandrader_ is now known as dandrader === JanC is now known as Guest23252 === JanC_ is now known as JanC [13:55] Hello! I'm getting an error on a branch that I tried to set approved, but when the CI built it: "Package 'uuid', required by 'mirserver', not found" -- known issue? [13:55] alf_: ^ this was on the default-wallpaper branch [13:55] mterry: Probably a problem in Mir trunk, I will take a look [13:59] alf_: mterry sounds like bug 1617435 [13:59] bug 1617435 in mir (Ubuntu) "libmirserver-dev is missing a depends for uuid-dev" [Medium,Triaged] https://launchpad.net/bugs/1617435 [13:59] Fixed -r 3679 [14:00] alan_g: awesome looks right. Only scheduled for 0.25 tho, wonder when that comes out. In meantime, stuff isn't buildable [14:00] alan_g: right, although I think we missed a part of the fix, which is libmirserver-dev depending on uuid-dev [14:01] mterry: USC trunk builds against Mir trunk, so we don't have to wait for release to merge [14:01] /o\ [14:02] alan_g: :) [14:02] alf_: yes cool, and right on the missing Depends [14:02] alf_: indeed if we didn't build against Mir trunk, I guess I wouldn't have seen the error :) [14:03] who wants to fix it? [14:03] I can whip up a branch, should be trivial [14:03] thanks === dandrader_ is now known as dandrader [14:11] alan_g: https://code.launchpad.net/~mterry/mir/missing-uuid-dep/+merge/304645 [14:12] mterry: alan_g: approved [14:13] alf_: awesome thanks. Is there a way to fast track it to trunk to unblock other branches? [14:15] mterry: It should land within the next hour or so. If CI is being difficult we can merge manually. [14:15] alf_: oh nice, I'm not familiar with mir landings. But I guess that makes sense if your trunk doesn't need to track archive [14:16] I was thinking a silo and all that jazz, but right, that's not needed [14:16] Thanks [14:18] mterry: Actually for USC builds to use the new version it should land in the mir-staging PPA using our mir-daily recipe. To expedite, I will trigger the recipe after the fix reaches trunk. So I guess that's 2-3 hours total. [14:19] That's no biggie. Thanks [14:19] kdub: satisfied? https://code.launchpad.net/~alan-griffiths/mir/support-gdk_window_move_to_rect/+merge/304474 [14:20] alan_g, yes, thanks === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === chihchun is now known as chihchun_afk === 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 [18:43] alf_: do you have any idea why NestedServer.named_cursor_image_changes_are_forwarded_to_host would fail in the autoland run for the uuid-dev change? https://mir-jenkins.ubuntu.com/job/build-2-binpkg-mir/2040/arch=amd64,compiler=gcc,platform=mesa,release=xenial+overlay/consoleFull [19:30] mterry, thats one of the tests that we've been having some problems with [19:31] you can probably just ignore/retrigger, its a racy [19:32] https://bugs.launchpad.net/mir/+bug/1523621 [19:32] Launchpad bug 1523621 in Mir "[ FAILED ] NestedServer.*_cursor_*" [High,In progress]