[09:54] <magdalena> Canonical Web Team is testing a new developer.ubuntu.com prototype. Want to help out for a £40 Amazon voucher? Sign up here: http://goo.gl/gseddd
[13:38] <kalikiana> timp: This is the log of the failing MainWindow unit rest https://jenkins.ubuntu.com/ubuntu-sdk/job/ubuntu-ui-toolkit-ci-i386-gles-stable/1216/console (search for 'mainwindow::init') - it segfaults at operator==. Other builds are failing, gles isn't...
[13:39] <kalikiana> A passing log looks like this https://jenkins.ubuntu.com/ubuntu-sdk/job/ubuntu-ui-toolkit-ci-i386-gles-stable/1216/console
[13:39] <kalikiana> Well, no. Like this https://jenkins.ubuntu.com/ubuntu-sdk/job/ubuntu-ui-toolkit-ci-amd64-stable/1466/consoleText
[13:40] <timp> kalikiana: where do you have the source code?
[13:40] <kalikiana> timp: https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/outTheWindow/+merge/301278
[13:41] <timp> kalikiana: by the way, prefixing the test functions with testCase means nothing right? It should be test_
[13:41] <timp> I changed that in tst_mainview.cpp too
[13:42] <kalikiana> timp: Yeah. I just copied that really.
[13:43] <timp> shouldn't we use Q_NULLPTR instead of nullptr?
[13:45] <timp> kalikiana: I don't immediately see something that is obviously wrong. There is so much new stuff there.
[13:46] <timp> kalikiana: can the units additions be in a separate MR?
[13:46] <timp> and the test_launcher.window.qml should not be replaced, but add test_launcher.mainwindow.qml, because we don't want to break Window { MainView { } } I guess
[13:46] <timp> hmm, you are importing Ubuntu.Components.Labs 1.3. 1.0 should suffice right?
[13:48] <timp> I wonder if we can run the i386-gles locally in lxd. That would help debugging.
[14:34] <kalikiana> timp: Why should the units be separate?
[14:34] <kalikiana> Retaining the Window { MainWindow { isa  good point, I'll change that
[14:35] <kalikiana> timp: If I used nullptr it's because we use it elsewhere. I have 0 opinion on that.
[14:37] <timp> elsewhere, but not everywhere
[14:37] <timp> tim@XPS-13-9350:~/src/ubuntu-ui-toolkit/staging/src/UbuntuToolkit$ grep nullptr *.cpp |wc -l
[14:37] <timp> 64
[14:37] <timp> tim@XPS-13-9350:~/src/ubuntu-ui-toolkit/staging/src/UbuntuToolkit$ grep Q\_NULLPTR *.cpp |wc -l
[14:37] <timp> 88
[14:38] <timp> we use both.
[14:38] <timp> it is just something I wondered, not an important thing
[14:41] <kalikiana> Maybe something for loicm to investigate, he's good at improving consistency in the codebase lately :-D
[14:43] <loicm> kalikiana, timp: eheh, I thought about that one too :) IMO we should use nullptr in cpp files and Q_NULLPTR in headers, so that people who don't want C++11 features can use our libs
[14:45] <timp> what's the advantage of using nullptr over Q_NULLPTR in the cpp files?
[14:48] <loicm> timp: C++11 is the standard we use to build the libs and plugins, so we don't the macro in the implementation files, just in the headers so that it builds by converting to NULL for people who don't build with a C++11 compiler
[14:48] <loicm> timp: we could use Q_NULLPTR in CPP files too though
[14:50] <loicm> timp: but that's what Qt does, and I think we should just do the same
[14:50] <timp> oh, ok.
[14:50] <kalikiana> I'd say using the same everywhere is easier, otherwise you have to second-guess all the time
[14:51] <timp> I assumed qt uses Q_NULLPTR everywhere. Mainly because using the same thing everywhere makes it less likely to use the wrong one
[14:52] <loicm> kalikiana: arguably, nullptr looks better than Q_NULLPTR and since implementation files are bigger than headers and likely to use the keyword more it could be tempting to prefer that one over the other
[14:53] <loicm> timp, kalikiana: but well, TBH I don't really care about that as long as we use Q_NULLPTR in headers
[14:53] <loicm> timp, kalikiana: and it's the same for Q_OVERRIDE and override actually