[08:53] <dandrader> my indicators (in desktop unity 7) started vanishing from time to time. is there a single command to reload/restart them all?
[08:53] <tsdgeos> dandrader: start unity8 :D
[08:53] <tsdgeos> dandrader: and then ctrl+c it :D
[08:53] <tsdgeos> that's how i get them back
[08:54] <dandrader> tsdgeos, won't that wreak havoc over my open windows? will it kill and restart compiz?
[08:54] <tsdgeos> dandrader: unity8?¿
[08:54] <dandrader> ah, unity8
[08:55] <dandrader> tsdgeos, you have unity8 installed on your desktop?
[08:55] <tsdgeos> dandrader: just ./run in your unity8 self compiled thing
[08:55] <dandrader> ah by "start" you mean running it, not the upstart "start" command :)
[08:55] <tsdgeos> correct
[09:01] <Saviq> morning folks
[09:01] <dandrader> tsdgeos, that's crazy. if you close unity8 as opposed to hitting ctrl+c the indicators disappear again :)
[09:01] <tsdgeos> yep
[09:01] <tsdgeos> well it's unity8 taking them down
[09:01] <tsdgeos> makes some kind of sense if you think about it
[09:01] <Saviq> dandrader, the indicator backend is sending 'stop' to them
[09:02] <Saviq> when closing
[09:03] <dandrader> right
[09:05] <tsdgeos> dandrader: about http://paste.ubuntu.com/6587933/ , sure i could do it, but there's any real benefit? that code pretty much isolated at the end of the function inside an if
[09:05] <dandrader> tsdgeos, just to make VerticalJournal::updatePolish() smaller
[09:06] <dandrader> tsdgeos, smaller functions (that roughly fit in a screen) are easier to read, IMHO
[09:07] <tsdgeos> a function call be called from anywhere
[09:07] <tsdgeos> if it's there
[09:07] <tsdgeos> you don't have to think where it's called from
[09:07] <tsdgeos> it's obvious only happens tehre
[09:07] <tsdgeos> but whatever
[09:07] <tsdgeos> you want a function
[09:07] <tsdgeos> i'll give you a function
[09:10] <tsdgeos> dandrader: any reason you did not make the same comment for the "if (m_needsRelayout) {" block?
[09:16] <tsdgeos> dandrader: also i'd appreciate what is your suggestion to make "qreal columnToAddY = !m_columnVisibleItems[0].isEmpty() ? m_columnVisibleItems[0].last().y() + m_columnVisibleItems[0].last().height() : 0;" sorter since any variant i try looks much less readable in my mind
[09:17] <tsdgeos> i'll add a column variable
[09:17] <tsdgeos> but meh anyway
[09:17] <dandrader> tsdgeos, no. since  updatePolish is back to a pretty reasonable size with the  calculateImplicitHeight() modification, doing the same there is not a must
[09:18] <tsdgeos> dandrader: and any reason you chose calculateImplicitHeight instead of the other block? after all the other block is taller than the calculateImplicitHeight one
[09:19] <dandrader> tsdgeos, no, the overall idea is just to split a big function into small chunks that do only one thing to make the formet big guy more readable
[09:19] <dandrader> tsdgeos, calculateImplicitHeight was just simpler to name :)
[09:19] <tsdgeos> the other one even had a name
[09:20] <tsdgeos> i just never created the functio
[09:20] <tsdgeos> but it was there in the .h
[09:20] <tsdgeos> doRelayout();
[09:21] <dandrader> tsdgeos, you're the victim of me having plenty of time to do code review :)
[09:27] <dandrader> tsdgeos, what those delegateCreationBegin and delegateCreationEnd properties mean exactly (btw, s/Begin/Start as using "begin" as a noun is weird)?
[09:28] <dandrader> seem to be some kind of vertical margin but I still didn't get it
[09:28] <tsdgeos> you should have complained about the name before we distro-patched Qt
[09:29] <tsdgeos> dandrader: it's the range of the height of the view where delegates will be created
[09:30] <tsdgeos> dandrader: becuse your view is 100000 pixels height but inside of a listview that is only 700pixels height you don't need to create delegates for all your height, only for what's visible inside the listview
[09:37]  * dandrader apt-get source qtdeclarative
[09:39] <dandrader> tsdgeos, is there a code review branch to get it upstreamed in gerrit?
[09:40] <tsdgeos> dandrader: not sure what you mean
[09:40] <tsdgeos> ah
[09:40] <tsdgeos> the range stuff?
[09:40] <tsdgeos> no there is not
[09:40] <tsdgeos> it's deemed as not appropiate for upstream
[09:41] <tsdgeos> because upstream listview sucks and has to be rewrriten
[09:41] <tsdgeos> well actually there is one probably
[09:41] <tsdgeos> just rejected
[09:41]  * tsdgeos looks
[09:42] <tsdgeos> yep
[09:42] <tsdgeos> https://codereview.qt-project.org/#change,60809
[09:43] <tsdgeos> dandrader: ↑↑
[09:44] <dandrader> thanks
[09:44] <Saviq> oups... someone blinked with the power plant...
[09:45] <dandrader> tsdgeos, so there's a new list view architecture on the way?
[09:45]  * Saviq does food to save power in case it doesn't come back within the half hour my battery still has in it...
[09:45] <tsdgeos> dandrader: nope
[09:46] <dandrader> " The generic solution for this problem is the new list view architecture"
[09:46] <tsdgeos> yes
[09:47] <tsdgeos> doesn't mean anyone is writing it
[09:47] <tsdgeos> basically he's blocking shit he doesn't want to maintain
[09:47] <dandrader> :)
[09:50] <dednick> mzanetti: howdy
[09:51] <mzanetti> dednick: o/
[09:54] <dednick> mzanetti: hi :) How do I get qmltests run as part of ci for a project?
[09:54] <dednick> mzanetti: specifically ubuntu-settings-components
[09:55] <mzanetti> dednick: they should be run as part of make check normally
[09:55] <dednick> mzanetti: it has a jenkins job already, but the tests arent run automatically. https://jenkins.qa.ubuntu.com/job/ubuntu-settings-components-qmltests-saucy/
[09:55] <dednick> mzanetti: that's only unit tests though no?
[09:56] <mzanetti> dednick: what kind of qmltests are you talking about?
[09:56] <mhr3> Saviq, could you re-look at json-defaults?
[09:56] <dednick> mzanetti: unity8 style
[09:56] <mzanetti> dednick: looking at the console output from here it would suggest the tests are actually running: https://jenkins.qa.ubuntu.com/job/ubuntu-settings-components-qmltests-saucy/6/console
[09:57] <dednick> qmltestrunner
[09:57] <dednick> mzanetti: those were manual starts
[09:57] <mzanetti> what do you mean with manual starts?
[09:58] <dednick> mzanetti: as in i started the job though jenkins, not through a ci job
[09:58] <mzanetti> dednick: ahh... you have that job, but it's not executed as a child of the -ci job yet
[09:58] <dednick> mzanetti: :) yes
[09:59] <mzanetti> dednick: check out lp:cupstream2distro-config
[09:59] <mzanetti> dednick: in there you'll find a config for your project where you can add this job
[10:00] <mzanetti> dednick: stacks/head/sdk.cfg
[10:00] <dandrader> how to I get the network indicator back in my desktop (unity7). indicator-network seems to be for the phone/unity8
[10:01] <mzanetti> dednick: check out stacks/phablet/shell.cfg on how they are added to unity8
[10:01] <dednick> mzanetti: cool. thanks
[10:02] <mzanetti> dednick: once done, propose a merge and ask fginther to deploy the config to the jenkins instance
[10:21] <dednick> Cimi: ping
[10:22] <Saviq> mhr3, yes, on my list for today
[10:24] <Cimi>  dednick pong
[10:25] <dednick> Cimi: hi, can you check out the ubuntu-settings-como
[10:25] <dednick> ponents merge again please?
[10:25] <Cimi> dednick, was checking now
[10:25] <dednick> Cimi: ah, thanks
[10:29] <Cimi> dednick, ok they all pass for me now
[10:30] <dednick> Cimi: awesome
[10:36] <Saviq> tsdgeos, can't find it... what was the new thing that should be used instead of .toLocal8Bit?
[10:36] <tsdgeos> hmmm
[10:36] <tsdgeos> toUtf8() ?
[10:36] <tsdgeos> Saviq: what you trying to do ?
[10:37] <Saviq> tsdgeos, qWarning("Unable to parse category JSON: %s", parseError.errorString().toLocal8Bit().constData());
[10:37] <tsdgeos> qWarning("Unable to parse category JSON: %s", parseError.errorString());
[10:37] <tsdgeos> ?
[10:37] <Saviq> tsdgeos, yeah, the docs aren't really clear on that
[10:37] <tsdgeos> or use the new << form
[10:38] <tsdgeos> qWarning() << "Unable to parse category JSON:" <<  parseError.errorString();
[10:38] <Saviq> tsdgeos, yeah, probably better
[10:38] <Saviq> tsdgeos, the docs for the former say "like printf()", so that indeed suggests you need a char*
[10:39] <tsdgeos> true, i'd say they understand QString but maybe it doesn't
[10:39] <tsdgeos> anyway << is better
[10:39] <Saviq> yup
[10:43] <nic-doffay> Saviq, got a minute to chat about the SF stuff?
[10:44] <Saviq> nic-doffay, yeah, assuming my battery won't die (power outage)
[10:44] <Saviq> nic-doffay, you got some 20 minutes ;)
[10:45] <nic-doffay> Saviq, ok cool. So the stuff in qtubuntu.
[10:45] <nic-doffay> What is reusable?
[10:45] <Saviq> nic-doffay, what do you want to reuse it for?
[10:46] <Saviq> nic-doffay, qtubuntu just needs stripping
[10:46] <Saviq> nic-doffay, i.e. it just has to stop building / installing the Ubuntu.Application module
[10:46] <Saviq> or whatever it's called
[10:47] <nic-doffay> Saviq, ok so none of that code is reused. So nothing inside that qtubuntu folder would be used for the simple shell?
[10:48] <Saviq> nic-doffay, the "simple shell" is just unity8, with its internal fake applications
[10:48] <dandrader> Saviq, are getting internet through the cellular network?
[10:48] <dandrader> are you
[10:48] <Saviq> dandrader, yes
[10:48] <Saviq> nic-doffay, "modules" from http://bazaar.launchpad.net/~phablet-team/qtubuntu/trunk/files/head:/src/ needs to go away
[10:48]  * dandrader recalls the sim card slot in Saviq's laptop
[10:49] <Saviq> dandrader, ha!
[10:49] <nic-doffay> Saviq, so you just want to benchmark unity8 running on the sf?
[10:49] <Saviq> nic-doffay, on either
[10:49] <Saviq> nic-doffay, but benchmarking is somewhat unrelated
[10:50] <Saviq> nic-doffay, there's basically two tasks here: a) drop SF support for app management and b) enable FPS display for *any* backend
[10:50] <Saviq> be it sf, mir or X11
[10:51] <nic-doffay> Saviq, ah ok.
[10:51] <nic-doffay> Saviq, thanks. The latter was what I was in the dark about.
[10:52] <Saviq> nic-doffay, cheers
[10:52] <Saviq> oh there's the battery light blinking now!
[10:52] <nic-doffay> Saviq, good luck with the power too. ;P
[10:52] <Saviq> nic-doffay, bad timing!
[10:52] <nic-doffay> Saviq, haha yeah just saw.
[10:52] <nic-doffay> I'm a lucky charm.
[11:14] <dednick> sil2100: howdy. i need to get a daily release for ubuntu-settings-components.
[11:18] <sil2100> dednick: hello! Ok, does it include anything critical? Could you add it to the Landing Asks?
[11:19] <dednick> sil2100: it's not even used by anything yet. But need to get some changes in before it is.
[11:19] <dednick> sil2100: er, don't think i have write access to asks
[11:21] <sil2100> dednick: ah, like that, so it's a safe upload then - normally your manager should add it to the Landing Asks, but I'll add it right now myself
[11:21] <sil2100> dednick: I'll try to get it out today
[11:21] <dednick> sil2100: thanks.
[11:55] <Saviq> power back up, /me scoots back home
[11:59] <tsdgeos> DBL_MIN is broken
[11:59] <tsdgeos> or am i
[11:59] <tsdgeos> ok
[11:59] <tsdgeos> i am
[11:59] <tsdgeos> DBL_MIN is not the smallest double
[12:00] <tsdgeos> but the smallest double increment
[12:00] <tsdgeos> sad that it is so close to INT_MIN
[12:02] <tsdgeos> ::lowest to the rescue!
[13:03] <dandrader> tsdgeos, I wonder if instead of having this delegateCreation[Begin|End] API you couldn'
[13:04] <dandrader> have something like a "clipDelegatesToParentRect"
[13:04] <dandrader> but I know it's too late to do anything about it
[13:06] <Saviq> dandrader, think it time to move the DDA to UITK yet? toolbar is suffering from not having it: bug #1261719
[13:11] <dandrader> Saviq, hmm, maybe. but there will be quite many changes once the "touch ownership" scheme is in place, which depends on the "qml as mir compositor" work to land.
[13:11] <dandrader> lp:~dandrader/unity8/touchOwnership
[13:13] <Saviq> dandrader, shouldn't be many changes *inside* the gesture recognition itself?
[13:14] <Saviq> tsdgeos, got anything out of more_logs?
[13:17] <dandrader> Saviq, well, that's the diff for the DirectionalDragArea http://goo.gl/bBRvKT. Essentially moving things around
[13:19] <Saviq> dandrader, couldn't that happen before?
[13:19] <Saviq> dandrader, i.e. can we safely split that branch into smaller chunks?
[13:25] <dandrader> Saviq,  technically yes, I could add the new classes but not make use of them. And therefore not update any code to make use of it (like DDA)
[13:25] <dandrader> Saviq, but that intermediate state wouldn't make much sense
[13:25] <Saviq> dandrader, yeah, no
[13:30] <Cimi> mzanetti, where's the cause of the broken binding on tab? did you understand yesterday?
[13:30] <mzanetti> Cimi: ??
[13:30] <Cimi> mzanetti, the bug we were talking friday
[13:31] <mzanetti> yeah. I don't understand the question
[13:31] <mzanetti> I don't know more than you do on that
[13:31] <Cimi> mzanetti, how you reckon to proceed?
[13:31] <Cimi> or how would you debug the binding?
[13:32] <mzanetti> ah
[13:32] <mzanetti> hmm...
[13:32] <Cimi> it's happening on qt 5.2 only iirc
[13:32] <mzanetti> yeah
[13:34] <mzanetti> Cimi: wasn't the issue that we load the tabs somehow delayed which sets width twice and causes the binding loop detection to jump in?
[13:34] <mzanetti> I think the right fix is to change the code in the tabs to be able to deal with it
[13:34] <Cimi> I cannot see any warning about loop
[13:36] <greyback> anyone else tried the qt5.2 ppa on their phone recently? I'm unable to swipe away the greeter now, it's flickering badly
[13:38] <mzanetti> greyback: I've seen this behavior when I just installed the ppa but didn't a clean recompile against qt 5.2
[13:38] <Mirv> mzanetti: I wonder if you could glance what eg.  lp:~kubuntu-packagers/kubuntu-packaging/qtfeedback-opensource-src would require to recompile against Qt 5.2? all the snapshot modules seem to fail with some sort of header inclusion problems (inclusion of headers contained within the own sources), but I don't seem to find what sort of .pro file changes would be required
[13:39] <mzanetti> Mirv: ok. checking it out
[13:39] <greyback> mzanetti: clean compile of unity8?
[13:39] <mzanetti> greyback: yeah
[13:39] <greyback> mzanetti: ok will do that
[13:39] <Mirv> mzanetti: thanks. just bzr branch that and bzr bd if you have 5.2 installed somewhere
[13:39] <mzanetti> ah dammit... I don't
[13:39] <mzanetti> meh...
[13:39] <mzanetti> Mirv: I can't install the packages in parallel to 5.0, right?
[13:40] <Mirv> mzanetti: no you can't, unless of course inside chroot or such (like I do)
[13:40] <mzanetti> mhm
[13:40] <mzanetti> Mirv: mind pasting me the error? if we're lucky it's easy enough so I don't have to go through that now
[13:40] <Mirv> I started with qt3d and now I see I can't build qt3d, qtsystems, qtfeedback or qtpim, but yet again I don't find what upstream did to eg qtconnectivity (which is now officially released) that makes it work
[13:42] <Mirv> mzanetti: I'm getting eg. http://pastebin.ubuntu.com/6588894/
[13:45] <Mirv> mzanetti: the plot thickens in the way that if I get the qtconnectivity snapshot we have from 20130802 I get a similar problem there, so in all likelihood it would be fixed between that date and 5.2.0 in https://qt.gitorious.org/qt/qtconnectivity/commits/
[13:54] <tsdgeos> Saviq: nope :-/
[13:54] <tsdgeos> dandrader: too late and too hard i'd say
[13:54] <Saviq> tsdgeos, :/
[13:55] <tsdgeos> Saviq: i mean, didn't get it to fail
[13:55] <Saviq> tsdgeos, right
[13:55] <tsdgeos> failed once
[13:55] <tsdgeos> but a different
[13:55] <tsdgeos>  one
[13:55] <Saviq> raacieeees, where are you?
[13:58] <tsdgeos> damn now it failed in my verticalJournal one :D
[13:58] <tsdgeos> grrr
[13:58] <tsdgeos> let's trigger the more_logs
[13:58] <Mirv> mzanetti: actually, it looks like the release tarballs would have a whole "include" directory with a lot of one line include files referring various sources in the source tree.. I wonder what generates that
[13:59] <tsdgeos> Mirv: sync.profile i think
[14:03] <Mirv> I really need to continue tomorrow, but maybe sync.profile/syncqt could be / should be used somehow with the snapshot modules unlike before
[14:31] <greyback> Saviq: standup?
[14:33] <Saviq> my mumble hangs
[14:33] <Saviq> on startup..
[14:33] <greyback> Saviq: we see you connect
[14:33] <Saviq> greyback, yeah, and then it goes B&W
[14:33] <Saviq> greyback, just go on without me
[14:34] <greyback> Saviq: we are
[14:45]  * greyback needs to reboot
[14:55] <fginther> dednick_, pong ?
[14:59] <mzanetti> fginther: hi.
[15:00]  * mzanetti searches for dednick's branch
[15:00] <dednick_> mzanetti: doesnt exist yet.
[15:01] <mzanetti> ah ok
[15:01] <dednick_> didnt know how. all a  bit confusing
[15:01] <mzanetti> yeah well, I'm sure fginther is helpful there :)
[15:01] <dednick_> fginther: trying to get ubuntu-settings-components qml tests to run during ci.
[15:02] <fginther> dednick_, I can help, what needs doing?
[15:02] <fginther> dednick_, can they run during the package build?
[15:03] <mzanetti> fginther: its the same as the unity8-qmluitests job
[15:03] <dednick_> fginther: they have mouse interaction, is that ok?
[15:05] <dednick_> fginther, mzanetti: i know that ubuntu-ui-toolkit checks if the DISPLAY variable is set when doing package tests and runs qml tests if it is. But they are pretty simple tests, so i wasn't sure if it was the same
[15:05] <mzanetti> fginther: it's just about hooking this one up into the settings-components-ci jobs: https://jenkins.qa.ubuntu.com/job/ubuntu-settings-components-qmltests-saucy/
[15:06] <fginther> mzanetti, dednick_, ah, if there's already a job for this, then it's just a config change to add
[15:07] <fginther> mzanetti, is that really a 'saucy' job or does it need to be updated to trusty?
[15:07] <mzanetti> fginther: yeah... actually I though we'd have a c2d-config merge prepared already and you'd just need to deploy... but no. the config needs to be touched still
[15:07] <mzanetti> I'd say upgrade to trusty
[15:07] <fginther> mzanetti, I can help with that
[15:15] <fginther> dednick_, mzanetti https://code.launchpad.net/~fginther/cupstream2distro-config/ubuntu-settings-components-qmltests/+merge/199302
[15:16] <mzanetti> fginther: thanks a lot
[15:16] <tedg> greyback, Did you see my ping last night?
[15:24] <tsdgeos> dandrader: damn now that i see, we don't support adding/removing items from the model either :D
[15:25] <tsdgeos> even if it's only at the end
[15:25] <tsdgeos> dandrader: would you be satistied with something that creates a random number of items of random height?
[15:25] <tsdgeos> dandrader: because i'm not sure it makes sense adding support to adding/removing items when it's not on scope
[15:25] <tsdgeos> Saviq: it's not on scope, right?
[15:27] <Saviq> tsdgeos, initially we can say the scopes will only fill the model from the beginning to the end
[15:27] <Saviq> tsdgeos, I *thinkU
[15:27] <Saviq> mhr3, ↑↑?
[15:27] <Saviq> mhr3, can/will scopes fill the model non-linearly?
[15:28] <sil2100> Saviq: hi! Is there a lot of risky changes in unity8 waiting for release?
[15:28] <Saviq> sil2100, shouldn't be, no
[15:28] <Saviq> sil2100, let me check
[15:28] <mhr3> Saviq, well, when we do resultset diffs, it'll look like it's non-linear to the listview, right?
[15:29] <sil2100> Saviq: since I would really love that AP-test change released, and maybe we could release everything
[15:29] <Saviq> sil2100, is safe
[15:29] <mhr3> Saviq, but without diffing, it's always append-only
[15:29] <Saviq> mhr3, when is "when"?
[15:30] <sil2100> Saviq: could you or kgunn add a landing asks if you have a moment related to this? :)
[15:30] <mhr3> Saviq, when we'll decide we need it :)
[15:30] <Saviq> sil2100, doing
[15:30] <tsdgeos> ok, so append only?
[15:30] <tsdgeos> mhr3: no modelReset()  either?
[15:30] <dandrader> tsdgeos, you mean that after creation the number of items in the model cannot change, they can only grow or shrink in size?
[15:31] <Saviq> sil2100, done
[15:31] <mhr3> tsdgeos, no guarantees on reset, you should support it
[15:31] <tsdgeos> well, that's more work that wasn't anticipated :D
[15:31] <tsdgeos> i should support lots of stuff
[15:31] <mhr3> tsdgeos, the only guarantee i'm giving is that there'll be no insert-in-middle
[15:32] <tsdgeos> but there's the things that will happen and the ones that wont
[15:32] <tsdgeos> ok then
[15:32] <tsdgeos> dandrader: so it'll take a bit more :D
[15:32] <mhr3> tsdgeos, well reset should be the easiest
[15:33] <tsdgeos> mhr3: sure, but non caring is even easier ;-)
[15:33] <mhr3> tsdgeos, and lazy :P
[15:33] <tsdgeos> let's call it time efficient
[15:33] <mhr3> right :)
[15:34] <mhr3> tsdgeos, but the diffing is likely to happen in february
[15:36] <mhr3> Saviq, so, annotations, how do you want them?
[15:37] <mhr3> separate model in each category?
[15:42] <dednick_> fginther: thanks
[15:44] <greyback> tedg: back. I saw you found a 65ms delay for authorizing sessions in unity-mir. I've not profiled to see why it's slow, could you open a bug on it please?
[15:44] <kgunn> greyback: so, once the shell attached show/hide...its the app A that actually "asks" for the shells' animation of that ?...or is app A actually doing all of the drawing within his own context ?
[15:45] <tedg> greyback, Sure, can do.  I was more pinging to see if it was something that was "bug worthy" :-)
[15:46] <greyback> kgunn: the shell will animate the app's surface (e.g. the split and open animation)
[15:46] <greyback> kgunn: Shell may also in future need to pass a "animationProgress" value to the app, as it looks like the app's toolbar itself will visually change during this animation. But that's later
[15:46] <kgunn> greyback: cool...makes sense
[15:47] <kgunn> greyback: last one...so the cookie fmt, is that something that comes via papi ?
[15:47] <tedg> greyback, bug 1261801
[15:49] <greyback> tedg: thanks
[15:59] <greyback> kgunn: papi will gain a open_trusted_helper("contentPicker") function. Internally it will receive a cookie from the contentPicker and tags its surface with that cookie.
[16:00] <kgunn> greyback: got it, so in reality the apps really aren't aware of the cookies or surface handling
[16:00] <greyback> kgunn: yep, they'll have no idea
[16:05] <kgunn> greyback: ok...me likie now
[16:19] <Saviq> mhr3, hey, why ResultsModel::componentValueWithFallback?
[16:21] <mhr3> Saviq, cause result->title() != result->metadata("title")
[16:22] <Saviq> mhr3, why?
[16:22] <Saviq> mhr3, neither are mandatory, why do we treat them differently?
[16:22] <mhr3> cause it's "standard attribute"
[16:22] <Saviq> mhr3, bleh, they're all standard ;P
[16:23] <mhr3> the api is trying to do some basic stuff very easy for the devs
[16:23] <mhr3> so title is kinda mandatory, but not really...
[16:23] <mhr3> meh
[16:24] <Saviq> mhr3, yeah exactly ;)
[16:24] <mhr3> pstolowski, maybe that should be changed really
[16:24] <mhr3> pstolowski, at least it'll be consistent with the [] operator
[16:24] <Saviq> mhr3, pstolowski, that can suggest to people they can't get a result with no title or art
[16:26] <mhr3> the exception that was thrown suggested that quite strongly :)
[16:26] <mhr3> but we got rid of that
[16:27]  * Saviq says: we shouldn't treat any of the fields in any special way
[16:27] <Saviq> mhr3, especially since people may want to use a different "title" field
[16:27] <Saviq> like "name" for contacts
[16:28] <pstolowski> Saviq, we wanted to have an minimal api for at least "generic" uses cases
[16:28] <mhr3> Saviq, yea, trust me things are already loosened up quite a lot :)
[16:29] <Saviq> pstolowski, even so, that should not "pass through" to the shell side
[16:29] <Saviq> pstolowski, and should not really be the default, I'd say
[16:32] <fginther> dednick_, ubuntu-settings-components-qmltests-trusty is all ready to go now, the next MP should execute it
[16:32] <dednick_> fginther: cool. thanks for that
[16:33] <pstolowski> Saviq, mhr3 there is currently a discrepancy between the outcome of result.add_metadata("title", "foo") and results["title"] = "foo". I think this needs fixing. BUT the former would throw on scope side when passing it to the shell, so I'm not sure what's the error you see
[16:34] <pstolowski> Saviq, what do you mean
[16:34] <pstolowski> Saviq, 'should not really be the default' ?
[16:34] <mhr3> pstolowski, result->title() != result->metadata("title")
[16:34] <pstolowski> mhr3, yes, I know
[16:35] <mhr3> that's what spawned the question in the first place
[16:35] <pstolowski> mhr3, that boils down to the discrepancy I mentioned
[16:35] <Saviq> yeah, let's get rid of result-> title :)
[16:35] <Saviq> done
[16:35] <Saviq> and result->art
[16:35] <Saviq> pstolowski, I mean that there may be wrappers around the basic API
[16:35] <mhr3> pstolowski, why do we even have the add_metadata() method?
[16:36] <Saviq> pstolowski, that would simplify things in "the general case", but their impl detail should not leak to the shell side
[16:36] <Saviq> mhr3, pstolowski, shouldn't metadata be something that's not actually the data that's displayed?
[16:37] <pstolowski> mhr3, that was added in the beginning when we were thinking in terms of 'standard' attributes and any custom attributes
[16:38] <mhr3> i hate doing changes to this, but let's finalize it
[16:39] <mhr3> and break the api once again
[16:40] <pstolowski> I'd say, let's leave title / art wrappers in the API for basic cases, but remove add_metadata or fix it to just do what [] does
[16:41] <pstolowski> albeit "add_metadata" name is a bit misleading
[16:41] <mhr3> +1 for removing add_metadata
[16:41] <mhr3> and perhaps metadata() too
[16:42] <mhr3> or at least renaming it
[16:42] <mhr3> .value()
[16:44] <Saviq> mhr3, https://code.launchpad.net/~mhr3/unity-scopes-shell/component-mapping/+merge/198807/comments/462713
[16:49] <mhr3_> pstolowski, eh, internet blackout, any comments after .value()?
 mhr3, https://code.launchpad.net/~mhr3/unity-scopes-shell/component-mapping/+merge/198807/comments/462713
[16:50] <pstolowski> mhr3_, i'm fine with it, will do the change
[16:56] <Saviq> pstolowski, I think it makes perfect sense for you to provide convenience wrappers
[16:56] <Saviq> pstolowski, like SongResult()
[16:56] <Saviq> pstolowski, etc.
[16:56] <Saviq> pstolowski, but that should not leak to shell side I think
[16:56] <Saviq> especially since that would mean we need to start thinking about versioning the protocol
[17:07] <pstolowski> ack
[17:44] <kdub_> ls
[22:48] <Saviq> robru, the unity8 flakiness already has a bug: #1260860
[22:48] <robru> Saviq, it's ok, we can merge them later. right now I'm just trying to recreate the ugly spreadsheet as closely as possible, with fresh bugs
[22:49] <Saviq> robru, ok