/srv/irclogs.ubuntu.com/2016/09/22/#ubuntu-app-devel.txt

=== JanC is now known as Guest5754
=== JanC_ is now known as JanC
magdalenaCanonical 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/gseddd09:54
=== _salem is now known as salem_
kalikianatimp: 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:38
kalikianaA passing log looks like this https://jenkins.ubuntu.com/ubuntu-sdk/job/ubuntu-ui-toolkit-ci-i386-gles-stable/1216/console13:39
kalikianaWell, no. Like this https://jenkins.ubuntu.com/ubuntu-sdk/job/ubuntu-ui-toolkit-ci-amd64-stable/1466/consoleText13:39
timpkalikiana: where do you have the source code?13:40
kalikianatimp: https://code.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/outTheWindow/+merge/30127813:40
timpkalikiana: by the way, prefixing the test functions with testCase means nothing right? It should be test_13:41
timpI changed that in tst_mainview.cpp too13:41
kalikianatimp: Yeah. I just copied that really.13:42
timpshouldn't we use Q_NULLPTR instead of nullptr?13:43
timpkalikiana: I don't immediately see something that is obviously wrong. There is so much new stuff there.13:45
timpkalikiana: can the units additions be in a separate MR?13:46
timpand 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 guess13:46
timphmm, you are importing Ubuntu.Components.Labs 1.3. 1.0 should suffice right?13:46
timpI wonder if we can run the i386-gles locally in lxd. That would help debugging.13:48
=== chihchun is now known as chihchun_afk
kalikianatimp: Why should the units be separate?14:34
kalikianaRetaining the Window { MainWindow { isa  good point, I'll change that14:34
kalikianatimp: If I used nullptr it's because we use it elsewhere. I have 0 opinion on that.14:35
timpelsewhere, but not everywhere14:37
timptim@XPS-13-9350:~/src/ubuntu-ui-toolkit/staging/src/UbuntuToolkit$ grep nullptr *.cpp |wc -l14:37
timp6414:37
timptim@XPS-13-9350:~/src/ubuntu-ui-toolkit/staging/src/UbuntuToolkit$ grep Q\_NULLPTR *.cpp |wc -l14:37
timp8814:37
timpwe use both.14:38
timpit is just something I wondered, not an important thing14:38
kalikianaMaybe something for loicm to investigate, he's good at improving consistency in the codebase lately :-D14:41
loicmkalikiana, 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 libs14:43
timpwhat's the advantage of using nullptr over Q_NULLPTR in the cpp files?14:45
loicmtimp: 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 compiler14:48
loicmtimp: we could use Q_NULLPTR in CPP files too though14:48
loicmtimp: but that's what Qt does, and I think we should just do the same14:50
timpoh, ok.14:50
kalikianaI'd say using the same everywhere is easier, otherwise you have to second-guess all the time14:50
timpI assumed qt uses Q_NULLPTR everywhere. Mainly because using the same thing everywhere makes it less likely to use the wrong one14:51
loicmkalikiana: 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 other14:52
loicmtimp, kalikiana: but well, TBH I don't really care about that as long as we use Q_NULLPTR in headers14:53
loicmtimp, kalikiana: and it's the same for Q_OVERRIDE and override actually14:53
=== aldrog is now known as aldrog_
=== salem_ is now known as _salem

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!