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