=== kgunn is now known as Guest52384
=== nudtrobert1 is now known as nudtrobert
=== maclin1 is now known as maclin
[09:13] <Saviq> greyback_, "why not" what?
=== timp is now known as t1mp
[11:28] <tsdgeos> Mirv: fix for the u1-dbqt FTBFS at https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src/+bug/1447182
[11:28] <ubot5`> Ubuntu bug 1447182 in qtbase-opensource-src (Ubuntu) "u1db-qt FTBFS with Qt 5.5" [High,New]
[11:31] <Mirv> tsdgeos: wowee, thanks! just uploaded my newest qtbase 5.5.1 build 40 mins ago but I'll rebuild it later
[11:32] <Mirv> tsdgeos: and thanks for the rush of other fixes/investigations too!
[11:32] <tsdgeos> Mirv: unfortunately that patch won't be in 5.5.1 so you'll have to distropatch it
[11:32] <Mirv> tsdgeos: I'm not surprised by it not traveling through the time to yesterday :)
[11:32] <tsdgeos> ;)
[11:33] <Mirv> tsdgeos: I've other post-5.5.1 patches too already
[11:34] <Mirv> tsdgeos: 5.5.1 will change networking in the way the may pose problems for us. I've experimented backporting fixes to our vivid image at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-032/+packages and using those weather app claims to have no network. I'm not sure if the fixes increased the need to use apparmor blocked functions.
[11:34] <tsdgeos> :/
[11:34] <Mirv> since the upstream patches (one of which got in post-5.5.1) fix the qnam hang and accessible() function bug #1470700
[11:34] <ubot5`> bug 1470700 in thumbnailer (Ubuntu) "QNetworkAccessManager hangs when in flight mode" [Undecided,Triaged] https://launchpad.net/bugs/1470700
[11:35] <Mirv> tsdgeos: but I may ask for your ponderings once I've 5.5.1 ready, if it still shows the same problem. it might be weather app doing something really wrong too, since no other app had any network problems.
[11:36] <tsdgeos> sure
=== alan_g is now known as alan_g|lunch
[12:15] <dandrader> didn't you have a branch for usc to solve (or work around) its window positioning issues in  multimonitor?
[12:15] <dandrader> greyback_, ^
[12:17] <pstolowski> Saviq, mzanetti hey, i'm going to mark silo 4 for landing, it's been delayed for months but finally works!
[12:17] <pstolowski> Saviq, mzanetti nb, i've rebuilt it this morning
[12:18] <greyback_> dandrader: I did have something a long time ago, but was more to rotate the display than anything else
[12:19] <greyback_> dandrader: I've logged https://bugs.launchpad.net/unity-system-compositor/+bug/1506846
[12:19] <ubot5`> Ubuntu bug 1506846 in Unity System Compositor "[multimonitor] nested server surface positioning incorrect" [Undecided,New]
[12:19] <dandrader> greyback_, it was adding a side-by-side parameter to the command line...
[12:19] <greyback_> dandrader: that doesn't fix it completely though
[12:22] <dandrader> Saviq, greyback_, I'm a bit puzzled about the landing strategy. I thought we were going to land multimonitor knowing it had some issues as a way of moving foward and that mir folks have something ready in the images to debug. as opposed to land only once it's in good shape (which can take too long). specially considering that since there's no multimonitor  support yet, we wouldn't be regressing anything
[12:24] <dandrader> Saviq, greyback_or is it that we want to be sure that all the existing issues in multimonitor are not on our side before landing?
[12:27] <pstolowski> Saviq, mzanetti let me know if i should wait for something else
=== alan_g|lunch is now known as alan_g
[13:32] <Saviq> pstolowski, if you have it tested, kick it, we have silo 22 in the works, but not gonna be ready with it today
[13:32] <Saviq> dandrader, I would like to at least have an idea of what's wrong when we have a clearly reproducible issue
[13:41] <ltinkl> dandrader, what do you think of this: http://paste.ubuntu.com/12798836/
[13:42] <dandrader> ltinkl, they're not the same
[13:43] <dandrader> ltinkl, ScreenController::getWindowForPoint checks the screen geometry, not the window geometry
[13:43] <dandrader> ltinkl, which is what I guess the QGuiApplication method does
[13:43] <ltinkl> dandrader, a sec
[13:43] <dandrader> ltinkl, because in mir the displays live in the same coordinate system
[13:44] <dandrader> ltinkl, like in a big virtual desktop
[13:44] <ltinkl> dandrader, http://code.woboq.org/qt5/qtbase/src/gui/kernel/qguiapplication.cpp.html#_ZN15QGuiApplication10topLevelAtERK6QPoint
[13:44] <dandrader> ltinkl, and qtmir puts the screens one next to the other
[13:44] <ltinkl> dandrader, I think it does the same
[13:45] <dandrader> ltinkl, see tileddisplayconfigurationpolicy.cpp
[13:45] <dandrader> ltinkl, well, if it does the same then I guess it's fine
[13:45] <ltinkl> dandrader, well just look at the Qt code
[13:45] <ltinkl> dandrader, I think it does roughly the same, but you're the expert ;)
[13:46] <dandrader> ltinkl, almost the same
[13:46] <dandrader> ltinkl, it also calls QPlatformScreen::topLevelAt
[13:47] <ltinkl> dandrader, but the old code didn't
[13:47] <ltinkl> dandrader, plus it checks if the window  is visible
[13:47] <dandrader> ltinkl, and I'm not even sure if the original code is totally correct
[13:48] <ltinkl> dandrader, it doesn't (didn't) take QGuiApplication::topLevelWindows() into account, or is there always only one toplevel?
[13:49] <dandrader> ltinkl, touch input comes from the builtin display. doesn't make sense trying to match it with the external one
[13:49] <dandrader> ltinkl, and I've no idea what would happen if you connect an eternal monitor that also has a touchscreen (not even sure how that works, the monitor would send the touch input through usb?)
[13:49] <ltinkl> dandrader, unless it's also a touch display... but meh
[13:50] <ltinkl> dandrader, ye not sure either :)
[13:50] <dandrader> ltinkl, and if mir would map the touch coords into this big virtual desktop space or not
[13:50] <dandrader> ltinkl, I say most probably not...
[13:51] <dandrader> ltinkl, so for now I think the sane thing to do is to simply send touch input to the built-in display and be done with it. writing a big TODO on top explainint the above scenario
[13:51] <ltinkl> dandrader, right, so for touch this is probably ok; I was more curious about my wheel events, there using it is likely not correct
[13:52] <ltinkl> dandrader, I should probably be using qGuiApp->topLevelAt()
[13:52] <dandrader> ltinkl, for mouse events you send to the window that the cursor
[13:52] <ltinkl> dandrader, since you can send wheel event to non-focused (partially) covered windows
[13:52] <ltinkl> dandrader, click yes, wheel not
[13:54]  * ltinkl bbl, need to pick kids from school, wife not feeling well
[13:57] <dandrader> ltinkl, are you talking about qtmir windows (shell windows) or client/application windows inside DesktopStage.qml?
[14:51] <Saviq> dednick, didn't we make prompts persistent? bug #1358225
[14:51] <ubot5`> bug 1358225 in unity8 (Ubuntu) "Locking+unlocking phone mysteriously dismisses location access prompt" [Undecided,New] https://launchpad.net/bugs/1358225
[14:51] <dednick> Saviq: pretty sure we did
[14:51] <ltinkl> dandrader, client windows inside shell
[14:52] <dednick> Saviq: although, perhaps they are stopped due to the suspension of the app.
[14:53] <dandrader> ltinkl, in which case you shouldn't be looking at qtmir code at all
[14:54] <Saviq> dednick, but only the app is SIGSTOP'ed, not the prompt
[14:54] <dednick> Saviq: the prompts are notified of their suspension
[14:55] <Saviq> dednick, yeah, and the helper needs to decide what tod o
[14:55] <Saviq> we don't close them
[14:55] <dednick> Saviq: no, unless something is going wrong
[14:55] <Saviq> dednick, I can't reproduce it anyway
[14:56] <Saviq> ah
[14:56] <Saviq> Ubuntu 14.10 r197
[14:56] <dednick> Saviq: ah
[14:56] <Saviq> Bug #1358225 reported by Matthew Paul Thomas on 2014-08-18
[14:56] <ubot5`> bug 1358225 in unity8 (Ubuntu) "Locking+unlocking phone mysteriously dismisses location access prompt" [Undecided,New] https://launchpad.net/bugs/1358225
[14:56] <dednick> yeah..
[14:56] <Saviq> → Fix released
[14:56] <dednick> \o/
[14:56] <ltinkl> dandrader, ye, I'm looking at unity8
[14:57] <dandrader> Saviq, greyback_, pushed the fix for the shell with outdated size
[14:57] <Saviq> dandrader, ack
[14:57] <Saviq> pstolowski, so what's the deal with silo 4? if you don't land it today, I'm putting a lock on unity{8,-api} landings :P
[14:58] <pstolowski> Saviq, i cannot mark it qa ready for some reason, bileto doesn't like me
[14:58] <dandrader> ltinkl, so the wheel event should go to whatever MirSurfaceItem has active focus (if any)
[14:58] <Saviq> pstolowski, done
[14:58] <dandrader> ltinkl, like any other mouse or key event
[14:58] <pstolowski> huh?
[14:58] <pstolowski> just like that? :O
[14:59] <ltinkl> dandrader, I don't think so... it's not what happens on X/u7 or wayland (unless we want to differ)
[14:59] <Saviq> dandrader, no, wheel event goes to whatever surface is under the cursor
[14:59] <ltinkl> exactly
[14:59] <pstolowski> Saviq, thanks!
[14:59] <Saviq> same as any other event
[14:59]  * dandrader checks
[14:59] <dandrader> ltinkl, Saviq, right
[15:00] <ltinkl> dandrader, only the key event should imo
[15:00] <Saviq> dandrader, windoze does that, and I hate its guts for it
[15:00] <dandrader> ltinkl, and QQuickWindow doesn't handle wheel events like that?
[15:00] <dandrader> ltinkl, s/handle/dispathces
[15:00] <Saviq> I'M POINTING AT THE THING I WANT TO INTERACT WITH, WHAT THE HELL ARE YOU DOING!?
[15:00] <ltinkl> :)
[15:00] <ltinkl> dandrader, what do you mean?
[15:01] <ltinkl> dandrader, at the moment, it does the right thing if you click inside a window (to activate it)
[15:01] <dandrader> ltinkl, because QQuickWindow is the one dispatching input (mouse, touch) events to items in the qml scene. so if the qml item under the mouse is not the one getting wheel events it's QQuickWindow's fault
[15:01] <ltinkl> dandrader, then it works also for non-focused windows (weird...)
[15:02] <Saviq> pstolowski, yeah, but try and find out with robru why it didn't work for you
[15:02] <dandrader> ltinkl, unless our unfocused windows are disabled
[15:02] <ltinkl> dandrader, disabled as in?
[15:03] <dandrader> ltinkl, QQuickItem.enabled = false
[15:03] <ltinkl> dandrader, hmm ye
[15:03] <pstolowski> Saviq, yeah i did that
[15:03] <ltinkl> dandrader, so in a desktop scenario, any non-focused window is disabled?
[15:04]  * Saviq says occlusion-driven
[15:04] <dandrader> ltinkl, I don't know. I was just hypothesizing
[15:04] <Saviq> if you can't see the window, you don't interact with it
=== dandrader is now known as dandrader|afk
[15:04] <ltinkl> Saviq, partially hidden
[15:04] <ltinkl> Saviq, behind the focused one
[15:04] <Saviq> ltinkl, you can see it then
[15:04] <ltinkl> well, we have a _lot_ of focus related issues
[15:05] <Saviq> sure, dednick's working on part of that (occlusion-based)
[15:05] <ltinkl> click the window decoration -> the window isn't activated, no focus
[15:05] <ltinkl> restore the window from minimization, it's raised but doesn't get focus
[15:06] <ltinkl> strangely, the only thing that works reliably is the spread (or alt+tab)
[15:13] <Saviq> ltinkl, you know the drill - file a bug, fix it, MP, I'll land it for you ;P
[15:13] <ltinkl> Saviq, ye ye :)
[15:50] <Saviq> greyback_, dandrader|afk, so do we need --display-config=sidebyside in the session after all?
[15:50] <greyback_> Saviq: I don't think so
[15:51] <greyback_> alan_g tells me we should get the behaviour we desire from usc by default
[15:51] <Saviq> ok /me drops, we can add with fix for u-s-c if needed
[15:51] <greyback_> yep
[15:51] <alan_g> USC defaults to sidebyside
[15:52] <alan_g> But (empirically) display-config options are not honoured on a replug
[15:53]  * alan_g is still investigating why lp:1506846
[15:55] <Saviq> ok /me rebuilds silo 22 for the last time
[15:55] <Saviq> dandrader|afk, greyback_, {do,can} we have a tag for multimon bugs?
[15:56] <greyback_> Saviq: there's this one https://bugs.launchpad.net/qtmir/+bugs?field.tag=multimonitor
=== dandrader|afk is now known as dandrader
[15:57] <Saviq> greyback_, ack, please use it for any subsequent bugs you guys file
[15:57] <Saviq> dandrader, ↑
[15:58] <dandrader> ok
[15:59] <dandrader> greyback_, I think the resize issue was the only thing from my side. want/need help with something else?
[15:59] <Saviq> greyback_, uhm... https://bugs.launchpad.net/bugs/+bugs?field.tag=multimonitor
[16:00] <greyback_> ah, it's quite a busy one already
[16:01] <greyback_> need a new tag so
[16:03] <Saviq> greyback_, yeah, otherwise we hunt for it between all the different projects
[16:36] <dandrader> Saviq, did you really have to merge unity8/liveCaption into unity8/externalMonitor? I wanted to have a branch depending on the latter
[16:38] <Saviq> dandrader, hum? I merged mousePointer, not liveCaption
[16:38] <Saviq> dandrader, needed it because there was a conflict further up the chain
[16:39] <Saviq> dandrader, and not sure what's the problem? can't you have a branch depending on externalMonitor?
[16:39] <dandrader> Saviq, that's not what history tells :)
[16:40] <dandrader> Saviq, because now a branch depending on externalMonitor  will also have to depend on all liveCaption branches
[16:40] <dandrader> Saviq, in qtubuntu and qtmir
[16:40] <dandrader> Saviq, and unity-api
[16:40] <Saviq> dandrader, but wait, https://code.launchpad.net/~unity-team/unity8/externalMonitor/+merge/273829
[16:41] <Saviq> dandrader, unless I mixed the comment up
[16:42] <dandrader> Saviq, check it with "bzr qlog"
[16:42] <Saviq> yeah doing
[16:45] <Saviq> dandrader, so yeah, I messed something up, but you undid it?
[16:45] <dandrader> Saviq, I didn't
[16:45] <Saviq> so where's that commit in https://code.launchpad.net/~unity-team/unity8/externalMonitor...
[16:46] <Saviq> ah now I see
[16:46] <Saviq> it hid under the merge
[16:47] <Saviq> dandrader, so yeah, sorry, I should've merged mousePointer instead
[16:48] <Saviq> must've thought liveCaption is between that and externalMonitor
[16:48] <dandrader> Saviq, is it even possible to undo it? guess only if you rewrite history
[16:48] <Saviq> dandrader, yeah, uncommit, push --overwrite
[16:49] <Saviq> we'd need ltinkl to uncommit x2 and remerge/resolve conflict in rotateScreenshots
[16:49] <dandrader> Saviq, don't forget my commit is inbetween
[16:49] <Saviq> dandrader, yeah I know
[16:49] <Saviq> uncommit, shelve, uncommit, revert, unshelve, commit
[16:50] <Saviq> or the like
[16:50] <Saviq> ltinkl, you around?
[16:54] <Saviq> dandrader, ok, I'll fix externalMonitor and let ltinkl know what to do
=== alan_g is now known as alan_g|EOD
[17:07] <Saviq> dandrader, overwrote externalMonitor
[17:07] <Saviq> dandrader, now I understand what tricked me
[17:07] <Saviq> https://ci-train.ubuntu.com/job/ubuntu-landing-022-1-build/200/console
[17:08] <Saviq> liveCaption was merged here before externalMonitor, so I thought that was the chain
[17:08] <dandrader> Saviq, ok, thanks
[17:08]  * greyback_ eow
[17:08] <Saviq> o/
[17:08] <greyback_> good weekend all
=== willcooke_ is now known as willcooke
[17:13] <Saviq> dandrader, ok, all resolved
[17:13] <Saviq> ltinkl, sorry, made a small mess yesterday with the merges, have resubmitted rotateScreenshots under unity-team now: https://code.launchpad.net/~unity-team/unity8/rotateScreenshots/+merge/274743
[17:14]  * Saviq feels like editing prerequisites shouldn't be a resubmission
[17:16] <Saviq> dandrader, ok, all resolved now, externalMonitor clear of deps
[17:17] <Saviq> and seems everything merges still
[17:22] <Guest52384> Saviq: silo 22 much better, on connect, i see what's expected now (on monitor) tried a few different ways (screen already on, connect then turn on etc)
[17:23] <Guest52384> but seeing consistent problem on disconnect
[17:23] <Saviq> look out @all, Guest52384 is kgunn hiding
[17:23] <Guest52384> oh, wow, didn't notice...weird
[17:24] <Saviq> Guest52384, yeah, that's a u-s-c spin most likely, Gerry's been looking for a traceback, not sure if filed a bug yet
[17:24] <Guest52384> Saviq: fwiw, it seems much better, unsure if you wanna land as is with known bug for disconnect....
[17:26] <Saviq> /nick kgunn
[17:26] <Saviq> please
[17:26] <Saviq> Guest52384, yeah, I wanna land, just not advertise it's done
[17:27] <Guest52384> Saviq: i did, but it's not even responding to /nick
[17:28] <kgunn> that fixed it
[17:28] <kgunn> at any rate +1 to landing
[17:32] <Saviq> kgunn, I only delayed because it got worse since before Mir 0.17
[17:33] <Saviq> and I had to fight with bluetooth
[17:36]  * kgunn agrees, it at least had to connect
[17:38] <Saviq> kgunn, well, fwiw we didn't do anything to address your issues :)
=== dandrader is now known as dandrader|afk
[17:54] <Saviq> o
[17:54] <Saviq> /
=== dandrader|afk is now known as dandrader