[09:26] <alan_g> greyback: can I draw your attention to the changes in miral-qt/src/platforms/mirserver/windowmanagementpolicy.cpp here: https://code.launchpad.net/~alan-griffiths/miral/reduce-WindowManagerTools/+merge/301885 - possibly something you're aware of already?
[09:27] <greyback> alan_g: the fact there was overlap did occur to me, I just considered it a convenience thing. I've no problem removing it
[09:29] <alan_g> "removing" == deleting these functions?
[09:45] <anpok> greyback: is ltinkl away for longer?
[09:51] <greyback> alan_g: yep
[09:52] <greyback> anpok: longer than a piece of string? :)
[09:52] <greyback> anpok: he was online yesterday, i don't think he's on holidays
[09:52] <alan_g> greyback: Ok, I'll do that instead. ;)
[10:08] <anpok> greyback: I am looking at qtubuntu and an input filter plugin called qcomposeplatforminputcontextplugin
[10:08] <anpok> can you shed some light on what part decides whether a plugin like that would be loaed
[10:09] <anpok> .. it currently is not.. so thats why ubuntu touch is not handling compose sequences..
[10:13] <greyback> anpok: could you try testing with this env var set: QT_IM_MODULE="compose"
[10:14] <greyback> I see the XCB qpa plugin has a cheeky qputenv("QT_IM_MODULE", QByteArray("compose"));
[10:14] <greyback> we might need to duplicate that
[10:18] <anpok> ok
[10:18] <anpok> it works on desktop qt
[10:18] <anpok> with unity8
[10:19] <anpok> so .. I was wondering if that env var could be a list? because we stil need malitt too
[10:19] <anpok> or maybe because we dont have maliit loaded on desktop it falls back and loads the compose plugin..
[10:23] <greyback> anpok: I'm not sure, need to read more
[10:24] <greyback> QPlatformInputContextFactory obviously only creates one instance
[10:26] <anpok> greyback: hm we could implement compose sequences in mir.. i had hopped it would not be necessary
[10:27] <anpok> greyback: QT_IM_MODUE=compose does the trick..
[10:27] <anpok> and breaks maliit
[10:28] <greyback> I don't see an obvious way they can co-exist in Qt
[10:29] <greyback> only idea is to create a QCombinationInputContext class, which imports both maliit & compose plugins underneath
[10:29] <anpok> hm we could extend maliitphablet to handle keys and include the compose key handlng there..
[10:32] <greyback> do we really need support for OSK and physical keyboard at the same time?
[10:33] <anpok> hm probably not
[12:10] <greyback> alan_g: small api comment with miral::WindowInfo - any reason you don't use mir::geometry::Size for min/max sizes?
[12:11] <greyback> and for the increment, would not an increment of 1 be the same as having no increment set?
[12:58] <alan_g> greyback: I guess. IIRC it was all optional (so width could be set without height) and I simplified by always having min/max with 0/numeric_limits<>::max. You're right the same could be done with increments.
[12:59] <alan_g> But... I think there's some independence between min_width and min_height and they shouldn't be combined in one value.
[13:02] <greyback> alan_g: sure, they're independent values. I just thought the Size type was a natural container for the pair of vals
[13:02] <greyback> no biggie anyway
[13:16] <alan_g> greyback: I'll pick up the change to increments though
[13:16] <greyback> ok
[14:29] <alan_g> alf_: you've approved two miral MPs (thanks!) but not looked at the prerequisite?
[14:33] <alf_> alan_g: looking
[14:34] <alan_g> thanks
[14:45] <alan_g> greyback: https://code.launchpad.net/~alan-griffiths/miral/simplify-size-increments/+merge/301909
[14:47] <greyback> alan_g: approved!
[14:53] <alan_g> alf_: reworded https://code.launchpad.net/~alan-griffiths/miral/add-introducing_the_miral_api/+merge/301779 - better?
[14:55] <greyback> alan_g: a question: have you a plan on how SurfaceObserver fits in with miral's api?
[14:56] <greyback> say if a window is repositioned, both SurfaceObserver::moved_to and WMPolicy::advise_move_to will fire
[14:57] <alan_g> yes. (But SurfaceObserver isn't in the MirAL API)
[15:00] <greyback> ok, I'll try to avoid relying on SurfaceObserver
[17:52] <peat-psuwit> Hello.
[17:53] <peat-psuwit> http://bazaar.launchpad.net/~mir-team/mir/development-branch/view/head:/src/platforms/android/server/device_quirks.cpp#L176
[17:53] <peat-psuwit> Why the pixel format is hard-coded to mir_pixel_format_abgr_8888?
[18:30] <anpok> that is only used to query information about the gpu..
[18:30] <anpok> do you ran into problems with that?
[18:37] <peat-psuwit> anpok: Well, the problem is my device don't support that format.
[18:38] <peat-psuwit> As the context is created, an exception gets thrown.
[18:39] <peat-psuwit> "std::exception::what: could not select EGL config for use with framebuffer"
[18:39] <anpok> peat-psuwit: hm then you could write a function that tests the device name and in your case returns a differen pixel format ..
[18:39] <anpok> make an MP for that..
[18:42] <peat-psuwit> anpok: Actually, I have another idea. I'll put that in try-catch block. If that failed, then try another format.
[18:42] <peat-psuwit> Thanks for your idea anyway.