[07:17] mmrazik: hi! I see there are some problems merging https://code.launchpad.net/~veebers/unity/update-tests-for-autopilot-1.3/+merge/162176 [07:17] sil2100: I know. was just talking with thomi. [07:18] sil2100: trying to build on a different panda ATM [07:19] mmrazik: geh, MultipleShotsRun again... I would really like to get rid of those time-measuring unit tests finally [07:19] mmrazik: thanks! [07:41] mmrazik: any idea why http://10.97.2.10:8080/job/unity-phablet-qmluitests/807/console failed? [07:43] tsdgeos: not quite sure. I would say somebody added the ppa to the VM but not the key. There is a commented out apt-add-repository (this one was adding the key) [07:43] tsdgeos: I've added --force-yes [07:43] should work now [07:43] thanks [07:43] mzanetti: ^^^ [07:43] mzanetti: any idea ? [07:44] he's on holiday afaik [07:54] tsdgeos, quick look at result highlighting, couldn't we use color: "#80ffffff" and only wrap the highlights in ? [07:55] hmmmm [07:57] can give it a try [07:57] sounds weird to me [07:57] but might work [07:58] seems to work [08:03] whatte [08:03] Cannot mix incompatible Qt library (version 0x50001) with this library (version 0x50002) [08:03] mmrazik: ↑↑ http://10.97.2.10:8080/job/unity-phablet-qmluitests/810/console [08:04] tsdgeos: mhm... I guess there is something broken on the VM [08:04] let me check [08:10] tsdgeos: I actually start to wonder if it is not a bug in qmlscene packaging [08:11] Mirv: can you have a look: http://10.97.2.10:8080/job/unity-phablet-qmluitests/810/console [08:11] I would expect I don't see that sort of errors if I use apt-get install [08:12] it works here otoh [08:12] locally i mean [08:14] mmrazik, tsdgeos: to me it seems that it uses some library that has been built against the old, 5.0.1 Qt5 [08:14] sure [08:14] yeah... which is something that should not happen due to deps [08:14] mmrazik, tsdgeos: is the qt5-proper PPA enabled for the PPA where the test package has been built? [08:15] We need to check if the PPA that's building the package actually used the new Qt5 [08:15] Where does the package come from? [08:15] sil2100: there isn't really any package... the job just tries to run qmlscene to workaround some other bug [08:15] with some super simple qml [08:15] Oh [08:15] * sil2100 wasn't up-to-date it seems [08:15] sil2100: http://pastebin.ubuntu.com/5647120/ [08:16] I'm just trying to reproduce there [08:17] Interesting, then it looks to me like indeed some dependency problem, maybe the Qt5 packaging would need an update, just I wonder which used package is not updated [08:17] Actually, let me check ldd [08:17] sil2100: working on figuring that out [08:18] mmrazik: I think we're missing updating libqt5qml5 [08:19] mmrazik, tsdgeos, Mirv: as you can see, qtdeclarative5-qtquick2-plugin is updated, but libqt5qml5 is not [08:21] Or maybe it got removed, one moment? [08:21] No, it did not [08:21] Ok, so it's clearly something wrong with Qt5 deps - it should update libqt5qml5 as well in this case [08:22] Mirv, mmrazik: I think that an update of either qtdeclarative5-qtquick2-plugin or qmlscene should also require the update of libqt5qml5, don't you think? [08:22] Otherwise QML apps won't run anyway [08:23] Mirv: ^^ [08:25] sil2100, Mirv : it must be something more than that. I upgraded libqt5qml5 to 5.0.2-2ubuntu1~raring1~test2 and still getting the same error [08:26] mmrazik: so probably something else as well [08:26] mmrazik: sadly, from what popey says, Mirv might be off today ;( [08:26] sil2100: where should I report this sort of bugs? [08:27] I guess we can find the missing piece ourselves and workaround in jenkins [08:27] mmrazik: one moment [08:27] yeah, checked the holiday calendar, timo is out today, national holiday I believe [08:27] mmrazik: https://bugs.launchpad.net/ubuntu/+source/qtbase-opensource-src <- maybe this is the right place for this bug [08:31] sil2100: libqt5quick5 seems to be the thing [08:31] Awesome [08:31] mmrazik: good catch [08:32] tsdgeos: can you try to retrigger the build? [08:35] lp:1178147 [08:35] fyi [08:37] mmrazik: thanks [08:38] mzanetti: sure [08:41] mmrazik: ↑ sure was for you :D [08:41] :) [08:51] garg [08:52] need to fix the qpa thing [08:57] Saviq: https://code.launchpad.net/~aacid/unity/qpa_502/+merge/163111 [08:57] tsdgeos, if I register a type, do you think there's any way to retrieve that type's name in QML? [08:58] tsdgeos, the JS type is "object", and there seem to be no members [08:58] no members? [08:58] ouch [08:58] tsdgeos, no properties / methods nothing [08:58] Saviq: did a (for var in obj) console.log(var)? [08:58] yeah [08:58] nothing [08:59] no idea then :-/ [08:59] errr [08:59] wait [08:59] I wonder if it'd be possible to pass it to C++ somehow [08:59] but what would it be... [09:00] tsdgeos, hum, why do we need private-dev [09:00] ? [09:00] Saviq: qpa [09:00] Saviq: no, no idea sorry :/ [09:01] tsdgeos, that's fine [09:02] tsdgeos, maybe the other way, ideas about getting an object by its name? other than eval()? [09:03] i.e. eval("Type") could return the registered type [09:04] nope :/ [09:04] so eval() works, but there's a "don't use eval" comment right next to it ;) [09:05] :D [09:06] fook it [09:15] Saviq: what about https://code.launchpad.net/~aacid/unity/remove_qsortfilterproxymodelqml_get/+merge/162955 anything else we need? [09:18] sil2100: veebers's unity-3d MP just landed (FYI) [09:18] tsdgeos, no, looks fine, will test and review in a bti [09:18] bit [09:18] okidokig [09:18] tsdgeos, coming right up to some more stuff to take a look at on the interface test [09:19] sure, just shout when you want me to have a look [09:49] tsdgeos, pushed [09:50] tsdgeos, the tests themselves should be more readable now [09:50] tsdgeos, and there's been some refactoring... [09:50] ok [09:56] Saviq: fails to build here [09:56] lp:~unity-team/+junk/shell-interfaces , right? [09:56] tsdgeos, yeah, what does it complain about? [09:56] tsdgeos, the enums by any chance? [09:56] yep [09:56] tsdgeos, that's just random [09:56] says need c++11 [09:56] tsdgeos, yeah, I've no idea what's going on [09:57] well, enum class needs c+11 [09:57] do we have it enabled? [09:57] tsdgeos, I think so [09:57] tsdgeos, and it builds here [09:57] tsdgeos, anyway, I had that issue, removed the "class" from the enums [09:57] tsdgeos, built fine [09:57] tsdgeos, work, work, work [09:57] add the "class" back [09:57] builds fine [09:58] I might be missing something somewhere, but dunno waht [09:58] what [10:00] tsdgeos, if you manage to find it, great, otherwise we'll drop them [10:00] Saviq: http://paste.kde.org/~tsdgeos/740492/ works here [10:00] tsdgeos, ah [10:00] not sure why the difference you vs me though :-/ [10:00] tsdgeos, it might be that project() resets the flags [10:00] would make sense [10:00] but why works for you? [10:02] tsdgeos, cache, probably [10:02] tsdgeos, i.e. once it builds [10:02] tsdgeos, it saves the new cflags in the cache [10:02] and uses those [10:02] or something [10:04] tsdgeos, some more small commits just went in [10:05] tsdgeos, actually, I need to roll back [10:05] ok [10:05] tell me again when you're done [10:07] tsdgeos, now [10:08] tsdgeos, ugh, one more minute [10:09] tsdgeos, now, sorry [10:09] * Saviq wants git [10:19] Saviq: void invokeAction(QString id); -> void invokeAction(const QString &id); to save 0.0005 µs? :D [10:19] tsdgeos, indeed [10:29] Saviq: i'm confused [10:29] tsdgeos, go [10:29] i've put a console.log at tst_notifications.qml in function test_model(data) { [10:29] sil2100, what's up with utah today? [10:29] before it calls verifyData [10:29] and i see that log [10:30] but then i've put a console.log in Verifier.qml in the verifyData and i don't see the log [10:30] why¿?¿ [10:30] sil2100, ap tests taking 14minutes today... clearly something is broken :) [10:30] running with qmltestrunner [10:31] tsdgeos, where did you put the log at? [10:31] Saviq: http://paste.kde.org/~tsdgeos/740516/ [10:31] tsdgeos, ah I know [10:31] tsdgeos, Verifier.qml isn't copied [10:31] i see calling verifyData and called verifyData [10:31] tsdgeos, after changing [10:31] but not the others [10:31] tsdgeos, you need to edit the one in build/ [10:31] tsdgeos, we need to find a way for CMake to update those copied files [10:32] tsdgeos, but otherwise you need to build [10:32] tsdgeos, for the changed one to be copied [10:32] make didn't help [10:32] let me clear [10:32] n [10:32] check that the change is there in your $BUILD_DIR [10:33] ah yeah, cleaning works [10:33] so yeah that has to be fixed, at least make should update them [10:36] in theory it does [10:36] I've seen it updating it.. [10:36] but yeah we need a generic, reliable solution [10:37] should [10:37] { tag: "Model.roles[urgency]", role: "urgency", type: "number" }, [10:37] be [10:37] { tag: "Model.roles[urgency]", role: "urgency", type: "enum" }, [10:37] ? [10:40] Saviq: ↑↑ [10:40] tsdgeos, that could be a shortcut [10:40] tsdgeos, but there's no way of distinguishing a number from an enum [10:40] in JS [10:43] right [10:43] ok [10:44] Saviq: in general looks good [10:45] tsdgeos, cheer [10:45] s [10:45] there's still the [10:45] if (writable) { [10:45] in writeable [10:45] which you said yesterday had to go away? === mmrazik is now known as mmrazik|lunch [10:47] tsdgeos, is there? [10:48] yep [10:48] tsdgeos, hmm not seeing it.. [10:48] * tsdgeos pulls [10:48] I do, however, see two debugs in there... [10:48] ah, i was old [10:48] wait [10:48] wrong file [10:49] tsdgeos, yeah, I fixed it... in a different project [10:49] Saviq: you forgot to add the & to the QString [10:49] :D [10:49] ugh [10:54] tsdgeos, I --overwrote, so you'll have to do the same next time [10:56] ok [10:58] Saviq: that's still the writable function i'm seeing http://paste.kde.org/~tsdgeos/740528/ [10:59] tsdgeos, pushed [11:00] oki [11:00] so yeah, seems good to me, haven't done a line per line check of Verifier [11:00] but the tst_Notifications makes sense [11:05] yeah, I need to write a test suite for the Verifier itself [11:06] later [11:06] tsdgeos, any idea of the simplest way to fake a QAbstractListModel? [11:07] I was thinking QList, but that didn't work [11:07] another possibility is QQmlListProperty, but that won't give up roles IIRC [11:09] brb [11:09] Saviq: what do you mean by fake? [11:09] tsdgeos, mock, more than fake [11:10] tsdgeos, i.e. what ListModel really does, but I'd need to pass it up from C++ === mmrazik|lunch is now known as mmrazik [11:10] tsdgeos, so that I can, without implementing a complete QALM [11:10] tsdgeos, get role-based data in a Repeater [11:11] i see [11:28] Saviq: what's the problem with qlist+qvariantmap? [11:29] tsdgeos, didn't work here? [11:29] you mean assigning it to a model: property? [11:29] tsdgeos, yeag [11:29] right [11:29] that probably won't work unless it's a QALM [11:29] afaik there are internal checks in what you can assign there [11:30] I'll have a play with QQmlListProperty [11:30] but then again... [11:31] QALM is minimal, is it actually worth it... [11:32] and not sure QQLP can at all work if it's not a property, but returned from QALM::data() [11:51] tsdgeos, can you make sure that all the three videos still play with your remove_..._get branch? [11:51] tsdgeos, I seem to only be able to play he Sintel one [11:51] weird [11:51] Saviq: playging from the carousel or after a search? [11:51] tsdgeos, carousel [11:51] oki [11:51] lunch waiting [11:51] will do first thing after [11:52] tsdgeos, both, actually [11:52] tsdgeos, sure, enjoy === mmrazik is now known as mmrazik|afk === alan_g is now known as alan_g|lunch [12:23] mhr3: good question! Let me check that now (just got back from lunch) [12:48] Utah is strange [12:49] It looks as if utah was killing all the tests prematurely [12:49] How are we supposed to merge in the 100scopes when we can't get the right test results? [12:50] mhr3: btw. what autopilot are you guys using for the 100scopes branch? [12:50] Since this might be a blocker as well [12:51] Of course this depends on whether you were modifying/adding any autopilot tests or all is in trunk already [12:52] sil2100, one that trunk was using up until a week ago [12:55] today (booting up the computer after yesterday's updates) unity is no longer starting up for me on 13.04. If I run it manually there's a compiz error saying that plugin 'opengl' could not be loaded. [12:57] dandrader, do you have any suspicious PPAs in your sources list anywhere? [12:57] dandrader: hmmm, i actually updated yesterday....kinda early in the day...and no problems for me [12:58] bregma, I have http://ppa.launchpad.net/phablet-team/desktop-deps/ubuntu and http://ppa.launchpad.net/phablet-team/tools/ubuntu [12:59] bregma, if I run it manually (typing "unity" in the terminal) it says plugin 'opengl' could not be loaded [13:00] dandrader: sounds like a binary mismatch on the proprietary drivers....x version vs what they were compiled against [13:01] yeah, I see new xorg drivers in my update list in a fresh 13.04 install [13:01] paulliu: ping [13:02] I even removed the nvidia packages and switched to use my onboard intel graphics [13:02] but problem remains [13:04] paulliu: hi [13:04] Saviq: we sould do a release [13:04] Saviq: to get the qpa thing in [13:04] tsdgeos, yeah, we should [13:05] Saviq: otherwise the run_on_device fails [13:05] Saviq: want me to do it? [13:05] tsdgeos, go for it === _salem is now known as salem_ [13:06] Saviq: btw all the videos fail here but that's because the device video player seems to be borked (i.e. doesn't work without my patch either) but the paths seem to be correctly passed, where are you trying it on? device or pc? [13:07] tsdgeos, device, and it plays fine on stock qml-phone-shell [13:07] Saviq: which image? [13:07] tsdgeos, 115, probably, checking [13:07] where do we find the image number again... [13:08] /etc/somewhere [13:08] phablet-flash it is, then [13:13] well, gnome-fallback works at least. will use it for now... [13:17] Saviq: https://code.launchpad.net/~aacid/unity/release175/+merge/163143 [13:18] tsdgeos, all plays fine on image 119 on the N10 [13:18] dandrader: this is really hacky, but i had a similar issue recently, i did apt-get dist-upgrade/upadate/autoremove/autoclean...twice, everything got happy [13:19] Saviq: i updated/dist-upgraded and my qsortfilterbranch can now play the 3 videos correctly [13:19] you can't? [13:19] dandrader: this is really hacky, but i had a similar issue recently, i did apt-get dist-upgrade/upadate/autoremove/autoclean...twice, everything got happy [13:19] tsdgeos, didn't try with your branch yet, stock 119 for now === mmrazik|afk is now known as mmrazik === alan_g|lunch is now known as alan_g [13:29] tsdgeos, yeah, seems the media player is unstable [13:29] tsdgeos, works [13:30] :) [13:45] Saviq: do you want to do https://code.launchpad.net/~aacid/unity/hud-result-highlighting/+merge/163115 or maybe dandrader can do it? [13:47] tsdgeos, I don't have to [13:48] cool [13:48] dandrader: can you do it? [13:50] tsdgeos, yes, I can review it [13:50] dandrader: tx [13:57] dandrader: your edge drag now passed :-) [13:57] oh lol [13:57] long lines dude again :D [13:58] :) [13:58] should have chosen someone else [13:58] heehhe [13:58] where's mzanetti when you need him :D [13:58] * tsdgeos adds some newlines [14:03] dandrader: lines splitted [14:03] \o/ === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [14:30] uurgfh [14:31] note to self: do not do "property var something; something: Item { }" [14:34] the Item is not considered as it would be normally [14:43] Saviq: what's the difference? [14:43] tsdgeos, it must be marked non-visual or something [14:43] tsdgeos, so when I had a Repeater there [14:43] tsdgeos, it would not query the model at all [14:44] tsdgeos, it would query the count, but not the roles [14:44] interesting [14:44] tsdgeos, nor, effectively, the actual data [14:44] tsdgeos, could deserve a check if it's a feature, and not a bug [14:45] Saviq: fwiw the support enum class in QFlags was merged and will be available for 5.1 [14:45] Saviq: true [14:46] tsdgeos, interesting [14:46] i mean, i did a quick fix yesterday in 10 minutes i was waiting for something else to compile with the guidance of some of the Qt guys [14:46] just neeed to throw some more casting around [14:47] yup [14:53] tsdgeos: https://code.launchpad.net/~paulliu/unity/phablet-fake-peoplepreviewdata/+merge/161514 [14:53] tsdgeos: I just re-use the branch. === alan_g is now known as alan_g|tea [14:53] oki [14:54] dandrader: to be honest doing the check that we are in bounds twice feels a bit weird, but ok, no point in discussing over that :D [14:55] tsdgeos, I don't feel strongly about it, you're free to not do it [14:56] dandrader: pushed [15:00] paulliu: lol, setUnityPeoplePreview was defined but not implemented? [15:01] tsdgeos: No.. :P [15:01] :D [15:01] nice one [15:02] paulliu: yes, that's what i meant [15:02] tsdgeos: ok. I'll add data into that variants. [15:02] makes mroe sense to have a mock PeoplePreviewData than a almost reimplement half of the qml we wanted to test [15:02] cool :) [15:08] Saviq: how much into know of the ListViewWithPageHeader tasks are you? [15:08] tsdgeos, E_SYNTAXERROR [15:08] :D [15:08] * tsdgeos stops trying to sound smart [15:09] Saviq: the ListViewWithPageHeader tasks at https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-dash [15:09] Saviq: there's one that says "reimplement in C++" [15:09] do we really need that¿ [15:09] or that's exposed as a possibility to have the other issues we have wiht the component if we can't fix them in pure QML? [15:10] tsdgeos, it felt like the sounder approach [15:10] tsdgeos, to not fight with the tool === alan_g|tea is now known as alan_g [15:11] sure [15:11] but has it's own set of problems as Gerry discovered [15:11] i.e. basically has the small problem of "can't be done" : [15:11] :D [15:11] yeah indeed [15:13] tsdgeos, based on past experience, though, I'm afraid of QML approach being unmaintainable [15:13] why? [15:13] i mean not the current thing we hav [15:13] but something that may be "better" [15:14] if we can make it happen of course :D [15:14] tsdgeos, yeah exactly [15:14] Saviq: as far as i understand the problem is having the flickable + listview [15:14] that makes the listview unhappy [15:14] right? [15:15] tsdgeos, not really [15:15] oh [15:15] tsdgeos, the biggest issue is, I'd say, the fact that you have to clip manually [15:15] tsdgeos, the flickable + listview is just a hack [15:15] well, that's listview for you [15:16] listview is weird in that it needs to be clipped [15:16] but if originY and contentY behaved as advertised [15:16] not even that it needs to be clipped [15:16] that's relatively fine [15:16] but the fact that you need to clip the delegates when they go behind the section header [15:16] that was a o_O moment for us [15:17] == we don't support transparent section headers [15:17] do we need to? [15:18] with the design we have, yes [15:18] and tbh it's not an unreasonable request [15:18] unless you copy parts of the background to the section headers [15:18] don't know, looks weird to have something going behind the section header [15:18] but i guess i'd have to see it [15:19] tsdgeos, that's what happens now [15:19] not on the phone, no? [15:19] yes [15:20] but we manually clip the delegates [15:20] ah [15:20] ok, so it's not happening :D [15:20] otherwise you could see them behind the section header [15:20] i thought i wasn't looking at the correct place [15:21] tsdgeos, I dunno, doing it all "properly" in C++ felt like a good solution [15:21] tsdgeos, but obviously that seems to be "unsupported" even more [15:21] yep [15:21] we could try and upstream parts of it [15:22] I do believe the "clip behind section headers" part [15:22] could be received by upstream [15:22] disabled by default [15:22] we could always extend listview to do what we want i guess [15:22] well, that was the idea [15:23] but it seems it would mean distropatching [15:23] tsdgeos,we had one other potential idea [15:24] tsdgeos, one that would require even more maths [15:24] :D [15:24] but would support "don't create items that are offscreen" [15:24]