[08:16] <tsdgeos> mzanetti: ping
[08:22] <tsdgeos> mzanetti: goint to need a qmluitests VM detached when you have time to try to repro that test that is now suddenly blocking us from out of the blue
[08:42] <mzanetti> tsdgeos: hey
[08:42] <mzanetti> tsdgeos: I'll get you the vm now
[08:42] <tsdgeos> tx
[08:46] <mzanetti> tsdgeos: ps-trusty-server-amd64-1 it is
[08:46] <mzanetti> kgunn: o/
[08:46] <tsdgeos> tx
[08:47] <kgunn> mzanetti: \o yo!
[08:47] <mzanetti> kgunn: fixed the last glitches
[08:47] <kgunn> cool...i'm all set up...i'll resync this afternoon
[09:29]  * tsdgeos does the evil eyes at Saviq
[09:29] <tsdgeos> :D
[09:30]  * tsdgeos does the evil eyes to himself
[09:35] <tsdgeos> mzanetti: https://code.launchpad.net/~aacid/unity8/fix_test_dash_shown/+merge/201899
[09:35] <mzanetti> :D
[09:36] <tsdgeos> mzanetti: you can bring back the vm to the pool
[09:36]  * mzanetti wonders why tsdgeos doesn't do the evil eyes to him
[09:36] <mzanetti> vm is back in pool
[09:36] <tsdgeos> mzanetti: you didn't do nor review the change, no?
[09:37] <mzanetti> ah right... no, I didn't do that change
[09:37] <tsdgeos> you're saved from evil eye-ing
[09:37] <Saviq> tsdgeos, uh oh, sorry
[09:37] <tsdgeos> Saviq: there's a few more checks against undefined that should be probably null
[09:37] <tsdgeos> but they are == or != and that still works
[09:38] <tsdgeos> it's [09:38] <mzanetti> tsdgeos: hmm... but how could this have gotten merged? I mean, shouldn't those tests have failed already with the bad commit?
[09:38] <tsdgeos> mzanetti: because it's a timing thing
[09:38] <mzanetti> ah
[09:38] <tsdgeos> that function there
[09:38] <tsdgeos> checks that everything we're going to need is loaded
[09:38] <mzanetti> oh, I got it
[09:38] <tsdgeos> by making sure they are there
[09:38] <tsdgeos> i guess we were unlucky and the merge ran on a fast machine :D
[09:39] <mzanetti> yeah, the vm's performance is quite variable depending on how many jobs are running
[10:29] <seb128> MacSlow, hey, could you review https://code.launchpad.net/~sam92/notify-osd/focusfollowdefault/+merge/198541 as well?
[10:31] <mzanetti> greyback: hi
[10:31] <mzanetti> greyback: just merged trunk and as I feared,everything broke badly
[10:31] <mzanetti> TaskController::startApplication appId='dialer-app' FAILED
[10:31] <mzanetti> Asking Upstart to start application 'dialer-app' failed
[10:31] <mzanetti> any idea? ^
[10:32] <mzanetti> greyback: if I try for a second time it crashes: (null):dbus_error.c:69: Unhandled error from nih_dbus_error_raise: Name "com.ubuntu.Upstart" does not exist
[10:33] <MacSlow> seb128, ok
[10:33] <seb128> MacSlow, thanks
[10:34] <MacSlow> seb128, but mpt also approved it already... but it's good to go from my side too
[10:34] <MacSlow> seb128, I can top-approve it
[10:34] <MacSlow> seb128, done
[10:34] <seb128> MacSlow, thanks
[10:36] <mzanetti> greyback: forget about the above... no idea what went wrong, now it works - sorry about the noise
[11:25] <Saviq> mzanetti, hey, you happy to show what you have for right edge?
[11:26] <mzanetti> Saviq: yip yip
[11:26] <Saviq> mzanetti, what do I do?
[11:26] <mzanetti> Saviq: when did you last flash your phone?
[11:26] <mzanetti> Saviq: do you already have the sidestage code from ricmm on your device?
[11:26] <Saviq> mzanetti, I don't think so, checking
[11:27] <Saviq> I'm at image 127
[11:27] <mzanetti> Saviq: hmm.. no idea which one that is
[11:27] <mzanetti> Saviq: better flash it with a fresh one to be on the save side
[11:28] <Saviq> mzanetti, 0.2+14.04.20140108.1-0ubuntu1
[11:28] <Saviq> mzanetti, will do, thought it was "you should have an old one"-type of a problem
[11:28] <mzanetti> Saviq: I just merged everything with trunk
[11:29] <mzanetti> Saviq: if your image is an older one you could use my branches before the "merge trunk" commit
[11:29] <Saviq> mzanetti, upgrading now
[11:29] <mzanetti> ack
[11:29] <mzanetti> Saviq: so, you need this branch: lp:~mzanetti/unity-api/new-screenshot-and-focusing-api unity-api
[11:30] <mzanetti> it's enough if you copy the Application*.h files to /us/include/...
[11:30] <mzanetti> then you need this one: bzr branch lp:~mzanetti/unity-mir/screenshotting-focusing-api unity-mir
[11:31] <mzanetti> need to compile + install
[11:31] <greyback> mzanetti: hey, sorry was away, that error sounds like upstart broke a bit, as that message says the dbus message to upstart failed to send
[11:31] <mzanetti> and then this one: bzr branch lp:~mzanetti/unity8/appmanager-rework
[11:31] <mzanetti> you can run_on_device this one ^
[11:32] <mzanetti> greyback: no worries. I still don't know what happened, at some point it was working again... the first 2 reboots I always got this error
[11:32] <mzanetti> greyback: but can't reproduce it any more. so everything fine I guess
[11:32] <greyback> mzanetti: I had it once before too
[11:39] <Saviq> ricmm_, greyback https://bugs.launchpad.net/ubuntu/+source/unity-mir/+bug/1269414 you saw that?
[11:55] <Saviq> tsdgeos, mzanetti, can you please do https://code.launchpad.net/~mterry/unity8/hide-greeter-on-focus-request/+merge/201817 ?
[11:55] <Saviq> we should add an ap test for that...
[11:57] <mzanetti> Saviq: ack
[11:59] <kgunn> greyback: so i was trying to build unity-mir on my device...which i did yesterday, i just updated
[12:00] <kgunn> the branch....but now, when i hit qmake...it spews the help
[12:00] <kgunn> seemingly
[12:00] <kgunn> ever seen this
[12:00] <ricmm_> kgunn: migrated to cmake
[12:00] <ricmm_> build with dpkg
[12:00] <kgunn> thanks
[12:00] <greyback> yeah, we switched to cmake
[12:01] <greyback> need to see if I can X-compile it now
[12:01] <mzanetti> greyback: if you manage to, let me know
[12:01] <mzanetti> last time I tried click chroot didn't like my system at all
[12:01] <greyback> mzanetti: will do
[12:04] <Saviq> mzanetti, FOOK 6k diff? think we could split it up in smaller chunks?
[12:04] <mzanetti> Saviq: no
[12:04] <Saviq> :/
[12:04] <mzanetti> Saviq: and it'll get about double the size
[12:04] <mzanetti> Saviq: because we're not supposed to break anything
[12:04] <mzanetti> Saviq: so the new sidestage has to be in this too
[12:05] <mzanetti> Saviq: but most of it is dropping old FIXME's :)
[12:05] <Saviq> mzanetti, we're hammering out the side stage case this week, too, so hopefully there will be direction (or there might be an interruption anyway)
[12:06] <mzanetti> Saviq: yeah, I heard. vesar is busy prototyping it. looking forward to it
[12:06] <tsdgeos> mzanetti: you doing mterry's review, then, right?
[12:06] <mzanetti> tsdgeos: yes, can do
[12:20] <mzanetti> Saviq: where did you see a 6k diff btw?
[12:20] <Saviq> mzanetti, unity8
[12:20] <mzanetti> Saviq: https://code.launchpad.net/~mzanetti/unity8/appmanager-rework/+merge/199815
[12:20] <mzanetti> 1.5, no?
[12:20] <Saviq> mzanetti, against your branch
[12:21] <Saviq> mzanetti, hmm wait
[12:21] <Saviq> mzanetti, merged on wrong branch
[12:22] <Saviq> mzanetti, 1.5k is fine
[12:22] <mzanetti> Saviq: yeah. it's ok. so this is only the Phone stuff... the tablet will come in with another 500 - 1000 lines approx
[12:26] <mzanetti> Saviq: does it work?
[12:26] <Saviq> mzanetti, not yet, couldn't cross-build :/
[12:30] <tsdgeos> noOoOOoOoO
[12:30] <tsdgeos> whitespace
[12:30] <tsdgeos> :D
[12:31] <tsdgeos> Mirv: if you have not started a qtdeclarative rebuild
[12:31] <tsdgeos> you want to include this one
[12:31] <tsdgeos> Mirv: https://codereview.qt-project.org/#change,75689
[12:32] <Mirv> tsdgeos: ok. well I "started" but KDE is eating all the builders so it has not started yet. reuploading with that added.
[12:32] <tsdgeos> Mirv: awesome, it should fix that crash in i386
[12:34] <Mirv> tsdgeos: do you have qtdeclarative release branch git checked out? could you check if I should update from the cb78684ae or if the 10 commits on top of that are not crucial? like by looking at the commit descriptions.
[12:34] <Saviq> xnox, hey, something changed and Qt cmake modules are not found any more when cross-building :/ any idea?
[12:34] <tsdgeos> Mirv: sure, let me check
[12:35] <Mirv> to me maybe thiago's d580411ca looks important, but not much else
[12:35] <Mirv> on the other hand if it doesn't look too important, it shouldn't hurt either...
[12:36] <tsdgeos> Mirv: 2f9099443d9acd6583e92785afbb38b2e4dcbfd5 looks like something we want to have (no clue what it does but sounds complicated, i.e. could break/fix stuff :D)
[12:36] <tsdgeos> Mirv: if updating to current tip of release is not hard i'd do it
[12:37] <Mirv> ok then :)
[12:40] <Saviq> mzanetti, ApplicationImage.qml: File not found?
[12:40] <Saviq> damn ^W
[12:40] <mzanetti> salem_: where do you get this?
[12:40] <mzanetti> Saviq: ^ (sorry salem_)
[12:41] <Saviq> mzanetti, hmm it didn't build, let me
[12:41] <Saviq> mzanetti, ah that's "real" u8
[12:41] <mzanetti> Saviq: ?
[12:41] <Saviq> mzanetti, distro u8 with new libunity-mir1
[12:41] <Saviq> mzanetti, so makes sense
[12:42] <mzanetti> ah ok, yeah
[12:42] <mzanetti> I dropped AplicationImage.qml
[12:42] <Saviq> mzanetti, yup
[12:43] <mzanetti> Saviq: btw... u8 trunk won't start with my libunity-mir, which causes libhud to go to 100% cpu
[12:43] <Saviq> mzanetti, mhm
[12:43] <mzanetti> Saviq: so make sure to reinstall unity-mir from the repo before leaving the device unattended for a while
[12:43] <mzanetti> or it'll get hooot
[12:43] <Saviq> mzanetti, :)
[12:44] <mzanetti> actually I should file a bug about it
[12:59] <cwayne> Saviq: ping: are we eventually planning on having the unity automatically detect the screen resolution settings? or will we always need to drop a file in /etc/ubuntu-touch-session.d/?
[13:00] <Saviq> cwayne, you mean DPR / GRID_UNIT_PX?
[13:00] <cwayne> yeah, specifically GRID_UNIT_PX
[13:00] <Saviq> cwayne, those are arbitrarily set, so AFAICT there will always be a per-device file there
[13:00] <Saviq> cwayne, 'cause it's not really DPI
[13:01] <cwayne> right, i was worried about that :)
[13:01] <cwayne> Saviq: where are those files actually read?
[13:01] <cwayne> i.e. is it just unity8 that actually reads the contents of those files?
[13:01] <Saviq> cwayne, no, it's being exported in the session I think
[13:02] <Saviq> mzanetti, can't launch apps, and run_on_device complains about pkilling processes that're not running?
[13:02] <Saviq> mzanetti, ah wait, got dialer
[13:03] <Saviq> mzanetti, what's the chopping at the top?
[13:06] <Saviq> mzanetti, is the "I can swipe enough to go back to the app when reached the end of the stack?
[13:06] <Saviq> +designed behaviour?
[13:14] <mzanetti> Saviq: no. that's todo still
[13:14] <mzanetti> Saviq: design is not exactly sure yet where the point of no return shall be
[13:14] <Saviq> mzanetti, you mean todo to fix?
[13:15] <Saviq> mzanetti, ok, how do we fix the cropping?
[13:15] <mzanetti> Saviq: what cropping?
[13:16] <Saviq> mzanetti, - yOffset is not needed any more
[13:16] <mzanetti> ?
[13:16] <Saviq> mzanetti, application.cpp in libunity-mir
[13:16] <Saviq> mzanetti, the screenshots coming from mir are now the actual size of the surface
[13:17] <mzanetti> Saviq: re launching of apps: currently you need to launch apps with the launcher as we didn't merge the fix to unity-scopes yet
[13:17] <Saviq> mzanetti, 'stood
[13:17] <mzanetti> Saviq: I don't see any cropping
[13:17] <Saviq> mzanetti, merge trunk libunity-mir
[13:18] <Saviq> mzanetti, you'll see it
[13:18] <ricmm_> Saviq: hi
[13:18] <Saviq> ricmm_, FUCK OFF
[13:18] <mzanetti> again? I did that today already
[13:18] <mzanetti> damn. conflicting again
[13:19] <ricmm> so yea yOffset is not needed as app buffers are now the size of the render area requested
[13:19] <ricmm> in accordance to the available geometry in the selected stgage
[13:20] <Saviq> ricmm, in the selected what?\
[13:20] <ricmm> Saviq: sthfgage
[13:20] <Saviq> stg007Fage
[13:20] <Saviq> mzanetti, you're being missed here
[13:21] <mzanetti> am I? why is that?
[13:21] <Saviq> mzanetti, just because ;D
[13:21] <Saviq> mzanetti, it's late, I didn't sleep much, hungover, don't listen to me ;D
[13:21] <mzanetti> is the beer any good down there?
[13:22] <mzanetti> lol. do you have the drunken voice again?
[13:22] <Saviq> mzanetti, it's *CHEAP* to start with
[13:22] <Saviq> not any more ;) that was Monday :D
[13:22] <mzanetti> :D
[13:22] <Saviq> mzanetti, a pound a beer, 3-course dinner with a bottle a wine a head, 16 pounds
[13:23] <ricmm> Saviq: hi
[13:23] <Saviq> and they give you half a cow
[13:23] <Saviq> ricmm, FUCK OFF
[13:23] <Saviq> ↑↑ he's sitting →→
[13:23] <ricmm> o/
[13:23] <mzanetti> :D
[13:25]  * mzanetti just realizes that the app suspend whitelist will mess with the screenshot stuff we're doing
[13:25] <mzanetti> i.e. the screenshots are most likely always outdated
[13:26] <ricmm> oh not at all
[13:26] <ricmm> it still takes screenshots of suspended app's buffers
[13:26] <ricmm> and technically the app wont have changed if its suspended
[13:26] <mzanetti> yeah, but the app is not suspended so it will change after the screenshot has been taken
[13:26] <mzanetti> that's what I mean... the whitelist
[13:26] <ricmm> oh the whitelist
[13:26] <ricmm> sorry
[13:26] <mzanetti> np
[13:27] <Saviq> mzanetti, the two last (bottom ones) screenshots get swapped sometimes
[13:27] <Saviq> mzanetti, you know about that?
[13:27] <ricmm> so the whitelisting is a hack
[13:27] <mzanetti> Saviq: yep... that will implicitly be fixed with the point of no return
[13:27] <ricmm> lets not write special code to support that outdate screenshot of music app
[13:27] <ricmm> ultimately it wont use whitelisting
[13:27] <Saviq> mzanetti, ok
[13:27] <ricmm> but the media hub
[13:27] <mzanetti> ricmm: ack
[13:39] <Saviq> mzanetti, lookin' good!
[13:40] <mzanetti> Saviq: nice :)
[13:40] <Saviq> mzanetti, noticed that fullscreen apps might need to be handled differently
[13:40] <Saviq> mzanetti, or are we not meant to put the toolbar on them?
[13:40] <mzanetti> Saviq: yeah, that's one of the questions I had for design
[13:40] <mzanetti> they don't know a solution yet
[13:40] <mzanetti> the prototype and mocks only dealt with non-fullscreenones
[13:41] <Saviq> mzanetti, no I mean that weren't we supposed to put the panel on the non-fullscreen ones?
[13:41] <mzanetti> Saviq: hmm... dunno. I'd think that looks weird, but who knows. maybe that'll be designs answer
[13:42] <Saviq> mzanetti, we will probably have to "composite" the OSK on the apps anyway
[13:42] <mzanetti> well, it solve some more issues tho
[13:42] <Saviq> mzanetti, yeah, and I thought videos were doing that (panel)
[13:42] <mzanetti> yeah, martins videos did
[13:43] <mzanetti> Saviq: vesar's prototype doesn't
[13:43] <Saviq> mzanetti, I think the video is more of what we  should be looking at, but yeah a confirmation is needed
[13:44] <mzanetti> hmm... no that was the mistake I did at first... I implemented the video while the prototype is the one where the changes from the reviews are in already
[13:45] <mzanetti> but we'll see... I have another design feedback call either today or tomorrow - depending on how busy things are on the southern hemisphere
[13:45] <Saviq> mzanetti, right, visual vs. behavioral
[13:46] <Saviq> mzanetti, great
[13:46] <mzanetti> but overall it's quite cool isn't it?
[13:46] <mzanetti> makes the right edge so much more useful
[13:50] <mzanetti> Saviq: I merged with trunk again, still nothing clipped off
[13:51] <Saviq> mzanetti, there's been changes to platform api and qtubuntu that changed that
[13:51] <mzanetti> ah...
[13:51] <Saviq> mzanetti, so apt-get update/upgrade should show you that
[13:52]  * mzanetti wishes he waited for another hour with the whole updating/merging thing :D
[13:52] <Saviq> mzanetti, conflicts?
[13:52] <mzanetti> yeah, lots of them
[13:53] <Saviq> :/
[13:53] <mzanetti> but merged already... just seems I'm not up to date again
[13:56] <mzanetti> still good after an upgrade... /me tries dist-upgrade
[13:56] <mzanetti> nope, nothing in there
[14:01] <mzanetti> Saviq: did you manually install something on top? ^
[14:02] <karni> Hey guys. Is the Y axis in Qt layouts pointed downwards from upper left corner, or upwards from lower left? I seem to be calculating correct values for vertical journal row spacing, but with the opposite sign. second.y - (first.y + first.height)
[14:02] <mzanetti> karni: 0, 0 -> upper left
[14:02] <karni> mzanetti: Thank you
[14:03] <Saviq> mzanetti, no, I flashed latest trusty-proposed and installed your unity-mir, built unity8
[14:03] <mzanetti> strange... looks fine here
[14:11] <karni> Saviq / tsdgeos: https://code.launchpad.net/~unity-team/unity8/new-scopes-vj-integration/+merge/201932
[14:11] <karni> tsdgeos: Thank you for your e-mail :)
[14:11] <tsdgeos> karni: no worries
[14:11]  * karni already notices copyright header wrong year heh
[14:12] <tsdgeos> :D
[14:13] <Saviq> karni, measuredTwoLinesHeight → out
[14:15] <karni> Saviq: ow WOW sorry, that wasn't supposed to land there. yes, we talked about it
[14:15]  * karni removes
[14:15] <Saviq> karni, no worries
[14:16] <Saviq> karni, I'd also s/columns/maxColumns/ probably
[14:17] <karni> Saviq: The thing is, that's useful for ResponsiveGridView. In this case, we never make the number of columns less than "columns" set, because of large column spacing or other factors.
[14:17] <karni> Saviq: That's why I thought naming it just columns would be more appropriate, as it always matches maxColumns. Thoughts?
[14:18] <Saviq> karni, not sure I followed
[14:18] <karni> Saviq: ResponsiveGridView - when you set maxColumns = 1000, it may happen number of columns will end up 23, because of delegate item with and column spacing
[14:19] <Saviq> karni, yup, why is here different?
[14:19] <karni> Saviq: in ResponsiveVerticalJournal - whatever you set the columns (i.e. maxColumns) value, that WILL always be the value of columns
[14:19] <Saviq> karni, ah
[14:19] <Saviq> karni, I don't think that should be the case
[14:19] <karni> That's where my question came from if we shouldn't limit the number of columns from arbitrary values
[14:19] <Saviq> karni, the number of columns should be dynamic
[14:19] <karni> in which case I'd agree we should name it maxColumns instead
[14:20] <Saviq> karni, we *know* the size of the cards (so column width)
[14:20] <Saviq> karni, what we don't know is spacing or column number
[14:20] <karni> hrm
[14:21] <karni> I ended with conclusion we don't know delegate size, but what you're saying makes sense.
[14:21] <Saviq> karni, we do
[14:21] <karni> That'll need fixing, and with that, columns -> maxColumns makes sense
[14:21] <Saviq> karni, it's small, medium or large
[14:21] <karni> correct
[14:21] <karni> my bad!
[14:21] <Saviq> karni, no worries
[14:21] <karni> Saviq: -> Needs fixing :)
[14:22] <tsdgeos> karni: https://code.launchpad.net/~aacid/unity8/journal_misc_fixes ?
[14:22] <Saviq> karni, done
[14:22]  * karni looks
[14:22] <tsdgeos> since daniel is back pained
[14:22] <tsdgeos> i'll let you review it
[14:23] <tsdgeos> who reviews https://code.launchpad.net/~aacid/qtubuntu-camera/no_priv_headers/+merge/201933 now that gusch is gone?
[14:23] <tsdgeos> Mirv: ↑↑↑
[14:23] <tsdgeos> sil2100: ↑↑↑ ?
[14:23] <tsdgeos> rsalveti: ↑↑↑↑ ?
[14:23] <Saviq> tsdgeos, start with bfiller
[14:24] <karni> tsdgeos: Jenkins failure is expected on that branch, right?
[14:24] <Saviq> karni, one interesting thing to know would actually be whether cards should be resized or spaced out
[14:24] <tsdgeos> karni: i retriggered the build
[14:24] <tsdgeos> we have a pretty bumpy CI
[14:25] <karni> tsdgeos: approved
[14:25] <karni> Saviq: Correct, I came through that, gave it all much thought. Should I consult Katie?
[14:25] <dednick> anyone know if it's possible to detect a click on a qml area, but not consume the events for it? ie. it gets passed still gets passed on.
[14:27] <tsdgeos> dednick: MouseArea has a property for that afair
[14:27] <karni> dednick: perhaps http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-mousearea.html#propagateComposedEvents-prop
[14:27] <sil2100> tsdgeos: right, bfiller is the right person, but I guess I can take a look at this as well
[14:28] <dednick> i've tried, but seems to get messed when there are mouse areas at a different/deeper parent level...
[14:29] <mzanetti> Saviq: added the "point of no return" as I think it makes sense. fixes the weird flipping issue you had
[14:31] <tsdgeos> dednick: standup?
[14:52] <dandrader> tsdgeos, still no feedback from design regarding half-filled organic grids/
[14:52] <dandrader> ?
[14:52] <tsdgeos> dandrader: nope :_/
[14:52] <tsdgeos> Saviq: can you get katie to answer the email we sent?
[14:53] <tsdgeos> mzanetti: you're preview man? you doing https://code.launchpad.net/~diegosarmentero/unity8/purchase-service/+merge/201807 ?
[14:53] <dandrader> tsdgeos, or I would exercise common sense and do what gallery does
[14:53] <mzanetti> tsdgeos: ack
[14:54] <tsdgeos> dandrader: ok, let me finish what i'm doing and i'll have a look at what the galllery does
[14:56] <elopio> good morning everybody.
[14:57] <elopio> I now need help with the cmake task to install the fake scopes and previews. Can somebody help me?
[15:03] <mzanetti> mterry: hey, would you agree that an AP test makes sense here? https://code.launchpad.net/~mterry/unity8/hide-greeter-on-focus-request/+merge/201817
[15:04] <mterry> mzanetti, uh, sure.  The bug I fixed I don't think needs it (because the bug is in how we respond to events from upstart), but that code in general could use it (for testing integration boundary with upstart)
[15:04] <mterry> I'll look at it
[15:04] <mzanetti> yeah
[15:05] <mzanetti> mterry: the functionality and the unit test look good to me. I'll approve once we have an AP test. Just drop it into the other app_lifecycle ap tests
[15:49] <mterry> mzanetti, do the autopilot tests not have an example of locking the screen? ...  I'm not sure how to induce a fake power button press
[15:49] <mzanetti> mterry: hmm... good question
[15:51] <mzanetti> mterry: how does it actually work?
[15:51] <mzanetti> mterry: I remember we were using Qt.KeyPower at some point, but that seems gone
[15:52] <mterry> mzanetti, how does locking actually work?  we get a signal from powerd that the display setting is changing
[15:52] <mzanetti> mterry: well, I guess in theory we'd need to change the display setting then
[15:53] <mterry> mzanetti, seems like something we should mock
[15:53] <mzanetti> mterry: not really in autopilot tests
[15:53] <mzanetti> ideally autopilot would not use any mocks at all
[15:54] <mterry> mzanetti, I get that they are integration tests, but I feel like actually changing hardware settings might be too much?
[15:54] <mterry> mzanetti, cameras watching the devices and all might not like the screen going out.  Though I suppose it would only be for a moment
[15:54] <mzanetti> and that's what we're striving for. the only reason we're using some mocks now is because we don't have an applicationmanager for the desktop yet
[15:56] <mzanetti> mterry: the more I think about it, the more I think we should do that... its the proper thing to do
[15:56] <mterry> mzanetti, actually change display brightness?
[15:56] <mzanetti> mterry: yes.
[15:56] <mzanetti> mterry: anyways, that's not really related to your tests here
[15:57] <mzanetti> mterry: so why don't you just not unlock it after starting up unity and unlock it directly by starting some other app?
[15:57] <mterry> mzanetti, well.  That's one test.  That test always worked though.
[15:57] <mterry> mzanetti, the thing that broke was focusing an already open app while the greeter was up
[15:57] <mzanetti> ah, I see
[15:57] <mterry> mzanetti, but...
[15:58] <mzanetti> hmm... so yes. my opinion is that we shouldn't mock in autopilot tests
[15:58] <mterry> powerd-cli should be able to futz with screen for us
[15:58] <mzanetti> yeah, that sounds like the proper thing to do
[15:59] <elopio> not that anyone was asking, but /me agrees :)
[15:59] <elopio> mzanetti: can you help me with the installation of the fake scopes ?
[15:59] <mzanetti> elopio: hi
[15:59] <mzanetti> elopio: what up? :)
[16:00] <mzanetti> what exactly do you want to install?
[16:00] <elopio> mzanetti: I need the scopes to be copied to builddir/install/lib/{arch}/unity8/qml/Unity/
[16:00] <elopio> but I don't know anything about cmake.
[16:01] <mzanetti> elopio: afaik they should already be packaged up into unity8-fake-env
[16:01] <tsdgeos> need to reboot, something broke in here
[16:01] <elopio> mzanetti: some of them, but not the ones I need.
[16:02] <elopio> builddir/tests/mocks/Unity has more files than
[16:02] <elopio> builddir/install/lib/{arch}/unity8/qml/mocks/Unity/
[16:04] <elopio> so I suppose I'm missing the install function in tests/mocks/Unity/CMakeLists.txt
[16:04] <elopio> but I don't know what to write in it
[16:04] <mzanetti> elopio: oh boy... that's going to be tricky now :/
[16:04] <mzanetti> elopio: so the thing is this:
[16:04] <mterry> mzanetti, hm.  powerd-cli doesn't let you turn off display, only on.  Do you happen to know a better way?
[16:05] <mzanetti> elopio: ideally we wouldn't use any mocks at all but we need to for now. that's why we install some of them
[16:05] <mterry> mzanetti, sorry if you replied, I had connection issue
[16:05] <mzanetti> elopio: the problem now is, if you just install your mock along with the others it will always be used for all tests
[16:05] <mzanetti> elopio: so we'd need a way in autopilot to tell which mocks to use and which not
[16:06] <mzanetti> mterry: no, I didn't reply yet. still thinking about something
[16:06] <elopio> mzanetti: in this case, I think that's a must. Otherwise, all the tests will access the u1 production servers.
[16:06] <elopio> mzanetti: we will cover the tests for the real scopes and servers in a different branch.
[16:06] <mzanetti> Saviq: help me :)
[16:07] <mterry> mzanetti, no rush, sorry
[16:10] <elopio> mzanetti: oh, but btw, what you said is doable. We can tell the tests to use just some of the fakes, but for that we would need them to be in a separate folder.
[16:10] <elopio> I suppose cmake can do that.
[16:12] <mzanetti> elopio: yeah, cmake can do that
[16:13] <mzanetti> mterry: really weird... powerd-cli help says <on|dc> and the descroption of that says "Off, On or Don't Care"
[16:13] <mzanetti> mterry: does that seem like a bug to you too?
[16:13] <mterry> mzanetti, maybe.  It has always been like that.  There is a documentation bug for certain.  Maybe also a missing functionality bug
[16:14] <mzanetti> mterry: hmm... interesting... if I manually suspend the screen and then call powerd-cli display on it turns on
[16:14] <mzanetti> mterry: but as soon as I kill powerd-cli again, it goes off again
[16:15] <mzanetti> mterry: so off wouldn't work anyways as unity still holds the "on" state afaiu
[16:15] <dandrader> mzanetti, a powerd-cli command is valid just as long as it's running
[16:15] <mterry> mzanetti, yeah.  powerd-cli will install an 'on-hold' that goes away when it does
[16:15] <dandrader> mzanetti, so you have to keep it running in a separate tab/ssh session
[16:15] <mterry> mzanetti, fair...
[16:15] <mzanetti> so I guess that architecture doesn't allow an off if someone else holds a on-lock
[16:16] <mterry> mzanetti, and that's why it doesn't accept off as an argument, sure
[16:16] <mzanetti> still a doc bug there I guess
[16:17] <mterry> And yet, the user can press a button and the android drivers deliver a signal to powerd that a screen turn off should happen
[16:17] <mterry> mzanetti, we could emulate/create that driver event?
[16:17] <mzanetti> mterry: yeah... either that, or there is some admin mode to powerd where you can kill other locks
[16:18] <mzanetti> mterry: I guess you need to ask someone from phonedations
[16:19] <mzanetti> elopio: check out tests/mocks/Unity/Application/CMakeListsts.txt
[16:19] <mzanetti> elopio: there are to install() statements at the end
[16:20] <mzanetti> elopio: add the same to tests/mocks/Unity/CMakeLists.txt for the target FakeUnityQml and put some other directory in there
[16:20] <elopio> mzanetti: let me give it a try.
[16:22] <mzanetti> elopio: along with that, please group the add_subdirectory() from the top and the bottom of the file
[16:23] <elopio> np
[16:27] <elopio> mzanetti: it doesn't work.
[16:27] <elopio> the libFakeUnityQml.so gets copied to the install lib, but I suppose we are still missing some files.
[16:28] <mzanetti> elopio: yeah, the qmldir file
[16:28] <elopio> ah, lets see
[16:32] <elopio> mzanetti: thank you!
[16:32] <mzanetti> np
[16:33] <elopio> now, I think we need to discuss a little more about that never use fakes policy.
[16:33] <elopio> we are actually aiming at closing external network access from the CI lab, at least for the tests run in merge proposals.
[16:34] <karni> Saviq: tsdgeos: I sent Katie an e-mail. Without her opinion, I don't know whether I should spread the cards or resize them depending on available space in VerticalJournal. I'll shelve that untill I get a response, and will look into why Scott couldn't surface the summary field in the Card header.
[16:34] <elopio> so many of the troubles we have now is because we didn't disallowed it when we started writing tests.
[16:34] <tsdgeos> karni: i think that's on the spec
[16:35] <karni> "Width of cards is determined by art width."
[16:35] <karni> sorry, wrong row
[16:35] <tsdgeos> or was
[16:35] <karni> "Cards within a category have equal width. Card widths may be one of the 3 pre-defined sizes: S, L or M."
[16:35] <tsdgeos> i had a question there with an answer
[16:35] <karni> not much besides that
[16:35] <karni> oh
[16:35] <tsdgeos> and i think it was marked as resolved
[16:35] <tsdgeos> so it's not shown anymore
[16:35] <tsdgeos> don't know if you can get them back
[16:36] <karni> Saviq: Do we have revision with old comments of the Future Dash spec? (if you're still around)
[16:36] <mzanetti> karni: seems he isn't any more. they closed down the location
[16:36] <karni> mzanetti: ack, np
[16:37] <karni> tsdgeos: honestly, it it says card widths maybe on of of the 3 pre-defined sizes, I guess I shouldn't resize them, space them out instead
[16:37] <karni> that would also match the behavior of ResponsiveGridView, I believe
[16:38] <mzanetti> karni: I'd say yes
[16:38] <karni> ack
[16:38] <karni> I just re-read what I wrote. I clearly can't type heh, sorry ;)
[16:39] <tsdgeos> dandrader|afk: but the gallery does exactly my thing does
[17:39] <elopio> my branch is ready for review.
[17:39] <elopio> https://code.launchpad.net/~elopio/unity8/app_preview/+merge/201718
[17:40] <elopio> mzanetti: can you?
[17:42] <mzanetti> elopio: not today any more but I'll get it through the queue
[17:43] <elopio> mzanetti: that's just fine, thank you.
[17:48]  * karni is having serious problems finding the delegateWidth of VerticalJournal, since the card-size is defined within the delegate Component
[17:48] <karni> mzanetti: You EODed yet? If not, maybe you could help me figure out one bit.
[18:06] <elopio> karni: which one is your team now? unity?
[18:07] <karni> elopio: Nope, I'm here temporarily, pushing a bit on pieces Phone Delivery needs
[18:07] <karni> to build scopes for MWC
[18:07] <karni> I'm enjoying it here :)
[18:12] <elopio> karni: ah, nice.
[18:14] <karni> ddd
[18:18] <dobey> where's the right place to file UX bugs as relates to global menu bar?
[20:58] <mhall119> Saviq: are all the packaged needed to build Unity 8 on Saucy built and published in the PPA now?
[23:44] <karni> @all Unity8 won't start with packages installed from demo-stuff PPA: http://paste.ubuntu.com/6764850/
[23:44] <karni> ↑↑↑
[23:44]  * karni flashed ubuntu-system --channel trusty-proposed -b + demo-stuff setup
[23:45] <karni>  /usr/lib/arm-linux-gnueabihf/unity8/qml/Unity/libUnity-qml.so: undefined symbol: _ZTIN5unity6scopes12ReceiverBaseE