[06:51] <greyback> ricmm_: https://docs.google.com/a/canonical.com/document/d/1HwxEhrZ45WDngypEmGLW1lHXqf6nLKqdnYORwTALo8E/edit
[08:40] <tsdgeos> Saviq: why the preference for null over undefined?
[08:41] <Saviq> tsdgeos, return null vs. failure
[08:41] <Saviq> tsdgeos, don't remember now why, but that reduced some warnings for me, let me check
[08:42] <Saviq> tsdgeos, but anyway, null has more "value" than undefined
[08:42] <Saviq> tsdgeos, ah I know now
[08:42] <Saviq> property Item header: findChild(card, "cardHeader")
[08:42] <Saviq> was warning when undefined
[08:43] <tsdgeos> ok
[08:43] <tsdgeos> change looks ok to me, was just wondering the reason :)
[08:43] <Saviq> tsdgeos, generally, undefined is... undefined
[08:43] <Saviq> tsdgeos, while null has a value... of null...
[08:44] <Saviq> so the function returns nothing now, as opposed to not knowing what it returns (of sorts)
[08:51] <tsdgeos> Saviq: and the otto thing fixed itslef :D
[08:51] <Saviq> tsdgeos, indeed it did
[08:52] <Saviq> tsdgeos, fginther was baffled
[08:52] <Saviq> tsdgeos, he couldn't find any reason why it started, or any reason why it stopped again...
[08:52] <Saviq> tsdgeos, we stopped crashing during smoke tests, too, though
[08:52] <tsdgeos> :D
[08:52] <tsdgeos> ah wait
[08:53] <tsdgeos> i wonder if it's the /proc thing
[08:53] <tsdgeos> or not, the /proc thing was only for Qt5.2
[08:53] <tsdgeos> and we're not using 5.2 in there
[09:42] <tsdgeos> dednick: so you think we should merge https://code.launchpad.net/~nick-dedekind/unity8/lp1264678-indicator.misalignment/+merge/200866 even with the sdk bug you found?
[09:42] <tsdgeos> dednick: also seen my comment at https://code.launchpad.net/~nick-dedekind/unity8/indicator.ubuntu-settings-components/+merge/199311 ?
[09:42] <dednick> tsdgeos: um, i think the bug is in trunk as well isnt it?
[09:43] <dednick> or i thought it would have nbeen...
[09:43] <tsdgeos> the on for the messaging?
[09:43] <tsdgeos> it's different but yes it's there
[09:43] <tsdgeos> ok
[09:44] <dednick> tsdgeos: i think we should merge. IMO...
[09:44] <tsdgeos> so you think we ought to merge it
[09:44] <tsdgeos> ok, i'll have a new look
[09:44] <dednick> tsdgeos: ta
[09:58] <tsdgeos> dednick: do we want to merge https://code.launchpad.net/~nick-dedekind/unity8/indicator.ubuntu-settings-components/+merge/199311 before that thing you say is fixed?
[10:01] <dednick> tsdgeos: um, i should probably make sure all is still well and nothing has regressed.
[10:01] <dednick> i'll put it back down to WIP
[10:01] <tsdgeos> oki
[10:39] <tsdgeos> dednick: https://code.launchpad.net/~nick-dedekind/unity8/lp1264678-indicator.misalignment/+merge/200866 needs remerging
[10:39] <dednick> tsdgeos: ok
[10:39] <dednick> thanks
[11:10] <tsdgeos> arg
[11:11] <tsdgeos> how do i tell cmake to use my custom installed qt
[11:11] <tsdgeos> can't seem to convince it to use PKG_CONFIG_PATH nor PATH (in case it's looking for qmake)
[11:11] <tsdgeos> ah wait, PATH worked now
[11:16] <tsdgeos> Mirv: ./tst_components -input tst_datepicker.qml
[11:16] <tsdgeos> is working for me
[11:17] <tsdgeos> Mirv: does it crash for you if run standalone?
[11:27] <dednick> tsdgeos: fixed merge
[11:27] <tsdgeos> oki
[11:30] <Mirv> tsdgeos: no, on my computer I did not get the problems the PPA builders are (reliably) getting, instead TextAreaAPI failed for me http://pastebin.ubuntu.com/6749529/
[11:31] <tsdgeos> :/
[11:31] <Mirv> tsdgeos: but the PPA builders stop before that, amd64 at DatePickerAPI and i386 at AlarmAPI
[11:31] <Mirv> almost like random but environment specific (so reproducable, but only on that machine) corruptions or such
[11:39] <tsdgeos> elopio: seen the comment i made on your search branch?
[11:40] <tsdgeos> Mirv: you should update the /proc patch to the new patch in https://codereview.qt-project.org/75282 that has now been merged and will be part of 5.2.2 (yeah missed 5.2.1 by one day)
[11:51] <Mirv> tsdgeos: ok
[11:54] <tsdgeos> Mirv: i can use the qt daily ppa to build the SDK
[11:54] <tsdgeos> do you have any other ppa around?
[11:55] <tsdgeos> Mirv: qtdeclarative5-unity-action-plugin doesn't want to install
[11:56] <tsdgeos> Qt5 Beta2  seems to have it
[11:56] <tsdgeos> let me switch to that ppa
[11:57] <Mirv> tsdgeos: qt5-beta2 PPA has the rebuilds of other packages (required, because of the libqt5core5a transition)
[11:57] <tsdgeos> Mirv: should i have both or just the qt5-beta2 PPA ?
[11:57] <Mirv> tsdgeos: if you want to test also qtbase stable branch snapshot in addition to the qtdeclarative snapshot that is already in qt5-beta2 PPA, keep the qt5-daily enabled
[11:57] <Mirv> tsdgeos: ^
[11:57] <tsdgeos> ok
[11:57] <Mirv> I didn't see difference however
[11:58] <Mirv> tsdgeos: you do know that some packages conflict if you plan use on your main desktop?
[11:58] <tsdgeos> Mirv: i'm using a chroot
[11:58] <Mirv> right, good
[12:15] <dednick> sil2100: I need a new release for ubuntu-settings-components. Still safe as it's not used.
[12:22] <dednick> larsu: can you sort a release for indicator-messages? need the fix for menu sensitivity
[12:23] <sil2100> dednick: I'll try, but will have to consult didrocks to maybe consider releasing it, as it has no affect on ubuntu-touch
[12:23] <sil2100> *effect
[12:24] <dednick> sil2100: hm. ok
[12:33] <dednick> tsdgeos: ok, that ubuntu-settings-component branch in unity8 is all set.
[12:44] <larsu> dednick: hm, I'd have thought that it gets released automatically again. seb128, do you know what's up?
[12:45] <seb128> larsu, no, we need a landing ask on the gdoc they have, let me add one for indicator-messages (and check other indicators)
[12:45] <tsdgeos> Mirv: so there's a known issue with 32 bit machines
[12:45] <seb128> dednick, ^
[12:45] <tsdgeos> Mirv: https://bugreports.qt-project.org/browse/QTBUG-35917
[12:45] <larsu> seb128: thanks!
[12:45] <dednick> seb128: thanks
[12:45] <tsdgeos> Mirv: that is causing one of the problems for me in my 32bit chroot, now i'll create a 64bit chroot and see how it oes
[12:50] <karni> Saviq: tsdgeos: any chance you guys could help me out with (supposedly) not having DashViews built? lp:~unity-team/unity8/new-scopes-vj-integration http://paste.ubuntu.com/6755972/
[12:51] <karni> I got blocked on that bit yesterday, and it's holding me back. meh.
[12:52] <tsdgeos> karni: does it work if you cd builddir and then run the make ?
[12:53] <tsdgeos> ah wait that is your new stuff
[12:53] <tsdgeos> not mine
[12:53] <tsdgeos> give me a sec
[12:53] <karni> I could try that, sure
[12:53] <tsdgeos> karni: are you setting all the paths and stuff?
[12:54] <karni> tsdgeos: That I may not know. I tried to add ResponsiveVerticalJournal to the appropriate CMakeLists, but I have a feeling that might be the problem.
[12:54] <tsdgeos> karni: what branch?
[12:54] <karni> lp:~unity-team/unity8/new-scopes-vj-integration
[12:55] <karni> tsdgeos: this is WIP, don't try too much ^ ^ I just want to get the make -C builddir/ tryResponsiveVerticalJournal not spit out compilation issues
[12:55] <tsdgeos> sure
[12:55] <tsdgeos> sorry lunch is calling, i'll try later, ok?
[12:55] <karni> sure thing :)
[12:55] <karni> enjoy your lunch
[13:09] <Mirv> tsdgeos: ok, interesting. that might explain some of eg. click-update-manager failure which only fails on i386. then again libhud-qt only fails on amd64..
[13:12] <Saviq> karni, FWIW, until you actually get to integrating it with the new scopes (i.e. building a CardVerticalJournal.qml), you could base on lp:unity8
[13:12] <Saviq> karni, but it's fine, we can make it so later as well
[13:12] <karni> Saviq: I see, I could try that
[13:14] <Saviq> karni, http://paste.ubuntu.com/6756080/ is what you're missing I'd say
[13:15] <karni> Saviq: will that now, thank you :)
[13:15] <Saviq> karni, and it's fine, work on what you have right now, we can split it out from new-scopes later
[13:15] <karni> okay
[13:15] <Saviq> karni, what I want is limit the diff between trunk and new-scopes
[13:16]  * karni nods
[13:16] <Saviq> karni, but new-scopes is an ok stop-gap anyway
[13:17] <Saviq> karni, only thing we'll lose is some history, potentially
[13:17] <karni> Understood :) I do see what yo usuggested helps, thank you
[13:17] <karni> tsdgeos: Saviq helped me out with import paths :)
[13:30] <elopio> tsdgeos: I did. Thanks for taking a look. I'm trying to fix that branch in
[13:30] <elopio> https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/textfield_emulators/+merge/189796
[13:36] <karni> tsdgeos: Not sure if that's my fault somewhere
[13:36] <karni> ASSERT: "m_indexColumnMap.contains(*modelIndex)" in file /home/karni/src/canonical/unity8/new-scopes/plugins/DashViews/verticaljournal.cpp, line 101
[13:36] <karni> Aborted (core dumped)
[13:36] <karni> make -C builddir/ tryResponsiveVerticalJournal from lp:~unity-team/unity8/new-scopes-vj-integration
[13:50] <tsdgeos> karni: having a look
[13:50] <karni> tnx
[13:51] <karni> tsdgeos: There's one thing I don't understand well. Does Journal have a concept of delegate?
[13:52] <tsdgeos> yes
[13:52] <karni> ok then : )
[13:52] <tsdgeos> same as for the listview or gridview
[13:53]  * karni nods
[13:53] <karni> tsdgeos: FTR don't try to run the tests of responsive vertical journal, that's not ready. I just wanted to be able to *see* it through tryResponsiveVerticalJournal
[13:53] <tsdgeos> sure
[13:54] <karni> And I thought it was high time for me to share whatever I had to keep things moving.
[13:54] <karni> Even if it's a core dump haha
[14:10] <seb128> MacSlow, hey, could you review https://code.launchpad.net/~townsend/notify-osd/remove-mouse-bubble-timer/+merge/193353 when you have some spare cycles?
[14:10] <MacSlow> seb128, noted
[14:11] <karni> tsdgeos: Please lemme know if you find anything, I'd love to help (if I can :) )
[14:11] <seb128> MacSlow, thanks
[14:11] <tsdgeos> karni: know what's wrong alrady
[14:11] <karni> tsdgeos: \o/
[14:11] <tsdgeos> karni: btw unfortunately the views we have don't support qml listmodels
[14:11] <tsdgeos> karni: since they are not abstractitemmodel
[14:12] <karni> tsdgeos: oh. that doesn't sound good.
[14:12] <tsdgeos> karni: so you'd have to wrap your ListModel in a SortFillterProxyModel or in a LimitModel
[14:13]  * karni looks at the docs
[14:13] <tsdgeos> they are our stuff
[14:13] <tsdgeos> not qml stuff
[14:13] <tsdgeos> just grep our source code
[14:14] <karni> okay
[14:16] <dandrader> tsdgeos, so unity8 uses ubuntumirserver qpa?
[14:17] <karni> tsdgeos: Meaning, I'd have to wrap my the ListModel { id: fakeModel ... } in tst_ResponsiveVerticalCournal with SortFilterProxyModel, and pass that as the test model?
[14:18] <dandrader> because I run it from the terminal, which has "QT_QPA_PLATFORM=ubuntumirclient" and it just worked. so I wonder what's happening
[14:19] <tsdgeos> karni: yep
[14:19] <karni> tsdgeos: thanks, I'll give it a shot
[14:19] <tsdgeos> dandrader: tbh i am not sure i know the answer to that question
[14:19] <tsdgeos> karni: that won't fix the crash
[14:19] <karni> tsdgeos: oh. can I do something about the crash as well?
[14:19] <tsdgeos> sure
[14:20] <tsdgeos> karni: if (!isComponentComplete() || height() < 0) { to ::refill in abstractjournal.cpp
[14:20] <karni> tsdgeos: If it gets too complex, I could continue work on the Card Header instead. That depends if I can pull it off haha :)
[14:20] <karni> tsdgeos: to.. call refill() ?
[14:20] <tsdgeos> karni: no in the refill call
[14:20] <tsdgeos> change the if
[14:20] <karni> oh gotcha
[14:20] <tsdgeos> to that
[14:20] <karni> tsdgeos: ack
[14:24] <tsdgeos> dandrader: seen the comments i made in the organic grid review?
[14:25] <tsdgeos> you did :D
[14:26] <tsdgeos> dandrader: can you review https://code.launchpad.net/~aacid/unity8/journal_misc_fixes/+merge/201785 ?
[14:27] <tsdgeos> oh man our friend test_Dash_Shown is back
[14:29] <karni> tsdgeos: wohoo. no crash, now wrap that model and hope to see something show up ;)
[14:29] <tsdgeos> cross fingers
[14:32] <tsdgeos> nic-doffay: standup
[14:33] <elopio> tsdgeos: do you know who can help me with the tests for the scopes and previews?
[14:33] <tsdgeos> me or mzanetti
[14:40] <elopio> tsdgeos or mzanetti: I will need big help with this branch:
[14:40] <elopio> https://code.launchpad.net/~elopio/unity8/app_preview/+merge/201718
[14:41] <elopio> because the code I'm doing is not testable. Please take a look at the line 107, and ping me back when you have some time to discuss.
[14:45] <karni> topic: '[Ubuntu-phone] ANN: Ubuntu Core/Touch Android 4.4 support [..]'
[15:02] <Saviq> didrocks, /me needs help with sane versioning in recipes, if you have 5 minutes
[15:02] <karni> Saviq: there's a question from my team - do we know if the Carousel has any limitations, like if it could not work in some template parameter combination?
[15:02] <Saviq> karni, there's a few, all should be listed in the spec
[15:03] <Saviq> karni, like there's a minimum of items, it can't have summary, it has to be vertical I believe
[15:03] <karni> Saviq: thanks, I'll follow up with him/see the spec
[15:03] <mzanetti> elopio: hey. so what exactly are you trying to do?
[15:03] <mzanetti> you writing tests for the tests? :)
[15:04] <elopio> mzanetti: hell yeah! I like danger.
[15:04] <mzanetti> but then, who is going to write the tests for those? :P
[15:04] <elopio> mzanetti: when writing the test helpers for the SDK, we found that they need tests inside the project.
[15:05] <mzanetti> ah... hmm, ok
[15:05] <elopio> otherwise, they would be tested indirectly by the projects using them, and it's caos.
[15:05] <mzanetti> yeah, I guess makes sense
[15:06] <elopio> mzanetti: the problem with testing the DashApps and AppPreview is that we can currently access them only through the click scope
[15:06] <elopio> and that means external communication with a server we don't control, so we will end up with a test we don't control.
[15:06] <elopio> does that make sense?
[15:07] <mzanetti> mhm
[15:07] <mzanetti> elopio: but why would you need to access those from the sdk helpers?
[15:08] <elopio> mzanetti: for example, I need to check that the helper called get_applications actually returns the list of app names displayed on the scope.
[15:09] <elopio> for that, I need to have a scope with a list of know apps.
[15:11] <elopio> what would be great is that instead of accessing DashApps through the click scope, we have an alternate scope only for testing with hardcoded values.
[15:11] <mzanetti> elopio: I think I'm missing something
[15:12] <mzanetti> elopio: you said you need to do this for the test helpers in the sdk
[15:12] <mzanetti> but I don't really see why another app would need to deal with the dash contents
[15:12] <mzanetti> shouldn't those helpers just be there for lets say, unlocking the greeter and such stuff?
[15:12] <karni> Saviq: Should I file a bug? spec "minimum number of items in the carousel is 5", code if (results.count <= 6) layout = "grid";
[15:13] <karni> Saviq: Or is the spec not up to date?
[15:13] <karni> (that's why I asked if I should file it)
[15:13] <elopio> mzanetti: the DashApps helpers and DashPreview helpers should be inside unity8, because the code for them is in unity8.
[15:13] <elopio> Then we will have tests in the project unity-scope-click that will use those helpers in order to test the functionality provided by the click scope.
[15:13] <Saviq> karni, I don't think the spec should say that - 5 might not be enough
[15:14] <elopio> mzanetti: are you with me there?
[15:14] <karni> Saviq: I'll leave a comment in the spec
[15:15] <Saviq> karni, thanks
[15:15] <karni> np :)
[15:16] <mzanetti> elopio: I don't think that makes much sense tbh
[15:16] <elopio> mzanetti: oh, this might help:
[15:16] <elopio> https://code.launchpad.net/~elopio/unity-scope-click/autopilot-open_preview/+merge/201797
[15:16] <elopio> that's the test I'm writing, that needs helpers from unity.
[15:16] <mzanetti> elopio: all this causes are more fragile tests
[15:16] <elopio> line 103
[15:17] <elopio> that code, in my opinion, should be part of unity8, not of the click scope.
[15:17] <elopio> mzanetti: why more fragile?
[15:17] <mzanetti> elopio: because if we mess up in unity, your scope tests will fail
[15:17] <mzanetti> elopio: imho the scope tests should just tests the scope, not unity
[15:17] <elopio> mzanetti: no, because if you mess in unity, the self-tests for the helpers will fail and you won't be able to merge.
[15:18] <elopio> mzanetti: well, that would be nice too. But how do I open the scope without unity?
[15:18] <mzanetti> yeah... its like having tests for tests for tests for nothing. why not just test the scope itself?
[15:18] <mzanetti> elopio: I'm sure there is a way
[15:18] <elopio> mzanetti: ok, lets say that you change the objectName titleLabel
[15:19] <elopio> you do that change in unity.
[15:19] <elopio> and if we don't have tests in unity to catch that change, it will result in a failure in unity-scope-click
[15:19] <mzanetti> elopio: exactly. the unity-scope-click tests should not depend on some objectName in unity
[15:20] <tsdgeos> Saviq: what do you think about forcing the bad loop for that test?
[15:20] <elopio> mzanetti: oh, but that's unavoidable. Because the code for the UI unity-scope-click is using lives in the unity project.
[15:20] <Saviq> tsdgeos, not sure what you mean?
[15:20] <elopio> mzanetti: what we need to do is provide helpers from unity, so unity-scope-click uses those helpers and doesn't have to take care about objectNames.
[15:20] <tsdgeos> Saviq: the testDashShown, does not fail if you force the non threaded scenegraph loop
[15:21] <Saviq> tsdgeos, ah
[15:21] <elopio> and if we change an objectName, or layout, or even some functionality, we change the helper and it will be transparent for unity-scope-click
[15:21] <Saviq> tsdgeos, yeah, that could be useful
[15:21] <mzanetti> I'm still not convinced. can't we just fire up that scope alone, without unity and test it?
[15:21] <mzanetti> Saviq: ^?
[15:21] <elopio> mzanetti: I would love that
[15:22] <tsdgeos> Saviq is working on that in the dash tool, no?
[15:22] <elopio> but the code for the UI would still live in the unity project.
[15:22] <mzanetti> elopio: you shouldn't test the ui
[15:22] <Saviq> tsdgeos, I did, but then you broke it with the dashbar
[15:22] <mzanetti> elopio: just do queries on the scopes api
[15:22] <tsdgeos> ^_^
[15:22] <mzanetti> there are tests inside unity8 which test the ui
[15:22] <Saviq> tsdgeos, PROPERTIES ENVIRONMENT... in CMakeLists.txt should do what we need for the env
[15:23] <elopio> mzanetti: eventually, we will need to test the integration of unity, unity-scope-click, the search server and the software center agent server.
[15:23] <tsdgeos> Saviq: oka, gonna try that, ideally i'd like it to be inside a "if qt 5.0" so if we update to 5.2 and still happens we really need to look at it
[15:23] <elopio> if we don't do autopilot tests for that, we will have to do it manually.
[15:23] <Saviq> tsdgeos, should be doable in CMake
[15:23] <Saviq> mzanetti, elopio, we should only test a few journeys, and then through actual unity8 shell
[15:24] <mzanetti> elopio: sure, but that's another thing
[15:24] <elopio> mzanetti: that's what I'm doing here.
[15:24] <Saviq> mzanetti, elopio, a very high level test
[15:24] <mzanetti> elopio: yeah, what saviq said, those full stack integration tests should live inside the unity8 repo
[15:24] <elopio> mzanetti: I'm testing a user journey to buy an app.
[15:24] <Saviq> mzanetti, should they? I don't think so
[15:24] <Saviq> mzanetti, they're ubuntu tests, not unity8 tests
[15:24] <mzanetti> hmm...
[15:25] <elopio> agree to that.
[15:25] <mzanetti> Saviq: but them being part of unity-scope-click feels wrong too
[15:25] <elopio> and those ubuntu tests need helpers to interact with unity8, and with unity-scope-click.
[15:25] <tsdgeos> pstolowski: is this yours? https://bugs.launchpad.net/bugs/1269456
[15:25] <tsdgeos> or was that pete-woods'? ↑
[15:26] <pete-woods> tsdgeos: the strings are in the apps providing the data
[15:26] <pstolowski> tsdgeos, not mine
[15:27] <tsdgeos> pstolowski: you start with p too so you and pete-woods are the same person in my mind ^_^ :D
[15:27] <elopio> mzanetti: for now, what we have in unity-scope-click are also helpers.
[15:27] <elopio> Maybe the test for the whole journey should live in a project with a bigger scope, I like that.
[15:27] <mzanetti> elopio: ok... I'm convinced now... we need those helpers.
[15:27] <elopio> where I think we disagree is that I say the helpers need to be next to the code that implements their functionality.
[15:27] <pete-woods> tsdgeos, pstolowski: http://bazaar.launchpad.net/~phablet-team/camera-app/trunk/view/head:/camera-app.qml
[15:27] <pstolowski> tsdgeos, :)
[15:27] <elopio> mzanetti: ok, so we disagree even before that :)
[15:28] <elopio> mzanetti: how would you do it without helpers?
[15:28] <mzanetti> as I said, I agree now that we need those helpers
[15:28] <mzanetti> let me check the code again
[15:28] <elopio> ahh, sorry.
[15:29] <elopio> mzanetti: I got it backwards :)
[15:34] <mzanetti> elopio: ok... so your problem now is that the test for the helpers (not the actual full stack test) is using the real scope backend instad of some mock, right?
[15:36] <mzanetti> tsdgeos: do we have any mocks for scope backends yet?
[15:36] <tsdgeos> we do
[15:36] <mzanetti> for which ones?
[15:36] <tsdgeos> ./mocks/Unity/moc_fake_scope.cpp
[15:36] <tsdgeos> in tests
[15:36] <mzanetti> ah right, of course
[15:37] <mzanetti> elopio: so, what you'd need to do is to start unity with the fake plugins for that test
[15:38] <Saviq> mzanetti, (got busy, but) I think such high level tests deserve a completely separate project
[15:38] <mzanetti> Saviq: yeah, +1
[15:38] <mzanetti> meh.. hes gone
[15:40] <mzanetti> elopio: welcome back :)
[15:40] <mzanetti> elopio: how far did you follow?
[15:42] <elopio> sorry
[15:42] <elopio> [09:41:32] <mzanetti> Saviq: yeah, +1
[15:42] <elopio> that was the latest I got.
[15:42] <mzanetti> elopio: ah ok. you got everything then
[15:42] <mzanetti> elopio: so, what you'd need to do is to start unity with the fake plugins for that test
[15:42] <mzanetti> this is the bottomline
[15:42] <elopio> mzanetti: yes, I want that!
[15:43] <elopio> do you know how to do it?
[15:43] <mzanetti> elopio: you can do this by exporting an env var before starting unity
[15:43] <mzanetti> iirc its LD_LIBRARY_PATH
[15:43] <elopio> :D:D:D
[15:43] <mzanetti> or QML2_PLUGIN_PATH
[15:43] <elopio> I thought I would be stuck with this for a couple of weeks :D
[15:43] <mzanetti> check out run.sh
[15:43]  * elopio checks.
[15:44] <mzanetti> elopio: so if you just run ./run.sh, then you'll have those fake backends
[15:44] <mzanetti> elopio: autopilot should normally _not_ use them.
[15:44] <mzanetti> elopio: but your case makes a valid exception
[15:45] <elopio> ok, I'll play with it and be back with the branch finished probably tomorrow.
[15:45] <mzanetti> elopio: please add comments on those tests on why you do "unit tests" with autopilot
[15:46] <elopio> mzanetti: I'll try to explain what I explained to you in test_emulators.py, sure.
[15:49] <elopio> Saviq: can you please explain to me what's the dash tool? It sounds like something I will enjoy.
[15:51] <Saviq> elopio, you'll be able to tweak the display of the scopes live
[15:51] <Saviq> elopio, and then paste the result into your $scope
[15:52] <elopio> Saviq: is that something for users, or for developers?
[16:07] <Saviq> elopio, scope developers
[16:08] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/bad_loop_dash_test/+merge/201802
[16:21] <elopio> I need help again.
[16:21] <elopio> when we run the tests from jenkins, will that builddir exist?
[16:21] <elopio> or are we just running from the installed deb?
[16:23] <tsdgeos> i think we run them on compile time
[16:23] <tsdgeos> but not totally sure
[16:24] <elopio> I'll just mark the branch as ready to review to see if jenkins complaints.
[16:29] <bregma> Saviq, I finally got Unity8 not crashing on Mir on the desktop, but I get 'file:///usr/share/unity8/Shell.qml:20:1: module "Unity.Application" is not installed' ... where should this be pulled from (assuming no fake env)?
[16:39] <seb128> bregma, hey, could somebody look at https://launchpadlibrarian.net/162536013/buildlog_ubuntu-trusty-ppc64el.unity_7.1.2%2B14.04.20131106.1-0ubuntu2_FAILEDTOBUILD.txt.gz ?
[16:40] <bregma> seb128, I think ChrisTownsend is already on it
[16:41] <seb128> great
[16:41] <bregma> https://code.launchpad.net/~townsend/unity/fix-zeitgeist-build-failure/+merge/201791
[16:41] <seb128> bregma, ChrisTownsend: thanks
[16:44] <tsdgeos> bregma: isn't that unity-mir?
[16:44] <tsdgeos> bregma: Unity.Application i mean
[16:44] <bregma> tsdgeos, I dunno, that's why I'm asking
[16:44] <tsdgeos> bregma: should be
[16:44] <tsdgeos> bregma: do you have unity-mir installed?
[16:45] <bregma> tsdgeos, hmm, doesn't look like it
[16:45] <tsdgeos> get it then
[16:45] <bregma> if it's required, shouldn;t it be a package dependency?
[16:47] <bregma> ah, I see the binary package name is libunity-mir1, it's already installed
[16:47] <bregma> fingers point at the usual suspect of assuming an Android/Linux system
[16:47] <tsdgeos> i guess
[16:48] <karni> tsdgeos: Do we want a minimumColumnWidth property for VerticalJournal? It's not always the case that if dev sets maximumNumberOfColums in ResponsiveVerticalJournal to 100 - that it actually makes sense, right? What should be the sanity measure?
[16:48] <bregma> is there an environment variable that needs to be set to make Qt pick up a nonstandard plugin path?
[16:49] <karni> tsdgeos: a fixed minimumColumnWidth?
[16:49] <tsdgeos> bregma: QT_PLugIN_PATH and loads of otehrs, depend of what you want to do
[16:49] <bregma> it's a start
[16:49] <karni> tsdgeos: Honestly, I'm having a problem coming up with formula for case when the no. of visible columns should actually be smaller than maximumNumberOfColumns set. Does that make sense?
[16:49] <tsdgeos> karni: i think that if someone wants to shoot himself on the foot
[16:50] <tsdgeos> it's his fault
[16:50] <karni> tsdgeos: That makes my life easier, lol ;)
[16:50] <karni> Guess thats' too much thinking on my end. Aight.
[16:50] <tsdgeos> bregma: there's also QML_IMPORT_PATH i think is called
[16:50] <tsdgeos> bregma: what are you trying to do?
[16:51] <bregma> tsdgeos, I am trying to get a Unity8 user session running on the Ubuntu Trusty desktop, as part of the ongoing convergence effort
[16:52] <tsdgeos> bregma: sure, i mean right now, what plugin you want to force?
[16:52] <bregma> tsdgeos, I want to get the Unity.Application to be found ...  I recall having to set the environment variables before
[16:54] <tsdgeos> bregma: if it's installed in usr/lib/*/qt5/ you should not need to set anything
[16:54] <tsdgeos> it's just picked as the other billions of plugins we use
[16:55] <karni> tsdgeos: I see your verticaljournal in its full glory. Success :) Thank you!
[16:55] <bregma> well, QML_IMPORT_TRACE will give me data
[16:55] <tsdgeos> karni: cool
[17:00] <tsdgeos> dandrader_: seen the misc fixes branch for the journals?
[17:10] <bregma> well, the magic incantation is QML2_IMPORT_PATH=/usr/lib/x86_64-linux-gnu/qt5/imports/Unity-Mir ... which means arch-specific config files hashtag sadface
[17:11] <bregma> but at least I now get a purple box in the lower left corner of my screen when loggin in to unity8 on the desktop
[17:11] <bregma> on to the next great adventure
[17:17] <bregma> ah, so my new problem is that all the shaders are failing to compile, such fun, wow, very setback
[17:18] <bregma> anyone have any clue about QOpenGLShader in the Unity8 stack
[17:18] <bregma> ?
[17:22] <dandrader> bregma, you might have better luck asking in #ubuntu-mir. guys there know much more about GL stuff (even if they lack in Qt knowledge)... and there's a GL debug log object in Qt you could use to get a hint of what's going on the GL side
[17:22] <dandrader> namely QOpenGLDebugLogger
[17:23] <dandrader> so hopefully an error message will show up in there
[17:24] <bregma> dandrader, it's obvious why the shaders aren't compiling, I need to figure out where the shaders come from and why the wrong ones are being picked up by Qt ...  probably another environment variable needs to be set somewhere
[17:24] <dandrader> ah ok
[17:29] <elopio> mzanetti: still around?
[17:29] <mzanetti> elopio: yep
[17:29] <elopio> mzanetti: the mock is using the generic DashPreview instead of AppPreview. How can I change that?
[17:31] <mzanetti> elopio: hmm... I think you'd need to create a new one. but I'd need to look it up myself
[17:31] <mzanetti> let me just finish this task here and I'll have a look
[17:32] <elopio> mzanetti: yes, thanks, because I have no idea how to create one.
[17:43] <bregma> ah, OK, my problem is that Qt5 is built on desktop to always assume an OpenGL context, and the quubuntu project used in Unity8 forces an OpenGL|ES context, giving a fundamental impedence mismatch
[17:44] <bregma> so Qt itself feeds GLSL into GLSL|ES and everyone ends up unhappy and eating ice cream from the bucket
[17:57] <mzanetti> elopio: hi. I have time for you now
[17:57] <mzanetti> elopio: so, I see there is already a fake_application_scope
[17:58] <elopio> mzanetti: yes, I'm using it right now.
[17:58] <elopio> the thing is that it's not using the right preview.
[17:58] <mzanetti> elopio: mhm... that seems to be a bug
[17:58] <mzanetti> probably in the fake scope, as it does work in the real thing
[17:58] <elopio> mzanetti: a bug on the fake?
[17:59] <elopio> yeah, the real thing is using AppPreview.
[17:59] <mzanetti> let me check how we determine which preview to use
[18:03] <mzanetti> elopio: hmm... seems that DeeModel which is created lacks some inforamtion about rendererid and contentType
[18:03] <elopio> mzanetti: which file are you looking at? I didn't even could find the fake source code.
[18:03] <mzanetti> elopio: tests/mocks/Unity/fake_applications_scope.cpp
[18:04] <mzanetti> so far I have no idea where that DeeModel is filled
[18:09] <elopio> mzanetti: alecu might be able to help us with this.
[18:10] <elopio> he's having lunch though.
[18:10] <elopio> mzanetti: I'm not sure if you are close to EOD, but please don't stay just for me, we can continue tomorrow.
[18:11] <mzanetti> elopio: no worries....
[18:12] <mzanetti> elopio: got it
[18:12] <mzanetti> elopio: tests/mocks/Unity/fake_preview.cpp
[18:12] <mzanetti> elopio: in there is a method rendererName()
[18:13] <mzanetti> elopio: it always returns generic-preview
[18:13] <mzanetti> elopio: the proview is created in in tests/mocks/Unity/fake_scope.cpp line 50
[18:15] <mzanetti> elopio: try doing something like if (m_id == "applications.scope") { preview->setRendererName("preview-application"); }
[18:15] <mzanetti> that should do I hope
[18:15] <elopio> mzanetti: let me try that.
[18:26] <alecu> hi mzanetti, elopio: anything I can help with?
[18:27] <mzanetti> alecu: hi. I think we found everything
[18:27] <alecu> great
[18:27] <mzanetti> elopio: does it work?
[19:01] <elopio> mzanetti, alecu, sorry, some real life stuff came up.
[19:01] <elopio> mzanetti: I don't really now where should I put that code.
[19:01] <elopio> I don't see any preview variable in the Scope.
[19:02] <elopio> and there's one inside the connect statement, but  p->setRendererName says there's no setRendererName member.
[19:02] <elopio> I'm sorry, this is the first line of c++ code I've written in like 5 years :)
[19:08] <mzanetti> :)
[19:25] <elopio> mzanetti: what about this? http://paste.ubuntu.com/6757904/
[19:26] <elopio> it works, but is that good c++ code?
[19:26] <mzanetti> elopio: hmm... might work... but not nice
[19:26] <mzanetti> one sec, I'll push something for you
[19:27] <elopio> yeah, I bet I need more patience than what you thought first when volunteering to help me :D
[19:27] <elopio> well, at least I made it work.
[19:28] <mzanetti> elopio: do you have a branch where you push this stuff?
[19:29] <mzanetti> ah this one https://code.launchpad.net/~elopio/unity8/app_preview/+merge/201718
[19:30] <elopio> mzanetti: that one, yes.
[19:30] <mzanetti> elopio: https://code.launchpad.net/~mzanetti/unity8/fake-application-previews/+merge/201836
[19:36] <elopio> mzanetti: so simple :D thank you very much.
[19:41] <mzanetti> no
[22:41] <imlostbro> I'm having trouble getting 'Details' to open in System Settings. Nothing pops up and when I go to Task Manager, I see gnome-control-center gradually hogging up ram. Does anyone know a fix??