[09:15] <tsdgeos> Saviq: that metatype error is weird :D I can reproduce with this simple code http://paste.ubuntu.com/14047921/ http://paste.ubuntu.com/14047922/
[09:15] <tsdgeos> still digging
[09:17] <Saviq> kk
[09:44] <corn_field> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1526591
[09:54] <Saviq> corn_field, can you confirm it's back after a few seconds? (like under 10s)
[09:57] <corn_field> Saviq, nope, i've waited 2 minutes and nothing, also the UI is in a strange state, if i tap on the video it does nothing, if i tap the screen i see the focus animation but still on a black screen
[09:58] <Saviq> corn_field, k, recovered fine here after a few seconds - anyway, not a unity8 issue, reassigned to camera-app (might get reassigned to the media backends in the end)
[09:59] <corn_field> Saviq, if i swipe from the right i get into the photo roll, that works but i i go back it;s still the black screen
[09:59] <corn_field> Saviq, yep, probably not unity8 bug :D
[10:00] <corn_field> btw, i'm on arale/mx4 not bq
[10:12] <Saviq> dandrader, need to bump unity-shell-application CMake req in lp:~dandrader/qtmir/sizeHints
[10:12] <Saviq> should be =13, is =12
[10:14] <dandrader> Saviq, done
[10:14] <Saviq> tx
[10:30] <tsdgeos> Saviq: so i "fixed" the ugly warning but testDragHandle still crashes :/
[10:54] <Saviq> tsdgeos, you'll get there, I'm sure
[11:10] <cimi> tsdgeos, if I add a department then I cancel it, the text in the search box is not aligned, silo 54
[11:11] <tsdgeos> cimi: do you have a screenshot?
[11:13] <cimi> tsdgeos, telegram :)
[11:13] <tsdgeos> hmm
[11:13] <tsdgeos> ok
[11:13] <tsdgeos> pstolowski was seeing this too
[11:14] <tsdgeos> but i wasn't i was hoping it was because things
[11:14] <pstolowski> yes, i've seen this many times
[11:14] <tsdgeos> but it is not i guess
[11:14] <tsdgeos> i'll have to have a look now :D
[11:14] <pstolowski> i still should have screenshots if that helps
[11:14] <cimi> :D
[11:15] <tsdgeos> pstolowski: what unity-api branch am i supposed to use value-slider-iface ?
[11:16] <pstolowski> tsdgeos, https://code.launchpad.net/~stolowski/unity-api/value-slider-iface/+merge/278428
[11:26] <tsdgeos> cimi: how do you do that exactly?
[11:26] <tsdgeos> pstolowski: ↑
[11:27] <tsdgeos> it works fine in make tryDash here
[11:27] <pstolowski> tsdgeos, o
[11:28] <pstolowski> tsdgeos, i'll let you know later after installing filters silo again (currently investigating something else)
[11:29] <pstolowski> tsdgeos, btw is the fix for the textfiled regression on the image yet?
[11:29] <tsdgeos> pstolowski: what textfield regression? the click thing?
[11:29] <tsdgeos> yes
[11:29] <pstolowski> tsdgeos, k, cool
[11:31] <greyback> Saviq: dandrader: https://code.launchpad.net/~gerboland/qtubuntu/fix-max-full-switch-size/+merge/280699
[11:31] <cimi> tsdgeos, I select a department, I delete it
[11:32] <tsdgeos> cimi: how do you delete it?
[11:32] <cimi> the cancel?
[11:32] <cimi> iir
[11:33] <tsdgeos> can you please try to give me the exact steps?
[11:33] <Saviq> greyback, tx
[11:38] <tsdgeos> cimi: ok i can reproduce, interestingly doesn't happen on the desktop :S
[11:44] <dandrader> @unity any of you guys run unity8 or unity8-dash on your desktop (as an X11 application) and use the touch emulation from mouse events feature?
[11:44] <dandrader> @unity note that I'm not counting the "make tryFoo" case
[11:54] <tsdgeos> cimi: fixed
[11:54] <tsdgeos> pstolowski: can you trigger a silo rebuild
[11:56] <pstolowski> tsdgeos, ok, build started
[12:00] <dandrader> Saviq, mzanetti_, do we care about x86 vivid builds?
[12:01] <mzanetti_> depends :D
[12:01] <mzanetti> dandrader, have more context?
[12:02] <dandrader> mzanetti, so I'm updating MouseTouchAdaptor to work with Qt. 5.5
[12:02] <dandrader> mzanetti, and in doing so it requires yet more libs besides xcb: x11 and xi2
[12:03] <dandrader> mzanetti, so I'm changing the CMakefiles so that we don't build touch emulation from mouse events on arm
[12:03] <dandrader> mzanetti, to get rid of those "legacy" dependencies on the phone
[12:03] <dandrader> mzanetti, and it doesn't make sense to emulate touches on the phone anyway
[12:04] <dandrader> mzanetti, but new MouseTouchAdaptor code might have something Qt 5.5 specific there
[12:04] <dandrader> mzanetti, ie, something that wouldn't work on Qt 5.4, which is what we have in Vivid+overlay
[12:04] <mzanetti> ah, I see
[12:05] <mzanetti> hmm... we do have 5.4 in the vivid-overlay?
[12:05] <mzanetti> erm, 5.5
[12:05] <mzanetti> no
[12:05] <dandrader> mzanetti, qt 5.5 is a xenial-only thing I think
[12:05] <mzanetti> ah, so you'd ifdef it away for armhf builds
[12:05] <dandrader> mzanetti, yes
[12:06] <mzanetti> mhm... if you're adding those ifdefs anyways, can't you just add "&& QT_VERSION >= 5.5" or so?
[12:06] <dandrader> mzanetti, so the question is whether it's worth the trouble of checking if MouseTouchAdaptor also builds in Qt 5.4 (vivid)
[12:06] <dandrader> mzanetti, and works
[12:06] <mzanetti> well, I would think it shouldn't be much efforts given you do the stuff for armhf already
[12:07] <mzanetti> but if I'm wrong with that, I guess we can give up vivid&x86 support in trunk...
[12:07] <dandrader> mzanetti, and the second question is whether I should keep the MouseTouchAdaptor code in unity8 and unity8-dash "main.cpp"s
[12:08] <dandrader> mzanetti, as it's only useful if you run them directly as an app in your desktop and pass "--mousetouch"
[12:08] <dandrader> mzanetti, the make tryTests do it in another way
[12:09] <mzanetti> I for one haven't used ./run.sh in ages
[12:09] <mzanetti> and also the whole shell can now be operated with mouse too
[12:09] <mzanetti> so I guess it can go away if it's a maintainance effort
[12:10] <dandrader> mzanetti, well, run "make tryShell" in trunk and try to move away the greeter :-D
[12:10] <mzanetti> didn't you say the make try stuff wouldn't be affected?
[12:11] <mzanetti> but yeah, I guess the issue that the small greeter version is not mouse friendly
[12:11] <dandrader> mzanetti, hmmm looks like autopilot uses it:
[12:11] <dandrader> mzanetti, tests/autopilot/unity8/shell/tests/__init__.py:152:                '-mousetouch'
[12:11] <dandrader> mzanetti, that's what I'm fixing now
[12:11] <mzanetti> which is probably a bad idea
[12:12] <dandrader> mzanetti, the touch emulation is broken in xenial now that it has qt 5.5
[12:12] <mzanetti> autopilot should not use mousetouch but instad tap() and mouseClick() when needed
[12:12] <dandrader> mzanetti, absolutely
[12:12] <dandrader> mzanetti, but I'm not touching that can of worms :-)
[12:12] <mzanetti> haha
[12:12] <mzanetti> well, I guess it's indeed easier to fix mousetouch then :D
[12:12] <dandrader> mzanetti, yes :D
[12:13] <mzanetti> however, we should at least a trello card for that can of worms
[12:13] <dandrader> mzanetti, yes
[12:13] <dandrader> mzanetti, shall I create one?
[12:13] <mzanetti> please
[12:18] <dandrader> mzanetti, https://trello.com/c/TyEoxwAj
[13:42] <mzanetti> dandrader, turns out this is ours after all: https://bugs.launchpad.net/mir/+bug/1517133
[13:44] <Saviq> dandrader, mzanetti, agreed we should do away with --mousetouch completely, if we can, small greeter version should probably react to click (change text to "... or click your mouse" when it discovers mouse hover over itself?)
[13:45] <mzanetti> yeah... sounds reasonable
[13:48] <dandrader> mzanetti, about the mouse speed bug. will check once mir 0.18 lands
[13:49] <dandrader> mzanetti, I would take duflu's observations with a grain of salt.
[14:21] <tsdgeos> Saviq: greyback: can you guys have a look at https://code.launchpad.net/~aacid/unity8/dash_backgroud_source_size_rework/+merge/276157 ?
[14:22] <dandrader> tsdgeos, would you have some time to review this one? https://code.launchpad.net/~dandrader/unity8/updateMouseTouchAdaptor/+merge/280718
[14:23] <tsdgeos> dandrader: sure
[14:23] <dandrader> tsdgeos, thanks
[14:23] <Saviq> tsdgeos, ack
[14:24] <greyback> tsdgeos: ack, looking
[14:24] <greyback> wow that's a high resolution image
[14:25] <greyback> is it literally just 2 triangles?
[14:25] <greyback> or are there gradients I cannot see
[14:26] <Saviq> greyback, not worth it to make them into anything smarter, it's only loaded and scaled once on startup, and the next time we get an updated background we'd have to yank it out anyway
[14:27] <greyback> Saviq: sure, it's just a lot of scaling to do at startup
[14:27] <greyback> I'm not suggesting doing anything fancy
[14:28] <Saviq> greyback, ideas welcome
[14:28] <Saviq> we could in theory ship 5 different sizes of the background... but I'd have to see numbers that it's actually worth it
[14:29] <greyback> Saviq: surely 1080p is the highest resolution realistically we support
[14:29] <Saviq> and ultimately we should generate and ship one that's exactly right for the device
[14:29] <Saviq> greyback, desktop
[14:29] <Saviq> greyback, fullscreen dash
[14:30] <greyback> Saviq: sure, but that's still max 1920 pixels
[14:30] <Saviq> greyback, 4K
[14:31] <Saviq> ask mzanetti
[14:31] <greyback> ok
[14:31] <Saviq> greyback, not like there are no phones with 4K screens already
[14:31] <mzanetti> ?
[14:31] <greyback> such a simple image might be more efficient saved and uncompressed with svg
[14:32] <greyback> but would require some research to prove
[14:32] <Saviq> greyback, you need to generate a bitmap from the svg first anyway
[14:32] <greyback> sure, but it doesnt have to read loads of pixels from uncompressed png
[14:33] <greyback> efficient cpu time I mean
[14:33] <Saviq> it's not compressed?
[14:34] <greyback> it needs to uncompress portions of the png before sampling
[14:36] <Saviq> greyback, so yeah, we'd need numbers to prove that anything else can get us substantial startup improvements
[14:36] <greyback> right
[14:36] <tsdgeos> Saviq: i've pushed a new change to https://code.launchpad.net/~aacid/unity8/fixQmlTestsNewSDK/+merge/280260 since another _action_button sneaked, do you need to re-top approve or it's ok?
[14:37] <greyback> Saviq: startup plus hotplug monitor events
[14:42] <Saviq> tsdgeos, it's ok
[14:43] <tsdgeos> dandrader: so we're good asuming we will never support arm+x11?
[14:43] <Saviq> greyback, in theory moves across monitor boundaries, too, but that we can avoid
[14:44] <dandrader> tsdgeos, I don't see any use case for arm+x11
[14:46] <tsdgeos> dandrader: it's the same use as x86+x11, just less common :D
[14:47] <Saviq> dandrader, please sort alphabetically, though
[14:48] <Saviq> in debian/*
[14:49] <dandrader> Saviq, done
[14:53] <tsdgeos> dandrader: could you add in the commit what this actually fixes besides whta ti does?
[14:53] <tsdgeos> something like "make tryFoo works again"
[14:53] <tsdgeos> if that is what it does :D
[14:55] <dandrader> tsdgeos, done
[15:26] <dandrader> tsdgeos, and this https://code.launchpad.net/~dandrader/unity8/fixDragHandleTest/+merge/280733
[15:26] <dandrader> tsdgeos, with those two branches, now I can finally continue the nodda review :)
[15:26] <tsdgeos> dandrader: don't workaround the crashes :D (j/k)
[15:42] <mterry> Saviq, can we fit https://code.launchpad.net/~mterry/unity8/briefly-inactive/+merge/280492 in?
[15:43] <mterry> Saviq, that's a CVE bug
[15:47] <Saviq> mterry, right, totally
[15:47] <mterry> mzanetti, if you can give https://code.launchpad.net/~unity-team/unity8/lockout-time-travel/+merge/280206 another look, maybe I can squeeze it into the next silo
[15:47] <mzanetti> kk
[15:47] <mterry> thanks!  :)
[15:56] <mzanetti> mterry, question:
[15:56] <mzanetti> doesn't this still suffer from the issue that guy on the mailing list had=
[15:56] <mzanetti> ?
[15:58] <mzanetti> ah no... tooEarly is working again now :)
[16:00] <Saviq> dandrader|lunch, looks like loggingCategory has a conflict with trunk? https://ci-train.ubuntu.com/job/ubuntu-landing-031-1-build/lastBuild/console
[16:03] <greyback> yep
[16:10] <mterry> mzanetti, the fix that solved the mailing list guy's issue was not re-using the now pointer for delayTarget
[16:12] <mzanetti> yeah... I figured
[16:19] <tsdgeos> dandrader|lunch: one of the test segfaults, see the MR
[16:57] <Saviq> josharenson, can you please rebase slim_greeter branch on top of lp:~lukas-kde/unity8/cursorHiding, there's a conflict in Shell.qml
[16:57] <josharenson> Saviq: sure
[16:58] <Saviq> ah there wouldn't be a conflict if not for ltinkl's OCD about missing newlines ;)
[16:58] <Saviq> josharenson, that might be a better solution, gimme a sec to verify if that's it
[16:58] <ltinkl> Saviq, uh where what
[16:59] <josharenson> Saviq: ha ok, I like pretty code, so no worries
[16:59] <Saviq> ltinkl, https://code.launchpad.net/~lukas-kde/unity8/cursorHiding/+merge/279198#diff-line-272
[16:59] <ltinkl> grmbl ye, sorry :/
[16:59] <ltinkl> but it looks tidy, doesn't it? ;)
[17:02] <Saviq> ltinkl, yeah please undo that newline
[17:02] <Saviq> ltinkl, then we don't need to rebase anything around
[17:04] <ltinkl> Saviq, ok, in the same MP?
[17:06] <ltinkl> anyways, done
[17:08] <Saviq> ltinkl, yeah, just a revert of that line
[17:09] <Saviq> ltinkl, in a case like that (typo you had to push), it's ok to --overwrite
[17:09] <ltinkl> Saviq, ok, always forget those bzr pecularities :)
[17:11] <Saviq> ltinkl, not like that's specific to bzr :)
[17:11] <Saviq> you --force in git if you rewrote history, too
[17:41] <mzanetti> Saviq, this *is* approved. could be considered too if not too late :)
[17:41] <mzanetti> https://code.launchpad.net/~unity-team/unity8/lockout-time-travel/+merge/280206
[18:37] <Saviq> mzanetti, already added
[18:38] <Saviq> or is it...
[18:38] <Saviq> thought I added it
[19:03] <davmor2> Saviq: I blame you :P
[21:38] <Saviq> davmor2, oh what happened, was there an earthquake?