[11:41] <greyback> tsdgeos: https://code.launchpad.net/~aacid/qtmir/unlikelyResetStartTime/+merge/280569 is not merging into trunk, deliberate?
[11:41] <tsdgeos> greyback: nah i messed up merge into with prerequisite i guess
[11:42] <tsdgeos> greyback: give me a min to fix it
[11:42] <greyback> sure
[11:43] <tsdgeos> greyback: done
[11:50] <greyback> dandrader: hey, I've a few old reviews I need you to quickly look at again, can I add to your todo list:
[11:50] <greyback> https://code.launchpad.net/~gerboland/qtmir/fix-cmdline-args/+merge/277691
[11:50] <greyback> https://code.launchpad.net/~unity-team/qtubuntu/DPR2/+merge/281664
[11:51] <dandrader> greyback, ok
[11:51] <greyback> and this one needs another go-over: https://code.launchpad.net/~unity-team/qtmir/dpr/+merge/257514
[11:51] <greyback> I'm in review mode today too
[12:18] <Saviq> greyback, got people looking at the DPR silo yet? mzanetti maybe you could spend some time with it?
[12:19] <greyback> Saviq: at the silo, no.
[12:19] <mzanetti> kk, can give it a test
[12:19] <greyback> https://requests.ci-train.ubuntu.com/#/ticket/776 <- docs in desc
[12:19] <greyback> mzanetti: ^
[12:22] <mzanetti> ack, ta
[13:13] <Saviq> @unity, btw, you can already access https://unity8-jenkins.ubuntu.com/ and see what's happening there if you like
[13:17] <mzanetti> dandrader, hey, I just came by this https://bugs.launchpad.net/mir/+bug/1517133 and then there is: https://code.launchpad.net/~ken-vandine/unity8/mouse_touchpad_schema/+merge/281643
[13:18] <mzanetti> dandrader, what is the plan for mouse speed settings?
[13:18] <mzanetti> should unity8 read them from config and tell values to Mir?
[13:20] <dandrader> mzanetti, afaik, no plan yet. that sounds ok to me. wonder if libinput has its own config file or something
[13:20] <mzanetti> dandrader, well, we need more than just speed and accel. ken's branch also prepares things like changing button order for left-handers etc
[13:21] <mzanetti> so unless libinput can do all that stuff on its own, I guess we want dconf & unity8 to handle it. if libinput can, we might want to talk to ken so the settings app controls that?
[13:22] <dandrader> mzanetti, also maybe mir wants to hide libinput as an implementation detail
[13:22] <dandrader> mzanetti, so mir users should be oblivious to it
[13:22] <mzanetti> yes, fair point
[13:23] <mzanetti> kk, thanks
[13:23] <mzanetti> lets go with unity8 controlling things then
[13:23] <dandrader> mzanetti, don't even know if mir already exposes a way for use to tweak those things
[13:23] <dandrader> anpok_, ^^
[13:24] <dandrader> s/for use/for us
[13:42] <greyback> dandrader: there is, see include/server/mir/input/device.h
[13:45] <ltinkl> mzanetti, dandrader: there is and libinput has an API to control this: http://wayland.freedesktop.org/libinput/doc/latest/group__config.html
[13:46] <ltinkl> even the left/right handedness stuff etc
[13:46] <greyback> ltinkl: libinput isn't exposed through mir though, it's internal only - instead mir has apis which we can use (hopefully all we need)
[13:46] <ltinkl> mzanetti, so maybe system settings should set this directly?
[13:46] <ltinkl> greyback, yeah, that's what I meant
[13:47] <greyback> ah ok
[13:47] <ltinkl> but I don't see the need for unity8 to control these things (if we don't have any config UI)
[13:47] <ltinkl> system settings has
[13:47] <ltinkl> or will have
[13:47] <greyback> ltinkl: ordinary apps can't use libinput to configure stuff tho (unless they're root), it has to be via mir then
[13:48] <greyback> unless I'm very mistaken ofc
[13:48]  * greyback a bit wobbly on this tbh
[13:48] <ltinkl> greyback, yup, so am I correct in thinking system settings should drive this via Mir?
[13:48] <greyback> ltinkl: yes
[13:48] <greyback> we'll need to create a quick dbus api in unity8 which uses these Mir apis
[13:49] <seb128> ltinkl, system settings is the wrong place imho
[13:49] <seb128> it's not a service
[13:49] <seb128> it's not going to be active on boot/login
[13:49] <seb128> something needs to read the config and apply it on session start
[13:49] <ltinkl> right, so we need that DBUS bridge
[13:49] <seb128> something should be unity8 imho
[13:49] <seb128> or we needs a settings daemon...
[13:49] <ltinkl> seb128, ye what gerry wrote, a DBUS service
[13:50] <seb128> wfm
[13:50] <seb128> a service, I don't care much if it's a dbus one
[13:50] <ltinkl> which gets started together with u8 and reads/applies those settings
[13:50] <seb128> or a systemd unit or whatever
[13:50] <greyback> dbus handy as quick, and appArmor can manage permissions
[13:50] <greyback> (quick to implement with Qt that is)
[13:51] <ltinkl> greyback, yeah and there might come a moment when we actually use the stuff to read some config from within the shell :)
[13:52] <greyback> ltinkl: whoa, let's not get too optimistic! :D
[14:08] <Saviq> ltinkl, greyback, seb128, won't we need a keyboard indicator at some point anyway, shouldn't that be who drives it?
[14:09] <seb128> Saviq, the way it currently works on unity7 is that the indicator changes the gsettings config and the settings daemon watch the config and apply it to the server
[14:10] <seb128> but I guess the indicators could to that themselve
[14:10] <seb128> I don't have a strong preference either way
[14:10] <greyback> Saviq: I think it's pointless to make a real keyboard indicator. All the relevant state for keymap is in unity8 anyway. We'd just be export that state to separate indicator process, for it to send that state back
[14:11] <Saviq> greyback, right, in that sense we could inject a dummy indicator we, in fact, own
[14:11] <Saviq> the UI for it, I mean
[14:11] <greyback> yeah
[14:12] <Saviq> which roughly coincides with what Wellark_ wants us to talk about for indicators, where they would supply us with QML instead of us interpreting the ever-growing GMenuModel approach
[14:13] <greyback> indeed
[15:04] <mzanetti> greyback, testing the dpr silo. when disabled, I couldn't spot any issues. when enabled, I can confirm your finding. not exactly sure why the terminal would behave like that
[15:04] <mzanetti> if I change font size in the terminal settings to make it look normal, things get quite blurry
[15:06] <mzanetti> I like how the scrolling speed is fixed
[15:10] <Saviq> mzanetti, terminal likely deals in real pixels, and gets scaled up, similar to canvas
[15:10] <mzanetti> I wonder if we shouldn't fix the shell rotation animation at least
[15:10] <mzanetti> given that's in our hands
[15:11] <mzanetti> but apart from that, I guess we should land it, and we should push for fixes for the rest
[15:11] <greyback> mzanetti: that's my strategy
[15:12] <greyback> mzanetti: I found another issue that occasionally locks up the shell at DPR2 (indicator image scaling x2 for infinity), so until I've that fixed, we're leaving it disabled
[15:15] <mzanetti> greyback, ah, the Icon in the indicator is still an issue?
[15:16] <mzanetti> greyback, the Icon is a bit broken anyways, it frequently prints binding loops about implicitHeight without DPR too
[15:16] <greyback> mzanetti: yep
[15:17] <mzanetti> greyback, I've update th issues description
[15:17] <mzanetti> e.g. UbuntuShape is fine, but ProportionalShape isn't
[15:17] <mzanetti> all ActitivyIndicators are too big
[15:18] <mzanetti> but I've ran the test plan with DPR=1, couldn't spot an issue there
[15:20] <anpok_> o_O
[15:20] <ltinkl> Saviq, I did a (successful) indicator injection in my desktopBrightness branch (brightness slider)
[15:20] <anpok_> i will be back next week..
[15:21] <anpok_> usc in 0.18 has a DBUS API to confgure input devices.. the interface is com.canonical.Unity.Input..
[15:21] <anpok_> it coves everything u-s-s exposes in the gsettings schema..
[15:22] <anpok_> for 0.19 or 0.20 I will add a mir client API so nested servers and clients can change the input settings too .. additionally they will be able to notice which devices are plugged unplugged ...
[15:23] <anpok_> dandrader, mzanetti, greybac ^
[15:23] <mzanetti> ack
[15:24] <mzanetti> anpok_, I think the speed config stuff is gaining priority now... but lets talk next week when you're back
[15:24] <ltinkl> anpok_, I guess it doesn't cover (yet) the new stuff proposed in https://code.launchpad.net/~ken-vandine/unity8/mouse_touchpad_schema/+merge/281643 ?
[15:30] <anpok_> ltinkl: it does .. double click times are a toolkit thing
[15:30] <anpok_> the other ones should map directly