=== duflu_ is now known as duflu [06:51] ricmm_: https://docs.google.com/a/canonical.com/document/d/1HwxEhrZ45WDngypEmGLW1lHXqf6nLKqdnYORwTALo8E/edit [08:40] Saviq: why the preference for null over undefined? [08:41] tsdgeos, return null vs. failure [08:41] tsdgeos, don't remember now why, but that reduced some warnings for me, let me check [08:42] tsdgeos, but anyway, null has more "value" than undefined [08:42] tsdgeos, ah I know now [08:42] property Item header: findChild(card, "cardHeader") [08:42] was warning when undefined [08:43] ok [08:43] change looks ok to me, was just wondering the reason :) [08:43] tsdgeos, generally, undefined is... undefined [08:43] tsdgeos, while null has a value... of null... [08:44] so the function returns nothing now, as opposed to not knowing what it returns (of sorts) [08:51] Saviq: and the otto thing fixed itslef :D [08:51] tsdgeos, indeed it did [08:52] tsdgeos, fginther was baffled [08:52] tsdgeos, he couldn't find any reason why it started, or any reason why it stopped again... [08:52] tsdgeos, we stopped crashing during smoke tests, too, though [08:52] :D [08:52] ah wait [08:53] i wonder if it's the /proc thing [08:53] or not, the /proc thing was only for Qt5.2 [08:53] and we're not using 5.2 in there [09:42] 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] dednick: also seen my comment at https://code.launchpad.net/~nick-dedekind/unity8/indicator.ubuntu-settings-components/+merge/199311 ? [09:42] tsdgeos: um, i think the bug is in trunk as well isnt it? [09:43] or i thought it would have nbeen... [09:43] the on for the messaging? [09:43] it's different but yes it's there [09:43] ok [09:44] tsdgeos: i think we should merge. IMO... [09:44] so you think we ought to merge it [09:44] ok, i'll have a new look [09:44] tsdgeos: ta [09:58] 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] tsdgeos: um, i should probably make sure all is still well and nothing has regressed. [10:01] i'll put it back down to WIP [10:01] oki === tsdgeos_ is now known as tsdgeos [10:39] dednick: https://code.launchpad.net/~nick-dedekind/unity8/lp1264678-indicator.misalignment/+merge/200866 needs remerging [10:39] tsdgeos: ok [10:39] thanks [11:10] arg [11:11] how do i tell cmake to use my custom installed qt [11:11] can't seem to convince it to use PKG_CONFIG_PATH nor PATH (in case it's looking for qmake) [11:11] ah wait, PATH worked now [11:16] Mirv: ./tst_components -input tst_datepicker.qml [11:16] is working for me [11:17] Mirv: does it crash for you if run standalone? [11:27] tsdgeos: fixed merge [11:27] oki [11:30] 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] :/ [11:31] tsdgeos: but the PPA builders stop before that, amd64 at DatePickerAPI and i386 at AlarmAPI [11:31] almost like random but environment specific (so reproducable, but only on that machine) corruptions or such [11:39] elopio: seen the comment i made on your search branch? [11:40] 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] tsdgeos: ok === _salem is now known as salem_ [11:54] Mirv: i can use the qt daily ppa to build the SDK [11:54] do you have any other ppa around? === MacSlow is now known as MacSlow|lunch [11:55] Mirv: qtdeclarative5-unity-action-plugin doesn't want to install [11:56] Qt5 Beta2 seems to have it [11:56] let me switch to that ppa [11:57] tsdgeos: qt5-beta2 PPA has the rebuilds of other packages (required, because of the libqt5core5a transition) [11:57] Mirv: should i have both or just the qt5-beta2 PPA ? [11:57] 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] tsdgeos: ^ === alan_g is now known as alan_g|afk [11:57] ok [11:57] I didn't see difference however [11:58] tsdgeos: you do know that some packages conflict if you plan use on your main desktop? [11:58] Mirv: i'm using a chroot [11:58] right, good === alan_g|afk is now known as alan_g [12:15] sil2100: I need a new release for ubuntu-settings-components. Still safe as it's not used. [12:22] larsu: can you sort a release for indicator-messages? need the fix for menu sensitivity [12:23] 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] *effect [12:24] sil2100: hm. ok [12:33] tsdgeos: ok, that ubuntu-settings-component branch in unity8 is all set. === alan_g is now known as alan_g|lunch [12:44] dednick: hm, I'd have thought that it gets released automatically again. seb128, do you know what's up? [12:45] 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] Mirv: so there's a known issue with 32 bit machines [12:45] dednick, ^ [12:45] Mirv: https://bugreports.qt-project.org/browse/QTBUG-35917 [12:45] seb128: thanks! [12:45] seb128: thanks [12:45] 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] 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] I got blocked on that bit yesterday, and it's holding me back. meh. [12:52] karni: does it work if you cd builddir and then run the make ? [12:53] ah wait that is your new stuff [12:53] not mine [12:53] give me a sec [12:53] I could try that, sure [12:53] karni: are you setting all the paths and stuff? [12:54] 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] karni: what branch? [12:54] lp:~unity-team/unity8/new-scopes-vj-integration === MacSlow|lunch is now known as MacSlow [12:55] 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] sure [12:55] sorry lunch is calling, i'll try later, ok? [12:55] sure thing :) [12:55] enjoy your lunch [13:09] 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] 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] karni, but it's fine, we can make it so later as well [13:12] Saviq: I see, I could try that [13:14] karni, http://paste.ubuntu.com/6756080/ is what you're missing I'd say [13:15] Saviq: will that now, thank you :) [13:15] karni, and it's fine, work on what you have right now, we can split it out from new-scopes later [13:15] okay [13:15] karni, what I want is limit the diff between trunk and new-scopes [13:16] * karni nods [13:16] karni, but new-scopes is an ok stop-gap anyway [13:17] karni, only thing we'll lose is some history, potentially [13:17] Understood :) I do see what yo usuggested helps, thank you [13:17] tsdgeos: Saviq helped me out with import paths :) === alan_g|lunch is now known as alan_g [13:30] tsdgeos: I did. Thanks for taking a look. I'm trying to fix that branch in [13:30] https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/textfield_emulators/+merge/189796 [13:36] tsdgeos: Not sure if that's my fault somewhere [13:36] ASSERT: "m_indexColumnMap.contains(*modelIndex)" in file /home/karni/src/canonical/unity8/new-scopes/plugins/DashViews/verticaljournal.cpp, line 101 [13:36] Aborted (core dumped) [13:36] make -C builddir/ tryResponsiveVerticalJournal from lp:~unity-team/unity8/new-scopes-vj-integration [13:50] karni: having a look [13:50] tnx [13:51] tsdgeos: There's one thing I don't understand well. Does Journal have a concept of delegate? [13:52] yes [13:52] ok then : ) [13:52] same as for the listview or gridview [13:53] * karni nods [13:53] 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] sure [13:54] And I thought it was high time for me to share whatever I had to keep things moving. [13:54] Even if it's a core dump haha [14:10] 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] seb128, noted [14:11] tsdgeos: Please lemme know if you find anything, I'd love to help (if I can :) ) [14:11] MacSlow, thanks [14:11] karni: know what's wrong alrady [14:11] tsdgeos: \o/ [14:11] karni: btw unfortunately the views we have don't support qml listmodels [14:11] karni: since they are not abstractitemmodel [14:12] tsdgeos: oh. that doesn't sound good. [14:12] 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] they are our stuff [14:13] not qml stuff [14:13] just grep our source code [14:14] okay [14:16] tsdgeos, so unity8 uses ubuntumirserver qpa? [14:17] 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] 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] karni: yep [14:19] tsdgeos: thanks, I'll give it a shot [14:19] dandrader: tbh i am not sure i know the answer to that question [14:19] karni: that won't fix the crash [14:19] tsdgeos: oh. can I do something about the crash as well? [14:19] sure [14:20] karni: if (!isComponentComplete() || height() < 0) { to ::refill in abstractjournal.cpp [14:20] 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] tsdgeos: to.. call refill() ? [14:20] karni: no in the refill call [14:20] change the if [14:20] oh gotcha [14:20] to that [14:20] tsdgeos: ack [14:24] dandrader: seen the comments i made in the organic grid review? [14:25] you did :D [14:26] dandrader: can you review https://code.launchpad.net/~aacid/unity8/journal_misc_fixes/+merge/201785 ? [14:27] oh man our friend test_Dash_Shown is back [14:29] tsdgeos: wohoo. no crash, now wrap that model and hope to see something show up ;) [14:29] cross fingers [14:32] nic-doffay: standup [14:33] tsdgeos: do you know who can help me with the tests for the scopes and previews? [14:33] me or mzanetti [14:40] tsdgeos or mzanetti: I will need big help with this branch: [14:40] https://code.launchpad.net/~elopio/unity8/app_preview/+merge/201718 [14:41] 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] topic: '[Ubuntu-phone] ANN: Ubuntu Core/Touch Android 4.4 support [..]' === dandrader is now known as dandrader|lunch [15:02] didrocks, /me needs help with sane versioning in recipes, if you have 5 minutes [15:02] 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] karni, there's a few, all should be listed in the spec [15:03] karni, like there's a minimum of items, it can't have summary, it has to be vertical I believe [15:03] Saviq: thanks, I'll follow up with him/see the spec [15:03] elopio: hey. so what exactly are you trying to do? [15:03] you writing tests for the tests? :) [15:04] mzanetti: hell yeah! I like danger. [15:04] but then, who is going to write the tests for those? :P [15:04] mzanetti: when writing the test helpers for the SDK, we found that they need tests inside the project. [15:05] ah... hmm, ok [15:05] otherwise, they would be tested indirectly by the projects using them, and it's caos. [15:05] yeah, I guess makes sense [15:06] mzanetti: the problem with testing the DashApps and AppPreview is that we can currently access them only through the click scope [15:06] 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] does that make sense? [15:07] mhm [15:07] elopio: but why would you need to access those from the sdk helpers? [15:08] 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] for that, I need to have a scope with a list of know apps. [15:11] 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] elopio: I think I'm missing something [15:12] elopio: you said you need to do this for the test helpers in the sdk [15:12] but I don't really see why another app would need to deal with the dash contents [15:12] shouldn't those helpers just be there for lets say, unlocking the greeter and such stuff? [15:12] 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] Saviq: Or is the spec not up to date? [15:13] (that's why I asked if I should file it) [15:13] mzanetti: the DashApps helpers and DashPreview helpers should be inside unity8, because the code for them is in unity8. [15:13] 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] karni, I don't think the spec should say that - 5 might not be enough [15:14] mzanetti: are you with me there? [15:14] Saviq: I'll leave a comment in the spec [15:15] karni, thanks [15:15] np :) [15:16] elopio: I don't think that makes much sense tbh [15:16] mzanetti: oh, this might help: [15:16] https://code.launchpad.net/~elopio/unity-scope-click/autopilot-open_preview/+merge/201797 [15:16] that's the test I'm writing, that needs helpers from unity. [15:16] elopio: all this causes are more fragile tests [15:16] line 103 [15:17] that code, in my opinion, should be part of unity8, not of the click scope. [15:17] mzanetti: why more fragile? [15:17] elopio: because if we mess up in unity, your scope tests will fail [15:17] elopio: imho the scope tests should just tests the scope, not unity [15:17] 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] mzanetti: well, that would be nice too. But how do I open the scope without unity? [15:18] yeah... its like having tests for tests for tests for nothing. why not just test the scope itself? [15:18] elopio: I'm sure there is a way [15:18] mzanetti: ok, lets say that you change the objectName titleLabel [15:19] you do that change in unity. [15:19] 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] elopio: exactly. the unity-scope-click tests should not depend on some objectName in unity [15:20] Saviq: what do you think about forcing the bad loop for that test? [15:20] mzanetti: oh, but that's unavoidable. Because the code for the UI unity-scope-click is using lives in the unity project. [15:20] tsdgeos, not sure what you mean? [15:20] 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] Saviq: the testDashShown, does not fail if you force the non threaded scenegraph loop [15:21] tsdgeos, ah [15:21] 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] tsdgeos, yeah, that could be useful [15:21] I'm still not convinced. can't we just fire up that scope alone, without unity and test it? [15:21] Saviq: ^? [15:21] mzanetti: I would love that [15:22] Saviq is working on that in the dash tool, no? [15:22] but the code for the UI would still live in the unity project. [15:22] elopio: you shouldn't test the ui [15:22] tsdgeos, I did, but then you broke it with the dashbar [15:22] elopio: just do queries on the scopes api [15:22] ^_^ [15:22] there are tests inside unity8 which test the ui [15:22] tsdgeos, PROPERTIES ENVIRONMENT... in CMakeLists.txt should do what we need for the env [15:23] 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] 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] if we don't do autopilot tests for that, we will have to do it manually. [15:23] tsdgeos, should be doable in CMake [15:23] mzanetti, elopio, we should only test a few journeys, and then through actual unity8 shell [15:24] elopio: sure, but that's another thing [15:24] mzanetti: that's what I'm doing here. [15:24] mzanetti, elopio, a very high level test [15:24] elopio: yeah, what saviq said, those full stack integration tests should live inside the unity8 repo [15:24] mzanetti: I'm testing a user journey to buy an app. [15:24] mzanetti, should they? I don't think so [15:24] mzanetti, they're ubuntu tests, not unity8 tests [15:24] hmm... [15:25] agree to that. [15:25] Saviq: but them being part of unity-scope-click feels wrong too [15:25] and those ubuntu tests need helpers to interact with unity8, and with unity-scope-click. [15:25] pstolowski: is this yours? https://bugs.launchpad.net/bugs/1269456 [15:25] Ubuntu bug 1269456 in Unity 8 "Infographic doesn’t seem to be translatable" [Undecided,New] [15:25] or was that pete-woods'? ↑ [15:26] tsdgeos: the strings are in the apps providing the data [15:26] tsdgeos, not mine [15:27] pstolowski: you start with p too so you and pete-woods are the same person in my mind ^_^ :D [15:27] mzanetti: for now, what we have in unity-scope-click are also helpers. [15:27] Maybe the test for the whole journey should live in a project with a bigger scope, I like that. [15:27] elopio: ok... I'm convinced now... we need those helpers. [15:27] where I think we disagree is that I say the helpers need to be next to the code that implements their functionality. [15:27] tsdgeos, pstolowski: http://bazaar.launchpad.net/~phablet-team/camera-app/trunk/view/head:/camera-app.qml [15:27] tsdgeos, :) [15:27] mzanetti: ok, so we disagree even before that :) [15:28] mzanetti: how would you do it without helpers? [15:28] as I said, I agree now that we need those helpers [15:28] let me check the code again [15:28] ahh, sorry. [15:29] mzanetti: I got it backwards :) [15:34] 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] tsdgeos: do we have any mocks for scope backends yet? [15:36] we do [15:36] for which ones? [15:36] ./mocks/Unity/moc_fake_scope.cpp [15:36] in tests [15:36] ah right, of course [15:37] elopio: so, what you'd need to do is to start unity with the fake plugins for that test [15:38] mzanetti, (got busy, but) I think such high level tests deserve a completely separate project [15:38] Saviq: yeah, +1 [15:38] meh.. hes gone [15:40] elopio: welcome back :) [15:40] elopio: how far did you follow? [15:42] sorry [15:42] [09:41:32] Saviq: yeah, +1 [15:42] that was the latest I got. [15:42] elopio: ah ok. you got everything then [15:42] elopio: so, what you'd need to do is to start unity with the fake plugins for that test [15:42] this is the bottomline [15:42] mzanetti: yes, I want that! [15:43] do you know how to do it? [15:43] elopio: you can do this by exporting an env var before starting unity [15:43] iirc its LD_LIBRARY_PATH [15:43] :D:D:D [15:43] or QML2_PLUGIN_PATH [15:43] I thought I would be stuck with this for a couple of weeks :D [15:43] check out run.sh [15:43] * elopio checks. [15:44] elopio: so if you just run ./run.sh, then you'll have those fake backends [15:44] elopio: autopilot should normally _not_ use them. [15:44] elopio: but your case makes a valid exception [15:45] ok, I'll play with it and be back with the branch finished probably tomorrow. [15:45] elopio: please add comments on those tests on why you do "unit tests" with autopilot [15:46] mzanetti: I'll try to explain what I explained to you in test_emulators.py, sure. [15:49] Saviq: can you please explain to me what's the dash tool? It sounds like something I will enjoy. [15:51] elopio, you'll be able to tweak the display of the scopes live [15:51] elopio, and then paste the result into your $scope [15:52] Saviq: is that something for users, or for developers? === Wellark_ is now known as Wellark [16:07] elopio, scope developers [16:08] Saviq: https://code.launchpad.net/~aacid/unity8/bad_loop_dash_test/+merge/201802 [16:21] I need help again. [16:21] when we run the tests from jenkins, will that builddir exist? [16:21] or are we just running from the installed deb? [16:23] i think we run them on compile time [16:23] but not totally sure [16:24] I'll just mark the branch as ready to review to see if jenkins complaints. [16:29] 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] 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] seb128, I think ChrisTownsend is already on it [16:41] great [16:41] https://code.launchpad.net/~townsend/unity/fix-zeitgeist-build-failure/+merge/201791 [16:41] bregma, ChrisTownsend: thanks [16:44] bregma: isn't that unity-mir? [16:44] bregma: Unity.Application i mean [16:44] tsdgeos, I dunno, that's why I'm asking [16:44] bregma: should be [16:44] bregma: do you have unity-mir installed? [16:45] tsdgeos, hmm, doesn't look like it [16:45] get it then [16:45] if it's required, shouldn;t it be a package dependency? [16:47] ah, I see the binary package name is libunity-mir1, it's already installed [16:47] fingers point at the usual suspect of assuming an Android/Linux system [16:47] i guess [16:48] 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] is there an environment variable that needs to be set to make Qt pick up a nonstandard plugin path? [16:49] tsdgeos: a fixed minimumColumnWidth? [16:49] bregma: QT_PLugIN_PATH and loads of otehrs, depend of what you want to do [16:49] it's a start [16:49] 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] karni: i think that if someone wants to shoot himself on the foot [16:50] it's his fault [16:50] tsdgeos: That makes my life easier, lol ;) [16:50] Guess thats' too much thinking on my end. Aight. [16:50] bregma: there's also QML_IMPORT_PATH i think is called [16:50] bregma: what are you trying to do? [16:51] 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] bregma: sure, i mean right now, what plugin you want to force? [16:52] tsdgeos, I want to get the Unity.Application to be found ... I recall having to set the environment variables before [16:54] bregma: if it's installed in usr/lib/*/qt5/ you should not need to set anything [16:54] it's just picked as the other billions of plugins we use [16:55] tsdgeos: I see your verticaljournal in its full glory. Success :) Thank you! [16:55] well, QML_IMPORT_TRACE will give me data [16:55] karni: cool [17:00] dandrader_: seen the misc fixes branch for the journals? [17:10] 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] 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] on to the next great adventure === dandrader_ is now known as dandrader [17:17] ah, so my new problem is that all the shaders are failing to compile, such fun, wow, very setback [17:18] anyone have any clue about QOpenGLShader in the Unity8 stack [17:18] ? [17:22] 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] namely QOpenGLDebugLogger [17:23] so hopefully an error message will show up in there [17:24] 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] ah ok [17:29] mzanetti: still around? [17:29] elopio: yep [17:29] mzanetti: the mock is using the generic DashPreview instead of AppPreview. How can I change that? [17:31] elopio: hmm... I think you'd need to create a new one. but I'd need to look it up myself [17:31] let me just finish this task here and I'll have a look [17:32] mzanetti: yes, thanks, because I have no idea how to create one. [17:43] 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] so Qt itself feeds GLSL into GLSL|ES and everyone ends up unhappy and eating ice cream from the bucket [17:57] elopio: hi. I have time for you now [17:57] elopio: so, I see there is already a fake_application_scope [17:58] mzanetti: yes, I'm using it right now. [17:58] the thing is that it's not using the right preview. [17:58] elopio: mhm... that seems to be a bug [17:58] probably in the fake scope, as it does work in the real thing [17:58] mzanetti: a bug on the fake? [17:59] yeah, the real thing is using AppPreview. [17:59] let me check how we determine which preview to use [18:03] elopio: hmm... seems that DeeModel which is created lacks some inforamtion about rendererid and contentType === dandrader is now known as dandrader|afk [18:03] mzanetti: which file are you looking at? I didn't even could find the fake source code. [18:03] elopio: tests/mocks/Unity/fake_applications_scope.cpp [18:04] so far I have no idea where that DeeModel is filled [18:09] mzanetti: alecu might be able to help us with this. [18:10] he's having lunch though. [18:10] 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] elopio: no worries.... [18:12]