=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== chihchun is now known as chihchun_afk | ||
=== chihchun_afk is now known as chihchun | ||
=== greyback__ is now known as greyback | ||
=== chihchun is now known as chihchun_afk | ||
mlankhorst | hah, looks like I can use the drm EGL platform in standalone Xmir instead of the Mir EGL platform. :P | 11:03 |
---|---|---|
mlankhorst | at least that one cleans up correctly.. | 11:05 |
mlankhorst | RAOF: should I file a bug for eglTerminate not cleaing up correctly with Mir? | 11:09 |
mlankhorst | https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1414999 | 11:18 |
ubot5 | Launchpad bug 1414999 in mir (Ubuntu) "double free in mir when calling eglTerminate and gbm_device_destroy" [Undecided,New] | 11:18 |
=== alan_g is now known as alan_g|lunch | ||
=== dandrader is now known as dandrader|bbl | ||
=== chihchun_afk is now known as chihchun | ||
=== alan_g|lunch is now known as alan_g | ||
alan_g | alf_: you should mention your suspicions of cloud-worker-13 on #ubuntu-ci-eng | 14:02 |
alf_ | alan_g: Have we had an other strange failure? I think I want to wait for one more data point at least. | 14:19 |
alan_g | alf_: Ack. (I've not been counting.) | 14:20 |
=== dandrader|bbl is now known as dandrader | ||
mpt | I’m working on the surface management spec, and I have a question about the minimized state | 15:49 |
mpt | Does/Should an app know, and be able to change, whether each of its windows is minimized? | 15:49 |
mpt | If it could, it could suspend decoding/display of video, pause games, etc, saving battery | 15:50 |
alan_g | the client API allows an app to query the state, get updates when the state changes and to request a state change. | 15:51 |
mpt | Ok :-) thanks | 15:51 |
=== dandrader is now known as dandrader|afk | ||
=== alan_g is now known as alan_g|EOD | ||
=== dandrader|afk is now known as dandrader | ||
kgunn | AlbertA: you around? | 19:06 |
kgunn | AlbertA: camako: so will mir permit clients to pass in a preference of positioning ? | 19:07 |
AlbertA | kgunn: we don't have that in the api yet...but there's a question for base windows on | 19:09 |
AlbertA | what would the coordinate system be | 19:09 |
=== greyback__ is now known as greyback | ||
AlbertA | but I see it as an optional field in MirSurfaceSpec | 19:10 |
kgunn | AlbertA: so was just chatting with mzanetti, and he was saying this is important for the "memory" aspect | 19:11 |
kgunn | that when you flip between mobile and desktop | 19:11 |
kgunn | desktop just ends up with all the windows in the same spot...even if you previously spread them all out | 19:12 |
kgunn | whereas, the desire would be for it to recall where they were and put them back into position | 19:12 |
AlbertA | kgunn: I would have thought this would be part of the "cookie" stuff | 19:12 |
AlbertA | which would be used by a shell to save/restore window information on the server side... | 19:12 |
kgunn | oh look...already a bug | 19:14 |
kgunn | https://bugs.launchpad.net/qtmir/+bug/1415161 | 19:14 |
ubot5 | Launchpad bug 1415161 in Unity 8 "U8 application windows don't remember their location or size when switching between Windowed->Staged->Windowed" [Undecided,New] | 19:14 |
kgunn | AlbertA: true, shell could do the tracking in the near term | 19:15 |
AlbertA | kgunn: at first glance I put it in the same bucket as restoring window positions when an application starts again from scratch which is the | 19:16 |
greyback | so I'm in 2 minds about Mir saving window state/position. Since we have 2 distinct view states (desktop/tablet) that would imply there's 2 separate state/position settings to track for each surface | 19:17 |
greyback | -surface+window | 19:17 |
greyback | should Mir have to support that? | 19:17 |
AlbertA | cookie thing racarr/chris have mentioned in the past | 19:17 |
AlbertA | I would imagine something like | 19:18 |
AlbertA | the client requests a unique cookie from the server | 19:18 |
AlbertA | and gets associated with session/surface maybe | 19:18 |
AlbertA | then a server side interface just asks a helper | 19:19 |
AlbertA | to store/retrieve info, given that cookie - the shell implementation would then | 19:19 |
AlbertA | save whatever pertinent information it wants (like desktop/tablet mode, last known position etc...) | 19:19 |
AlbertA | and likewise, mir server would ask the same helper, given that cookie to retrieve stored state... | 19:20 |
AlbertA | the alternative is the client specifying initial positions.... | 19:22 |
AlbertA | but then we have to agree on what type of coordinate system to use... | 19:22 |
AlbertA | it would probably have to be something normalized to the current view coordinate system | 19:23 |
kgunn | AlbertA: right, and we want to avoid absolute positioning iirc | 19:24 |
greyback | yeah that's fair, let the shell save what it needs | 19:27 |
kgunn | AlbertA: client cookie only good for child surface tho right? | 19:30 |
kgunn | e.g. topmost parent isn't going to know it's position right ? | 19:31 |
kgunn | camako: just wondering, looks like racarr addressed alan's comment, we can ta ? | 19:43 |
kgunn | https://code.launchpad.net/~mir-team/mir/add-non-input-event-ctors-and-port-event-sinks/+merge/247084 | 19:43 |
camako | kgunn, done | 20:01 |
kgunn | camako: no prob...was just askin' really | 20:01 |
camako | sure | 20:01 |
kgunn | camako: i'm kinda cross referencing backlog and branches....seeing where we're really at | 20:02 |
camako | kgunn, need help? | 20:02 |
kgunn | camako: i might ping you as i go...and you might wanna skim it after i finish | 20:02 |
camako | kgunn, sure | 20:02 |
AlbertA | kgunn: cookie is more anything I think, basically to persist data and give it a unique id | 20:27 |
kgunn | AlbertA: thanks...i did find it in the backlog "MirCookie/MirReference support (focus grant, cross-session/client parenting/referencing)" | 20:28 |
AlbertA | kgunn: oh...yeah that maybe a bit different, that's more about cross-process ids | 20:28 |
AlbertA | kgunn: but could be related...I have not given it deep thought :) | 20:29 |
kgunn | camako: this feels like we should approve, fixes a bug as well... | 21:23 |
kgunn | https://code.launchpad.net/~vanvugt/mir/fix-buffers_ready_for_compositor/+merge/247124 | 21:23 |
kgunn | altho if you want to review first, i'd understand | 21:24 |
camako | kgunn, I looked at it.. yeah it looks reasonable | 21:24 |
camako | was going to take a deeper look | 21:24 |
kgunn | camako: and is jenkins still being a punk ? | 21:27 |
kgunn | https://code.launchpad.net/~mir-team/mir/add-dispatchable-interface/+merge/246372 | 21:27 |
kgunn | ah...nope seems he's gotta conflict | 21:28 |
camako | kgunn, alf noticed some failures but thought they were contained or due to one specific server | 21:28 |
camako | kgunn, yes that particular one need TLC from RAOF | 21:29 |
kgunn | RAOF: you on? | 22:12 |
RAOF | kgunn: Indeed I am | 22:12 |
kgunn | so i was trying to help :) | 22:12 |
kgunn | RAOF: and i goofed, but already figured out how to do it right...but | 22:13 |
kgunn | don't know how to undo one particular thing | 22:13 |
kgunn | so i was addressign the conflict on | 22:13 |
kgunn | lp:~mir-team/mir/add-dispatchable-interface | 22:13 |
kgunn | and thot i addressed the right --take but i didn't | 22:14 |
kgunn | shoulda done by hand | 22:14 |
RAOF | Heh. | 22:14 |
kgunn | ...and pushed, only to realize the goof | 22:14 |
kgunn | so how does one "revert" the push | 22:14 |
RAOF | Either by adding an extra commit, or by push --overwrite. | 22:15 |
kgunn | cause if you uncommit/revert...then push, it says "you've diverged you fool" | 22:15 |
kgunn | so opportunity to learn for me as well | 22:15 |
kgunn | RAOF: what's the penalty if any of --overwrite ? | 22:15 |
RAOF | Yeah, “push --overwrite” is what you want in that circumstance. | 22:15 |
kgunn | or does it simply obliterate that last commit | 22:16 |
RAOF | It obliterates what's currently in the branch and replaces it with what you push. | 22:16 |
kgunn | (e.g. does it negate your approve votes or do some weird history loss thing) | 22:16 |
kgunn | ok...will do that | 22:16 |
RAOF | No, nothing like that. | 22:16 |
RAOF | Some tools can get a bit confused because they expect the contents of a revision to be immutable (ie: rev 2278 has one contents now and will have a different contents after --overwrite) | 22:17 |
RAOF | But it's all fairly harmless. | 22:17 |
kgunn | RAOF: ok, that seemed to work...took a while to make sure i did it correct...of course, i only touch ./tests/CMakeLists.txt | 22:41 |
kgunn | but after...now it's complaining about others | 22:41 |
kgunn | https://code.launchpad.net/~mir-team/mir/add-dispatchable-interface/+merge/246372 | 22:41 |
kgunn | is that common ? | 22:41 |
RAOF | No. That would suggest that there are other conflicts introduced. | 22:43 |
kgunn | RAOF: i suppose i should have done merge lp:mir ...vs lp:mir/tests/CMakeLists.txt | 22:44 |
kgunn | ? | 22:44 |
RAOF | I'm not sure what lp:mir/tests/CMakeLists.txt would do? | 22:44 |
kgunn | it only merges that file | 22:44 |
RAOF | I didn't know you could do that :) | 22:44 |
kgunn | hehe | 22:44 |
RAOF | I'd probably just do “bzr merge lp:mir” and check that everything's ok. | 22:45 |
kgunn | ok...merging the entire tree | 22:45 |
kgunn | woa... 5 conflicts encountered | 22:45 |
kgunn | and lots of stuff moved about | 22:46 |
RAOF | Yeah, the ABI things now conflict. | 22:46 |
kgunn | yep | 22:46 |
kgunn | Text conflict in common-ABI-sha1sums | 22:46 |
kgunn | Text conflict in platform-ABI-sha1sums | 22:46 |
kgunn | Text conflict in server-ABI-sha1sums | 22:46 |
kgunn | Text conflict in src/common/symbols.map | 22:46 |
kgunn | Text conflict in tests/CMakeLists.txt | 22:46 |
kgunn | RAOF: i assume the map gets taken care as part of the sha1sum updates | 22:46 |
kgunn | ? | 22:46 |
RAOF | symbols.map? No, that needs manual merging. | 22:47 |
kgunn | RAOF: how does one resolve the sha1sums ? script ? | 22:48 |
RAOF | You need to manually edit it to resolve the conflict. | 22:48 |
kgunn | k | 22:48 |
kgunn | RAOF: ok...doing the symbols.map last, and it looks like an hour ago robert added a 3.2 | 23:09 |
kgunn | http://bazaar.launchpad.net/~mir-team/mir/development-branch/revision/2267 | 23:09 |
kgunn | does that mean | 23:09 |
kgunn | i need to mannually add a 3.3 for your adds ? ...or just merge them under 3.2 since we haven't release yet ? | 23:10 |
RAOF | Can probably merge them under 3.2 | 23:11 |
kgunn | RAOF: does order matter ? | 23:11 |
RAOF | No | 23:11 |
kgunn | RAOF: one last one... on your add of 3.2 your close brace has MIR_COMMON_3.1; whereas sir robert's has MIR_COMMON_3; | 23:15 |
kgunn | i see 3.1 closed with MIR_COMMON_3 as well... | 23:16 |
kgunn | what would be the correct convention | 23:16 |
RAOF | It doesn't _really_ matter; 3.1 would be slightly more correcct. | 23:16 |
RAOF | Indeed, you can leave out the base-revision entirely. It's basically just saying “These symbols comprise MIR_COMMON_3.2, and require MIR_COMMON_3.1” | 23:17 |
kgunn | that was my guess | 23:19 |
kgunn | RAOF: thanks for letting me do, learned a little....pushed | 23:20 |
kgunn | gonna kick jenkins, if it passes we should top approve | 23:20 |
RAOF | And I'll merge that through all the dependent branches. Thanks! | 23:26 |
RAOF | Soooo. | 23:26 |
RAOF | For those playing at home, Grim Fandango remastered is available on Linux. | 23:27 |
racarr | On by default the last timeI used it | 23:33 |
racarr | ... | 23:33 |
racarr | lol | 23:33 |
racarr | up + enter mishap | 23:33 |
racarr | qtmir -> event 2.0 port finished...of coursemuch manual testing required | 23:36 |
RAOF | Woot! | 23:37 |
RAOF | racarr: Remember to buy Grim Fandango for the plane trip to Brussels :) | 23:37 |
racarr | I've never played it actually... | 23:38 |
RAOF | Yeah, that's what I though. | 23:39 |
RAOF | t | 23:39 |
RAOF | It might have been a bit before your time :P | 23:39 |
RAOF | Which is why you should buy it, silly! | 23:39 |
kgunn | who doesn't love mexican skull art really | 23:41 |
kgunn | in a video game no less | 23:41 |
racarr | oh that is kind of my jam | 23:41 |
kgunn | never heard of this...but now i am totally intrigued | 23:41 |
RAOF | OH MAN! | 23:41 |
RAOF | You're a travel agent in the land of the dead! | 23:41 |
RAOF | Starting on the day of the dead! | 23:43 |
RAOF | Intrigue! Mystery! Skeletal pigeon eggs! | 23:44 |
kgunn | hehe | 23:44 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!