[00:00] <kdub_> fixing 1299977 is oddly cathartic
[00:01] <kdub_> also, how much code should we share between our examples and our production code? I say ideally 'nothing' and the examples should only be based on the public headers
[13:51] <racarr__> Morning!
[13:52] <alan_g> racarr__: Afternoon here
[13:53] <alan_g> racarr__: got time to make a couple of trivial fixes to https://code.launchpad.net/~mir-team/mir/cursor-spike-lightning-round-fix-input-area-contains/+merge/220111 - so we can land it?
[13:54] <alan_g> anpok_: racarr__ here's a real easy one to review: https://code.launchpad.net/~alan-griffiths/mir/fix-1325602/+merge/221846
[13:56] <racarr__> alan_g: Thanks! as soon as I finish breakfast I will
[14:14] <alan_g> dednick: What do you think of:
[14:14] <alan_g> s/trusted_participant_starting/participant_added/g
[14:14] <alan_g> s/trusted_participant_stopping/participant_removed/g
[14:15] <dednick> alan_g: i have no problem with that.
[14:15]  * alan_g makes it so
[15:42] <kdub_> we're in this funny position where we have an api/abi between the production code and examples/
[15:43] <kdub_> my particular problem is that both the demo compositor and the default compositor need a renderer and some occlusion detection
[15:44] <alan_g> What's funny about production code having an api/abi and example code using it?
[15:45] <kdub_> well, i'd be okay if the api/abi was only the stuff in include/ of course
[15:45] <kdub_> but in our examples, we're recommending modifying the production code to suit the purposes of the examples
[15:45] <alan_g> That's odd
[15:46] <kdub_> particularly mc::filter_occlusions_from and mc::GLRenderer
[15:47]  * alan_g suspects the answer lies in bzr blame
[15:47] <kdub_> well, the answer lies in how we're sharing GLRenderer
[15:48] <kdub_> like, its useful because its the default, but do we want to share the code that is useful to the mir defaults in the hope that shell writers can make use of it too?
[15:48] <kdub_> I say we don't, if you override a default, you have to write a full alternative
[15:50] <alan_g> kdub_: I'm not familiar enough with the current state to know how reasonable it is. (Can one just wrap the default and change things that way?)
[15:51] <kdub_> well, one could wrap the default, but we allow overridding various internally-called functions in GLRenderer
[15:52] <alan_g> kdub_: I mean through the public api
[15:54] <kdub_> right, like take the_gl_renderer() and wrap the default GLRenderer with shadow/frame painting
[15:56] <alan_g> My feeling is that we don't have enough use-cases (yet) to drive a correct design, and that we've got [premature] generalization in the wrong places.
[15:57] <kdub_> right, and I think the right place to move to overridding is the DisplayBufferCompositor (which just has a bool composite() function)
[15:57] <kdub_> instead of Renderer which is funny interface with begin(), render(), end(), set_rotation(), etc
[15:58] <kdub_> I just want to figure out if I should try to share mc::filter_occlusions_from with the demo shell, or just write a demo shell occlusion algorithm that doesn't use production code
[16:00] <alan_g> I'm not voting on the "correct" answer. I just know the code is hard to adapt every time we try supporting something new. It needs good test cases and a refactor.
[16:02] <racarr__> Im voting for decorations and shadows in the scene :p
[16:03] <alan_g> kdub_: I don't think it hurts to share that algorithm.
[16:03] <kdub_> it doesn't hurt to share, but hurts a bit to expand it to think about fancier decorations :)
[16:09] <alan_g> kdub_: you were happy with the previous version (but CI wasn't). Could you check: https://code.launchpad.net/~alan-griffiths/mir/rework-test_client_library.cpp-mk2/+merge/221854 - thanks
[16:09] <kdub_> okay
[16:20] <racarr__> alan_g: Oh updated lightning-round btw
[16:25] <alan_g> racarr__: top approved an hour ago btw
[16:35] <racarr__> alan_g: Aha, thanks :)
[16:54] <alan_g> anpok_: OK to land https://code.launchpad.net/~alan-griffiths/mir/fix-1325602/+merge/221846?
[17:41] <anpok_> alan_g|EOD: yes

[18:28] <racarr__> mwahaha I replaced my keybaord
[18:28] <racarr__> with my laptop
[18:28] <racarr__> and set up synergy for mouse sharing
[18:28] <racarr__> its quite nice
[18:28] <racarr__>  (+ keybooooooard)
[18:28] <racarr__> ...though apparently with some key repeat glitches
[18:30] <racarr__> digging in to the emulator bug now...its a little weird... (https://bugs.launchpad.net/ubuntu/+source/android/+bug/1319582)
[18:31] <racarr__> I dont know where the fix is but it cant be in mir/qtubuntu, etc, because how are they supposed to clean up
[18:32] <racarr__> a clients eglWindowSurface (which in the emulator model has driver/host ssssssssssssssside reeeeeesources)
[18:32] <racarr__> ...wow this keyrepeat ttttthing is great
[18:34] <racarr__> I mean its like you allocate an eglContext and then crash and nothing leaks, presumably the kernel side component of the driver cleans up any hardware resources
[18:34] <racarr__> so this is an emulator driver bug that android has worked around somehow (or we are misusing the emulator)
[18:37] <racarr__> Who ever thought "apt-get source android" would be a thing
[18:43] <racarr__> failed to fetch...hash sum mismatch?!?!
[19:57] <racarr__> typedef SomeSortOfSmartPtr<type> TypePtr is an ugly pattern :p
[19:57] <racarr__> I think I tracked down the emulator bug...and have a strong guess thats what lead to it.
[20:40] <AlbertA> anaybody else with canonical irc connection issues?
[20:41] <racarr__> nah. launchpad connection issues though
[23:59] <kgunn> hey there...for anyone wanting to lend a hand in testing
[23:59] <kgunn> we're trying to promote our mir 0.2.0