=== thomi_ is now known as thomi === duflu_ is now known as duflu === tvoss|food is now known as tvoss [08:07] Saviq: the qmlui tests seems to have a different failure, looking at this job from earlier: https://code.launchpad.net/~saviq/unity8/helper-retry-unlock/+merge/198648 [08:07] I've fired off the job again as the failing test is different each time :-\ [08:18] veebers, right :/ - thanks, I'll take over now === iahmad is now known as iahmad|afk [08:24] mornin' [08:24] tsdgeos, o/ [08:24] tsdgeos, can you make anything of http://paste.ubuntu.com/6557929/ ? [08:25] * tsdgeos reads [08:26] wow :D [08:26] is that a crash [08:26] ? [08:26] basically seems to me that something completed it's building and a lot of properties are being evaluated/set [08:34] Saviq: ↑↑↑↑ [08:34] tsdgeos, yeah, it's a unity-api qmltest crashing under 5.2 [08:35] tsdgeos, unfortunately whatever I touch in that test, the crash is different straight away :/ [08:35] tsdgeos, and well, somewhere else, too [08:35] ouch [08:36] nothing really obvious tbh [08:57] argggg damn test dashbar tests [08:57] tabbar i mean === iahmad|afk is now known as iahmad [09:47] dednick, hey, review done [09:51] could use reviews for the testing stuff in scopes-shell [09:51] Saviq: thanks [09:51] Saviq: text: menuData && menuData.label || "" - really? thats pretty weird [09:51] Saviq, any progress on the dev-tool? [09:52] * tsdgeos cries [09:53] why is the tabbar not creating children on CI :-/ [09:53] oh wait [09:55] * tsdgeos <--- stupid [09:55] the sdk code needed still not been released [09:55] and here i was trying to make it work ^_^ [09:56] children you shall not make install to the system and then don't remember you had done it [09:58] good thing at least i found one of the bugs i was having in the verticalJournal implementation meanwhile :D [09:59] mhr3, didn't get there yet, but plan to start real soon [10:00] mzanetti, can you do review for mhr3? [10:00] Saviq: yip yip [10:00] mzanetti, https://code.launchpad.net/unity-scopes-shell/+activereviews [10:00] cheers [10:00] mzanetti, I'll do the json-defaults [10:06] Saviq, hey. Got a second to chat about the component to dismiss the keyboard? As you mentioned it's a bit more complicated differentiating between taps and swipes. [10:08] nic-doffay, well, yeah, only I don't think we can do it right now, maybe it's fine to tap-to-launch straight away [10:09] dednick, yeah it's weird, more concise, but as I said, not really readable [10:09] Saviq, I'm dubious about that. But if you'd like me to commit it I'll go ahead. It's a one line change since it looks like someone already added an inverse mouse area for this behaviour. [10:09] Saviq: is it a javascript operator? [10:10] *expression, or whatever [10:10] thingy [10:15] dednick, false || undefined === undefined [10:15] dednick, false || "foo" === "foo" [10:16] nic-doffay, while having moved to dandrader's TappedOutsideNotifier? [10:17] Saviq: true || "foo" ? [10:17] dednick, true [10:17] dednick, true && "foo" === "foo" [10:18] dednick, it's kind of like python's `True and "foo" or "bar" == "foo"` [10:18] Saviq: i c [10:18] wops, my vertical journal does not get reconstucted up correctly :-D [10:19] dednick, when using logical operators on non-bools, they're not converted into bools, but the expression evaluates to the last encountered value, more or less [10:19] dednick, so when you do foo && foo.bar ? foo.bar : "" [10:19] dednick, it does not evaluate to bool(foo) && bool(foo.bar) ? foo.bar : "" [10:20] dednick, but rather to bool(foo && foo.bar) ? foo.bar : "" [10:20] dednick, so if foo.bar is "baz" [10:20] bool("baz") ? "baz" : "" [10:20] so true ? "baz" : "" [10:20] so "baz" [10:21] and foo && foo.bar || "" [10:21] goes, more or less, to "baz" || "", so "baz" [10:22] hm [10:27] tvoss, there? [10:27] Saviq, yup [10:29] Saviq, sorry not sure what you meant: ' nic-doffay, while having moved to dandrader's TappedOutsideNotifier?' [10:31] nic-doffay, just one line change for switching from InverseMouseArea to TappedOutsideNotifier? [10:31] nic-doffay, that'd be great ;) [10:31] nic-doffay, we need to switch to TON, 'cause IMA didn't work well on devices [10:32] Saviq, haha yeah it's just one line. [10:32] Saviq, or two I think :P [10:32] nic-doffay, sure, please test it works on devices then [10:32] nic-doffay, and write a test, too! [10:34] Saviq, sure [10:34] mhr3: https://code.launchpad.net/~mhr3/unity-scopes-shell/scopes-ng-tests/+merge/198437 line 437. wanted? [10:35] meh, it's copied over from the lib [10:36] which means there's lgpl licenced test... guess i should change that [10:37] true [10:37] 5.2.0 official out [10:37] huh? that was fast [10:37] didn't they just discuss when the next rc should come? [10:38] mzanetti, pushed [10:41] damnit, reconstructing the verticalJournal up is not easy at all :/ [10:49] mzanetti, tsdgeos old news, it was out yesterday ;) [10:50] tsdgeos, less easy and doing top-down? [10:50] Saviq: not officially ;-) [10:50] tsdgeos, pfft [10:50] tsdgeos, I SAW IT THERE IN official-releases! [10:50] the tarballs were out [10:50] here http://download.qt-project.org/official_releases/qt/ ! [10:50] it was on hacker news too :) [10:50] see? 11-Dec-2013 16:12 [10:50] Saviq: there was no email ;-) [10:50] tsdgeos, bah! [10:50] tarball may had been changed :D [10:51] ;) [10:51] Saviq: anyway, thing is that when you go up in the verticalJournal you can't really know in which of the columns you have to position the item [10:51] because the next item you position up may mean you have to rearrange the things [10:51] so i'll have to do that i guess, which is not cool [10:51] that or remember the columns of every item [10:51] which is worse :D [10:53] tsdgeos, hmm ah in case one of the previous items is like *long*? [10:53] yep [10:53] tsdgeos, so that it covers two rows when going top-down, but you don't know that yet when going up [10:53] tsdgeos, you think it's really worse to store them? [10:53] if i order them the same way going up that when going down [10:53] when i reach the top [10:53] stuff is jaggy and not 0 aligned [10:53] tsdgeos, yup, understood [10:54] ideally i should be able to reorder them before you see them on screen [10:54] since i have a buffer zone too [10:54] tsdgeos, I just wonder if it's really that bad to store the positions... [10:54] tsdgeos, more memory-hungry, sure (how much?) [10:54] well it's not bad, just a bit more memory intensive [10:54] tsdgeos, but the other one is much more computationally heavy [10:54] not much, i just need to store the integer of the column [10:55] yeah exactly [10:55] tsdgeos, your call, I can see pros and cons of both [10:56] i mean storing the column is so much easier [10:56] mzanetti, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1237923 → Confirmed [10:56] Ubuntu bug 1237923 in Ubuntu UI Toolkit "SSH keys should not be generated automatically - or at least kept for QtCreator use only" [Undecided,New] [10:56] tsdgeos, yeah, and what... a kB memory per 1000 entries? [10:56] getting the algo right to reconstruct + move the stuff as needed is much harder [10:56] (probably more, but not much) [10:56] Saviq: done [10:56] mzanetti, cheers [10:57] Saviq: ok, let's go storing the column for now and we can always make it better if we find it's taking to much memory [10:57] tsdgeos, I really doubt we will :) [11:11] Saviq: storing the column doesn't work if we want to support resizing [11:12] tsdgeos, right, but I'm fine with redoing it in that case [11:13] tsdgeos, like I can actually agree to do the whole model top-down when you resize the column [11:13] sure, but means i still need to write the algorithm :D [11:13] ah [11:13] tsdgeos, it's not like resizing is going to happen often [11:13] sure [11:14] tsdgeos, iteration 2, basically === _salem is now known as salem_ [11:53] dandrader, did you write any tests for PressedOutsideNotifier? [11:54] nic-doffay, yes [11:54] in tests/plugins/Ubuntu/Gestures [11:54] nic-doffay, ↑ [11:55] dandrader, cool [11:56] nic-doffay, adding stuff to it? [11:57] dandrader, nah not yet at least. === MacSlow is now known as MacSlow|lunch [12:04] mzanetti, regarding the QVariant returns, i find it odd when a method is returning QVariant and you see "return QString(foo);" [12:07] mhr3: fair enough... it's personal preference. So, your code, your rules. feel free to ignore === _salem is now known as salem_ [12:08] mzanetti, otoh i do like less typing :) if it's a common thing with variants i can change it, and will get used to it [12:08] mhr3: yeah. it's quite common in Qt to let it convert to QVariants implicitly [12:09] fine then [12:14] anyone noticed that if you exit the unity8 shell app on desktop, if stops the desktop indicators? :) [12:14] oops [12:14] i think it's sending upstart a command [12:15] dednick: yep, here too. I usually restart them with "start indicator-session" [12:22] dandrader, do I need to change any CMakeLists to use Ubuntu gestures from qmluitests? [12:25] nic-doffay, you mean you want a test listed in tests/qmltests/CMakeLists.txt to "import Ubuntu.Gestures"? [12:26] dednick, one for you https://code.launchpad.net/~saviq/unity8/clean-paths-cmakelists/+merge/198725 [12:26] dandrader, that's right. [12:27] nic-doffay, you will have to add "${CMAKE_BINARY_DIR}/plugins" to the IMPORT_PATHS parameter of his add_qml_test entry [12:28] isn't that default? [12:28] nope [12:28] Saviq, no. some tests want to use mock versions of some of the plugins there [12:28] dandrader, yup [12:28] nic-doffay, so something like: [12:28] add_qml_test(Panel Indicators IMPORT_PATHS ${CMAKE_BINARY_DIR}/plugins ${qmltest_DEFAULT_IMPORT_PATHS}) [12:28] nic-doffay, so bear in mind the order of the IMPORT_PATHS [12:29] matter [12:30] dandrader, cool I see it's already been added for dash etc. [12:34] Saviq: ok, will take a look after lunch. [12:34] dednick, cheers === dednick is now known as dednick|lunch [12:39] Saviq: So lp:~aacid/+junk/verticalJournal should be pretty good [12:39] Saviq: needs someone to go over the functional and test review [12:39] Saviq: and a place to merge it :D [12:39] tsdgeos, new-scopes [12:39] tsdgeos, or well... [12:39] Saviq: unity-scopes-s [12:39] tsdgeos, it can go into lp:unity8 directly [12:40] right [12:40] ok [12:40] tsdgeos, it doesn't have to be used, as long as it's tested [12:40] sure [12:40] i need to work a bit more on the tests [12:40] but it's almost there [12:44] mhr3, hmm scopes.get(scopeSelector.selectedIndex) → ASSERT failure in QList::at: "index out of range" [12:45] who was telling me that those index checks in data are useless? [12:45] mzanetti, tsdgeos ^? :P [12:45] mhr3: I did [12:45] oh but wait, that's get(), not data() [12:45] mhr3: well... otherwise noone would have noticed and there's just some data missing [12:46] ah wait... this is a manual get() [12:46] not the data() method [12:46] in that case it's different [12:47] fixing in the tests branch [12:47] and adding test for it :) [12:48] Anyone up for a quick & east review? https://code.launchpad.net/~dandrader/unity-mir/lp1248795/+merge/198731 [12:48] mzanetti, [12:48] s/east/easy [12:48] https://bugs.launchpad.net/unity8/+bug/1258126 [12:48] Ubuntu bug 1258126 in Unity 8 "Arrow in tabs in indicators positioned badly" [High,New] [12:48] this is weird [12:49] in ambiance theme [12:49] dandrader: I'll take it [12:49] the indicator is placed with x: button.width - width [12:49] greyback, thanks! [12:49] dandrader: I always get it wrong and thing 'var' is the deprecated one [12:49] mhr3, lp:~unity-team/unity8/scope-dev-tool [12:49] with button.width being text.paintedWidth + text.anchors.leftMargin + text.anchors.rightMargin [12:49] s/thing/think/ [12:50] text is the label in indicators [12:50] greyback, http://qt-project.org/doc/qt-5.0/qtqml/qml-variant.html [12:50] "The variant type is a generic property type. It is obsolete and exists only to support old applications; new applications should use var type properties instead." [12:50] dandrader: yep I know. I just get that mixed up in my head [12:51] greyback, a ok, got what you meant now :) [12:52] Cimi: hmm... maybe paintedWidth borked? [12:52] dandrader: approved [12:52] mzanetti, it's my guess too [12:53] mhr3, re: auto → sure, easier to write, not easier to read ;) [12:53] mhr3, but yeah, maybe var names should just carry what they are, so that you don't have to go and look at its type anyway [12:54] mhr3: complaining about me nitpicking on "auto" :P ? [12:54] yes :) [12:55] Saviq, pushed the index thing [12:55] mhr3, you mean fixed it? [12:55] yes [12:55] mzanetti, does QtC resolve auto? [12:55] mhr3, ok [12:55] dunno.. [12:55] mzanetti, I mean it should ideally resolve it in a tooltip, for example [12:56] 2.9 wasn't able to, I remember that anywy [12:56] mzanetti, or well, you can look at return type of the function anyway [12:56] mzanetti, and I agree with mhr3 that unless you put type info into the var name itself, you still need to hunt for the type [12:56] Saviq: sure... but it requires me to move the mouse and wait a second for the tooltip to show up :D [12:56] pfff :P [12:57] *the mouse* [12:57] :P [12:57] the horror! [12:57] mhr3, http://people.canonical.com/~msawicz/scope-tool/ [12:58] Saviq, also, why do you call scopes.get() with incorrect index? :) [12:58] mhr3, I wasn't [12:58] mhr3, well, was trying not to [12:58] Saviq, yey, lovely :) [12:59] i mean the tool === dandrader is now known as dandrader|afk [12:59] mhr3, right, it's a race probably [12:59] mzanetti, confirmed... [12:59] mhr3, I get assert with 0 [13:00] Saviq, calling too early? [13:00] Cimi: hmm.. can you reproduce that in a simplified testcase? [13:00] mhr3, binding [13:00] mhr3, the option selector already created and selected its 0 index [13:01] mzanetti, nope [13:01] mhr3, but somehow the model isn't ready for it yet [13:01] Saviq, yea, it takes a while to init the scopes model, anyway, with the patch you'll get null back [13:02] Saviq, you could wait for the loaded signal though [13:03] Saviq, also ekran is screen? [13:03] sounds like a wild animal :D [13:03] mhr3, yes :) [13:03] mhr3, how about "zrzut"? ;) [13:04] mhr3, not sure where covers went, though :/ [13:04] yea, that one is *just* odd, no associations :) [13:04] but ekran totally has wings [13:04] and is blue [13:05] https://www.google.co.uk/search?q=ikran&source=lnms&tbm=isch&sa=X&ei=d7SpUta_OoTnywPFmYCACA&ved=0CAcQ_AUoAQ&biw=1301&bih=656 [13:09] ;D [13:10] mhr3, look again http://people.canonical.com/~msawicz/scope-tool/ [13:10] why the double edit? [13:11] mhr3, 'cause you can't access it in phone layout [13:11] mhr3, there's no "SEARCH" panel [13:11] oh [13:11] ok [13:11] mhr3, we could go for button, but thought that would be good enough [13:11] sure, doesn't need to be perfect [13:12] mhr3, any idea where covers went? [13:12] mhr3, don't get them in plain unity8 either [13:12] hmm, server issue? === alan_g is now known as alan_g|lunch [13:13] Saviq, oh do you have the icon -> art branch installed? [13:13] mhr3, good question [13:13] mhr3, prolly not [13:13] that would explain it === dandrader|afk is now known as dandrader === MacSlow|lunch is now known as MacSlow [13:23] Saviq: what is shell_app_HDRS? === dednick|lunch is now known as dednick [13:24] dednick, yeah, exactly - nothing [13:24] dednick, it's not defined anywhere [13:24] ok === iahmad_ is now known as iahmad [13:25] ok... I was trying to get food for two hours now... [13:25] /food [13:29] mhr3, right - icon vs. art indeed - where *is* that branch, btw? [13:29] * Saviq got lost [13:32] Saviq, lp:~mhr3/unity-scopes-shell/scopes-ng-tests [13:32] so also in the json-defaults one [13:33] mhr3, right! [13:37] mhr3, http://people.canonical.com/~msawicz/scope-tool/ ;) [13:37] mhr3, will package it and it basically get in into new-scopes [13:37] +can [13:38] much better :) [13:38] mhr3, tests will only come later when we do something the dash itself doesn't do (like putting JSON through the validator) [13:39] really... */food* [13:39] i'll also play with it so it's able to talk to an uninstalled scope [13:42] Saviq: hm, that getProperty doesnt work yet. changes to roles doesnt update the values :( [13:42] Saviq: because it's a string property we're checking for. [13:43] Saviq: ie getProperty(menuData, "label", "") will not respond to changes to menuData.label [13:43] dednick, "obviously that assumes that extAttrib only changes [13:43] atomically - which is not the case for menuData, for example - so it makes [13:43] sense to keep menuData explicit, while moving extAttrib and maybe some others. [13:43] Or well, menuData could be handled as well, by means of Qt.binding(), I think." [13:44] would have nice to have the menuData like that it as well. [13:45] Saviq: can you return a binding from a function? [13:46] dednick, Qt.binding(function() { return menuData[property] }) should work [13:46] dednick, hmm or not [13:47] dednick, you'd have to make sure that menuData.property is named somewhere there [13:47] dednick, so that the binding attaches to dataChanged [13:47] dednick, not sure [] will be good enough [13:50] eh. would need to do it in onCompleted as well. can't use binding in declaration [13:52] i knew there was a reason for all those && ?, i tried this before... [13:52] dednick, why? [13:53] dednick, as long as the changing thing is called explicitly in the binding [13:53] dednick, it should update fine [13:53] dednick, that's why I mentioned a custom get(object, property, default) method [13:53] dednick, as .getProperty assumes the object is !undefined [13:54] dednick, the get() would not assume that [13:54] Saviq: yeah, but need get(object, property, propertyName, default [13:54] dednick, and should be evaluated whenever any of its arguments change [13:54] dednick, property vs. propertyName? [13:54] hasOwnProperty. [13:54] i guess can just to !== undefined [13:55] dednick, yeah, first check if object is defined [13:55] dednick, then if it has property [13:55] dednick, if either is false, return default [13:55] dednick, and that should cause the thing to reevaluate as needed - *assuming* that object changes atomically [13:55] Saviq: how to you check if it has a property? you mean just "menuData && menuData.label != undefined" [13:56] dednick, which menuData doesn't - but extendedAttr has [13:56] dednick, right, menuData is different [13:56] dednick, that's why I said that a binding is needed [13:56] dednick, and I doubt menuData[property] will be good enough [13:57] dednick, you need to call menuData.label explicitly for dataChanged to be connected [13:57] dednick, so for menuData indeed I'm not sure it makes sense [13:58] dednick, you *could* hack it around with something along the lines of: menuData.onDataChanged: menuData.changed() [13:58] dednick, but that's probably not the best thing to do [14:01] Saviq: http://pastebin.ubuntu.com/6561497/ [14:01] can really use either for extended data [14:02] dont need a binding if we give the property, as it will be reevaluated when the parameter changes [14:03] dednick, only extendedData.xCanonicalTime will complain about extendedData undefined [14:03] dednick, as will menuItem.label [14:04] oh, you mean when you call into the function? hmm. === alan_g|lunch is now known as alan_g [14:08] dednick, yeah, at that point you'd have to go menuData && menuData.property [14:08] dednick, as the argument - which is bleh. [14:10] Saviq: but as you said, doesnt that statement evaluate to the value of menuData.property if it's true? or is that only if you use || ? [14:10] but i guess that defeats the purpose. sigh.... [14:10] dednick, yeah, it will, but yes - it defeats the purpose exactly [14:11] i might just change the menuData.label back to good old && || . dont think there's really any other neat way around it. [14:13] dednick, only thing I could think of was menuData[propertyName] in a Qt.binding() [14:13] dednick, but I'm worried that doesn't actually work [14:13] Saviq: it doesnt. [14:13] plus you need to use inside onCompleted, which sucks [14:14] dednick, yeah, I'm ok with && for menuData [14:14] dednick, since there's no clean way around it [14:33] dednick, standup [14:34] Saviq, you should have another automated bot for automated standup calls [14:44] MacSlow: hey. as you'll be gone soon, what's the status of the SIM pinlock? [14:44] MacSlow: did you fix those two issues I found? === dandrader is now known as dandrader|lunch [14:45] mzanetti, branch is ready since London with your requested fixes [14:45] MacSlow: oh... damn... ok... I'll review it and fix any comments myself then while you're away [14:45] mzanetti, I confidnet you'll be happy with the current state [14:46] MacSlow: so far I only did a testing review. not a code review. but yeah... I don't think its really far off any more [14:46] MacSlow: I'll try to have it merged by the time you come back. [14:47] mzanetti, even made a screencast for you -> https://www.youtube.com/watch?v=raJpJx6DkQU :) [14:47] haha [14:47] always fun to see some motor bikes [14:47] ;D [14:48] mzanetti, no bikes in that screencast this time :) [14:48] MacSlow, there's some in the "you should also watch" screen ;) [14:48] and in your avatar [14:48] Saviq, those are "bugs" in Google's recommendations-algorithms ;) [14:49] Cimi, re: bug #1258571 - yeah, that's what we discussed in London [14:49] bug 1258571 in unity8 (Ubuntu) "Select backgrounds based on aspect ratio and read them from dconf" [High,Triaged] https://launchpad.net/bugs/1258571 [14:49] Cimi, stretching is the worst thing you can do to any image ;) [14:49] Saviq, stretch/crop [14:49] Saviq, all OSes do that [14:49] Cimi, so fit, not stretch [14:49] whatever [14:49] scale [14:49] Cimi, yes [14:50] Cimi, yeah, but having a single one that works well on the phone in portrait and on tablet in landscape isn't really easy [14:50] Cimi, we decided to go landscape + portrait for the default ones [14:50] I think it will be weird [14:51] Cimi, when you select a different background - that's when it will be scaled+croped [14:51] cropped [14:51] rotating the tablet and seeing wallpaper changing [14:51] Cimi, no no [14:51] Cimi, it's only about native aspect [14:51] Saviq, the bug report is about orientation [14:51] Cimi, so on tablet it will always be the tablet one [14:51] Cimi, ok maybe it's worded wrong indeed [14:52] Cimi, so write down in the bug please that the selection is only supposed to be made based on native device orientation [14:52] ok [14:52] /aspect ratio [14:52] ok [14:53] done [14:53] seb128, ^^ [14:53] seb128, that bug, we need extra gestating schema [14:53] gsetting [14:56] Cimi, why? [14:56] what schemas/setting [14:56] seb128, look at the bug [14:56] I did [14:56]