[07:39] <om26er> RAOF: hello
[07:41] <duflu> om26er: He seems to be away today
[07:42] <om26er> duflu: oh, ok. I was told to contact RAOF regarding libmirclient-debug as I needed the mouse pointer co-ordinates from it. Do you know if there are any docs on that somewhere ?
[07:44] <duflu> om26er: The debug extension provides only two headers and we keep the docs in the headers.... dpkg -L libmirclient-debug-extension-dev
[07:45] <duflu> So that would be the place if any
[07:45] <duflu> Oh, one header. Duplicated :)
[07:45] <duflu> Seems the feature isn't there
[07:47] <om26er> yeah seems the co-ordinates of a surface are available only
[07:48] <om26er> even more, does this extension require mir to be running in debug mode ?
[07:48] <duflu> om26er: Not sure. I'm not aware of such a feature but that doesn't mean it doesn't exist
[07:49] <om26er> duflu: I did send an email to Chris last night so, will probably get a reply next week
[07:50] <duflu> om26er: Yeah sorry. He just seems to be absent today
[10:03] <duflu> anpok_: Progress. I now have in-server clients (render_surfaces) working in VirtualBox. 100FPS at 1320x910 in a VM :)
[10:53] <dandrader> alan_g, greyback, regarding immediate miral-qt work: I think we should now propose branches for lp:~unity-team/qtmir/miral-qt-integration instead of lp:miral. Then, once lp:~unity-team/qtmir/miral-qt-integration lands, propose directly for lp:qtmir
[10:54] <dandrader> alan_g, greyback, sounds like a plan?
[10:55] <greyback> dandrader: can we get a silo together with a working miral-ised unity8, just to assess where we are right now
[10:55] <dandrader> greyback, need miral 0.4, as I told on the e-mail
[10:55] <greyback> dandrader: which doesn't stop us making a test silo, including miral
[10:55] <alan_g> dandrader: greyback there are pros and cons to each approach, it depends where we think most of the remaining work lies.
[10:57] <alan_g> I have a somewhat biassed view because I'm just looking at the interaction with Mir and MirAL.
[11:01]  * greyback changing office, bbiab
[11:12]  * alan_g thinks miral will need work for packaging to work on vivid (because of the g++ ABI)
[11:42] <alan_g> greyback: in my review of miral-qt I'm looking at orientation. So far, MirAL doesn't expose orientation of displays or surfaces and I'm not sure that matters to /window management/. That is, I think it's a /compositing/ concern. And for compositing I think we need a different abstraction than miral::Window (with a way to map between of course). Other stuff that belongs to that abstraction are buffers_ready_for_composit
[11:42] <alan_g> or(), occlusion, generate_renderables(). Does that make sense to you?
[11:43] <greyback> alan_g: are you including preferred_orientation in that assessment>
[11:44] <greyback> display rotation causes a geometry change, the window manager may want to do work to reposition/resie surfaces to suit
[11:45] <greyback> but the WM might also want to notify the app of the orientation it wants it to display at
[11:45]  * greyback ponder
[11:45] <greyback> s
[11:49] <alan_g> I'm not entirely sure about orientation (or preferences) it isn't yet clear to me
[11:50] <greyback> ok, quick summary: windows can have a list of preferred orientations (orientations the UI supports)
[11:51] <alan_g> yep
[11:51] <greyback> then the shell should limit the system orientation to match those preferences
[11:51] <greyback> within reason
[11:52] <alan_g> that's the wibble word
[11:52] <greyback> so if surfaceA specifies it prefers portrait orientation, and it is focused, shell should be in portrait
[11:53] <greyback> right, because it's not straightforward - if you are on desktop, shell isn't going to change from natural landscape to portrait, just because the surface prefers it
[11:54] <alan_g> Ack. that convinces me that there's a WM component.
[11:54] <greyback> for a traditional desktop, everything will be landscape. But on a tablet or phone, preferred orientations may cause the shell to decide to change orientation
[11:54] <greyback> yeah, I believe the WM needs to care
[11:55]  * alan_g has seen portrait desktop setups
[11:55] <greyback> oh sure, they exist. But you can't easily switch orientation just because the app prefers it. Alt-Tabbing between portrant & landscape surfaces shouldn't force you to rotate your monitor on its stand
[11:55] <alan_g> greyback: thanks, I need to think some more
[11:56] <greyback> but changing display orientation on a phone/tablet is trivial
[11:57] <alan_g> Unless "locked" by the user
[11:57] <greyback> indeed
[11:59] <alan_g> So MirAL's next big feature should be an orientation model that supports choices
[12:01]  * alan_g thinks hard
[12:01] <greyback> take note that unity8 orientation support is all done in unity8 - Mir is not doing any rotation of the shell
[12:01] <alan_g> ack
[12:03] <greyback> which isn't ideal, we're not updating the display config with the "correct" orientation - it something I need to look at again. It was mainly blocked due to bug 1556142
[12:03] <ubot5`> bug 1556142 in Mir "Changing scale, formFactor or DPI in display configuration causes renderer teardown/recreate unnecessarily" [High,In progress] https://launchpad.net/bugs/1556142
[12:37] <alan_g> greyback: I know RAOF has been chipping away at that, could be worth re-examining post Mir-0.25
[12:38] <greyback> alan_g: ack
[12:48] <dandrader> alan_g, miral no longer builds in V+O http://pastebin.ubuntu.com/23425346/
[12:49] <alan_g> dandrader: "interesting"
[15:44] <dandrader> greyback, while I wait for miral 0.4 I gonna start experimenting with exposing child miral windows to unity8 (popups, menus). with a separate branch on top of lp:~unity-team/qtmir/miral-qt-integration
[15:45] <greyback> dandrader: perfect!
[15:45] <greyback> dandrader: I believe we both agree that any new work on qtmir is done on top of that branch
[16:15] <alan_g> dandrader: greyback quick review? https://code.launchpad.net/~alan-griffiths/miral/update-changelog/+merge/310077
[16:16] <greyback> looks good, acked