[08:01] <MacSlow> Greetings folks!
[08:01]  * greyback waves from Cape Town
[08:01] <MacSlow> greyback, enjoying the sun? :)
[08:02] <greyback> MacSlow: yep, it's warm & sunny. We're inside working hard however
[08:03] <MacSlow> greyback, I know :)
[08:03] <greyback> MacSlow: welcome back. Have a good holiday?
[08:04] <MacSlow> greyback, thanks... basically yes... but my moving-plans didn't work out as planned... so it's a bit of a mixed bag :)
[08:04] <greyback> MacSlow: ah, I wasn't aware you were planning to move. Same city? Same country? :)
[08:05] <MacSlow> same city... but now after more than seven weeks still no i-net in the new flat :/
[08:05] <kgunn> MacSlow: you surface...welcome back
[08:05] <MacSlow> kgunn, thanks
[08:09] <tsdgeos> guys
[08:10] <tsdgeos> are you having scoperegistry at 100% too?
[08:10] <MacSlow> hey tsdgeos
[08:10] <tsdgeos> MacSlow: welcome back
[08:10] <MacSlow> tsdgeos, thanks
[08:17] <tsdgeos> MacSlow: have you dist-upgaded? can you reproduce the cpu usage of scoperegistry being at 100% all the time?
[08:19] <MacSlow> tsdgeos, just doing all the updating right now... I'll report back if I see that too here
[08:20] <MacSlow> tsdgeos, getting > 1GBytes work of updates :)
[08:20] <tsdgeos> lol
[08:21] <MacSlow> tsdgeos, typical for a frist day after holiday :)
[08:27] <tsdgeos> pstolowski: hi ho, can you reproduce the cpu usage of scoperegistry being at 100% all the time?
[08:30] <pstolowski> tsdgeos, hi! i don
[08:31] <tsdgeos> missing 't or extra n?
[08:31] <tsdgeos> :D
[08:31] <pstolowski> tsdgeos, i don't have the full setup with unity8 atm, so I can't right now
[08:31] <tsdgeos> pstolowski: this is on the desktop
[08:31] <tsdgeos> happens both in unity7 and kde
[08:31] <tsdgeos> s/kde/plasma
[08:31] <tsdgeos> D:
[08:31] <pstolowski> tsdgeos, ah, so it's not when real client talks to it?
[08:32] <tsdgeos> i haven't tried starting unity8 tbh
[08:32] <tsdgeos> let me see if that makes it happy
[08:32] <pstolowski> tsdgeos, ok, I'll take a look and let you know
[08:35] <tsdgeos> unity8 is segfaulting now :-S
[08:35] <tsdgeos> come on!
[08:37] <tsdgeos> hmmm
[08:37] <tsdgeos> i have http://ppa.launchpad.net/unity-team/demo-stuff/ubuntu/
[08:38]  * tsdgeos bets something went wrong in there
[08:43] <sil2100> jamesh: hi! Just a note - when testing mediascanner2 on Friday, I noticed that it was using far more CPU than mediascanner
[08:43] <jamesh> sil2100: in general use, or when idle?
[08:43] <jamesh> I mean, when scanning or when idle?
[08:44] <sil2100> jamesh: I guess that when it was idle as well, top was mentioning a 3-4% CPU usage all the time, and my phone strangely started generating more heat then usually on idle
[08:44] <jamesh> sil2100: okay.  I'll take a look.
[08:45] <sil2100> jamesh: thanks
[08:46] <tsdgeos> pstolowski: MacSlow: purging ppa:unity-team/demo-stuff from my system made stuff go back to normal
[08:46] <MacSlow> tsdgeos, thanks for the hint!
[08:47] <pstolowski> tsdgeos, ok. i'm not using this ppa atm
[08:47] <tsdgeos> i was because i was told it was needed for the new scopes to work or something
[08:47] <tsdgeos> but may have changed
[08:47] <tsdgeos> let's see if the capetown people show up and we can ask them
[08:49] <pstolowski> tsdgeos, don't get me wrong, this ppa is ok and the way to go. but perhaps something broke there
[08:51] <jamesh> sil2100: out of interest, if you stop the upstart job and run mediascanner-service-2.0 from a terminal, do you see the same CPU usage problems?
[08:52] <sil2100> jamesh: will check a bit later, I just clean-flashed my device with the newest image
[08:52] <jamesh> sil2100: thanks
[08:52] <sil2100> jamesh: but I only tried running mediascanner through upstart on Friday, so no direct-launching
[08:53] <jamesh> sil2100: yep.  I've done most of my testing from a terminal, so I was wondering if the different environment triggers the problem.
[08:54] <jamesh> I'll test it out myself, but thought I'd mention it up front as a possibility.
[09:34] <pstolowski> tsdgeos, I can confirm 100% cpu with scoperegistry in trunk
[09:34] <tsdgeos> cool, tx
[09:45] <didrocks> hey Saviq
[09:45] <didrocks> Saviq: we have 2 reliable autopilot tests failures on unity8 since Friday evening
[09:45] <didrocks> happened on the 4 images produced on mako
[09:46] <didrocks> http://ci.ubuntu.com/smokeng/trusty/touch/mako/125:20140113:20140107.1/6032/unity8-autopilot/ on the last run for instance
[09:47] <Saviq> mzanetti, can you have a look please ↑
[09:48] <Saviq> mzanetti, or delegate at least
[09:48] <Saviq> didrocks, can you get us a list of packages that changed? u8 wasn't released for a few weeks now
[09:48] <didrocks> sure, one sec
[09:49] <didrocks> Saviq: /!\ the list is big, but it seems mostly gstreamer related
[09:49] <didrocks> (opencv)
[09:49] <didrocks> Saviq: it started with those changes: http://people.canonical.com/~ogra/touch-image-stats/20140110.1.changes
[09:49] <didrocks> I don't see anything striking me though
[09:50] <didrocks> as you are not using python3-autopilot I guess
[09:53] <Saviq> didrocks, yeah, not yet
[09:53] <didrocks> Saviq: keep us posted, we are not promoting any image before having your expertise on what regressed (if it's a real issue) you
[09:56] <Saviq> didrocks, will do, running the suite on my mako now
[09:57] <didrocks> thx!
[10:02] <Saviq> tsdgeos, mzanetti, bug #1268525 btw
[10:02] <Saviq> we  got FTBFS
[10:03] <tsdgeos> booo
[10:07] <tsdgeos> Saviq: do you want us to fix it *now* or can we wait for mterry?
[10:15] <Saviq> tsdgeos, it can wait, just making you aware
[10:15] <tsdgeos> okidoki
[10:22] <dednick> Saviq: what's USC in terms of unity/mir?
[10:25] <anpok> unity system compositor
[10:25] <tsdgeos> E_TOO_MANY_ACRONYMS
[10:25] <anpok> :)
[10:27] <tsdgeos> dednick: can you review https://code.launchpad.net/~allanlesage/unity8/autopilot-indicator-page-title-matches-widget/+merge/196991 ? seems your name is in there :D
[10:27] <dednick> ahha, yeah, that would make sense
[10:28] <dednick> tsdgeos: ok
[10:35] <tsdgeos> dednick: since the running of autopilots seems to be borked on the CI at the moment please make sure you run the whole autopilot suite and it succeeds for you
[10:36] <Saviq> pete-woods, any idea how https://errors.ubuntu.com/problem/5eef1d661e41b06e44728924231b45e26457dbb7 could be happening?
[10:38] <Saviq> greyback, https://errors.ubuntu.com/oops/86923190-7b60-11e3-978e-2c768aafd08c ideas about this stacktrace?
[10:38] <pete-woods> Saviq: that's weird, there hasn't been a new release of libusermetrics in quite a while
[10:39] <Saviq> pete-woods, well, we might have never seen that, simply - whoopsie upload got enabled on the phones very recently
[10:39] <Saviq> tsdgeos, we saw https://errors.ubuntu.com/problem/06fd8687e02be79bfdb8ed6a820caf9f727581ed before didn't we?
[10:40]  * tsdgeos clicks
[10:40] <greyback> Saviq: never seen that before. Nothing obvious comes to mind
[10:40] <tsdgeos> yes
[10:40] <tsdgeos> i do remember that
[10:40] <tsdgeos> was a total red herring
[10:41] <tsdgeos> got fixed by just making the shutdown stuff happen correctly
[10:41] <tsdgeos> is it back?
[10:41] <tsdgeos> seems so
[10:41] <Saviq> tsdgeos, last example is January 2
[10:41] <tsdgeos> well we never made shutdown really work well
[10:41] <Saviq> tsdgeos, https://errors.ubuntu.com/oops/a339c5de-742a-11e3-893e-e4115b0f8a4a
[10:42] <Saviq> didrocks, it's python-gi/python-gobject
[10:42] <Saviq> mzanetti, you're off the hook for the ap failure
[10:43] <didrocks> Saviq: do you have more infos that we can share with pitti?
[10:43] <didrocks> (maybe on #ubuntu-touch?)
[10:43] <mzanetti> Saviq: thanks
[10:43] <tsdgeos> Saviq: yeah it's one of the multiple "we still don't shutdown correctly all the time" crashes
[10:43] <tsdgeos> Saviq: do we want to put more effor in getting that fixed now?
[10:45] <didrocks> Saviq: ah, or the issue is in the test itself and the warning is triggering an issue?
[10:46] <tsdgeos> dednick: you have a few branches up for review, want me to tackle some of those? or you have someone in mind to check them?
[10:46] <didrocks> Saviq: the commit is https://git.gnome.org/browse/pygobject/commit/?id=7193f050
[10:47] <didrocks> Saviq: I guess you have an implicit type conversion in your test?
[10:47] <dednick> tsdgeos: be my guest!
[10:48] <Saviq> didrocks, here's the failing thing: http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/tests/autopilot/unity8/shell/tests/test_notifications.py#L291
[10:49] <didrocks> nothing shocking on first look
[10:50] <Saviq> didrocks, but it might actually be the script that's failing
[10:50] <didrocks> Saviq: that sounds more plausible
[10:51] <Saviq> didrocks, I'm digging more
[10:51] <didrocks> thanks! good hunt :)
[10:55] <tsdgeos> dednick: how does https://code.launchpad.net/~nick-dedekind/unity8/lp1264678-indicator.misalignment/+merge/200866 relate to https://bugs.launchpad.net/ubuntu-ux/+bug/1253804 and https://code.launchpad.net/~fboucault/ubuntu-ui-toolkit/fix_tabs_ordering ?
[10:56] <tsdgeos> are they both fixing the same? or is it different issues that trigger a similar problem?
[10:57] <dednick> tsdgeos: hm... looks like it, but the mp for that bug doesnt seem to be the same.
[10:58] <tsdgeos> dednick: two questions
[10:58] <tsdgeos> dednick: can you reproduce the errror somehow? and is that something we can unittest?
[11:01] <dednick> tsdgeos: yeah, give me a minute and i'll work out the steps. I'll have to investigate possible unit test, only happens under certain circumstance
[11:02] <tsdgeos> dednick: oki, it'd be cool if we could get a unittest
[11:03] <tsdgeos> to proof the code indeed fixes something, since the change seems mostly a code shuffling to my untrained eye
[11:03] <tsdgeos> dednick: maybe explain in the commit log why this shuffling actually fixes it?
[11:03] <dednick> tsdgeos: essentially the fix is 116-118 :)
[11:04] <tsdgeos> ah
[11:11] <tsdgeos> dednick: looking at 116-118 don't you think this is something that should be fixed at the Tabs level?
[11:11] <tsdgeos> i mean if the model changes the Tabs should react to it automatically, don't see why you should tell it to update
[11:11] <dednick> tsdgeos: no, it's to do with the filtermodel data changing because of an indicator visiblity change.
[11:12] <tsdgeos> but still
[11:12] <tsdgeos> you have
[11:12] <tsdgeos> model: filteredIndicators
[11:12] <tsdgeos> why doesn't Tabs update itself?
[11:12] <tsdgeos> though i see you're using the "old" Tabs
[11:12] <tsdgeos> you can feed it a model now instead all those weird Tabs thing
[11:13] <tsdgeos> i guess the old tabs as not very good
[11:13] <dednick> tsdgeos: it's because of this line: readonly property int currentMenuIndex : filteredIndicators.mapToSource(tabs.selectedTabIndex)
[11:13] <dednick> the currentMenuIndex needs to change when the visibility of an item with a lower index changes.
[11:15] <tsdgeos> dednick: still not convicing me :D
[11:15] <dednick> tsdgeos: hm
[11:15] <tsdgeos> sure i agree that has to update
[11:15] <tsdgeos> ahh
[11:15] <tsdgeos> or maybe yes
[11:15]  * tsdgeos looks at it again
[11:15] <dednick> tsdgeos: actually, i've unconviced myself now..
[11:16] <dednick> *unconvinced
[11:16] <dednick> not that it's a word..
[11:17] <dednick> tsdgeos: while this way works, it's a bit roundabout and not very efficient
[11:18] <tsdgeos> i got it now
[11:18] <tsdgeos> it's not that you want selectedTabIndex to "change", it's that you want currentMenuIndex to get updated
[11:18] <tsdgeos> right?
[11:19] <dednick> tsdgeos: yeah
[11:21] <dednick> tsdgeos: but i think IndicatorRow should probably be doing the updating and notifying the MenuContent.
[11:21] <tsdgeos> dednick: you lost me there :D
[11:25] <tsdgeos> dednick: so i get you're reworking it?
[11:26] <dednick> tsdgeos: investigating it :) i'll try work on a unit test as well
[11:26] <tsdgeos> cool!
[11:39] <tsdgeos> dednick: i can't reproduce https://bugreports.qt-project.org/browse/QTBUG-34351 with my self compiled 5.2.1
[11:39] <tsdgeos> dednick: what were you using? ppa 5.2.? can you try again?
[11:40] <dednick> tsdgeos: i'm back on 5.0.2 now
[11:40] <tsdgeos> ok
[11:40] <tsdgeos> let's put a reminder then :D
[11:41] <dednick> tsdgeos: when did 5.2.1 become available? Saviq tried with 5.2 before i think
[11:42] <tsdgeos> dednick: it did not, i'm compiling from git
[11:42] <dednick> tsdgeos: ok
[11:44] <dednick> hmm. damn, cant remember how to reproduce this damn bug
[11:57] <tsdgeos> :/
[11:57] <tsdgeos> dednick: you have lots of  enabled: menuData && menuData.sensitive || false that could just be  enabled: menuData && menuData.sensitive
[11:57] <tsdgeos> no
[11:57] <tsdgeos> ?
[11:59] <dednick> umm... maybe? not really sure about the qml && evaluation. Saviq told me to use the || ,  although that may have been for string and such.
[11:59] <dednick> tsdgeos: is it actually documented somewher?
[11:59] <tsdgeos> dednick: for a string makes sense, but for a bool?
[12:00] <tsdgeos> i mean you are doing bool || false
[12:00] <tsdgeos> which is always the first bool, no?
[12:01] <tsdgeos> anyway doesn't hurt either
[12:01] <tsdgeos> so if it works
[12:01] <tsdgeos> let leave it there :D
[12:01] <dednick> :)
[12:26] <tsdgeos> hmmm
[12:26] <tsdgeos> what's causing https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/900/console ?
[12:27] <Saviq> greyback, ideas ↑? something changed in mir's headers?
[12:28] <greyback> looking
[12:29] <tsdgeos> and why it works for me
[12:31] <greyback> ricmm_: https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/900/console
[12:36] <tsdgeos> what's libunity-mir-dev 0.2+14.04.20140108.1bzr168pkg0trusty0-0ubuntu1  ?
[12:36] <tsdgeos> unity-mir only has 162 revs
[12:36] <tsdgeos> ¿?
[12:37] <tsdgeos> greyback: i repeat
 what's libunity-mir-dev 0.2+14.04.20140108.1bzr168pkg0trusty0-0ubuntu1  ?
 unity-mir only has 162 revs
 ¿?
[12:38] <greyback> tsdgeos: sorry, network here dodgy
[12:38] <greyback> tsdgeos: that's a mystery to me
[12:38] <tsdgeos> it's coming from somehwre called  http://naartjie/archive//head.unity8/
[12:39] <tsdgeos> fginther: do you know what's that ↑ ?
[12:39] <tsdgeos> Saviq: ↑ ?
[12:39] <greyback> tsdgeos: so hte path /usr/include/mirserver is missing as a header include path, seeing why
[12:39] <tsdgeos> greyback: my current thinking is that somehow that unity-mir package is picking up the cmake stuff from tvoss and it's broken because of that
[12:40] <tsdgeos> but i'd like to know what that bzr168 mean
[12:40] <tsdgeos> s
[12:40] <greyback> tsdgeos: that's my suspicion yeah.
[12:43] <Saviq> tsdgeos, that's a local archive that's built when autolanding unity-mir
[12:43] <tsdgeos> Saviq: any idea why the bzr rev is off?
[12:43] <Saviq> tsdgeos, it's a per-stack (hence head.unity8) - all packages that are built in -autolanding jobs get put there
[12:44] <tsdgeos> ahhhh
[12:44] <Saviq> tsdgeos, good question, it should be 162
[12:44] <tsdgeos> so basically the cmake port broke unity-mir it seems :D
[12:44] <tsdgeos> bad us all for not anticipating it
[12:48] <Saviq> tsdgeos, so cmake's not installing that header?
[12:48] <tsdgeos> Saviq: i think the problem is that the pkg config of old unity-mir included more includepaths than the new one
[12:48] <tsdgeos> checking
[12:49] <Saviq> tsdgeos, ah possible
[12:50] <tsdgeos> yepp
[12:50] <tsdgeos> the
[12:50] <tsdgeos> Requires: ubuntu-platform-api mirclient mirserver Qt5Core
[12:50] <tsdgeos> is gone
[12:51] <tsdgeos> which most probably causes that include stuff missing
[12:53] <tsdgeos> Saviq: greyback: https://code.launchpad.net/~aacid/unity-mir/requires_pkg/+merge/201385
[12:54] <greyback> tsdgeos: heh, beat me to it :)
[12:54] <tsdgeos> and now
[12:54] <tsdgeos> food!
[13:01] <greyback> tsdgeos: approved
[13:28] <Saviq> Cimi, ping
[13:28] <Cimi> Saviq, pong
[14:10] <tsdgeos> Saviq: i'll continue landing stuff manually while otto is borked
[14:10] <Saviq> tsdgeos, yup
[14:10] <tsdgeos> mterry: hi ho, make sure you have a look at the bug Saviq assigned you
[14:10] <Saviq> tsdgeos, you know how to kick generic-land?
[14:10] <tsdgeos> Saviq: not really, i was planning of just doing it manually :D
[14:11] <tsdgeos> Saviq: but if there's a better way, i'm all ears
[14:11] <Saviq> mterry, bug #1268525
[14:12] <Saviq> tsdgeos, you find the autolanding job that failed: http://s-jenkins.ubuntu-ci:8080/job/unity8-autolanding/933/console
[14:12] <Saviq> tsdgeos, and you restart the generic-land job: http://s-jenkins.ubuntu-ci:8080/job/generic-land/21153/rebuild/?
[14:12] <Saviq> tsdgeos, approve the branch first
[14:12] <Saviq> tsdgeos, and then change FAILED to PASSED when restarting the job
[14:13] <tsdgeos> ok, letme see if i can do it :D
[14:14] <mterry> tsdgeos, Saviq: that should be fine.  We don't actually link against liblightdm-qt5 yet.  Not until we split
[14:14] <mterry> tsdgeos, Saviq: we just staticly link against the fake -2 version we make
[14:14] <Saviq> mterry, hmm right
[14:15] <Saviq> mterry, somehow I can't build it on device because of that :?
[14:15] <mterry> Saviq, alright looking
[14:21] <didrocks> Saviq: any news on the test failing? (Didn't get a chance to read scrollback)
[14:22] <Saviq> didrocks, pitti's filed a bug upstream
[14:22] <didrocks> Saviq: do you have the ref?
[14:22] <Saviq> didrocks, bug #1268578
[14:22] <Saviq> didrocks, and there's a workaround
[14:22] <didrocks> Saviq: do you plan to implement the workaround?
[14:23] <Saviq> didrocks, yeah, doing so now
[14:24] <didrocks> thanks!
[14:24] <didrocks> then, please put a landing ask for unity8 if good
[14:26] <mzanetti> MacSlow: hey, you're back
[14:26] <MacSlow> mzanetti, yup
[14:26] <Saviq> didrocks, tsdgeos, https://code.launchpad.net/~saviq/unity8/workaround-1268578/+merge/201420
[14:26] <Saviq> MacSlow, welcome back!
[14:27] <mzanetti> MacSlow: welcome back
[14:27] <MacSlow> mzanetti, but still burried in catch-up on everything :)
[14:27] <MacSlow> Saviq, thanks :)
[14:27] <MacSlow> let's see if mumble still works ;)
[14:27] <mzanetti> MacSlow: I guess so... I received 123 mails in the last 4 hours... don't wanna know how many there are after 4 weeks :D
[14:27] <MacSlow> mzanetti, more than I feel is healthy ;)
[14:30] <tsdgeos> Saviq: you joning?
[14:30] <tsdgeos> greyback: ↑  ?
[14:31] <Saviq> tsdgeos, not really
[14:31] <tsdgeos> okidoki
[14:37] <greyback> tsdgeos: ah ok, it's the sidestage code causing this problem, not trunk
[14:41] <tsdgeos> good! (or not)
[14:41] <tsdgeos> :D
[14:46] <Saviq> mterry, http://pastebin.ubuntu.com/6744944/
[14:46] <Saviq> mterry, the failure on device U
[14:46] <Saviq> -U
[14:56] <didrocks> Saviq: ok, so no need for unity8 workaround I guess for now
[15:16] <fginther> tsdgeos, regarding libunity-mir-dev 0.2+14.04.20140108.1bzr168pkg0trusty0-0ubuntu1. The bzr version is based on the MP being merged, so it can be higher then the trunk branch. The package in the naartjie archive is also built from the last MP that passed autolanding (so the latest builds always replaces the last one regardless of the version number).
[15:16] <fginther> tsdgeos, This number is at least misleading, I'll see if I can find a way to improve it.
[15:17] <tsdgeos> fginther: that'd help, now that the number did not exist one could guess it was the latest, but if the number had existed one could have assumed the wrong code was in there
[15:18] <fginther> tsdgeos, I agree, it's a recipe for disaster
[15:20] <mterry> Saviq, I just build unity8 fresh on mako with debuild fine
[16:08] <tsdgeos> dandrader: do you have a sec?
[16:16] <dandrader> tsdgeos, yes
[16:16] <tsdgeos> dandrader: so i'm doing the organicgrid
[16:17] <tsdgeos> and since it's mostly "lineal" i'm doing the same deal of storing the m_firstVisibleIndex and a list of QList<QQuickItem*>
[16:17] <tsdgeos> now the thing is that due to the ordering inside a 6-module of the indexes
[16:18] <tsdgeos> when i'm going down in index number to find which index is not visible anymore
[16:18] <tsdgeos> it may happen that the index 4 of the "6-module" is not visible but the index 5 is
[16:18] <tsdgeos> see the UX spec for the positioning
[16:19] <tsdgeos> so i was thinking that maybe i should create the delegates in the modules of 6
[16:19] <tsdgeos> and not individually
[16:19] <tsdgeos> what do you think?
[16:19] <dandrader> didn't get this "6-module" story
[16:19] <tsdgeos> do you have the ux spec open?
[16:20] <dandrader> trying to open it but google drive seems very slow
[16:23] <dandrader> tsdgeos, it's the "Future Dash : UX spec"?
[16:23] <tsdgeos> dandrader: yep
[16:24] <dandrader> tsdgeos, so, what about it
[16:24] <dandrader> ?
[16:24] <tsdgeos> dandrader: so in the organic grid
[16:24] <tsdgeos> each 6 delegates for a module
[16:24] <tsdgeos> and are positioned in that 3x2 way
[16:24] <tsdgeos> yes?
[16:25] <dednick> tsdgeos: that MP is ready with tests now. Few changes though... now "realigns" if the visibility of indicator which is currently open changes.
[16:25] <tsdgeos> dednick: oki, will check tomorrow
[16:25] <dednick> tsdgeos: ta
[16:25] <dandrader> tsdgeos, what do that ux text mean by a "module"?
[16:26] <tsdgeos> "a module is all the cards needed for the repeating pattern, 6 cards"
[16:26] <tsdgeos> it's in the description
[16:26] <dandrader> ah
[16:27] <tsdgeos> ok, so now read again what i wrote at the beginning and see if it makes sense
[16:27] <tsdgeos> if not i'll try to rephrase it
 ok, so now read again what i wrote at the beginning and see if it makes sense
 if not i'll try to rephrase it
[16:30] <dandrader_> tsdgeos, so this organic grid can scroll horizontally or vertically?
[16:30] <tsdgeos> in the dash vertically
[16:31] <tsdgeos> i'll adapt it later for scrolling horizontally so we can reuse it in the gallery-app
[16:31] <tsdgeos> but for now asume it's only vertically
[16:33] <dandrader_> tsdgeos, I got the scenario but didn't get what's your problem
[16:34] <tsdgeos> my problem is what should i do :-)
[16:35] <tsdgeos> when index 3 is not in the vertical area we create
[16:35] <tsdgeos> but index 5
[16:35] <tsdgeos> is
[16:35] <tsdgeos> do i create index 3, 4 and 5?
[16:35] <tsdgeos> or do i create 6 too?
[16:35] <tsdgeos> and the same when deleting up
[16:35] <dandrader_> tsdgeos, ah, ok. I don't think there
[16:35] <dandrader_> there's a problem
[16:35] <tsdgeos> because something got out of bounds
[16:36] <tsdgeos> so i'm suggesting to treat the modules as single entities for "bounds" checking
[16:36] <dandrader_> in creating the items between indexes 2 and 5
[16:36] <tsdgeos> so that i either create the 6 module
[16:36] <dandrader_> even though they're not yet visible
[16:36] <tsdgeos> or delete the 6 module
[16:36] <dandrader_> if that makes the code simpler
[16:36] <tsdgeos> certainly does
[16:36] <tsdgeos> and it should not incur in a huge memory "waste"
[16:38] <dandrader_> it's no waste. it's similar to the "buffer" technique, where you also create the delegates that are very close to the visible rect
[16:38] <tsdgeos> sure
[16:39] <tsdgeos> that's of course buffering
[16:39] <tsdgeos> it's just a "more generous" buffer :D
[16:39] <tsdgeos> ok, i'll do that then
[21:31] <karni> Anyone flashed trusty-proposed today? I'm having problems starting the phone after having installed the demo-stuff ppa along the instructions (as usual after flashing the phone).
[21:31] <karni> It seems the backlit is on, and it briefly flickers something (anything) on every 8 seconds or so. Can't restart unity from shell, core dumped.
[21:32] <karni> not even sure if whatever it's blicking is meaningful, because I can only tell *something* blinks.