=== JanC_ is now known as JanC === chihchun_afk is now known as chihchun [07:39] RAOF: hello [07:41] om26er: He seems to be away today [07:42] 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] om26er: The debug extension provides only two headers and we keep the docs in the headers.... dpkg -L libmirclient-debug-extension-dev [07:45] So that would be the place if any [07:45] Oh, one header. Duplicated :) [07:45] Seems the feature isn't there [07:47] yeah seems the co-ordinates of a surface are available only [07:48] even more, does this extension require mir to be running in debug mode ? [07:48] om26er: Not sure. I'm not aware of such a feature but that doesn't mean it doesn't exist [07:49] duflu: I did send an email to Chris last night so, will probably get a reply next week [07:50] om26er: Yeah sorry. He just seems to be absent today [10:03] anpok_: Progress. I now have in-server clients (render_surfaces) working in VirtualBox. 100FPS at 1320x910 in a VM :) === dandrader_ is now known as dandrader [10:53] 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] alan_g, greyback, sounds like a plan? [10:55] dandrader: can we get a silo together with a working miral-ised unity8, just to assess where we are right now [10:55] greyback, need miral 0.4, as I told on the e-mail [10:55] dandrader: which doesn't stop us making a test silo, including miral [10:55] dandrader: greyback there are pros and cons to each approach, it depends where we think most of the remaining work lies. [10:57] 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) === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === hikiko is now known as hikiko|ln [11:42] 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] or(), occlusion, generate_renderables(). Does that make sense to you? [11:43] alan_g: are you including preferred_orientation in that assessment> [11:44] display rotation causes a geometry change, the window manager may want to do work to reposition/resie surfaces to suit [11:45] 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] s [11:49] I'm not entirely sure about orientation (or preferences) it isn't yet clear to me [11:50] ok, quick summary: windows can have a list of preferred orientations (orientations the UI supports) [11:51] yep [11:51] then the shell should limit the system orientation to match those preferences [11:51] within reason [11:52] that's the wibble word [11:52] so if surfaceA specifies it prefers portrait orientation, and it is focused, shell should be in portrait [11:53] 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] Ack. that convinces me that there's a WM component. [11:54] 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] yeah, I believe the WM needs to care [11:55] * alan_g has seen portrait desktop setups [11:55] 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] greyback: thanks, I need to think some more [11:56] but changing display orientation on a phone/tablet is trivial [11:57] Unless "locked" by the user [11:57] indeed [11:59] So MirAL's next big feature should be an orientation model that supports choices [12:01] * alan_g thinks hard [12:01] take note that unity8 orientation support is all done in unity8 - Mir is not doing any rotation of the shell [12:01] ack === alan_g is now known as alan_g|lunch [12:03] 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] 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 === alan_g|lunch is now known as alan_g [12:37] greyback: I know RAOF has been chipping away at that, could be worth re-examining post Mir-0.25 [12:38] alan_g: ack === hikiko|ln is now known as hikiko [12:48] alan_g, miral no longer builds in V+O http://pastebin.ubuntu.com/23425346/ [12:49] dandrader: "interesting" === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [15:44] 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] dandrader: perfect! [15:45] dandrader: I believe we both agree that any new work on qtmir is done on top of that branch [16:15] dandrader: greyback quick review? https://code.launchpad.net/~alan-griffiths/miral/update-changelog/+merge/310077 [16:16] looks good, acked === kenvandine_ is now known as kenvandine === JanC is now known as Guest51811 === JanC_ is now known as JanC === JanC_ is now known as JanC