[08:02] <Zhenech> argh
[08:03] <Zhenech> could someout please ban him?
[08:22] <Saviq> mzanetti, tsdgeos (I'm not really here), I fwd'ed you an email from bfiller about the people lens
[08:22] <tsdgeos> yeah he was complaining yesterday
[08:22] <mzanetti> hehe, about?
[08:22] <Saviq> if one of you (or greyback, when he comes online)
[08:22] <tsdgeos> there seems to be something randomly broken about the hud too
[08:22] <tsdgeos> works and then it doesn't
[08:22] <tsdgeos> and then i flash
[08:22] <Saviq> can take a look at our options
[08:22] <tsdgeos> and it doesn't and then it does
[08:22] <mzanetti> tsdgeos: ah right... I noticed the HUD breakage too yesterday
[08:23] <tsdgeos> and i can't pinpoint why or what makes it work or not work
[08:23] <Saviq> mzanetti, tsdgeos, one more option to add to bfiller's list is to just limit the amount of contacts displayed in the people lens
[08:23] <Saviq> and require to search for more
[08:24] <mzanetti> Saviq: ok... we'll check it out. go back to bed ;)
[08:24] <mzanetti> or wherever you came from :P
[08:24] <Saviq> mzanetti, tsdgeos, ping me if needed, I'll try and check in once in a while
[08:24] <mzanetti> Saviq: have a nice weekend btw
[08:26] <mzanetti> tsdgeos: not sure how much you are involved there (I guess not at all) but hud-service goes wild here all the time.
[08:27] <mzanetti> tsdgeos: who would be the right one contact on that one?
[08:27] <tsdgeos> ted
[08:27] <Saviq> mzanetti, thanks
[08:29] <mzanetti> pff... hundreds of contacts... who needs that anyways :P I use like 4 of the 30 I have in my address book :D
[08:32] <tsdgeos> +1
[08:32] <mzanetti> anyone got a dummy database I could use for testing?
[08:32] <tsdgeos> i have billions of contacts since the Z10 imports all my facebook, twitter and linkedin contacts onto the phone
[08:32] <tsdgeos> use 3 of the favorites :D
[08:33] <mzanetti> yeah... my jabber contact list is actually much longer than the phone address book (I just realized now)
[08:34] <tsdgeos> mzanetti: i'd go with Saviq's suggestion and limit the number of contacts to show to what we have now
[08:35] <mzanetti> tsdgeos: you know the LVWPH by now... couldn't we add a hack that it actually does not show in full height and only when scrolling down to lets say 80% of the visible height actually expand it at the bottom while shrinking at the top?
[08:35] <mzanetti> tsdgeos: the issue definitely memory usage because of our LVWPH
[08:35] <tsdgeos> don't touch the LVWPH
[08:36] <mzanetti> haha
[08:36] <tsdgeos> not even with a long stick
[08:36] <Saviq> can we ban morphis?
[08:36] <tsdgeos> it will stick to you and you won't know how to unstick it :D
[08:36] <tsdgeos> Saviq: if you know anyone with ops
[08:36] <Saviq> tsdgeos, mzanetti yeah, that would mean we'd maintain the most functionality
[08:36] <Saviq> you'd still be able to access all of your contacts (via search)
[08:36] <tsdgeos> and should be "easy"
[08:36] <Saviq> tsdgeos, one liner
[08:37] <Saviq> or so
[08:37] <tsdgeos> we just need a LimitProxyFilter somewhere
[08:37] <Saviq> tsdgeos, it's there already
[08:37] <Saviq> tsdgeos, but disabled
[08:37] <tsdgeos> lol :D
[08:37] <tsdgeos> ok
[08:37] <mzanetti> actually... can't we just enable that collapsing button?
[08:37] <mzanetti> I guess thats what you meant saviq
[08:37] <Saviq> mzanetti, not really, uncollapsing => all contacts, die!
[08:38] <Saviq> mzanetti, uncollapsing doesn't (yet) move the responsibility to the inner FilterGrid
[08:38] <Saviq> mzanetti, it just unfilters in place
[08:39] <mzanetti> ok...
[08:40] <Saviq> mzanetti, tsdgeos "filter: true; collapsedRowCount: 50 / columns" or similar in PeopleFilterGrid should do
[08:43] <mzanetti> nic-doffay: did you solve the bug from yesterday?
[08:43] <nic-doffay> mzanetti, yeah pete did.
[08:44] <mzanetti> nic-doffay: what was it?
[08:44] <mzanetti> nic-doffay: like I assumed?
[08:44] <nic-doffay> Some stuff had to be moved to the signals.
[08:44] <nic-doffay> mzanetti, ^
[08:44] <nic-doffay> mzanetti, I've committed a bit more code for the gradient.
[08:44] <nic-doffay> Mind taking a look later today and giving any additional comments?
[08:44] <mzanetti> nic-doffay: sure
[08:45] <nic-doffay> I think that's the last feature the infographics are going to need.
[08:45] <mzanetti> let me just fix the people lens (unless tsdgeos is already on it)
[08:47] <tsdgeos> mzanetti: all yours
[08:47] <mzanetti> tsdgeos: ack
[08:59] <mhr3> sil2100, didrocks, any idea what's wrong with the utah and powerpc builds?
[08:59] <mhr3> see http://10.97.0.1:8080/job/cu2d-unity-head-2.1build/lastBuild/console
[08:59] <mhr3> 2013-05-31 05:15:26,624 ERROR powerpc: Build powerpc build of unity-lens-music 6.9.0daily13.05.31ubuntu.unity.next-0ubuntu1 in ubuntu raring RELEASE (https://launchpad.net/~ubuntu-unity/+archive/daily-build-next/+build/4629566) failed because of Failed to build
[08:59] <mhr3> and clicking that gives a successful build
[08:59] <didrocks> mhr3: I think sil2100 relaunched it
[08:59] <didrocks> mhr3: seems a package build issue
[09:00] <didrocks> like architecture mismatch
[09:00] <mhr3> didrocks, why are those failing in the first place though?
[09:00] <mhr3> it's not the first time
[09:00] <didrocks> mhr3: yeah, I know, I ask Mirv to investigate, there should be a arch: any/all somewhere
[09:00] <didrocks> but not in the first generation, in a deeper one
[09:00] <didrocks> liek a dep of a dep
[09:01] <mhr3> didrocks, k, good to know it's being dealt with, can someone relaunch the utah ap checking?
[09:01] <didrocks> mhr3: I think sil2100 forced the publication, let's wait for him
[09:04] <mhr3> didrocks, btw what does cu2d stand for? :)
[09:06] <didrocks> mhr3: Canonical Upstream To Distro ;)
[09:12] <mhr3> aaah :)
[09:13] <Mirv> mhr3: well I didn't find the cause or arch:any/all, but still it's the most probable explanation why the failures happen at the time of an libunity update
[09:16] <Mirv> so still needs investigation
[09:22] <greyback> mzanetti: hey there. Thoughts on the people lens bug? It's definitely not a simple fix
[09:22] <smspillaz> Mirv: sil2100: do either of you know if there's a script around somewhere to spawn autopilot in a lightdm --test-mode xeyphr session ?
[09:22] <smspillaz> I just stumbled upon that --test-mode thing, thought it could almost be extended to run the AP tests too
[09:26] <sil2100> smspillaz: hi, hm, sadly I never used --test-mode before, so no idea here - maybe thomi tried that in the past?
[09:26] <smspillaz> sil2100: try it ;-)
[09:27] <smspillaz> sil2100: you can launch a guest session of ubuntu with xephyr + llvmpipe
[09:28] <mzanetti> greyback: I'm on it... we'll just limit it to 50 people for now
[09:28] <smspillaz> sil2100: maybe I'll look into that tonight ... could be helpful for running AP tests without having to go through the install / reset settings rigamoroll
[09:30] <greyback> mzanetti: ok
[09:32] <mzanetti> greyback: https://code.launchpad.net/~mzanetti/unity/phablet-max-50-people/+merge/166729
[09:33] <greyback> mzanetti: on it
[09:38] <greyback> mzanetti: would you have time for https://code.launchpad.net/~gerboland/unity/refactor-wm-and-test/+merge/166524 ?
[09:39] <mzanetti> greyback: wow... long one. yeah. can do it
[09:40] <greyback> mzanetti: unfortunately yeah, it's a bit long. But it's mostly just moving code around, and then 2 big tests.
[09:42] <mzanetti> nic-doffay: looks fine
[09:42] <mzanetti> the gradient-thing that is
[09:43] <greyback> mzanetti: I also have this bugfix, which I need to get in today: https://code.launchpad.net/~gerboland/unity/fix-shell-focus-on-app-close/+merge/166545
[09:44] <mzanetti> greyback: yay. nice one
[09:50] <mzanetti> greyback: testing the fix-shell-focus:
[09:50] <mzanetti> greyback: the actual fix works fine, but:
[09:50] <mzanetti> greyback: when you have an app open and launch a second one, it will switch to the first one and only afterwards switch to the second one
[09:51] <mzanetti> greyback: I know that has been there before, but I have the impression it got a bit worse with your branch
[09:51] <mzanetti> not sure if its related at all tho. still quite ugly. do you think that could be fixable too?
[09:52] <Mirv> smspillaz: nope, sadly doesn't ring a bell. but thomi indeed could know.
[09:57] <greyback> mzanetti: I'll have a look
[09:58] <mzanetti> greyback: I commented on the MP too
[09:58] <greyback> mzanetti: thanks
[09:58] <smspillaz> Mirv: actually, looks not-so-workable to me
[09:58] <smspillaz> Mirv: it doesn't look like there's a straightforward way to get the services to launch with the correct environment variables
[09:58] <smspillaz> they launch in the parent x session and not the xephyr one
[09:58] <smspillaz> that's a shame though, unity works perfectly fine inside of xephyr otherwise
[10:01] <smspillaz> though you *can* hack around it by relaunching the panel service inside of the xephyr session ...
[11:05] <mzanetti> greyback: done with the review
[11:05] <greyback> mzanetti: thank you. I'm slow, need to reflash the phone
[11:07] <tsdgeos> who knows about dee stuff here?
[11:07] <tsdgeos> seems the hud problem i am having is a dee regression/behaviour change
[11:08] <seb128> tsdgeos, mhr3
[11:08] <tsdgeos> mhr3: hello
[11:08] <mhr3> tsdgeos, hey
[11:08] <tsdgeos> mhr3: so i am debugging a regression in the hud
[11:09] <tsdgeos> and have found that the model we are using for the results sometimes tells me it has 0 columns, even if synchronized says true
[11:09] <tsdgeos> and then latr if i say "come on it can't be you have 0 columns" and ask how many columns it has
[11:09] <tsdgeos> correctly tells me it has 8
[11:10] <tsdgeos> is there a new signal for number of columns changed or something we should be listening to?
[11:11] <mhr3> tsdgeos, first things first, i suppose hud is the owner of the model and you're the client
[11:11] <tsdgeos> yes
[11:11] <Saviq> paulliu, mzanetti is already on the people lens bug
[11:11] <mhr3> tsdgeos, is hud up by the time you try to synchronize the model?
[11:11] <paulliu> Saviq: ok.
[11:11] <paulliu> Saviq: Why I cannot access that bug report?
[11:12] <mhr3> tsdgeos, cause if it isn't you become the owner and you're expected to define the schema
[11:12] <Saviq> paulliu, not sure, it should be public, let me see
[11:12] <mhr3> tsdgeos, and when you do become the owner the model is considered synchronized
[11:12] <Saviq> paulliu, public now
[11:12] <tsdgeos> mhr3: it is, since it's telling me which model to use (i.e. i do a give me the results model name call first)
[11:13] <mhr3> tsdgeos, could you make sure with dee_shared_model_is_leader?
[11:13] <tsdgeos> mhr3: sure, let me try
[11:14] <mhr3> the value of that when you see 0 columns is the interesting data point
[11:16] <tsdgeos> ok, building the package
[11:16] <tsdgeos> will take 5-10 mins
[11:16] <mhr3> k
[11:19] <paulliu> Saviq: yeah. I can see it now. So my permission is a bit weird I think.
[11:19] <Saviq> paulliu, it was private and owned by a team you weren't part of it seems
[11:19] <paulliu> Saviq: ok
[11:22] <tsdgeos> mhr3: it seems i'm the leader
[11:22] <tsdgeos> DeeListModel(0x1fc9298) DeeListModelPrivate::createRoles numColumns 0
[11:22] <tsdgeos> DeeListModel(0x1fc9298) DeeListModelPrivate::createRoles isLeader 1
[11:23] <tsdgeos> that's bad, right?
[11:23] <tsdgeos> or isn't?
[11:23] <mhr3> well, yes and no
[11:23] <tsdgeos> ok :D
[11:24] <greyback> :)
[11:24] <mhr3> it's doesn't break everything, the hud will become non-leader of the model, but it can still write to it and you will get everything
[11:25] <mhr3> the only problem really is that you don't get the schema right away
[11:25] <tsdgeos> right
[11:25] <tsdgeos> so why am i the leader?
[11:25] <mhr3> so the simple fix is to set the schema yourself when you become a leader
[11:25] <tsdgeos> does it mean i'm connecting earlier than the hud to the name the hud just gave me?
[11:25] <mhr3> afterall you must know what schema you expect
[11:26] <tsdgeos> mhr3: actaully i kind of don't
[11:26] <tsdgeos> since this is an intermediate layer
[11:26] <tsdgeos> hud-client -> dee-qt -> dee
[11:26] <mhr3> hmm
[11:26] <tsdgeos> i mean i could add api in dee-qt so the users gave him the number of columns, but that defeats the point of having a get_columns call :D
[11:27] <mhr3> they changed the way names are owned in glib that made this happen in R+
[11:28] <tsdgeos> mhr3: is there any way the model can tell me the schema has changed?
[11:28] <mhr3> hmm, let me check if something is emitted
[11:34] <mhr3> tsdgeos, ok, so if you become the leader the schema will be set only once you receive a change from the other peer (that did set the schema)
[11:35] <tsdgeos> any way for me to not become the leader? other than waiting some time?
[11:38] <mhr3> tsdgeos, easiest would be for hud to not reply with the model name until it actually acquires it
[11:39] <tsdgeos> makes sense
[11:39] <tsdgeos> mhr3: is this thing new? i mean this worked forever, were we just lucky?
[11:40] <mhr3> tsdgeos, or use private (non-dbus) connection, that one should be synchronous still :)
[11:40] <mhr3> tsdgeos, as i said, glib slightly changed the way names are owned (it's more async now than it used to be)
[11:40] <tsdgeos> he he
[11:40] <tsdgeos> i see
[11:41] <tsdgeos> ted: wakeup!
[11:45] <Saviq> popey, « perl -p -i -e 's/false/true/' » yikes!
[11:46] <Saviq> ;)
[11:46] <tsdgeos> mhr3: this is what the hud does http://paste.ubuntu.com/5719648/ doesn't that guarantee it will be the leader?
[11:47] <tsdgeos> it does *before* returning query->results_name via dbus to me
[11:47] <popey> Saviq: I know, awesome isn't it ☻
[11:47] <popey> there's only one occurance and it doesn't have /g ☻
[11:47] <popey> (for now)
[11:48] <mhr3> tsdgeos, nope, it's the same thing, you can't tell unless the model gets synchronized
[11:49] <tsdgeos> mhr3: so what's the easy way to guarantee it'll be the leader? busy loop on dee_shared_model_is_leader ?
[11:50] <mhr3> tsdgeos, there's a prop that says "i *really* want to be the leader, if someone else is, steal the leadership from them"
[11:51] <tsdgeos> but that won't help me either
[11:51] <mhr3> tsdgeos, but then you'd see that you become a leader, and then loose the leadership a tiny while later
[11:51] <tsdgeos> dee-qt is basically built around the assumption that when a model is synchronized the schema is set
[11:51] <tsdgeos> and that's failing here because somehow the client is the leader
[11:51] <mhr3> well, that assumption is wrong :)
[11:52] <tsdgeos> is there no prop to say (i don't want to be the leader, wait until the leader is there) :D
[11:52] <tsdgeos> well, it seemed to work well until now :D
[11:52] <mhr3> unfortunately no, but yes maybe we should add that
[11:52] <tsdgeos> not that i'm the dee-qt original coder anyway
[11:52] <tsdgeos> i mean i can workaround the problem easily
[11:52] <tsdgeos> rechecking for the number of columns "often"
[11:53] <tsdgeos> but that's not cool :D
[11:53] <popey> Saviq: fixed ㋛ http://bazaar.launchpad.net/~popey/+junk/phablet-flash-wrapper/view/head:/add_apps.sh
[11:53] <mhr3> i do agree that dee-qt should be definitely able to tell when a model is "ready"
[11:53] <mhr3> or any dee client really
[11:54] <tsdgeos> yep, that's my main problem at the moment
[11:55] <tsdgeos> mhr3: previously you said " if you become the leader the schema will be set only once you receive a change from the other peer", that's actually fine for me (at this moment) if i get some signal that tells me the schema changed
[11:55] <tsdgeos> does such signal exist?
[11:55] <mhr3> by change i meant row-added/removed/changed
[11:55] <paulliu> Hi. Does anyone know where is the source code of ChewieUI? I need to dig into that part.
[11:56] <tsdgeos> paulliu: try asking renato_ in #ubuntu-touch
[11:56] <paulliu> tsdgeos: ok.
[11:57] <mhr3> tsdgeos, we could also try to flush the dbus connection after own_name call, that should theoretically fix it too
[11:57] <tsdgeos> mhr3: ok, so i guess i could re-check the column number on the first row-added
[11:57] <mhr3> but all of these fixes are adding blocking io, and that no good
[11:58] <mhr3> tsdgeos, the "clean" fix is really for hud to return the name only after the model is synchronized
[11:58] <tsdgeos> mhr3: agreed, but that also adds blocking io on the hud, no?
[11:59] <tsdgeos> or should the hud wait for "notify::synchronized" and then return the name?
[11:59] <tsdgeos> that makes sense
[11:59] <tsdgeos> mhr3: ↑↑↑
[11:59] <mhr3> not necessarily, it can wait for the synchronized signal asynchronously
[11:59] <mhr3> right ^^
[11:59] <tsdgeos> gotcha
[12:00] <tsdgeos> ok, let's wait for texas then
[12:01] <mhr3> hmm, was just checking gio changes and there's nothing in name owning itself, so it's either a more complex message scheduling change in gio or something even deeper (in dbus-daemon itself?)
[12:50] <dandrader> greyback, FIY: just proposed my changes to Stage.qml -> https://code.launchpad.net/~dandrader/unity/phablet_edgeDragInStage/+merge/166777
[12:50] <greyback> dandrader: thanks :)
[13:15] <mzanetti> dandrader: ping
[13:16] <dandrader> mzanetti, pong
[13:16] <mzanetti> dandrader: hey, I'm updating the launcher tests but the DDA doesn't seem to do anything. I guess I need to enable that mousetouch thingie for it to work, right?
[13:16] <dandrader> mzanetti, you have to send touch events, not mouse events
[13:17] <mzanetti> dandrader: can I enable that mouse->touch conversion for qmlscene somehow?
[13:17] <dandrader> mzanetti, no
[13:17] <mzanetti> dandrader: hmm... so the all tests involving a DDA won't work in qmlscene any more then
[13:17] <dandrader> mzanetti, to manual test on the desktop we might need to do our own qmlscene equivalent :(
[13:17] <mzanetti> ok, I see
[13:18] <dandrader> what I was doing as a quick hack was replacing Shell.qml in main.cpp with the qml I wanted to try out manually with touch events on the desktop
[13:18] <mzanetti> oh... thats useful
[13:18] <mzanetti> thanks
[13:18] <mzanetti> can you hint me how to do touch events in tests?
[13:19] <dandrader> mzanetti, http://bazaar.launchpad.net/~dandrader/unity/phablet_edgeDragInStage/revision/715
[13:19] <dandrader> mzanetti,  check tests/qmltests/Components/tst_Stage.qml  and tests/utils/modules/Unity/Test/UnityTestCase.qml  there
[13:19] <dandrader> mzanetti, and also the existing tst_Launcher test
[13:20] <dandrader> mzanetti, btw, were you able to work around that "Flickable on top of DDA" issue?
[13:20] <mzanetti> dandrader: yes... I disable the DDA as soon as the launcher is revealed
[13:20] <mzanetti> dandrader: and have a second MouseArea for hiding the launcher again
[13:21] <mzanetti> dandrader: so the DDA is only used to start revealing and then sits there being disabled
[13:21] <mzanetti> dandrader: ah... and I found a bug.
[13:22] <mzanetti> dandrader: https://code.launchpad.net/~mzanetti/unity/phablet-folding-launcher/+merge/166000
[13:22] <mzanetti> dandrader: Its fixed in there... you might want to check it to see if the fix is ok
[13:25] <dandrader> mzanetti, well, the definition of the "dragging" property is "Whether a drag gesture is taking place (regardless of whether it's a correct single-finger directional drag or not)"
[13:26] <mzanetti> dandrader: bug dragging == (Undecided || Recognized)
[13:26] <dandrader> mzanetti, which maps to "as long as DDA is holding some touch points"
[13:26] <mzanetti> dandrader: => Rejected == !dragging
[13:27] <mzanetti> dandrader: so current state in trunk is not consistent... if you're not happy with my fix you need to change dragging()
[13:27] <dandrader> mzanetti, I think that "Rejected == !dragging" would be true if DDA got rid of his touch points once reaching Rejected state, which currently doesn't happen
[13:27] <mzanetti> dandrader: if you change dragging() I would need a new property that does what dragging currently does including a signal
[13:29] <dandrader> ah, yeah the dragging() method. I recall I had the very same discussion with Saviq and he wanted it to be like you suggest
[13:29] <dandrader> mzanetti, majority wins. So please also update the documentation of the dragging property
[13:29] <mzanetti> dandrader: well, I could probably replace the usage of dragging with checks on status... but currently dragging does exactly what I need... when dragging == true, I need to show the launcher, when dragging == false I need to hide again
[13:29] <Saviq> \o/
[13:29] <mzanetti> hehe
[13:31] <dandrader> mzanetti, it might make sense to update DDA's tests to check for the emission of draggingChanged when rejected is reached....
[13:32] <mzanetti> dandrader: ok
[13:33] <greyback> Saviq: dude, you're on holiday, go away
[13:33] <Saviq> greyback, I am away
[13:33] <mzanetti> nic-doffay: standup?
[13:33] <Saviq> ← see
[13:33] <greyback> Saviq: for someone away, you're remarkably responsive
[13:34] <nic-doffay> mzanetti, one sec
[13:34] <nic-doffay> need to grab my mic and all
[13:50] <paulliu> tsdgeos: https://code.launchpad.net/~paulliu/unity/i18n/+merge/166765
[13:50]  * tsdgeos clicks
[13:57] <tsdgeos> mzanetti: i may have to do a HUD change, ping me before you do the release
[13:58] <greyback> mzanetti: updated https://code.launchpad.net/~gerboland/unity/fix-shell-focus-on-app-close/+merge/166545
[13:58] <greyback> mzanetti: expect about 30 minutes for a fix for the flicker
[14:02] <mzanetti> awesome
[14:02] <mzanetti> dandrader|afk: do you think using the DDA has also impacts on the speed you can reveal the launcher?
[14:03] <mzanetti> dandrader|afk: pmcgowan reports he's not able to reveal the launcher any more most of the times
[14:04] <mzanetti> I think he's used to drag it out with a gesture from bottom-left towards top-right which is not in the allowed angle any more
[14:04] <kgunn> mzanetti: i kind of noticed the same difficulty yesterday...wonder if its the swipe velocity value he's got in DDA
[14:04] <kgunn> felt more speed related to me as i'm an index finger user
[14:05] <mzanetti> well, now that you say it... Before I really thought I would not be able to keep the straigt direction with my thumb... but yes, it mostly happens when revealing very fast
[14:06] <mzanetti> nah... seems the direction...
[14:07] <mzanetti> maybe we need to widen the angle a little
[14:08] <dandrader> mzanetti, no, it should have no impact on the speed you can reveal the launcher
[14:08] <larsu> dednick: I see you started working on loading indicator files - do you want a shared library for that or are you fine parsing it yourself? (it's not that big of a format...)
[14:09] <dednick> larsu: is it ini format?
[14:09] <larsu> yup
[14:09] <dednick> larsu: it's ok, i've just used qsettings which supports it.
[14:09] <larsu> we added some things since oakland, a description is here: http://bazaar.launchpad.net/~larsu/libindicator/new-indicator-file-format/revision/491/README
[14:11] <dednick> larsu: thanks. i'll account those changes into what i have.
[14:42] <greyback> mzanetti: could you please try out http://pastebin.ubuntu.com/5720050/ and check it fixes the launch flicker bug?
[14:43] <mzanetti> greyback: sure... give me one minute please
[14:43] <mzanetti> dandrader: hmm... I wanted to update the tests for the dragging property
[14:43] <greyback> my internet has become very slow, pushing a branch taking ages
[14:44] <mzanetti> dandrader: what I did is to add a Q_COMPARE to the if where the gesture becomes rejected
[14:44] <mzanetti> dandrader: but I intentionally left the Q_COMPARE at the end of the function to 2, but thing is, it becomes 3
[14:45] <dandrader> greyback, are you using this bash trick? -> alias bzrpushs='bzr push --stacked-on bzr+ssh://bazaar.launchpad.net/+branch/unity/phablet/'
[14:45] <mzanetti> dandrader: which means, we emit draggingChanged even when its not changing
[14:45] <mzanetti> dandrader: +1 for shorter aliases: alias pu='bzr push --stacked-on bzr+ssh://bazaar.launchpad.net/+branch/unity/phablet/'
[14:45] <mzanetti> :)
[14:46] <mzanetti> anyways...
[14:46] <mzanetti> dandrader: do you think that is an issue? should I introduce a m_dragging var and keep track of that to only correctly emit changed signals?
[14:46] <greyback> dandrader: yep, but seems my speed gone down to 40Kbps
[14:48] <dandrader> mzanetti, that after your change, right?
[14:49] <mzanetti> dandrader: yes... my change introduces that...
[14:49] <dandrader> mzanetti, Undecided -> Rejected (draggingChanged(false)), then Rejected -> WaitingForTouch (draggingChanged(false) once again)
[14:49] <mzanetti> dandrader: exactly
[14:50] <dandrader> mzanetti, we don't need to introduce an m_dragging variable as it duplicates information and therefore it's liable to get outdated and therefore conflict with other variables
[14:50] <mzanetti> dandrader: ah... right... we can see if oldstate is !rejected before emitting
[14:51] <dandrader> mzanetti, better make setStatus() have a bit more context information, so that it knowns also the previous state before emitting the draggingChanged() signal
[14:51] <dandrader> mzanetti, that way it can differentiate between Rejected -> WaitingForTouch and Recognized -> WaitingForTouch
[14:52] <dandrader> mzanetti, in which case it will only send the draggingChanged() event for the latter
[14:52] <dandrader> mzanetti, damn, just read that you had already suggested the same thing. wrote all that for nothing :)
[14:53] <mzanetti> hehe... at least you got me to think it through once more
[14:53] <mzanetti> seems save now ;)
[14:56] <mzanetti> dandrader: Recognized -> Undecided is not possible, right? you can only go from WaitingForTouch to Undecided
[14:56] <dandrader> mzanetti, yes
[14:59] <mzanetti> dandrader: ok. tests pass again and docs. https://code.launchpad.net/~mzanetti/unity/phablet-folding-launcher/+merge/166000
[15:06] <dandrader> mzanetti, Saviq: here's the bug report https://bugreports.qt-project.org/browse/QTBUG-31491
[15:06] <mzanetti> dandrader: cheers
[15:07] <tedg> tsdgeos, A fix that you can try.  https://code.launchpad.net/~ted/hud/dee-sync/+merge/166819
[15:07] <tedg> Going to put it on my phone now.
[15:08] <dandrader> mzanetti, do you want me to review the whole thing?
[15:08] <mzanetti> dandrader: if you want
[15:09] <Saviq> dandrader, yup, confirmed, thanks
[15:10] <dandrader> mzanetti, well, it's been a while since I last reviewed anything of relevant size.
[15:10] <dandrader> mzanetti, so I'm fine on reviewing this
[15:11] <mzanetti> dandrader: ok. cool.
[15:12] <dandrader> mzanetti, now that you're familiar with DDA, would you mind reviewing https://code.launchpad.net/~dandrader/unity/phablet_edgeDragInStage/+merge/166777   :)
[15:12] <mzanetti> dandrader: sure
[15:13] <tsdgeos> tedg: ok, me me check too
[15:15] <mzanetti> tedg: is it a known issue that hud-service goes wild every once in a while?
[15:15] <mzanetti> happens sinse a week or so
[15:15] <mzanetti> since
[15:15] <tedg> mzanetti, Wild?
[15:16] <mzanetti> tedg: means, on my PC ~20% CPU usage, on the Galaxy Nexus ~80% CPU usage
[15:16] <mzanetti> unfortunately I couldn't figure yet when exactly it happens
[15:17] <mzanetti> but every once in a while my fans turn on and I check top and its the hud-service
[15:17] <tedg> mzanetti, Hmm, no, not aware of anything there.
[15:17] <mzanetti> same for the phone... every once in a while it starts getting warm and draining batteries
[15:17] <tedg> Hmm, do you use it a lot?  If nothing else it should shutdown after 10 minutes of non-use.
[15:18] <mzanetti> tedg: I don't use it at all
[15:18] <mzanetti> tedg: I have the feeling it happens when the shell goes away or so
[15:18] <mzanetti> in case it happens again here. is there anything I can do to get more information?
[15:19] <tedg> Hmm, not sure what could be happening
[15:19] <tedg> I guess give it a SEGV and generate an apport report?
[15:19] <mzanetti> tedg: ok... I'll keep an eye on it
[15:20] <mzanetti> greyback: hmm... seems not to fix the issue
[15:21] <mzanetti> greyback: do I need to apply the patch in combination of another branch of yours or is trunk fine?
[15:21] <greyback> mzanetti: on trunk
[15:22] <mzanetti> greyback: well... it seems better again...
[15:22] <mzanetti> greyback: still can reproduce it with launching first the phone app and then the gallery
[15:23] <greyback> mzanetti: let me try that
[15:23] <mzanetti> (might be related to app startup time as the gallery is the slowest one)
[15:23] <greyback> mzanetti: huh, I found phone was slowest. The delay could need tweaking.
[15:28] <greyback> mzanetti: fine on my nexus. I'll admit it's a hacky solution, but right now there's no way for shell to know if an application has drawn its first frame.
[15:28] <mzanetti> greyback: right... I had the same issue with the blur thing
[15:29] <mzanetti> greyback: anyways... most of the times your hack seems to work
[15:30] <greyback> mzanetti: I've put it in a MR https://code.launchpad.net/~gerboland/unity/phablet-fix-flicker-on-launch/+merge/166829
[15:30] <tsdgeos> tedg: i can comment indicator-appmenu in debian/control to build on the phone, right?
[15:31] <mzanetti> greyback: is that a function inside a function?
[15:31] <greyback> mzanetti: yep
[15:31]  * mzanetti needs to looka t some C++ code to come down
[15:32] <gatox> hi.... is the build of phablet working in S?? Because when trying to run the ./build -s ... some of the ppas with the dependencies couldn't be found for S
[15:32] <tedg> tsdgeos, Yup
[15:32] <tedg> tsdgeos, I drop the metacity one as well.
[15:32] <tedg> We should probably just remove that test.
[15:32] <tedg> tsdgeos, FYI, that branch works for me.
[15:32]  * tedg is cropping photos like a madman
[15:33] <tsdgeos> tedg: cool
[15:33] <tsdgeos> tedg: do you have someone to review it?
[15:33] <tsdgeos> in the unity-backend team ?
[15:34] <tsdgeos> i'm still dpkg-buildpking
[15:34] <tedg> tsdgeos, Uhm, no one in particular.  If you would that'd probably be reasonable to me.
[15:34] <tedg> Not sure that we have a "hud backend team" anymore.
[15:35] <tsdgeos> but you have a "all things backend team" :D
[15:35] <tedg> Heh
[15:35] <tsdgeos> sure, i can test it first and then have a look at the code
[15:35] <tsdgeos> should not be that hard (TM)
[15:36] <tsdgeos> tedg: actually i only need to install libhud-client2_13.10.1daily13.05.23ubuntu.unity.next-0ubuntu1_armhf.deb, no?
[15:36] <tedg> tsdgeos, Yeah, that's all you *need* but I usually do "dpkg -i *.deb" to not think about it :-)
[15:38] <tsdgeos> hmmm
[15:38] <tsdgeos> is the automerger broken?
[15:38] <tsdgeos> or just sloooow
[15:41] <tsdgeos> tedg: didn't work, i still got to be the leader of it :-/
[15:41] <tsdgeos> DeeListModel(0x186e850) DeeListModelPrivate::createRoles synchronized true
[15:41] <tsdgeos> DeeListModel(0x186e850) DeeListModelPrivate::createRoles numColumns 0
[15:41] <tsdgeos> DeeListModel(0x186e850) DeeListModelPrivate::createRoles isLeader 1
[15:41]  * tsdgeos dpkg -i *.deb just in case
[15:41] <tedg> tsdgeos, And did you reboot?
[15:41] <tsdgeos> yep
[15:41] <tedg> Hmm, not sure why it works for me then...
[15:42] <tsdgeos> well because it did already work
[15:42] <tsdgeos> randomly
[15:43] <tedg> Hmm, it never worked for me before.
[15:43]  * tedg reboots again
[15:43] <tsdgeos> oh it did work here sometimes
[15:43] <tsdgeos> maybe you just made it harder to repro
[15:44] <tsdgeos> yeah same thing :/
[15:44] <tsdgeos> which makes no sense :D
[15:46] <tsdgeos> mhr3: any input on ted's code? https://code.launchpad.net/~ted/hud/dee-sync/+merge/166819
[15:48] <tedg> tsdgeos, So it seems the values above say that it is synchronized, which is what we were checking for.
[15:49] <tedg> tsdgeos, Perhaps we need to wait for a column?
[15:49] <tsdgeos> tedg: what mhr3 commented is that you should be the leader
[15:49] <tsdgeos> i.e. dee_shared_model_is_leader should be true for you
[15:50] <tsdgeos> thing is i think he said that on synchronized you'd be that
[15:51] <tedg> Perhaps in the service side we need to wait until we get the name.
[15:51] <tedg> I think that the leader thing is a race to own the name.
[15:51] <tedg> It would make sense that the service would win.
[15:51] <tedg> But, perhaps we're getting cases where it doesn't.
[15:52] <tsdgeos> tbh i don't know, it's a bit of a pain that this changed out of the blue :-/
[15:53] <tedg> I don't think anything *changed* other than it's probably a fix or optimization or something like that.
[15:53] <tedg> Fix with side effects.
[15:54] <tsdgeos> ah
[15:54] <tsdgeos> i think i know why this doesn't help
[15:55] <tsdgeos> you are doing it in the client side :D
[15:55] <tsdgeos> what mhr3 suggested was doing in the server side
[15:55] <tsdgeos> or not
[15:55] <tsdgeos> don't know
[15:55]  * tsdgeos confused
[15:56] <tedg> I think we perhaps need both.
[15:56] <tsdgeos> damn wailing cousin on next door :D
[15:56] <tedg> Basically ensure that the service is the leader and that we know that on the other side.
[15:56] <tsdgeos> yep
[15:56] <mzanetti> someone please review this but NOT top approve yet (some changes are still pending merge) https://code.launchpad.net/~unity-team/unity/release-1.79/+merge/166840
[15:56] <mzanetti> greyback:  maybe? ^
[15:57] <tsdgeos> tedg: think you can try that?
[15:57] <mhr3> tsdgeos, tedg, right, it should be on the server side - wait for the model to synchronize before passing it's name over the bus
[15:57] <mhr3> that will fix things
[15:57] <greyback> mzanetti: I'll take
[15:57] <tedg> tsdgeos, Yup, trying.
[15:57] <tedg> mhr3, Makes sense.
[15:57] <mhr3> tedg, no need to do it on client side if server ensures that
[15:57] <tedg> Hating dbus names right now.
[15:58] <tedg> mhr3, I think it's better to do client side in general as there's less updating that way, perhaps not worth writing the code... but since I already wrote it :-)
[15:59] <mhr3> tedg, it looks a bit scary, so i'd go with smaller amount of code in this case (for the client)
[15:59] <greyback> mzanetti: approved (not top level)
[16:00] <mhr3> tedg, i have an idea - lets implement dbus mutex library ;P
[16:00] <tedg> mhr3, Heh, I'm so happy to be getting rid of some of our dbus activation stuff already.  I don't need more.
[19:22] <MCR_> Hi @all :)
[19:23] <alecu> hi!
[19:24] <MCR_> andyrock, hi - do you have a minute ?
[19:26] <MCR_> A volunteer to set up a PPA with Compiz 0.9.10-dev and Unity/nux/libunity for Raring would be needed...
[19:27] <MCR_> Since we had an ABI break, there is no way to run latest Compiz with latest Unity on Raring without self-compilation...
[19:28] <MCR_> Seems like *nothing* here builds correctly: https://code.launchpad.net/~unity-team/unity/trunk/+recipes
[19:29] <MCR_> Please see bug #1185778 for details...
[19:30] <MCR_> bregma ?
[19:31] <MCR_> Trevinho, ^^
[20:46] <eean> so I have an app that uses org.kde.StatusNotifierWatcher for the statusbar
[20:46] <eean> but it still isn't showing up in the indicator
[20:46] <eean> s/statusbar/systray/
[20:47] <eean> is there logic somewhere on what is 'allowed' in the indicator?