| === chihchun_afk is now known as chihchun | ||
| alan_g | RAOF: are you about? | 07:24 |
|---|---|---|
| RAOF | alan_g: Yes! | 07:25 |
| alan_g | Do you have thoughts about the placement information we should share with clients? | 07:25 |
| RAOF | Yes. | 07:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| alan_g | Ack, we already send resize. | 07:32 |
| alan_g | So a client could create a fullscreen surface, never paint it, and place everything WRT that. | 07:33 |
| alan_g | And know where all its "real" surfaces are | 07:34 |
| RAOF | Correct. | 07:35 |
| RAOF | That is an excellent bug! | 07:35 |
| 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:36 |
| alan_g | I'm not sure The Architect would approve | 07:37 |
| RAOF | Oh, a client doing that is transparently (hah!) unreasonable. | 07:38 |
| RAOF | But it's not something we can easily forbid. | 07:38 |
| RAOF | It's not (to my knowledge) a security problem, and it's not something normal clients would actually bother to do. | 07:39 |
| alan_g | If it is not forbidden someone will rely on it. | 07:40 |
| 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:41 |
| RAOF | Is it simple? They need to construct a fullscreen window and then do all their drawing on it. | 07:43 |
| 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:44 |
| 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:45 |
| 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:48 |
| alan_g | "most" being less than half of MirSurfaceType? ;) | 07:49 |
| alan_g | But I see the point | 07:49 |
| 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:50 |
| RAOF | I would also be happy to restrict placement to fully-constructed (ie: with content) surfaces. | 07:51 |
| alan_g | Doesn't really help: it can have a bufferstream with a single transparent(?) pixel | 07:52 |
| 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:53 | |
| 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:54 |
| alan_g | greyback *can* modify their placement in the window management policy | 07:55 |
| RAOF | He shouldn't be able to. | 07:56 |
| RAOF | streams are meant to be sub-WM. | 07:56 |
| 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 | 07:57 |
| RAOF | alan_g: AbstractShell currently handles stream configuration itself; how does that interact with MirAL? | 08:03 |
| alan_g | WindowSpecification::streams() | 08:05 |
| alan_g | The WM policy see that before passing the modification request to AS | 08:06 |
| RAOF | So the flow goes frontend -> MirAL -> AS? OK. | 08:07 |
| RAOF | I hope bug# 1619165 is sufficiently useful? | 08:09 |
| alan_g | frontend -> AS -> MirAL::BasicWM -> WM policy -> MirAL::BasicWM -> AS | 08:09 |
| 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:10 |
| 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:11 |
| alan_g | Hmm. That would be wrong too. I'll check later. (Must go right now) | 08:13 |
| === alan_g is now known as alan_g|AFK | ||
| * RAOF → EOD. | 08:14 | |
| === Saviq_ is now known as Saviq | ||
| === alan_g|AFK is now known as alan_g | ||
| 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. | 09:57 |
| === hikiko is now known as hikiko|ln | ||
| === hikiko|ln is now known as hikiko | ||
| 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 | 11:05 |
| === dandrader_ is now known as dandrader | ||
| === JanC is now known as Guest23252 | ||
| === JanC_ is now known as JanC | ||
| 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:55 |
| alan_g | alf_: mterry sounds like bug 1617435 | 13:59 |
| ubot5 | bug 1617435 in mir (Ubuntu) "libmirserver-dev is missing a depends for uuid-dev" [Medium,Triaged] https://launchpad.net/bugs/1617435 | 13:59 |
| alan_g | Fixed -r 3679 | 13:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| 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:03 |
| === dandrader_ is now known as dandrader | ||
| mterry | alan_g: https://code.launchpad.net/~mterry/mir/missing-uuid-dep/+merge/304645 | 14:11 |
| alf_ | mterry: alan_g: approved | 14:12 |
| mterry | alf_: awesome thanks. Is there a way to fast track it to trunk to unblock other branches? | 14:13 |
| 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:15 |
| mterry | I was thinking a silo and all that jazz, but right, that's not needed | 14:16 |
| mterry | Thanks | 14:16 |
| 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:18 |
| 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:19 |
| kdub | alan_g, yes, thanks | 14:20 |
| === 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 | ||
| 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 | 18:43 |
| kdub | mterry, thats one of the tests that we've been having some problems with | 19:30 |
| kdub | you can probably just ignore/retrigger, its a racy | 19:31 |
| kdub | https://bugs.launchpad.net/mir/+bug/1523621 | 19:32 |
| ubot5 | Launchpad bug 1523621 in Mir "[ FAILED ] NestedServer.*_cursor_*" [High,In progress] | 19:32 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!