| === JanC_ is now known as JanC | ||
| === chihchun_afk is now known as chihchun | ||
| om26er | RAOF: hello | 07:39 |
|---|---|---|
| duflu | om26er: He seems to be away today | 07:41 |
| 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:42 |
| duflu | om26er: The debug extension provides only two headers and we keep the docs in the headers.... dpkg -L libmirclient-debug-extension-dev | 07:44 |
| 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:45 |
| om26er | yeah seems the co-ordinates of a surface are available only | 07:47 |
| 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:48 |
| om26er | duflu: I did send an email to Chris last night so, will probably get a reply next week | 07:49 |
| duflu | om26er: Yeah sorry. He just seems to be absent today | 07:50 |
| duflu | anpok_: Progress. I now have in-server clients (render_surfaces) working in VirtualBox. 100FPS at 1320x910 in a VM :) | 10:03 |
| === dandrader_ is now known as dandrader | ||
| 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:53 |
| dandrader | alan_g, greyback, sounds like a plan? | 10:54 |
| 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:55 |
| alan_g | I have a somewhat biassed view because I'm just looking at the interaction with Mir and MirAL. | 10:57 |
| * greyback changing office, bbiab | 11:01 | |
| * alan_g thinks miral will need work for packaging to work on vivid (because of the g++ ABI) | 11:12 | |
| === 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 | ||
| 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:42 |
| greyback | alan_g: are you including preferred_orientation in that assessment> | 11:43 |
| greyback | display rotation causes a geometry change, the window manager may want to do work to reposition/resie surfaces to suit | 11:44 |
| 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:45 |
| alan_g | I'm not entirely sure about orientation (or preferences) it isn't yet clear to me | 11:49 |
| greyback | ok, quick summary: windows can have a list of preferred orientations (orientations the UI supports) | 11:50 |
| alan_g | yep | 11:51 |
| greyback | then the shell should limit the system orientation to match those preferences | 11:51 |
| greyback | within reason | 11:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| * 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:55 |
| greyback | but changing display orientation on a phone/tablet is trivial | 11:56 |
| alan_g | Unless "locked" by the user | 11:57 |
| greyback | indeed | 11:57 |
| alan_g | So MirAL's next big feature should be an orientation model that supports choices | 11:59 |
| * 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:01 |
| === alan_g is now known as alan_g|lunch | ||
| 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:03 |
| === alan_g|lunch is now known as alan_g | ||
| alan_g | greyback: I know RAOF has been chipping away at that, could be worth re-examining post Mir-0.25 | 12:37 |
| greyback | alan_g: ack | 12:38 |
| === hikiko|ln is now known as hikiko | ||
| dandrader | alan_g, miral no longer builds in V+O http://pastebin.ubuntu.com/23425346/ | 12:48 |
| alan_g | dandrader: "interesting" | 12:49 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| 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:44 |
| 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 | 15:45 |
| alan_g | dandrader: greyback quick review? https://code.launchpad.net/~alan-griffiths/miral/update-changelog/+merge/310077 | 16:15 |
| greyback | looks good, acked | 16:16 |
| === kenvandine_ is now known as kenvandine | ||
| === JanC is now known as Guest51811 | ||
| === JanC_ is now known as JanC | ||
| === JanC_ is now known as JanC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!