| === morphis|away is now known as morphis | ||
| Zhenech | argh | 08:02 |
|---|---|---|
| Zhenech | could someout please ban him? | 08:03 |
| 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:22 |
| 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:23 |
| 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:24 |
| 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:26 |
| mzanetti | tsdgeos: who would be the right one contact on that one? | 08:27 |
| tsdgeos | ted | 08:27 |
| Saviq | mzanetti, thanks | 08:27 |
| 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:29 |
| 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:32 |
| mzanetti | yeah... my jabber contact list is actually much longer than the phone address book (I just realized now) | 08:33 |
| tsdgeos | mzanetti: i'd go with Saviq's suggestion and limit the number of contacts to show to what we have now | 08:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| Saviq | mzanetti, uncollapsing doesn't (yet) move the responsibility to the inner FilterGrid | 08:38 |
| Saviq | mzanetti, it just unfilters in place | 08:38 |
| mzanetti | ok... | 08:39 |
| Saviq | mzanetti, tsdgeos "filter: true; collapsedRowCount: 50 / columns" or similar in PeopleFilterGrid should do | 08:40 |
| mzanetti | nic-doffay: did you solve the bug from yesterday? | 08:43 |
| nic-doffay | mzanetti, yeah pete did. | 08:43 |
| 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:44 |
| 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:45 |
| tsdgeos | mzanetti: all yours | 08:47 |
| mzanetti | tsdgeos: ack | 08:47 |
| 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 | 08:59 |
| 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:00 |
| 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:01 |
| mhr3 | didrocks, btw what does cu2d stand for? :) | 09:04 |
| didrocks | mhr3: Canonical Upstream To Distro ;) | 09:06 |
| mhr3 | aaah :) | 09:12 |
| 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:13 |
| === greyback|away is now known as greyback | ||
| Mirv | so still needs investigation | 09:16 |
| 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:22 |
| 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:26 |
| smspillaz | sil2100: you can launch a guest session of ubuntu with xephyr + llvmpipe | 09:27 |
| 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:28 |
| greyback | mzanetti: ok | 09:30 |
| mzanetti | greyback: https://code.launchpad.net/~mzanetti/unity/phablet-max-50-people/+merge/166729 | 09:32 |
| greyback | mzanetti: on it | 09:33 |
| greyback | mzanetti: would you have time for https://code.launchpad.net/~gerboland/unity/refactor-wm-and-test/+merge/166524 ? | 09:38 |
| mzanetti | greyback: wow... long one. yeah. can do it | 09:39 |
| greyback | mzanetti: unfortunately yeah, it's a bit long. But it's mostly just moving code around, and then 2 big tests. | 09:40 |
| mzanetti | nic-doffay: looks fine | 09:42 |
| === om26er is now known as om26er|lunch | ||
| mzanetti | the gradient-thing that is | 09:42 |
| 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:43 |
| mzanetti | greyback: yay. nice one | 09:44 |
| === mmrazik is now known as mmrazik|afk | ||
| 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:50 |
| 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:51 |
| Mirv | smspillaz: nope, sadly doesn't ring a bell. but thomi indeed could know. | 09:52 |
| === davmor2_ is now known as davmor2 | ||
| greyback | mzanetti: I'll have a look | 09:57 |
| 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 | 09:58 |
| smspillaz | though you *can* hack around it by relaunching the panel service inside of the xephyr session ... | 10:01 |
| === ubot5` is now known as ubot5 | ||
| === mmrazik|afk is now known as mmrazik | ||
| === mmrazik is now known as mmrazik|afk | ||
| mzanetti | greyback: done with the review | 11:05 |
| greyback | mzanetti: thank you. I'm slow, need to reflash the phone | 11:05 |
| tsdgeos | who knows about dee stuff here? | 11:07 |
| tsdgeos | seems the hud problem i am having is a dee regression/behaviour change | 11:07 |
| seb128 | tsdgeos, mhr3 | 11:08 |
| tsdgeos | mhr3: hello | 11:08 |
| === MacSlow is now known as MacSlow|lunch | ||
| mhr3 | tsdgeos, hey | 11:08 |
| tsdgeos | mhr3: so i am debugging a regression in the hud | 11:08 |
| 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:09 |
| tsdgeos | is there a new signal for number of columns changed or something we should be listening to? | 11:10 |
| === mzanetti is now known as mzanetti|lunch | ||
| 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:11 |
| 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:12 |
| mhr3 | tsdgeos, could you make sure with dee_shared_model_is_leader? | 11:13 |
| tsdgeos | mhr3: sure, let me try | 11:13 |
| mhr3 | the value of that when you see 0 columns is the interesting data point | 11:14 |
| tsdgeos | ok, building the package | 11:16 |
| tsdgeos | will take 5-10 mins | 11:16 |
| mhr3 | k | 11:16 |
| 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:19 |
| 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:22 |
| tsdgeos | that's bad, right? | 11:23 |
| tsdgeos | or isn't? | 11:23 |
| mhr3 | well, yes and no | 11:23 |
| tsdgeos | ok :D | 11:23 |
| greyback | :) | 11:24 |
| === mmrazik|afk is now known as mmrazik | ||
| 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:24 |
| 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:25 |
| 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:26 |
| mhr3 | they changed the way names are owned in glib that made this happen in R+ | 11:27 |
| 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:28 |
| 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:34 |
| tsdgeos | any way for me to not become the leader? other than waiting some time? | 11:35 |
| mhr3 | tsdgeos, easiest would be for hud to not reply with the model name until it actually acquires it | 11:38 |
| tsdgeos | makes sense | 11:39 |
| tsdgeos | mhr3: is this thing new? i mean this worked forever, were we just lucky? | 11:39 |
| 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:40 |
| tsdgeos | ted: wakeup! | 11:41 |
| Saviq | popey, « perl -p -i -e 's/false/true/' » yikes! | 11:45 |
| 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:46 |
| 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:47 |
| mhr3 | tsdgeos, nope, it's the same thing, you can't tell unless the model gets synchronized | 11:48 |
| tsdgeos | mhr3: so what's the easy way to guarantee it'll be the leader? busy loop on dee_shared_model_is_leader ? | 11:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| tsdgeos | yep, that's my main problem at the moment | 11:54 |
| 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:55 |
| tsdgeos | paulliu: try asking renato_ in #ubuntu-touch | 11:56 |
| paulliu | tsdgeos: ok. | 11:56 |
| === alan_g is now known as alan_g|lunch | ||
| 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 |
| === pete-woods is now known as pete-woods-lunch | ||
| mhr3 | but all of these fixes are adding blocking io, and that no good | 11:57 |
| 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:58 |
| 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 | 11:59 |
| tsdgeos | ok, let's wait for texas then | 12:00 |
| 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:01 |
| === mzanetti|lunch is now known as mzanetti | ||
| 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 :) | 12:50 |
| === MacSlow|lunch is now known as MacSlow | ||
| === larsu_ is now known as larsu | ||
| === alan_g|lunch is now known as alan_g | ||
| mzanetti | dandrader: ping | 13:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:29 |
| dandrader | mzanetti, it might make sense to update DDA's tests to check for the emission of draggingChanged when rejected is reached.... | 13:31 |
| mzanetti | dandrader: ok | 13:32 |
| 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:33 |
| nic-doffay | mzanetti, one sec | 13:34 |
| nic-doffay | need to grab my mic and all | 13:34 |
| paulliu | tsdgeos: https://code.launchpad.net/~paulliu/unity/i18n/+merge/166765 | 13:50 |
| === dandrader is now known as dandrader|afk | ||
| * tsdgeos clicks | 13:50 | |
| tsdgeos | mzanetti: i may have to do a HUD change, ping me before you do the release | 13:57 |
| 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 | 13:58 |
| 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:02 |
| mzanetti | dandrader|afk: pmcgowan reports he's not able to reveal the launcher any more most of the times | 14:03 |
| 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:04 |
| 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:05 |
| === dandrader|afk is now known as dandrader | ||
| mzanetti | nah... seems the direction... | 14:06 |
| mzanetti | maybe we need to widen the angle a little | 14:07 |
| 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:08 |
| 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:09 |
| dednick | larsu: thanks. i'll account those changes into what i have. | 14:11 |
| === mmrazik is now known as mmrazik|afk | ||
| greyback | mzanetti: could you please try out http://pastebin.ubuntu.com/5720050/ and check it fixes the launch flicker bug? | 14:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| dandrader | mzanetti, that after your change, right? | 14:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| mzanetti | hehe... at least you got me to think it through once more | 14:53 |
| mzanetti | seems save now ;) | 14:53 |
| === alan_g is now known as alan_g|tea | ||
| mzanetti | dandrader: Recognized -> Undecided is not possible, right? you can only go from WaitingForTouch to Undecided | 14:56 |
| dandrader | mzanetti, yes | 14:56 |
| mzanetti | dandrader: ok. tests pass again and docs. https://code.launchpad.net/~mzanetti/unity/phablet-folding-launcher/+merge/166000 | 14:59 |
| dandrader | mzanetti, Saviq: here's the bug report https://bugreports.qt-project.org/browse/QTBUG-31491 | 15:06 |
| mzanetti | dandrader: cheers | 15:06 |
| 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:07 |
| dandrader | mzanetti, do you want me to review the whole thing? | 15:08 |
| mzanetti | dandrader: if you want | 15:08 |
| Saviq | dandrader, yup, confirmed, thanks | 15:09 |
| === alan_g|tea is now known as alan_g | ||
| dandrader | mzanetti, well, it's been a while since I last reviewed anything of relevant size. | 15:10 |
| === mmrazik|afk is now known as mmrazik | ||
| dandrader | mzanetti, so I'm fine on reviewing this | 15:10 |
| mzanetti | dandrader: ok. cool. | 15:11 |
| 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:12 |
| tsdgeos | tedg: ok, me me check too | 15:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| === om26er_ is now known as om26er | ||
| 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:18 |
| 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:19 |
| mzanetti | greyback: hmm... seems not to fix the issue | 15:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:28 |
| mzanetti | greyback: anyways... most of the times your hack seems to work | 15:29 |
| 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:30 |
| 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:31 | |
| 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 |
| === mmrazik is now known as mmrazik|afk | ||
| 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:32 | |
| tsdgeos | tedg: cool | 15:33 |
| tsdgeos | tedg: do you have someone to review it? | 15:33 |
| tsdgeos | in the unity-backend team ? | 15:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| tsdgeos | hmmm | 15:38 |
| tsdgeos | is the automerger broken? | 15:38 |
| tsdgeos | or just sloooow | 15:38 |
| 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:41 |
| tsdgeos | well because it did already work | 15:42 |
| tsdgeos | randomly | 15:42 |
| 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:43 |
| tsdgeos | yeah same thing :/ | 15:44 |
| tsdgeos | which makes no sense :D | 15:44 |
| tsdgeos | mhr3: any input on ted's code? https://code.launchpad.net/~ted/hud/dee-sync/+merge/166819 | 15:46 |
| tedg | tsdgeos, So it seems the values above say that it is synchronized, which is what we were checking for. | 15:48 |
| 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:49 |
| tsdgeos | thing is i think he said that on synchronized you'd be that | 15:50 |
| 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:51 |
| tsdgeos | tbh i don't know, it's a bit of a pain that this changed out of the blue :-/ | 15:52 |
| 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:53 |
| tsdgeos | ah | 15:54 |
| tsdgeos | i think i know why this doesn't help | 15:54 |
| 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:55 | |
| 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:56 |
| 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:57 |
| 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:58 |
| 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) | 15:59 |
| 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. | 16:00 |
| === om26er is now known as om26er|away | ||
| === dandrader is now known as dandrader|lunch | ||
| === gatox is now known as gatox_lunch | ||
| === alan_g is now known as alan_g|life | ||
| === dandrader|lunch is now known as dandrader|bank | ||
| === om26er|away is now known as om26er | ||
| === gatox_lunch is now known as gatox | ||
| === dandrader|bank is now known as dandrader | ||
| MCR_ | Hi @all :) | 19:22 |
| alecu | hi! | 19:23 |
| MCR_ | andyrock, hi - do you have a minute ? | 19:24 |
| MCR_ | A volunteer to set up a PPA with Compiz 0.9.10-dev and Unity/nux/libunity for Raring would be needed... | 19:26 |
| MCR_ | Since we had an ABI break, there is no way to run latest Compiz with latest Unity on Raring without self-compilation... | 19:27 |
| MCR_ | Seems like *nothing* here builds correctly: https://code.launchpad.net/~unity-team/unity/trunk/+recipes | 19:28 |
| MCR_ | Please see bug #1185778 for details... | 19:29 |
| ubot5 | bug 1185778 in Unity "Latest Compiz ABI not compatible with Unity anymore: unity : Depends: compiz-core-abiversion-20130125" [Undecided,Invalid] https://launchpad.net/bugs/1185778 | 19:29 |
| MCR_ | bregma ? | 19:30 |
| MCR_ | Trevinho, ^^ | 19:31 |
| 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:46 |
| eean | is there logic somewhere on what is 'allowed' in the indicator? | 20:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!