[02:01] <duflu> AlbertA: Around?
[09:26] <alan_g> alf_: fixed for mir_server_mesa_egl_native_display_is_valid() - is it OK now? https://code.launchpad.net/~alan-griffiths/mir/fix-mirplatformgraphics/+merge/228815
[09:28] <alf_> alan_g: looks good, (top) approved
[09:28] <alan_g> thanks
[10:17] <alan_g> greyback: does this capture all the "configuring Mir" issues we discussed a while back? https://bugs.launchpad.net/mir/+bug/1351255
[10:34] <greyback> alan_g: yep, thank you. I commented on what would work for us. See what you think
[10:54] <alf_> alan_g: When we call mir_connection_release() the lifecycle callback for connection lost gets called... Do you know if this was done on purpose?
[11:51] <alan_g> alf_: I've no recollection of the issues around that
[11:53] <alf_> alan_g: thanks
[13:57] <alan_g> greyback: if mo::DefaultConfiguration had a virtual function "bool accept_unparsed_arguments(vector<string> const&)" would that work for you?
[14:00] <greyback> alan_g: not clear what that does. Do I pass it the env vars? What does the return value mean?
[14:00] <alan_g> You could override it with your own command-line processor logic
[14:01] <alan_g> @https://bugs.launchpad.net/mir/+bug/1351255/comments/1
[14:02] <alan_g> It isn't literally what you asked for, but would be easier to implement.
[14:02] <greyback> alan_g: so I need to give Mir a list of command line arguments to ignore?
[14:03] <alan_g> No. Anything Mir doesn't recognised is passed in the argument
[14:04] <alan_g> Anything Mir did process has been stripped
[14:05] <greyback> alan_g: ok I see. Let me think about it please
[14:06] <alan_g> Actually, maybe void is a better return type: if you're unhappy you can just throw an exception.
[14:07] <alan_g> void mo::DefaultConfiguration::handle_unparsed_arguments(vector<string> const& argv)
[14:10] <alan_g> greyback: Another option would for you to pass a function<void(vector<string> const& argv)> to the constructor
[14:12] <greyback> alan_g: I think either would work for me. What I'd have to do is pass argv into mir, and then based on the handle_unparsed_arguments calls, re-assemble the stripped argv to then pass to Qt
[14:14] <alan_g> greyback: yes. You'd prefer vector<char*>? (To use "tokens.size(), tokens.data()")
[14:14] <greyback> alan_g: yep, would prefer char*
[14:15] <alan_g> OK, so long as you can accept you don't control the lifetime of the pointee.
[14:16] <alan_g> A "function<>" would probably be the least coupled approach, does that cause any problems?
[14:17] <greyback> alan_g: not really, I can work with it
[14:18] <alan_g> greyback: OK one unparsed_arguments callback coming up
[14:18] <greyback> alan_g: thank you :)