[08:07] <veebers> 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] <veebers> I've fired off the job again  as the failing test is different each time :-\
[08:18] <Saviq> veebers, right :/ - thanks, I'll take over now
[08:24] <Saviq> mornin'
[08:24] <Saviq> tsdgeos, o/
[08:24] <Saviq> tsdgeos, can you make anything of http://paste.ubuntu.com/6557929/ ?
[08:25]  * tsdgeos reads
[08:26] <tsdgeos> wow :D
[08:26] <tsdgeos> is that a crash
[08:26] <tsdgeos> ?
[08:26] <tsdgeos> basically seems to me that something completed it's building and a lot of properties are being evaluated/set
[08:34] <tsdgeos> Saviq: ↑↑↑↑
[08:34] <Saviq> tsdgeos, yeah, it's a unity-api qmltest crashing under 5.2
[08:35] <Saviq> tsdgeos, unfortunately whatever I touch in that test, the crash is different straight away :/
[08:35] <Saviq> tsdgeos, and well, somewhere else, too
[08:35] <tsdgeos> ouch
[08:36] <tsdgeos> nothing really obvious tbh
[08:57] <tsdgeos> argggg damn test dashbar tests
[08:57] <tsdgeos> tabbar i mean
[09:47] <Saviq> dednick, hey, review done
[09:51] <mhr3> could use reviews for the testing stuff in scopes-shell
[09:51] <dednick> Saviq: thanks
[09:51] <dednick> Saviq: text: menuData && menuData.label || ""    - really? thats pretty weird
[09:51] <mhr3> Saviq, any progress on the dev-tool?
[09:52]  * tsdgeos cries
[09:53] <tsdgeos> why is the tabbar not creating children on CI :-/
[09:53] <tsdgeos> oh wait
[09:55]  * tsdgeos <--- stupid
[09:55] <tsdgeos> the sdk code needed still not been released
[09:55] <tsdgeos> and here i was trying to make it work  ^_^
[09:56] <tsdgeos> children you shall not make install to the system and then don't remember you had done it
[09:58] <tsdgeos> good thing at least i found one of the bugs i was having in the verticalJournal implementation meanwhile :D
[09:59] <Saviq> mhr3, didn't get there yet, but plan to start real soon
[10:00] <Saviq> mzanetti, can you do review for mhr3?
[10:00] <mzanetti> Saviq: yip yip
[10:00] <Saviq> mzanetti, https://code.launchpad.net/unity-scopes-shell/+activereviews
[10:00] <mzanetti> cheers
[10:00] <Saviq> mzanetti, I'll do the json-defaults
[10:06] <nic-doffay> 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] <Saviq> 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] <Saviq> dednick, yeah it's weird, more concise, but as I said, not really readable
[10:09] <nic-doffay> 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] <dednick> Saviq: is it a javascript operator?
[10:10] <dednick> *expression, or whatever
[10:10] <dednick> thingy
[10:15] <Saviq> dednick, false || undefined [10:15] <Saviq> dednick, false || "foo" [10:16] <Saviq> nic-doffay, while having moved to dandrader's TappedOutsideNotifier?
[10:17] <dednick> Saviq: true || "foo" ?
[10:17] <Saviq> dednick, true
[10:17] <Saviq> dednick, true && "foo" [10:18] <Saviq> dednick, it's kind of like python's `True and "foo" or "bar" == "foo"`
[10:18] <dednick> Saviq: i c
[10:18] <tsdgeos> wops, my vertical journal does not get reconstucted up correctly :-D
[10:19] <Saviq> 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] <Saviq> dednick, so when you do foo && foo.bar ? foo.bar : ""
[10:19] <Saviq> dednick, it does not evaluate to bool(foo) && bool(foo.bar) ? foo.bar : ""
[10:20] <Saviq> dednick, but rather to bool(foo && foo.bar) ? foo.bar : ""
[10:20] <Saviq> dednick, so if foo.bar is "baz"
[10:20] <Saviq> bool("baz") ? "baz" : ""
[10:20] <Saviq> so true ? "baz" : ""
[10:20] <Saviq> so "baz"
[10:21] <Saviq> and foo && foo.bar || ""
[10:21] <Saviq> goes, more or less, to "baz" || "", so "baz"
[10:22] <dednick> hm
[10:27] <Saviq> tvoss, there?
[10:27] <tvoss> Saviq, yup
[10:29] <nic-doffay> Saviq, sorry not sure what you meant: '<Saviq> nic-doffay, while having moved to dandrader's TappedOutsideNotifier?'
[10:31] <Saviq> nic-doffay, just one line change for switching from InverseMouseArea to TappedOutsideNotifier?
[10:31] <Saviq> nic-doffay, that'd be great ;)
[10:31] <Saviq> nic-doffay, we need to switch to TON, 'cause IMA didn't work well on devices
[10:32] <nic-doffay> Saviq, haha yeah it's just one line.
[10:32] <nic-doffay> Saviq, or two I think :P
[10:32] <Saviq> nic-doffay, sure, please test it works on devices then
[10:32] <Saviq> nic-doffay, and write a test, too!
[10:34] <nic-doffay> Saviq, sure
[10:34] <mzanetti> mhr3: https://code.launchpad.net/~mhr3/unity-scopes-shell/scopes-ng-tests/+merge/198437 line 437. wanted?
[10:35] <mhr3> meh, it's copied over from the lib
[10:36] <mhr3> which means there's lgpl licenced test... guess i should change that
[10:37] <mzanetti> true
[10:37] <tsdgeos> 5.2.0 official out
[10:37] <mzanetti> huh? that was fast
[10:37] <mzanetti> didn't they just discuss when the next rc should come?
[10:38] <mhr3> mzanetti, pushed
[10:41] <tsdgeos> damnit, reconstructing the verticalJournal up is not easy at all :/
[10:49] <Saviq> mzanetti, tsdgeos old news, it was out yesterday ;)
[10:50] <Saviq> tsdgeos, less easy and doing top-down?
[10:50] <tsdgeos> Saviq: not officially ;-)
[10:50] <Saviq> tsdgeos, pfft
[10:50] <Saviq> tsdgeos, I SAW IT THERE IN official-releases!
[10:50] <greyback> the tarballs were out
[10:50] <Saviq> here http://download.qt-project.org/official_releases/qt/ !
[10:50] <greyback> it was on hacker news too :)
[10:50] <Saviq> see? 11-Dec-2013 16:12
[10:50] <tsdgeos> Saviq: there was no email ;-)
[10:50] <Saviq> tsdgeos, bah!
[10:50] <tsdgeos> tarball may had been changed :D
[10:51] <Saviq> ;)
[10:51] <tsdgeos> 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] <tsdgeos> because the next item you position up may mean you have to rearrange the things
[10:51] <tsdgeos> so i'll have to do that i guess, which is not cool
[10:51] <tsdgeos> that or remember the columns of every item
[10:51] <tsdgeos> which is worse :D
[10:53] <Saviq> tsdgeos, hmm ah in case one of the previous items is like *long*?
[10:53] <tsdgeos> yep
[10:53] <Saviq> tsdgeos, so that it covers two rows when going top-down, but you don't know that yet when going up
[10:53] <Saviq> tsdgeos, you think it's really worse to store them?
[10:53] <tsdgeos> if i order them the same way going up that when going down
[10:53] <tsdgeos> when i reach the top
[10:53] <tsdgeos> stuff is jaggy and not 0 aligned
[10:53] <Saviq> tsdgeos, yup, understood
[10:54] <tsdgeos> ideally i should be able to reorder them before you see them on screen
[10:54] <tsdgeos> since i have a buffer zone too
[10:54] <Saviq> tsdgeos, I just wonder if it's really that bad to store the positions...
[10:54] <Saviq> tsdgeos, more memory-hungry, sure (how much?)
[10:54] <tsdgeos> well it's not bad, just a bit more memory intensive
[10:54] <Saviq> tsdgeos, but the other one is much more computationally heavy
[10:54] <tsdgeos> not much, i just need to store the integer of the column
[10:55] <Saviq> yeah exactly
[10:55] <Saviq> tsdgeos, your call, I can see pros and cons of both
[10:56] <tsdgeos> i mean storing the column is so much easier
[10:56] <Saviq> mzanetti, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1237923 → Confirmed
[10:56] <Saviq> tsdgeos, yeah, and what... a kB memory per 1000 entries?
[10:56] <tsdgeos> getting the algo right to reconstruct + move the stuff as needed is much harder
[10:56] <Saviq> (probably more, but not much)
[10:56] <mzanetti> Saviq: done
[10:56] <Saviq> mzanetti, cheers
[10:57] <tsdgeos> 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] <Saviq> tsdgeos, I really doubt we will :)
[11:11] <tsdgeos> Saviq: storing the column doesn't work if we want to support resizing
[11:12] <Saviq> tsdgeos, right, but I'm fine with redoing it in that case
[11:13] <Saviq> tsdgeos, like I can actually agree to do the whole model top-down when you resize the column
[11:13] <tsdgeos> sure, but means i still need to write the algorithm :D
[11:13] <tsdgeos> ah
[11:13] <Saviq> tsdgeos, it's not like resizing is going to happen often
[11:13] <tsdgeos> sure
[11:14] <Saviq> tsdgeos, iteration 2, basically
[11:53] <nic-doffay> dandrader, did you write any tests for PressedOutsideNotifier?
[11:54] <dandrader> nic-doffay, yes
[11:54] <dandrader> in tests/plugins/Ubuntu/Gestures
[11:54] <dandrader> nic-doffay, ↑
[11:55] <nic-doffay> dandrader, cool
[11:56] <dandrader> nic-doffay, adding stuff to it?
[11:57] <nic-doffay> dandrader, nah not yet at least.
[12:04] <mhr3> mzanetti, regarding the QVariant returns, i find it odd when a method is returning QVariant and you see "return QString(foo);"
[12:07] <mzanetti> mhr3: fair enough... it's personal preference. So, your code, your rules. feel free to ignore
[12:08] <mhr3> 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] <mzanetti> mhr3: yeah. it's quite common in Qt to let it convert to QVariants implicitly
[12:09] <mhr3> fine then
[12:14] <dednick> anyone noticed that if you exit the unity8 shell app on desktop, if stops the desktop indicators? :)
[12:14] <dednick> oops
[12:14] <dednick> i think it's sending upstart a command
[12:15] <greyback> dednick: yep, here too. I usually restart them with "start indicator-session"
[12:22] <nic-doffay> dandrader, do I need to change any CMakeLists to use Ubuntu gestures from qmluitests?
[12:25] <dandrader> nic-doffay, you mean you want a test listed in tests/qmltests/CMakeLists.txt to "import Ubuntu.Gestures"?
[12:26] <Saviq> dednick, one for you https://code.launchpad.net/~saviq/unity8/clean-paths-cmakelists/+merge/198725
[12:26] <nic-doffay> dandrader, that's right.
[12:27] <dandrader> nic-doffay, you will have to add "${CMAKE_BINARY_DIR}/plugins" to the IMPORT_PATHS parameter of his add_qml_test entry
[12:28] <Saviq> isn't that default?
[12:28] <Saviq> nope
[12:28] <dandrader> Saviq, no. some tests want to use mock versions of some of the plugins there
[12:28] <Saviq> dandrader, yup
[12:28] <Saviq> nic-doffay, so something like:
[12:28] <Saviq> add_qml_test(Panel Indicators IMPORT_PATHS ${CMAKE_BINARY_DIR}/plugins ${qmltest_DEFAULT_IMPORT_PATHS})
[12:28] <dandrader> nic-doffay, so bear in mind the order of the IMPORT_PATHS
[12:29] <dandrader> matter
[12:30] <nic-doffay> dandrader, cool I see it's already been added for dash etc.
[12:34] <dednick> Saviq: ok, will take a look after lunch.
[12:34] <Saviq> dednick, cheers
[12:39] <tsdgeos> Saviq: So  lp:~aacid/+junk/verticalJournal  should be pretty good
[12:39] <tsdgeos> Saviq: needs someone to go over the functional and test review
[12:39] <tsdgeos> Saviq: and a place to merge it :D
[12:39] <Saviq> tsdgeos, new-scopes
[12:39] <Saviq> tsdgeos, or well...
[12:39] <tsdgeos> Saviq: unity-scopes-s
[12:39] <Saviq> tsdgeos, it can go into lp:unity8 directly
[12:40] <tsdgeos> right
[12:40] <tsdgeos> ok
[12:40] <Saviq> tsdgeos, it doesn't have to be used, as long as it's tested
[12:40] <tsdgeos> sure
[12:40] <tsdgeos> i need to work a bit more on the tests
[12:40] <tsdgeos> but it's almost there
[12:44] <Saviq> mhr3, hmm scopes.get(scopeSelector.selectedIndex) → ASSERT failure in QList<T>::at: "index out of range"
[12:45] <mhr3> who was telling me that those index checks in data are useless?
[12:45] <mhr3> mzanetti, tsdgeos ^? :P
[12:45] <mzanetti> mhr3: I did
[12:45] <mhr3> oh but wait, that's get(), not data()
[12:45] <mzanetti> mhr3: well... otherwise noone would have noticed and there's just some data missing
[12:46] <mzanetti> ah wait... this is a manual get()
[12:46] <mzanetti> not the data() method
[12:46] <mzanetti> in that case it's different
[12:47] <mhr3> fixing in the tests branch
[12:47] <mhr3> and adding test for it :)
[12:48] <dandrader> Anyone up for a quick & east review? https://code.launchpad.net/~dandrader/unity-mir/lp1248795/+merge/198731
[12:48] <Cimi> mzanetti,
[12:48] <dandrader> s/east/easy
[12:48] <Cimi> https://bugs.launchpad.net/unity8/+bug/1258126
[12:48] <Cimi> this is weird
[12:49] <Cimi> in ambiance theme
[12:49] <greyback> dandrader: I'll take it
[12:49] <Cimi> the indicator is placed with x: button.width - width
[12:49] <dandrader> greyback, thanks!
[12:49] <greyback> dandrader: I always get it wrong and thing 'var' is the deprecated one
[12:49] <Saviq> mhr3, lp:~unity-team/unity8/scope-dev-tool
[12:49] <Cimi> with button.width being text.paintedWidth + text.anchors.leftMargin + text.anchors.rightMargin
[12:49] <greyback> s/thing/think/
[12:50] <Cimi> text is the label in indicators
[12:50] <dandrader> greyback, http://qt-project.org/doc/qt-5.0/qtqml/qml-variant.html
[12:50] <dandrader> "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] <greyback> dandrader: yep I know. I just get that mixed up in my head
[12:51] <dandrader> greyback, a ok, got what you meant now :)
[12:52] <mzanetti> Cimi: hmm... maybe paintedWidth borked?
[12:52] <greyback> dandrader: approved
[12:52] <Cimi> mzanetti, it's my guess too
[12:53] <Saviq> mhr3, re: auto → sure, easier to write, not easier to read ;)
[12:53] <Saviq> 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] <mzanetti> mhr3: complaining about me nitpicking on "auto" :P ?
[12:54] <mhr3> yes :)
[12:55] <mhr3> Saviq, pushed the index thing
[12:55] <Saviq> mhr3, you mean fixed it?
[12:55] <mhr3> yes
[12:55] <Saviq> mzanetti, does QtC resolve auto?
[12:55] <Saviq> mhr3, ok
[12:55] <mzanetti> dunno..
[12:55] <Saviq> mzanetti, I mean it should ideally resolve it in a tooltip, for example
[12:56] <greyback> 2.9 wasn't able to, I remember that anywy
[12:56] <Saviq> mzanetti, or well, you can look at return type of the function anyway
[12:56] <Saviq> 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] <mzanetti> Saviq: sure... but it requires me to move the mouse and wait a second for the tooltip to show up :D
[12:56] <mhr3> pfff :P
[12:57] <mzanetti> *the mouse*
[12:57] <mzanetti> :P
[12:57] <mhr3> the horror!
[12:57] <Saviq> mhr3, http://people.canonical.com/~msawicz/scope-tool/
[12:58] <mhr3> Saviq, also, why do you call scopes.get() with incorrect index? :)
[12:58] <Saviq> mhr3, I wasn't
[12:58] <Saviq> mhr3, well, was trying not to
[12:58] <mhr3> Saviq, yey, lovely :)
[12:59] <mhr3> i mean the tool
[12:59] <Saviq> mhr3, right, it's a race probably
[12:59] <Cimi> mzanetti, confirmed...
[12:59] <Saviq> mhr3, I get assert with 0
[13:00] <mhr3> Saviq, calling too early?
[13:00] <mzanetti> Cimi: hmm.. can you reproduce that in a simplified testcase?
[13:00] <Saviq> mhr3, binding
[13:00] <Saviq> mhr3, the option selector already created and selected its 0 index
[13:01] <Cimi> mzanetti, nope
[13:01] <Saviq> mhr3, but somehow the model isn't ready for it yet
[13:01] <mhr3> Saviq, yea, it takes a while to init the scopes model, anyway, with the patch you'll get null back
[13:02] <mhr3> Saviq, you could wait for the loaded signal though
[13:03] <mhr3> Saviq, also ekran is screen?
[13:03] <mhr3> sounds like a wild animal :D
[13:03] <Saviq> mhr3, yes :)
[13:03] <Saviq> mhr3, how about "zrzut"? ;)
[13:04] <Saviq> mhr3, not sure where covers went, though :/
[13:04] <mhr3> yea, that one is *just* odd, no associations :)
[13:04] <mhr3> but ekran totally has wings
[13:04] <mhr3> and is blue
[13:05] <mhr3> 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] <Saviq> ;D
[13:10] <Saviq> mhr3, look again http://people.canonical.com/~msawicz/scope-tool/
[13:10] <mhr3> why the double edit?
[13:11] <Saviq> mhr3, 'cause you can't access it in phone layout
[13:11] <Saviq> mhr3, there's no "SEARCH" panel
[13:11] <mhr3> oh
[13:11] <mhr3> ok
[13:11] <Saviq> mhr3, we could go for button, but thought that would be good enough
[13:11] <mhr3> sure, doesn't need to be perfect
[13:12] <Saviq> mhr3, any idea where covers went?
[13:12] <Saviq> mhr3, don't get them in plain unity8 either
[13:12] <mhr3> hmm, server issue?
[13:13] <mhr3> Saviq, oh do you have the icon -> art branch installed?
[13:13] <Saviq> mhr3, good question
[13:13] <Saviq> mhr3, prolly not
[13:13] <mhr3> that would explain it
[13:23] <dednick|lunch> Saviq: what is shell_app_HDRS?
[13:24] <Saviq> dednick, yeah, exactly - nothing
[13:24] <Saviq> dednick, it's not defined anywhere
[13:24] <dednick> ok
[13:25] <Saviq> ok... I was trying to get food for two hours now...
[13:25] <Saviq> /food
[13:29] <Saviq> mhr3, right - icon vs. art indeed - where *is* that branch, btw?
[13:29]  * Saviq got lost
[13:32] <mhr3> Saviq,  lp:~mhr3/unity-scopes-shell/scopes-ng-tests
[13:32] <mhr3> so also in the json-defaults one
[13:33] <Saviq> mhr3, right!
[13:37] <Saviq> mhr3, http://people.canonical.com/~msawicz/scope-tool/ ;)
[13:37] <Saviq> mhr3, will package it and it basically get in into new-scopes
[13:37] <Saviq> +can
[13:38] <mhr3> much better :)
[13:38] <Saviq> mhr3, tests will only come later when we do something the dash itself doesn't do (like putting JSON through the validator)
[13:39] <Saviq> really... */food*
[13:39] <mhr3> i'll also play with it so it's able to talk to an uninstalled scope
[13:42] <dednick> Saviq: hm, that getProperty doesnt work yet. changes to roles doesnt update the values :(
[13:42] <dednick> Saviq: because it's a string property we're checking for.
[13:43] <dednick> Saviq: ie getProperty(menuData, "label", "") will not respond to changes to menuData.label
[13:43] <Saviq> dednick, "obviously that assumes that extAttrib only changes
[13:43] <Saviq> atomically - which is not the case for menuData, for example - so it makes
[13:43] <Saviq> sense to keep menuData explicit, while moving extAttrib and maybe some others.
[13:43] <Saviq> Or well, menuData could be handled as well, by means of Qt.binding(), I think."
[13:44] <dednick> would have nice to have the menuData like that it as well.
[13:45] <dednick> Saviq: can you return a binding from a function?
[13:46] <Saviq> dednick, Qt.binding(function() { return menuData[property] }) should work
[13:46] <Saviq> dednick, hmm or not
[13:47] <Saviq> dednick, you'd have to make sure that menuData.property is named somewhere there
[13:47] <Saviq> dednick, so that the binding attaches to dataChanged
[13:47] <Saviq> dednick, not sure [] will be good enough
[13:50] <dednick> eh. would need to do it in onCompleted as well. can't use binding in declaration
[13:52] <dednick> i knew there was a reason for all those && ?, i tried this before...
[13:52] <Saviq> dednick, why?
[13:53] <Saviq> dednick, as long as the changing thing is called explicitly in the binding
[13:53] <Saviq> dednick, it should update fine
[13:53] <Saviq> dednick, that's why I mentioned a custom get(object, property, default) method
[13:53] <Saviq> dednick, as .getProperty assumes the object is !undefined
[13:54] <Saviq> dednick, the get() would not assume that
[13:54] <dednick> Saviq: yeah, but need get(object, property, propertyName, default
[13:54] <Saviq> dednick, and should be evaluated whenever any of its arguments change
[13:54] <Saviq> dednick, property vs. propertyName?
[13:54] <dednick> hasOwnProperty.
[13:54] <dednick> i guess can just to !== undefined
[13:55] <Saviq> dednick, yeah, first check if object is defined
[13:55] <Saviq> dednick, then if it has property
[13:55] <Saviq> dednick, if either is false, return default
[13:55] <Saviq> dednick, and that should cause the thing to reevaluate as needed - *assuming* that object changes atomically
[13:55] <dednick> Saviq: how to you check if it has a property? you mean just "menuData && menuData.label != undefined"
[13:56] <Saviq> dednick, which menuData doesn't - but extendedAttr has
[13:56] <Saviq> dednick, right, menuData is different
[13:56] <Saviq> dednick, that's why I said that a binding is needed
[13:56] <Saviq> dednick, and I doubt menuData[property] will be good enough
[13:57] <Saviq> dednick, you need to call menuData.label explicitly for dataChanged to be connected
[13:57] <Saviq> dednick, so for menuData indeed I'm not sure it makes sense
[13:58] <Saviq> dednick, you *could* hack it around with something along the lines of: menuData.onDataChanged: menuData.changed()
[13:58] <Saviq> dednick, but that's probably not the best thing to do
[14:01] <dednick> Saviq: http://pastebin.ubuntu.com/6561497/
[14:01] <dednick> can really use either for extended data
[14:02] <dednick> dont need a binding if we give the property, as it will be reevaluated when the parameter changes
[14:03] <Saviq> dednick, only extendedData.xCanonicalTime will complain about extendedData undefined
[14:03] <Saviq> dednick, as will menuItem.label
[14:04] <dednick> oh, you mean when you call into the function? hmm.
[14:08] <Saviq> dednick, yeah, at that point you'd have to go menuData && menuData.property
[14:08] <Saviq> dednick, as the argument - which is bleh.
[14:10] <dednick> 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] <dednick> but i guess that defeats the purpose. sigh....
[14:10] <Saviq> dednick, yeah, it will, but yes - it defeats the purpose exactly
[14:11] <dednick> i might just change the menuData.label back to good old && || . dont think there's really any other neat way around it.
[14:13] <Saviq> dednick, only thing I could think of was menuData[propertyName] in a Qt.binding()
[14:13] <Saviq> dednick, but I'm worried that doesn't actually work
[14:13] <dednick> Saviq: it doesnt.
[14:13] <dednick> plus you need to use inside onCompleted, which sucks
[14:14] <Saviq> dednick, yeah, I'm ok with && for menuData
[14:14] <Saviq> dednick, since there's no clean way around it
[14:33] <Saviq> dednick, standup
[14:34] <Cimi> Saviq, you should have another automated bot for automated standup calls
[14:44] <mzanetti> MacSlow: hey. as you'll be gone soon, what's the status of the SIM pinlock?
[14:44] <mzanetti> MacSlow: did you fix those two issues I found?
[14:45] <MacSlow> mzanetti, branch is ready since London with your requested fixes
[14:45] <mzanetti> MacSlow: oh... damn... ok... I'll review it and fix any comments myself then while you're away
[14:45] <MacSlow> mzanetti, I confidnet you'll be happy with the current state
[14:46] <mzanetti> 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] <mzanetti> MacSlow: I'll try to have it merged by the time you come back.
[14:47] <MacSlow> mzanetti, even made a screencast for you -> https://www.youtube.com/watch?v=raJpJx6DkQU :)
[14:47] <mzanetti> haha
[14:47] <mzanetti> always fun to see some motor bikes
[14:47] <Saviq> ;D
[14:48] <MacSlow> mzanetti, no bikes in that screencast this time :)
[14:48] <Saviq> MacSlow, there's some in the "you should also watch" screen ;)
[14:48] <mzanetti> and in your avatar
[14:48] <MacSlow> Saviq, those are "bugs" in Google's recommendations-algorithms ;)
[14:49] <Saviq> Cimi, re: bug #1258571 - yeah, that's what we discussed in London
[14:49] <Saviq> Cimi, stretching is the worst thing you can do to any image ;)
[14:49] <Cimi> Saviq, stretch/crop
[14:49] <Cimi> Saviq, all OSes do that
[14:49] <Saviq> Cimi, so fit, not stretch
[14:49] <Cimi> whatever
[14:49] <Cimi> scale
[14:49] <Saviq> Cimi, yes
[14:50] <Saviq> 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] <Saviq> Cimi, we decided to go landscape + portrait for the default ones
[14:50] <Cimi> I think it will be weird
[14:51] <Saviq> Cimi, when you select a different background - that's when it will be scaled+croped
[14:51] <Saviq> cropped
[14:51] <Cimi> rotating the tablet and seeing wallpaper changing
[14:51] <Saviq> Cimi, no no
[14:51] <Saviq> Cimi, it's only about native aspect
[14:51] <Cimi> Saviq, the bug report is about orientation
[14:51] <Saviq> Cimi, so on tablet it will always be the tablet one
[14:51] <Saviq> Cimi, ok maybe it's worded wrong indeed
[14:52] <Saviq> Cimi, so write down in the bug please that the selection is only supposed to be made based on native device orientation
[14:52] <Cimi> ok
[14:52] <Saviq> /aspect ratio
[14:52] <Cimi> ok
[14:53] <Cimi> done
[14:53] <Cimi> seb128, ^^
[14:53] <Cimi> seb128, that bug, we need extra gestating schema
[14:53] <Cimi> gsetting
[14:56] <seb128> Cimi, why?
[14:56] <seb128> what schemas/setting
[14:56] <Cimi> seb128, look at the bug
[14:56] <seb128> I did
[14:56] <Cimi> https://launchpad.net/bugs/1258571
[14:56] <seb128> that doesn't make sense
[14:56] <seb128> we discussed that via email with Saviq some time ago
[14:56] <seb128> having per form factor keys doesn't make any sense
[14:57] <Saviq> seb128, we talked with cwayne and design folk in London
[14:57] <Saviq> seb128, it's not per-form-factor
[14:57] <Saviq> seb128, it's for-portrait and for-landscape
[14:57] <Saviq> seb128, and well, I don't really care whether it comes from gsettings or somewhere
[14:57] <seb128> are those actually different backgrounds, or just one rotated?
[14:57] <Saviq> seb128, different ones
[14:58] <cwayne> apologies if i didn't word the bug clearly enough
[14:58] <seb128> shrug
[14:58] <seb128> Saviq, cwayne: and which one of those 2 keys to plan to use in desktop mode?
[14:58] <Saviq> seb128, the idea is that OEMs can provide two backgrounds, one working well on portrait, one on landscape - only taking *native* aspect into account
[14:59] <Saviq> seb128, desktop is native landscape - so that one
[14:59] <Saviq> seb128, so we might just add background_portrait - or even take it from somewhere else than gsettings
[15:00] <cwayne> we just suggested gsettings as that's where the current background info lives and would be the easiest in terms of customization
[15:00] <seb128> Saviq, I was going to say, maybe just read the gsettings key and append -portrait to the filename and try to load that first
[15:01] <seb128> e.g gsettings would be UbuntuRock.png
[15:01] <seb128> you would try loading UbuntuRock-portrait.png if it's there
[15:02] <seb128> cwayne, Saviq: the current design of the background config doesn't allow for portrait/landscape difference, what happen if you pick a background in portrait?
[15:02] <seb128> does it change only that one? or landscape as well?
[15:02] <seb128> we need design guidance on how the config is going to work to not be confusing
[15:02] <Saviq> seb128, that's a problem in the settings app - it should reflect the native resolution of the device, I think
[15:03] <Saviq> seb128, but, again, I probably have even more questions for that than you do!
[15:03] <seb128> Saviq, well, if there are 2 images for landscape/portrait, do we need to be able to select both?
[15:03] <seb128> cwayne^^
[15:03] <Saviq> seb128, again, I have more questions!
[15:03] <seb128> Saviq, well, let's get those resolved before adding gsettings keys
[15:04] <Saviq> seb128, like that's gonna happen!
[15:04] <Saviq> seb128, I'm fine with appending -portrait, tbh
[15:05] <seb128> Saviq, well, the issue with all those solutions, is that
[15:05] <seb128> - you end up with the setting not reflecting what you have on screen
[15:05] <seb128> - if you pick a custom background, how do you got back to the vendor ones?
[15:05] <Saviq> seb128, right back at you :)
[15:06] <seb128> well, if you ask me I'm staying that those different images seems like a stupid idea and we shouldn't do it..
[15:06] <cwayne> well if the device is portrait, only show/care about the -portrait gsettings key
[15:06] <Saviq> cwayne yeah, which ends up being just one gsettings key ultimately
[15:07] <cwayne>  right
[15:07] <Saviq> cwayne, which begs the question... should the default not be per-device?
[15:07] <cwayne> Saviq: what if we have one key that points to a dir that can contain a -landsape.png and a -portrait.png
[15:07] <seb128> cwayne: then the configuration behaves differently when you rotate the device without telling you?
[15:08] <cwayne> seb128: its about the native aspect ratio, not the current one
[15:08] <cwayne> AIUI its not supposed to switch when you rotate
[15:08] <Saviq> cwayne, I'm starting to think it should just use the image override
[15:08] <Saviq> cwayne as in the system image - per-device
[15:08] <Saviq> cwayne so you'd put a different background on manta, different on mako
[15:08] <Saviq> even under the same name
[15:09] <seb128> cwayne: portrait is not supposed to be used in portrait mode?
[15:09] <Saviq> seb128, only native aspect ratio
[15:09] <Saviq> seb128, not when you change orientation
[15:10] <seb128> so it's 1 image by device?
[15:10] <cwayne> Saviq: right, but then we'd need different custom tarballs for different devices, which we were trying to avoid
[15:10] <Saviq> seb128, effectively yes
[15:10] <seb128> so why just not shipping that as the default wallpaper?
[15:10] <Saviq> seb128, ↑↑
[15:11] <Saviq> brb
[15:11] <cwayne> because then that image wouldn't look good on a mako for example
[15:12] <cwayne> davidcalle: heya, where would be the best place to file a wishlist bug against a server-side scope?
[15:14] <davidcalle> cwayne, if you find it in the list of unity-scopes sub-projects (https://launchpad.net/unity-scopes), on the scope itself. Or more generally, against unity-scope. There is no public place for server specific bugs (yet?).
[15:15] <cwayne> davidcalle: awesome, thanks
[15:16] <cwayne> seb128: so the whole point is to be able to have 1 custom tarball that will dynamically choose the right background so that we don't have to make a -tablet image
[15:16] <davidcalle> cwayne, np :) *now waits for bugmail*
[15:18] <seb128> cwayne: there is 0 difference in image/setup between a phone and a tablet image/for different devices?
[15:19] <seb128> cwayne, Saviq: do we have some sort of code running on first device boot? could we just set the background key to the right value then?
[15:19] <cwayne> seb128: correct. there's 1 image that works on both
[15:20] <seb128> it would make things easy/compatible with what we have now and not at a runtime cost
[15:20] <seb128> better to do a check/write a key once that check at every unity start
[15:31] <davidcalle> cwayne, oh wait, you can't actually report a bug against unity-scopes... Ugh. Is it the weather not on top bug?
[15:31] <tsdgeos> this is veeeeeeery confusing
[15:31] <cwayne> davidcalle: no it was jcastro asking me, i think he had a wishlist bug for the askunity scope
[15:32] <tsdgeos>         QTRY_COMPARE(item.y(), y);
[15:32] <tsdgeos>         qDebug() << item.y() << y;
[15:32] <cwayne> davidcalle: i just guessed and did the weather one to the home scope
[15:32] <tsdgeos> FAIL!  : VerticalJournalTest::testVerticalSpacing() Compared doubles are not the same (fuzzy compare)
[15:32] <tsdgeos>    Actual   (item.y()): 355
[15:32] <tsdgeos>    Expected (y): 11
[15:32] <tsdgeos>    Loc: [verticaljournaltest.cpp(33)]
[15:32] <tsdgeos> QDEBUG : VerticalJournalTest::testVerticalSpacing() 11 11
[15:32] <cwayne> seb128: that seems reasonable to me, i don't think anyone wanted us to do the check every time unity started, just once :)
[15:32] <tsdgeos> so it's 355 vs 11 but then i print them and it's 11 and 11 ?¿?¿?¿
[15:33] <davidcalle> cwayne, it's actually on the scope too... I'll make a place for these bugs. And for askubuntu, it's on unity-scope-askubuntu, I'm pretty sure I already know the bug :)
[15:34] <cwayne> davidcalle: :)
[15:41] <mhr3_> tsdgeos, TRY_COMPARE is too much magic, not too surprised :P
[15:41] <tsdgeos> mhr3_: is not magic at all
[15:41] <tsdgeos> it's just a loop
[15:42] <tsdgeos> ahh, know what's going on
[15:43] <mhr3_> tsdgeos, hm?
[15:43] <tsdgeos> found my problem
[15:43] <tsdgeos> or the "hm?" is about try compare being just a loop?
[15:44] <mhr3_> tsdgeos, "hm" == so what's the actual problem?
[15:44] <tsdgeos> i was working on deleted memory :D
[15:44] <mhr3_> nice :)
[15:45] <tsdgeos> good guy valgrind at rescue
[15:48] <mhr3_> mzanetti, happy enough with the tests branch now?
[15:48] <mzanetti> mhr3_: will have a look
[15:49] <mhr3_> got two more branches built on top of it, so would like it in asap
[15:49] <Saviq> cwayne, seb128, right, so there's a few jobs that run on system / session startup
[15:50] <Saviq> cwayne, seb128, that do something only once (and write a .file somewhere to not do it again)
[15:50] <cwayne> right, we even have some of those for customization already as well
[15:50] <Saviq> cwayne, seb128, so we could add a job that writes an .override file if it doesn't exist
[15:50] <seb128> right
[15:51] <seb128> I like that approach better tbh
[15:53] <Saviq> seb128, +1
[15:53] <seb128> ;-)
[15:54] <Saviq> cwayne, could you mark affefcts bug #1258571 for the customization project? sssssomething?
[15:55] <mzanetti> mhr3_: hmm... not sure if its my setup (probably it is) but tests are failing here
[15:55] <cwayne> Saviq: done, sorry i thought it had already been attached
[15:55] <mhr3_> mzanetti, ci likes them
[15:55] <mhr3_> mzanetti, so it's you :)
[16:01] <kgunn> dednick: just to be sure...this branch https://code.launchpad.net/~nick-dedekind/unity8/indicator-menuitems-lp1253810/+merge/198597
[16:01] <kgunn> doesn't really fix that bug right ?
[16:01] <kgunn> e.g. its just an artifact in the name of the branch
[16:02] <dednick> kgunn: it's part of the fix.
[16:02] <dednick> kgunn: along with a qmenumodel fix which has already gone int
[16:02] <dednick> *in
[16:02] <Saviq> didrocks, bug #1260379
[16:03] <didrocks> Saviq: I think we can make that part of the -autopilot package
[16:03] <didrocks> wdyt?
[16:03] <didrocks> unity8-autopilot that is
[16:03] <dednick> kgunn: i'm just in the process of checking the tests that i've made against the branch, and we should be able to merge.
[16:03] <Saviq> didrocks, could
[16:03] <didrocks> Saviq: I would start with that TBH ;)
[16:03] <Saviq> didrocks, please comment/mark-affect
[16:03] <didrocks> ok
[16:04] <kgunn> dednick: thanks...sorry to be a nag, was that bug consistent enough to know it fixes it for sure
[16:04] <dednick> kgunn: i haven't been able to reproduce, but Saviq has.
[16:04] <dednick> although i havent tried it on my phone now that i have it with me.
[16:04] <kgunn> dednick: mmmm....polish texts :)
[16:05] <kgunn> ...or excuse me Polish
[16:05] <dednick> haha
[16:05] <Saviq> kgunn, excuse me, there were no texts involved - missed calls are enough ;P
[16:05] <Saviq> dednick, btw, that branch ready yet?
[16:05] <Saviq> dednick, or are you tweaking still?
[16:07] <Saviq> ah 8 minutes ago :)
[16:07] <dednick> Saviq: it's ready.
[16:07] <Saviq> dednick, ok
[16:09] <mhr3_> Saviq, seems like you didn't push the search edit
[16:10] <Saviq> mhr3_, possible
[16:10] <Saviq> mhr3_, pushed
[16:10] <mhr3_> lovely
[16:17] <Saviq> didrocks, but bug #1260384
[16:17] <didrocks> Saviq: can you address those to the CI team? :)
[16:17] <Saviq> didrocks, isn't the -itself enough?
[16:17] <didrocks> Saviq: sinon, ack on that one, that would make our life easier :)
[16:18] <Saviq> didrocks, not sure I can, either
[16:18] <didrocks> Saviq: should be, but not sure why you really ping me :)
[16:18] <Saviq> didrocks, for → Confirmed ;)
[16:18] <didrocks> ah
[16:18] <didrocks> ok, yeah, can do
[16:18] <Saviq> didrocks, as we discussed this before
[16:19] <didrocks> done
[16:19] <didrocks> with a comment ;)
[16:19] <Saviq> nic-doffay, a simple one when you have a bit of time https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1260379
[16:20] <nic-doffay> Saviq, cool
[16:20] <Saviq> didrocks, see you want for false || value in the end :)
[16:20] <tsdgeos> Saviq: do you want me to propose the verticaljournal as a new plugin or rename the LVWPH plugin into something like "DashViews" and add it there?
[16:20] <Saviq> tsdgeos, same plugin is fine I think
[16:20] <didrocks> Saviq: right ;)
[16:20] <tsdgeos> Saviq: oki, will do some renaming then
[16:21] <Saviq> didrocks, erm
[16:21] <Saviq> didrocks, that was at dednick ;)
[16:21] <Saviq> sorry
[16:21] <Saviq> dednick, see you want for false || value in the end :)
[16:22] <Saviq> dednick, there seem to be some unrelated fixes in there now?
[16:22] <didrocks> Saviq: I was reacting on "a simple one" (telling, right, it's a simple one)
[16:23] <Saviq> didrocks, ok :)
[16:24] <dednick> Saviq: um, related to the Factory, but not necessarily to that bug.
[16:24] <Saviq> dednick, yeah, it's ok, though - assume there's no other bugs for those
[16:25] <Saviq> dednick, but we'll get tests for them ;)
[16:25] <dednick> Saviq: yeah, that's what i'm doing now. I found those bugs with the tests.
[16:25] <Saviq> dednick, ok awesome
[16:26] <Saviq> dednick, changes look good, testing again
[16:26]  * Saviq goes `rm -R shell/builddir`...
[16:30] <Cimi> mzanetti, ping
[16:30] <mzanetti> Cimi: o/
[16:30] <Cimi> mzanetti, so, the binding seems broken
[16:30] <mzanetti> fix it :)
[16:31] <Cimi> mzanetti, well, I dunno why doesn't work
[16:31] <Cimi> mzanetti, on the item
[16:31] <mzanetti> mhm... can you point me to the line of code?
[16:31] <Cimi> x: button.width - width
[16:31] <Cimi> mzanetti, /usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/Themes/Ambiance/TabBarStyle.qml
[16:31] <mzanetti> Cimi: oh, inside the theme?
[16:31] <Cimi> you can sudo qtcreator that :)
[16:31] <Cimi> yes
[16:32] <Cimi> it's useful to debug
[16:32] <mzanetti> and why don't the apps suffer from that?
[16:32] <Cimi> don't ask me yet
[16:32] <Cimi> I need more brain power
[16:32] <Cimi> :P
[16:32] <Cimi> so I need your head as well
[16:33] <Cimi> mzanetti, for indicatorImage
[16:33] <Cimi> mzanetti, there's x: button.width - width
[16:33] <dednick> Saviq: how do i get whitespace test failure output?
[16:33] <Cimi> but in the case of the indicator button.width changes AFTER x, and x is not update :-\
[16:34] <Cimi> mzanetti, you can do that if you do onXChanged and onWidthChanged
[16:34] <Cimi> on indicatorImage and button respectively
[16:34] <mzanetti> Cimi: probably a binding loop detection that kicks in
[16:34] <Saviq> dednick, ./tests/whitespace/check_whitespace.py . | grep -v builddir
[16:35] <dednick> Saviq: ta
[16:35] <Saviq> dednick, or well, make -C builddir works, too
[16:35] <Saviq> test
[16:35] <Saviq> make -C builddir test
[16:35] <didrocks> Saviq: kgunn: for the unity8 AP failures, as it's due to screenlocking, I don't remember but the fix will be in the unity8 AP tests, right?
[16:36] <Cimi> mzanetti, I can't see any print
[16:36] <Cimi> mzanetti, on the terminal
[16:36] <Cimi> about binding loops
[16:36] <Saviq> didrocks, https://code.launchpad.net/~saviq/unity8/helper-retry-unlock/+merge/198648
[16:36] <Cimi> mzanetti, but on the gallery app it updates, not here
[16:37] <mhr3_> tsdgeos, is there a way to know that a plugin is running under qmlplugindump?
[16:37] <tsdgeos> mhr3_: no idea, sorry
[16:38] <didrocks> Saviq: that should fix all the AP issues we saw, right?
[16:38] <Saviq> didrocks, as far as I can tell, yes
[16:39] <Saviq> didrocks, bear in mind that's not something I could reproduce locally
[16:39] <didrocks> Saviq: yeah, still worth a try
[16:39] <Saviq> didrocks, worse case it will give us more data
[16:39] <Saviq> *worst
[16:39] <didrocks> Saviq: we'll release unity8 once the 2 other bugs are fixed as well
[16:39] <nic-doffay> Saviq, this test_pressed_outside_notifier causes the top test to fail. It doesn't set the search as active even though triggerSearch is being called in the top most test. Any insights as to why?
[16:39] <didrocks> Saviq: ok, I'm writing that :)
[16:39] <didrocks> thanks!
[16:39] <Saviq> didrocks, yup
[16:40] <Saviq> didrocks, next step - we'll need cameras onto the devices
[16:40] <didrocks> Saviq: complete +1, that was so helpful in otto
[16:40] <Saviq> didrocks, if it doesn't help, that is
[16:40] <mhr3_> tsdgeos, cause that thing is highly broken, it manages to unload the module but doesn't destroy objects it creates from there
[16:40] <didrocks> Saviq: well, generally, way better to see visually at least what happened
[16:40] <tsdgeos> mhr3_: and?
[16:40] <Saviq> didrocks, yup
[16:40] <Saviq> nic-doffay, nope, sorry
[16:40] <tsdgeos> mhr3_: does that crash or something?
[16:41] <mhr3_> tsdgeos, yes, cause i spawn a thread
[16:41] <tsdgeos> boo
[16:41] <tsdgeos> mhr3_: on module load?
[16:41] <mhr3_> after a timeout
[16:41] <nic-doffay> Saviq, clicking it manually with the mouse causes the tests to pass.
[16:41] <Saviq> dednick, http://pastebin.ubuntu.com/6562236/ no worky :/
[16:41] <nic-doffay> But that's just the same as doing triggerSearch?
[16:42] <tsdgeos> mhr3_: can you delay the spawning until it's really needed? would that help
[16:42] <tsdgeos> ?
[16:42] <Saviq> nic-doffay, would need a deeper look, sorry no can do right now
[16:42] <mhr3_> tsdgeos, it's needed when you instantiate the class :P
[16:42] <Saviq> dednick, and it does end up broken still
[16:42] <tsdgeos> mhr3_: then i think someone should fix qmlpluginloader thingie
[16:44] <tsdgeos> mhr3_: or maybe it even got fixed in 5.2?
[16:44] <Saviq> tsdgeos, mhr3_, we probably should only be running qmlplugindump manually
[16:44] <Saviq> tsdgeos, mhr3_, same as with qdbusxml2cpp
[16:44] <Saviq> stuff like that
[16:44] <mhr3_> Saviq, you mean to put the generated stuff in bzr?
[16:44] <Saviq> mhr3_, yes
[16:44] <mhr3_> yea, that'd work
[16:45] <Saviq> mhr3_, they're not really meant to be ran automagically
[16:45] <tsdgeos> but everyone does :D
[16:45] <dednick> Saviq: :/ i have no idea how that ends as undefined... you can assign null to var surely?
[16:46] <Saviq> dednick, to var, yes - it tries to assign to UnityMenuModel
[16:46] <Saviq> dednick, so that actual error is from UnityMenuAction
[16:46] <dednick> Saviq: it's assigning a undefined to a object pointer..
[16:46] <Saviq> dednick, should be assigning null instead
[16:46] <Saviq> ah it is null
[16:46] <dednick> but it shouldnt be undefined.
[16:47] <Saviq> dednick, something then changes it to undefined
[16:47] <Saviq> dednick, but seems unrelated to the fact that I can still reproduce the issue, though
[16:47] <dednick> yeah
[16:47] <dednick> Saviq: you still have the qmenumodel update on phone right?
[16:49] <Saviq> dednick, hmm
[16:49] <Saviq> dednick, right, I might not have
[16:49] <Saviq> dednick, I probably don't - forgot about this
[16:49] <dednick> *cross fingers*
[16:50] <Saviq> dednick, yeah, that makes sense
[16:50] <Saviq> dednick, that warning, though, would be good to track down anyway
[16:51] <Cimi> mzanetti, ideas?
[16:52] <mzanetti> Cimi: still searching... In Panel/MenuContent.qml there is a fixme which might have influence on this
[16:52]  * Cimi reads
[16:52] <mzanetti> referring to a QTBUG... Which btw waits on input from us
[16:53] <Saviq> dednick, ok, looking good, sorry for the noise
[16:54] <dednick> Saviq: yay! i'll try sort out the warning though
[16:54] <Saviq> dednick, other branch?
[16:54] <Saviq> dednick, or same?
[16:55] <dednick> Saviq: er. give me a few minutes and i might be able to put it in same.
[16:55] <Saviq> dednick, ok
[16:58] <mhr3_> tsdgeos, not much changed in 5.2 for plugindump
[16:58] <tsdgeos> ok
[17:00] <dednick> Saviq: was that in tests it was complaining?
[17:00] <Saviq> dednick, no, when running
[17:00] <mhr3_> Saviq, btw re basename() re-revert, we ok to get it back? or should it wait for the ap to get committed?
[17:00] <Saviq> mhr3_, let's get a test
[17:00] <Saviq> mzanetti, we're not waiting for this, are we ↑?
[17:01] <mhr3_> i'm surprised that it still works though :P
[17:01] <mzanetti> Saviq: waiting for what?
[17:02] <Saviq> mzanetti, the baseName vs. completeBaseName thing
[17:02] <Saviq> mzanetti, in unity-scopes-shell
[17:02] <Saviq> mzanetti, was it cleanup / in-preparation for other things?
[17:02] <dednick> Saviq: no idea. it's not happening for me.
[17:02] <dednick> Saviq: i'll have to fix in another branch
[17:02] <dednick> and test on phone
[17:03] <mzanetti> Saviq: yeah... my new branch needs it and also is meant to clean stuff up.
[17:03] <dednick> Saviq: can you check if it still will connect to network if you select access point?
[17:03] <mzanetti> Saviq: but no. we can get this in now. should not wait for my current branch
[17:04] <cwayne> davidcalle: hey, what happened to the launchpad scope?
[17:04] <Saviq> mzanetti, I know we *can* get it in
[17:04] <Saviq> mzanetti, question was whether we want to wait for ap test
[17:05] <Saviq> mzanetti, and I said yes, as there's nothing pressing us right now to get it in?
[17:05] <mhr3_> Saviq, also json-defaults ;)
[17:05] <mzanetti> ok...
[17:05] <Saviq> mhr3_, yeah, tomorrow
[17:06] <Saviq> dednick, i definitely get "menuModelChanged: undefined" from onMenuModelChanged: console.log("menuModelChanged:", menuModel) in MenuItemFactory
[17:06] <Saviq> dednick, on startup
[17:07] <Saviq> dednick, and on indicator unload
[17:08] <dednick> Saviq: hm, yeah, me too
[17:08] <davidcalle> cwayne, python2
[17:09] <davidcalle> cwayne, tied to the python2 launchpad API
[17:09] <MacSlow> ok, see you folks in a few weeks!
[17:09] <cwayne> davidcalle: ah, is launchpadlb not ported yet?
[17:09] <Saviq> dednick, anyway, doesn't affect functionality
[17:09] <Saviq> dednick, acking
[17:10] <davidcalle> cwayne, I think it's blocked on some other python lib... zope maybe.
[17:10] <cwayne> davidcalle: ah, makes sense, thanks
[17:11] <cwayne> is that a good thing to assume for most of the python ones that havent made it in yet?
[17:12] <dednick> Saviq: give me 2 secs. got it fixed
[17:12] <Saviq> dednick, oh cools
[17:12] <davidcalle> cwayne, most of them, yeah, others reasons are : aggressive scraping, touchy content provider
[17:13] <robru> Saviq, ping about bug 1258655. will it be fixed today? I can land it today if it's fixed in the next 10ish hours.
[17:13] <davidcalle> cwayne, and bad performance (unreliable APIs, slow, etc)
[17:14] <Saviq> robru, kdub is working on that one
[17:14] <Saviq> robru, he's closer to your time zone, so could very well happen
[17:14] <dednick> Saviq: done.
[17:14] <cwayne> davidcalle: yeah, makes sense, do we have like a list or some doc on the status of individual scopes?
[17:14] <robru> Saviq, ok, thanks.
[17:14] <Saviq> robru, bug #1253810 is almost there
[17:14] <robru> kdub, please ping me when it's done
[17:15] <dednick> Saviq: kinda weird though...
[17:15] <davidcalle> cwayne, there is a doc, a bit outdated. There is also this tool, which is not updated either, but is closer to something useful and easy to tweak. http://framli.eu/scopes_browser/index.html?scope=unity-scope-clementine
[17:16] <dednick> i'm guessing the ListView doesnt register a null model as a change when it's already a empty QVariant
[17:17] <Saviq> dednick, right, so you're effectively converting an invalid mainMenu.model into null
[17:17] <Saviq> dednick, it might be that ListView.model will always be undefined, even if you assign null indeed
[17:17] <dednick> Saviq: yeah, it's a bit dodge.
[17:18] <dednick> Saviq: the menuModel should probably just be q QtObject
[17:18] <dednick> Saviq: although same problem at lower level...
[17:18] <Saviq> dednick, yeah
[17:19] <Saviq> robru, FWIW, the Mir bug is not a unity8 one, so those can be released separately
[17:19] <davidcalle> cwayne, updating it right now with a script... but it's been a long time: will probably fail ;)
[17:19] <Saviq> robru, hence marked invalid
[17:19] <cwayne> davidcalle: :)
[17:19] <kdub> robru, okay
[17:20] <Saviq> dednick, probably worth fixing, too:
[17:20] <Saviq> WARNING: ListItems.Standard.icon is DEPRECATED. Use iconName and iconSource instead.
[17:21] <Saviq> dednick, and well:
[17:21] <Saviq> MenuContent.qml:105:21: QML Loader: Binding loop detected for property "indexActive"
[17:21] <Saviq> dednick, indicators are pretty vocal, if you ask me!
[17:21] <Saviq> ;)
[17:23] <dednick> Saviq: yeah, working on that :)
[17:25] <Saviq> ok
[17:25] <Saviq> dednick, thanks for that!
[17:25] <Saviq> /afk
[19:30] <kgunn> Saviq: what mir bug ?
[19:31] <kgunn> > FWIW, the Mir bug is not a unity8 one, so those can be released separately
[19:44] <cwayne> has there been any progress on shipping scopes as click packages?
[20:07] <mhr3> cwayne, not yet
[20:08] <mhr3> cwayne, plus i'd say that primary issue is that there's no design decision on where a scope would be added
[20:08] <cwayne> mhr3: what do you mean?
[20:09] <mhr3> i mean what should happen when you install a scope
[20:09] <mhr3> where does it "go"
[20:11] <cwayne> mhr3: hm, should we get together with design? or should this wait until the api is further along anyway?
[20:11] <mhr3> we brought it up last week
[20:12] <mhr3> so it's on radar
[20:15] <cwayne> mhr3: awesome, thanks for the info :)
[22:11] <Saviq> kgunn, the blanking one on mako
[22:11] <Saviq> kgunn, https://launchpad.net/bugs/1258655
[22:11] <kgunn> ah