[08:42] <dandrader> mzanetti, gdbus call --session --dest com.canonical.UnityGreeter --object-path / --method com.canonical.UnityGreeter.HideGreeter
[08:42] <Saviq> pstolowski, pete-woods, remote scopes crashing unity8: bug #1418176, actually hoping it's related to bug #1410385 that we don't have any trace on yet
[08:42] <pete-woods> Saviq: thanks
[08:55] <pete-woods> Saviq: have a fix already :)
[08:55] <pstolowski> Saviq, we have a fix for that in silo 8, but currently fighting with test failures there
[08:55] <Saviq> pete-woods, :)
[09:22] <tsdgeos> pstolowski: what do you think of my comment in https://code.launchpad.net/~stolowski/unity-scopes-shell/fix-temp-scopes/+merge/248235 ?
[09:22] <pstolowski> tsdgeos, yeah, i've a branch
[09:22] <tsdgeos> Cimi: and you from https://code.launchpad.net/~cimi/unity8/fix-open-new-scope-from-tmp/+merge/248538 ?
[09:22] <tsdgeos> :D
[09:23] <pstolowski> tsdgeos, tbh i'm not totally sure why we need that, i guess it's for you to be able to mock stuff?
[09:24] <tsdgeos> pstolowski: you mean having the api in a separate place?
[09:24] <tsdgeos> pstolowski: yeah so that we have an expectation of what the api is going to be
[09:24] <tsdgeos> and we can mock it
[09:24] <pstolowski> tsdgeos, having the abstract scopes interface... yeah, ok
[09:24] <tsdgeos> and it doesn't happen that you change it behind our feet without us realizing
[09:25] <tsdgeos> which may be easier to happen if it was all part of your project alone
[09:29] <tsdgeos> pstolowski:
[09:29] <tsdgeos> 	+ libunity-api-dev (>= 7.95),
[09:29] <tsdgeos> 	libunity-api-dev (>= 7.94),
[09:29] <tsdgeos> second needs to be a -
[09:30] <pstolowski> tsdgeos, oh, a mistake in conflict resolution
[09:31] <pstolowski> tsdgeos, pushed
[09:47] <tsdgeos> pstolowski: https://code.launchpad.net/~stolowski/unity-scopes-shell/fix-temp-scopes/+merge/248235 looks good to me, want me to top approve or prefer someone else to review too?
[09:51] <pstolowski> tsdgeos, top approve pls, thanks!
[09:52] <tsdgeos> pstolowski: btw closing from scopes makes so much sense
[09:52] <tsdgeos> \o/
[09:52] <tsdgeos> pstolowski: was wondering if we even wanted to kill the possibility of closing from scope
[09:52] <tsdgeos> since basically now it's just callign scopes
[09:53] <tsdgeos> it's not even checking if the scope was opened though that scope
[09:53] <tsdgeos> but i guess it's fine
[09:56] <Saviq> tsdgeos, pstolowski, there's one reason (I think) why we had it in Scope, and that's a stack of scopes
[09:57] <Saviq> i.e. you go Apps > Store > NewScope > YouTube > Store
[09:57] <Saviq> you have two Store scopes, and you want to retain its history
[09:57] <pstolowski> tsdgeos, yeah. i left it exposed in Scope not to break any of your code.
[09:57] <tsdgeos> Saviq: that won't work atm
[09:58] <tsdgeos> you'll get a gotoscope on the last one
[09:58] <tsdgeos> well we dont' support stacks anyway :D
[09:58] <Saviq> tsdgeos, don't think so?
[09:58] <Saviq> tsdgeos, you only  get gotoScope for favs
[09:58] <tsdgeos> Saviq: yes with the code pstolowski just did
[09:58] <tsdgeos> i think
[09:58] <Saviq> tsdgeos, but anyway, yeah, we have no stack, and it doesn't actually seem like we will
[09:59] <Saviq> anyone seen MacSlow today?
[09:59] <tsdgeos> nope
[10:06] <Saviq> seb128, http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-008
[10:10] <seb128> Saviq, that fixes it
[10:10] <seb128> thanks
[10:10] <Saviq> coolz
[10:10] <seb128> now what about qtmir/gtk? ;-)
[10:16] <Saviq> seb128, they're testing the silo
[10:17] <seb128> great
[10:18] <Saviq> kgunn, I removed the sync now to prevent accidental rebuilds
[11:54] <Cimi> tsdgeos, but Scope::activate(QVariant const& result) is ever being called?
[11:55] <tsdgeos> Cimi: of course
[11:55] <Cimi> tsdgeos, by what?
[11:56] <Cimi> tsdgeos, confused about those mocks
[11:56] <tsdgeos> tsdgeos_work@xps:~/phablet/unity8/unity8/qml/Dash$ wcgrep "activate("
[11:56] <tsdgeos> ./GenericScopeView.qml:72:            // TODO Technically it is possible that calling activate() will make the scope emit
[11:56] <tsdgeos> ./GenericScopeView.qml:75:            scope.activate(result)
[11:56] <tsdgeos> ./ScopesList.qml:126:                        onRequestActivate: root.scope.activate(result);
[11:56] <Cimi> ah I see
[12:12] <Cimi> tsdgeos, because the previous  close scope was checking m_openScope which changed only from the activate call
[12:12] <Cimi> tsdgeos, this activate call only seem to happen when someone clicks an item inside the opened scope
[12:12] <Cimi> that's why I removed that code inside the mock, it looked confusing
[12:13] <tsdgeos> well you're aware there's test code using it, no?
[12:13] <tsdgeos> i mean you just removed part of the test
[12:14] <tsdgeos> i suggest you just stop using the scopeToCallCloseOn
[12:14] <tsdgeos> or wathever weird name i used
[12:14] <tsdgeos> can't remember now
[12:14] <tsdgeos> and just call closeScope on scopes
[12:14] <Cimi> yeah
[12:14] <tsdgeos> and put an assert on Scope::closeScope mock to make it clear we don't want to use it
[12:15] <Cimi> tsdgeos, shall I add something inside the new close inside scopes?
[12:15] <tsdgeos> and make Scopes::closeScope actually work (and assert if the scope you want to close is not the one that was activated)
[12:15] <Cimi> for the mock
[12:15] <Cimi> so I need to create this temp scopes set too?
[12:15] <Cimi> I don't understand the boundaries of mocks and what is needed and what not
[12:17] <tsdgeos> well you need to make it work, otherwise how are you going to test that clicking in that button that is supposed to bring you to another scope actually brought you to another scope?
[12:18] <tsdgeos> there's no need to create/destroy them
[12:18] <tsdgeos> we have a few scopes in the mock that are not there by default
[12:18] <tsdgeos> so you can just do what the old closeScope did, store the pointer in a variable/list and make sure the close you're getting is in that variable/list
[13:52] <Saviq> tsdgeos, hmm, our history popup in the dash appears offscreen, have we been touching that code recently?
[13:52] <tsdgeos> Saviq: not that i remember
[13:53]  * Saviq goes to #sdk
[14:05] <mzanetti> Daekdroom: https://code.launchpad.net/~mzanetti/unity8/launcher-fixes/+merge/248761
[14:05] <mzanetti> dandrader: https://code.launchpad.net/~mzanetti/unity8/launcher-fixes/+merge/248761
[14:06] <dandrader> mzanetti, cool. reviewing it now
[14:07] <Daekdroom> Hm... do I have to review it as well? :)
[14:26] <mterry> Is anyone familiar with what differences exist between tryTest and testTest?  I've got this problem where a DirectionalDragArea isn't working in testTest but does in tryTest...  :(
[14:26] <mterry> dandrader, ^?
[14:31] <MacSlow> mterry, tryTest is interactive... while testTest is automatic
[14:31] <mterry> MacSlow, yeah, but why would drags be affected?
[14:32] <mterry> MacSlow, something seems to be stopping all touch/mouse interactions in test mode
[14:33] <MacSlow> mterry, hm... not sure... I've not run into such issues with drag-related QML-tests (for notifications)
[14:33] <MacSlow> mterry, can you be more specific?
[14:33] <mterry> :(  It also affects dragging down the indicators and the launcher
[14:34] <mterry> MacSlow, in test mode, clicks don't seem to register.  I've removed all code in init() and use a sample test with wait(100000).  So no test code is messing things up.  But for some reason, testTest fails to take input while tryTest is fine
[14:35] <mterry> This is only with a branch I have that is trying to merge in another branch.  Both branches are fine by themselves.  But the size of the branches makes it hard to narrow down the change
[14:35] <mterry> And I'm not even sure where to look because this is such a weird bug
[14:35] <mterry> I don't know where we execute code that is specific to testTest runs vs tryTest runs
[14:36] <dandrader> mterry, "make testFoo" uses qmltestrunner whereas "make tryFoo" uses uqmlscene
[14:37] <mterry> dandrader, huh...
[14:37] <MacSlow> mterry, you can have the commandlines for those different make-targets dumped and then copy&paste them to play around...
[14:37] <MacSlow> mterry, maybe that'll help to better narrow down your issue
[14:37] <mterry> yeah
[14:38] <MacSlow> mterry, I did just that for the new mocked NotificationModel in one of the notification-related QML-tests
[14:38] <dandrader> mterry, with "make test" the tst_Foo.qml file is run by qmltestrunner binary, with "make try", the qml test file is run by the uqmlscene binary. clearer now?
[14:39] <mterry> dandrader, yes no it's clear.  I was just trying to remember what I knew about those two and what they did different
[14:39] <mterry> I wonder if there is also an environment var diff
[14:39] <dandrader> mterry, and in uqmlscene we convert mouse events to touch events before sending them to the qml scene
[14:39] <mterry> hmmm
[14:40] <dandrader> mterry, in order to emulate a touchscreen usage in the desktop
[14:41] <dandrader> mterry, also I don't think you can properly interact with a test in "make testFoo" while it's hanging in a wait()...
[14:42] <MacSlow> mterry, btw... I only use mouseClick() and mouseDrag() in the notification QML-tests.
[14:42] <dandrader> MacSlow, which is a bad habit as it does not simulate well the usage on touchscreen devices
[14:42] <mterry> dandrader, I'm pretty sure you can...  let me test on trunk
[14:42] <facubatista> I just upgraded to Vivid r89 and unity8 seems to have a weird problem, it repeats this every ~10 seconds, in its logs: http://linkode.org/TMgjPipYdh9URrootGEwv3
[14:42] <facubatista> does anybody know what it could be? thanks!
[14:43] <dandrader> mterry, I recall I had inconsistent and weird results wherever I tries to interact with a test while on wait()..... but maybe I'm wrong
[14:43] <dandrader> *whenever
[14:44] <MacSlow> dandrader, hm... that was never pointed out in MR-reviews... I'll keep it in mind for the future.
[14:46] <tsdgeos> dandrader: https://code.launchpad.net/~dandrader/unity8/fixSurfaceActiveFocus/+merge/247836
[14:46] <dandrader> tsdgeos, ok
[14:49] <mterry> dandrader, you are so right!   wait() blocks me from interacting.  Phew!  So something else is wrong because I have failing tests, but I thought I was seeing something much worse.  I could have sworn I've done that in the past. Thanks for the heads up
[14:49] <MacSlow> mterry, mixup between wait() and waitForRendering() maybe?
[14:50] <mterry> Maybe...  it would be nice if there *was* a "stop and let user futz with stuff" command that I could insert in a test for testing purposes
[14:51] <dandrader> tsdgeos, fixed
[14:52] <tsdgeos> dandrader: ok, reapproved
[14:52] <dandrader> tsdgeos, thanks
[15:43] <Saviq> MacSlow, try running the test under xvfb, loop it, there's probably just some timing issue, I was able to repro quite reliably
[15:43] <MacSlow> Saviq, ah ok... will try that
[15:44] <MacSlow>  Saviq, I removed some wait()s I wasn't fond of... guess I overdone it :)
[15:45] <Saviq> MacSlow, let me know if you need some testing done, maybe add debugging etc.
[15:48] <MacSlow> Saviq, do we have a specifc make-target for xvfb-run or do I need to do this manually?
[15:48] <Saviq> MacSlow, xvfbtestNotifications
[15:49] <MacSlow> Saviq, hm... still passes here
[15:50] <MacSlow> Saviq, I'll try my slower laptop
[15:50] <Saviq> MacSlow, yup, that might trigger it too
[15:50] <MacSlow> Saviq, I tend to forget the GeForce-monster that's in this machine
[16:56] <greyback_> dandrader: hey, I've taken over https://code.launchpad.net/~mir-team/qtmir/port-to-event-2.0/+merge/248067 - if you have time, could you give it a review pass please?
[16:56] <greyback_> dandrader: tomorrow obviously
[16:59] <dandrader> greyback_, I'm fine with you taking it over
[17:00] <dandrader> greyback_, oh, you took over the branch, not the review
[17:00] <greyback_> dandrader: yeah
[17:01] <dandrader> so lazy dandrader still has to review it
[19:13] <josharenson> Anyone who has build ubuntu-system-settings-online-accounts? It seems that the online-accounts-service isn't finding mirclient and its compiling in mir-helper-stub.cpp instead of mir-helper.cpp. Is this expected? Its giving me a headache w/ trusted sessions.
[19:16] <gQuigs> who maintains https://unity.ubuntu.com?
[19:16] <gQuigs> I'm looking for an updated version of this page - https://unity.ubuntu.com/getinvolved/development/unity8/#developing-unity
[19:16] <gQuigs> vivid current instructions for developing unity8 (specifically want to do desktop, but on an nvidia card if possible)
[19:17] <josharenson> gQuigs: I'm not sure there is an updated version... Do you have any specific questions?
[19:17] <josharenson> ah
[19:18]  * josharenson looks for a branch that could help
[19:18] <gQuigs> do I need any PPAs on vivid?  and will it even work with the nvidia proprietary driver?
[19:20] <gQuigs> seems it's a wordpress site...
[19:20] <josharenson> gQuigs: still looking, I actually haven't ran it on the desktop in a while... mostly been working on mobile. As for the nvidia driver, I cannot answer that, maybe try #ubuntu-mir
[19:33] <josharenson> gQuigs: I'd try running http://cdimage.ubuntu.com/ubuntu-desktop-next/daily-live/current/ from a usb drive
[19:34] <josharenson> gQuigs: I just tried making it work a hacky way, and broke my computer for a bit
[19:35] <gQuigs> josharenson: oh, I know that doesn't work right now..  so even to develop it only works on open source right now
[19:35] <gQuigs> for some reason I thought it was just not stable for that yet..
[19:35] <gQuigs> josharenson: thanks!
[19:35] <josharenson> gQuigs: yeah I just saw the docs stating that... np, sorry I couldn't be of more help