[07:17] hey mmrazik! [07:17] mmrazik: FYI https://code.launchpad.net/~robru/webbrowser-app/packaging/+merge/153650 [07:17] I think you need to configure CI for it [07:20] didrocks: its there. for some reason the triggering was stuck. I'm using some locking mechanism and there was a stuck process holding the lock (i.e. running but stack) [07:20] ok :) [07:20] this happened 2nd time in the last several months :-/ [07:20] mmrazik: the CI does use some kind of ppa? [07:20] didrocks: oh... like a local repo? [07:21] local repo or ppa [07:21] I would have except that some are failing. [07:21] didrocks: not really... maybe stuff like qt5-propper [07:21] ok [07:23] how do I flip through an apps open windows like alt+tab but app specific (i.e. if i have 5 terminal windows open) [07:24] didrocks: btw. the debian/rules is indeed broken in that merge proposal (AFAICS) [07:24] mmrazik: oh? I missed that [07:25] ah tab/spaces i guess [09:43] Saviq: just readin your mail... what you mean with "But the notion of focus is limited to text entry fields." ? [09:43] mzanetti, that in a touch-only interface there is no focusing, other than on a text entry field [09:44] Saviq: nope... [09:44] mzanetti, with keyboard navigation you focus on items to navigate between them [09:44] Saviq: xbmcremote is fully navigatable with keyboard only. and there is one textfield in the whole app [09:44] mzanetti, yeah [09:44] mzanetti, of course [09:45] Saviq: there is always some focused element... touching with your finger just doesn't care about it [09:45] mzanetti, but when you only use a touch interface, you wouldn't know, would you ;) [09:45] Saviq: infact, touching a mouse element puts the activeFocus to the next wrapping FocusScope [09:46] mzanetti, yes, sure, but still, it doesn't affect a touch-only interface at all, does it [09:46] Saviq: no... but where do we have a touch-only interface? [09:47] ok... right now the shell probably is :D but that needs to change [09:47] mzanetti, yup ;) [09:48] mzanetti, anyway, I know - the examples could've been better [09:48] Saviq: I just didn't understand that part... [09:48] fully support everything else in that thread [09:48] mzanetti, and if you guys prove me wrong (i.e. there won't be a use-case where we need to differentiate based on available input) [09:49] I'll be happy as hell ;) [09:49] Saviq: well, I think there shouldn't. IMO its bad that notifications are click through on the desktop and not on the phone... [09:49] but thats another discussion again [09:50] mzanetti, I agree [09:50] mzanetti, but click-through on touch would be broken [09:50] Saviq: its also on the desktop :D [09:50] mzanetti, that's disputable ;) [09:50] *hides* [09:51] mzanetti, but I do agree we need to revisit stuff like that [09:52] Saviq: I guess what you meant is not that theres no "focus" on touch ui's but rather there's no "onMouseOver" on touch uis. that makes a difference [09:53] mzanetti, no, I meant focus [09:53] mzanetti, as the only things that you do focus are text entries [09:53] even if behind the scenes focus travels with you [09:54] Saviq: not agreeing here... first, yes, it travels with you, which makes a difference implementation wise, and second, there are cases where you actually highlight it too - eg. copy/paste [09:55] mzanetti, implementation wise, sure it makes a diff, but that's only when you plan to allow keyboard navigation [09:55] if you don't care about keyboard nav, you don't need focus at all [09:56] thats true... but we do care about that I guess... anyways, we're going round in circles... I think we both have the same opinion on how to handle the whole situation... no need to dispute over wordings :) [09:56] mzanetti, c/p you mean selecting text in a browser? I don't know if I treat that as focus... even with our browser you can select text for c/p without focusing it [09:56] mzanetti, yeah ;) [09:57] mzanetti, I did mean, overall, that we should _not_ differentiate if at all possible [09:57] but if we _do_, then, if at all possible, not based on the abstract / arbitrary form factor variable [09:57] full ack [10:14] tsdgeos: hey ho! [10:14] tsdgeos: friendly reminder: https://code.launchpad.net/~mzanetti/autopilot/faqs/+merge/152864 :) [10:14] ah sorry [10:15] np [10:15] i thought that had my implicit ok [10:15] i'll give you the expliciti one :D [10:15] tsdgeos: seems noone wants to top-approve as long as you have the Needs Fixing in there [10:15] :) [10:17] mzanetti: fixed, are you finding someone else to top approve? or want me to do it too? [10:18] tsdgeos: its ok... probably thomi should top approve stuff that goes to python-autopilot [10:18] oki [10:31] Saviq: do you remember why we need the super friends ppa? [10:31] Saviq: i don't have any package installed from it and stuff compiles/links just fine [10:35] tsdgeos, why qmluitests is kept separate? [10:35] Cimi: separate to what? [10:35] tsdgeos, unittests [10:36] Cimi: becasue it needs to open a window that needs gl and the builders don't have that thus make test would fail [10:36] tsdgeos, ah I see [10:38] Cimi: is https://code.launchpad.net/~unity-team/unity/phablet.crossfadeimage-tests/+merge/153221 ready for review? want me to have a look? [10:39] tsdgeos, ready [10:39] tsdgeos, I'm about to start testing dashbar botto swipe [10:39] oki [10:42] tsdgeos, we might only need it for quantal [10:42] tsdgeos, the people lens uses libfriends [10:44] Saviq: does it? i don't have libfriends here and it compiled fine :-S [10:45] Saviq: ah, all goes thorough dee it seems [10:45] tsdgeos, ok, it uses Dee directly [10:45] so you don't need it on compile time [10:46] tsdgeos, yeah [10:46] so we probably need friends on runtime [10:46] shall we add that to some of the apt-get install we do? [10:46] tsdgeos, it's not a hard req [10:47] oki [10:47] Saviq: so https://code.launchpad.net/~aacid/unity/more_build_work/+merge/153743 [10:47] tsdgeos, we'll just have to describe it in the docs [10:47] tsdgeos, and in that case drop the super-friends PPA [10:48] right, let me drop it from that MR then [10:48] yup [10:48] quantal too, right? [10:56] in the dashbar tests I need to have a model of the lenses, how do I create a fake one or use the existing? [10:59] good question :D [10:59] do you need to have fake ones to inject some values? [10:59] or using the existing ones is ok? [11:00] tsdgeos, it's ok [11:00] Cimi: https://code.launchpad.net/~unity-team/unity/phablet.crossfadeimage-tests/+merge/153221 looks ok to me, any reason you did not put the "readonly" to running ? [11:01] tsdgeos, that part was added by mzanetti [11:01] tsdgeos, I am not sure we need it at all!! [11:01] mzanetti, why did you add running property? [11:02] for the waitForAnimation part i gather [11:02] tsdgeos: Cimi: nope. I forgot... should be readonly [11:02] mzanetti: can you update it and then i'll approve the MR [11:02] mzanetti, but why do we have it in the first place I meant? [11:02] sure [11:03] Cimi: to not have to rely on wait() to know when the animation is done [11:03] mzanetti, but it's not needed in unity [11:03] mzanetti, just for tests... [11:03] Cimi: besides, it could be useful for implementations too when you want to make sure to not set a new image before the previous animation is completed [11:04] mmm ok [11:04] Cimi: and its perfectly valid to add properties that ease up testing [11:04] Cimi: as long as they don't kill memory or cpu [11:04] mzanetti, they make code more complex [11:05] Cimi: I don't agree that adding one property exposing some state of a component makes code more complex... [11:05] mzanetti, one property is nothing [11:05] mzanetti, but one, two or other changes for each file [11:05] will increase complexity [11:05] Cimi: sure... you shouldn't add 50 lines of javascript [11:06] but look at the tests... I think yours - with the wait for the animation - were way more complex then my version [11:06] mzanetti, anyway, this property might also be useful when using it, so it's good to have it [11:06] so this change actually simplifies the code - as tests are code too [11:08] mzanetti, I used wait to avoid adding properties indeed [11:09] hving a look at the diff it seems the property simplifies the test quite a bit [11:09] mzanetti: just add the readonly and let's approve it [11:12] tsdgeos, so how do I use the models? [11:12] Cimi: not sure, which file are you testing exactly [11:12] ? [11:12] tsdgeos, dashbar [11:13] Cimi: i think injecting a fake model here makes more sense tbh [11:13] y [11:13] ok [11:16] tsdgeos: done [11:16] mzanetti, https://pastebin.canonical.com/86996/ can you reduce that diff, please? [11:17] mzanetti, looks like you didn't refresh before changing :/ [11:17] mzanetti: reject https://code.launchpad.net/~mzanetti/unity/xvbf-test/+merge/151928 right? [11:18] Saviq: oops [11:19] mzanetti, I tried to sanitize the work items a bit, with correct milestones and such === mmrazik is now known as mmrazik|lunch [11:19] Saviq: is there a way to just revert my change again or do I manually undo the diff? [11:21] tsdgeos: yes... I ca delete it [11:21] mzanetti: ok [11:23] Cimi: mzanetti: what happened to https://code.launchpad.net/~mzanetti/unity/phablet-rename-notepad/+merge/151197 ? [11:24] tsdgeos: have to ask Ugo [11:24] I'll do [11:29] Saviq: I hope it should be ok again... please have a quick check [11:29] mzanetti, cheers [11:29] tsdgeos: Ugo took care about the MP [11:29] mzanetti: meaning? [11:29] we should approve ours? [11:30] tsdgeos: what happened here is this: [11:30] notes-app got renamed. that requires changes in notes-app, the shell, and the image generation project - mostly at the same time [11:31] so when an app gets renamed I usually review all 3 MP's but don't top-approve any of them [11:31] and leave that to the developer of the app to make sure its in the correct order/timeframe [11:31] seems that approach has failed here [11:32] but its approved now [11:32] ok :-) [11:33] mzanetti: if you add the readonly to lp:~mzanetti/unity/preview-play-button-size and lp:~unity-team/unity/phablet.crossfadeimage-tests we'll get down to only 12 branchs in review :D [11:34] tsdgeos: I will... === mmrazik|lunch is now known as mmrazik [11:36] Cimi: i see you approved https://code.launchpad.net/~unity-team/unity/phablet-people-listview-carousel/+merge/153154 but not top approved, what is missing? you prefer someone else to have a look? [11:39] tsdgeos, yes [11:40] Cimi: ok, i can do another review, if you want, can you give me some edge cases i should check when running in the tablet, etc? so i can check those before reading the code and make sure it makes sense? [11:41] tsdgeos, I don't have a tablet [11:42] tsdgeos, I think the best idea would be playing with it and seeing if you can see regressions [11:42] Cimi: ok [11:42] tsdgeos, I tested and there aren't for me [11:53] ok guys, i tried to work on ubuntu online accounts but when running dpkg-buildpackacge in signon-plugin-oauth2-0.15 in raring i get this: http://pastebin.com/MhjPaf3w [11:55] didrocks: we have some packaging changes (adding a subpackage with autopilot tests) for autopilot-qt [11:55] I assume that can't go into raring, right? [11:56] mmrazik: autopilot-qt is still not in raring. I know that cyphermox was working on that some days ago [11:56] shall I branch lp:autopilot-qt into lp:autopilot-qt/raring and change the cupstream2distro-config stuff? [11:56] didrocks: oh... right [11:56] mmrazik: so coordinate with him first please [11:56] ok [11:56] mmrazik: maybe we can have everything in one shot :) [12:02] gusch: do you have a tablet? [12:03] ok, i will just file a bug against signon-plugion-oauth2 when i get back home [12:03] oh not even tablet is needed [12:04] tsdgeos: yes [12:05] gusch: https://code.launchpad.net/~unity-team/unity/phablet-people-listview-carousel/+merge/153154 needs fixing [12:05] looks like there is some vertical spacing missing [12:05] or something [12:05] i get lots of overlaps where the carousel is used [12:07] tsdgeos: added the readonly on both... in the play-button one its a bit useless, but ok [12:08] tsdgeos: ah - I see the implicitHeight is not fixed - I'll push an update [12:08] mzanetti: maybe qml can do some optimization, won't hurt [12:08] yeah sure... I've added it already === MacSlow is now known as MacSlow|lunch [12:10] tsdgeos: pushed [12:11] tsdgeos: ups - no, there was an error [12:15] gusch: can we get a test for the implicitheight? do you think it's hard? [12:15] tsdgeos: so far I have tests for the JS only - and no plans to extend that [12:16] tsdgeos: reason is, that I don't work on the shell anymore ... [12:17] Saviq: while testing PageHeader.qml we noticed this: https://pastebin.canonical.com/87001/ [12:17] gusch: :/ [12:17] gusch: ok, the MR still needs fixing though, on the tablet it looks very different from the current one (i.e. "too much" spacing) [12:17] Saviq: I think the PageHeader shouldn't directly access the greeter, instead that Connection should be outside the component [12:18] mzanetti, yeah, bad shortcut [12:18] gusch: i'll comment and let's see who fixes it since i guess you are not doing it because you are not a shell guy anymore [12:18] tsdgeos: I pushed the update for the implicit height now [12:18] ack... no problem... just wanted to know if you agree [12:18] yep, seen [12:18] mzanetti, this should probably be exposed on the shell [12:19] mzanetti, accessing greeter directly _anywhere_ outside of Shell.qml is bad [12:19] yeah... [12:31] woot, i can use the hud to add contants in the telephony app, someone has been wiring up stuff :-) [12:46] tsdgeos, :) [12:47] ohh, i see the patch for fast window switching got some praise even on the reg http://www.theregister.co.uk/2013/03/04/ubuntu_13_04_review/page2.html :-) thanks guys! === _salem is now known as salem_ [13:06] Saviq: mzanetti hey guys, thanks for updating bp's, i am totally for using "13.04-month-5" monikers [13:06] np :) [13:06] only wonder was....will it "screw up" 13.04 reporting metrics [13:06] i asked warner but never got an answer [13:06] kgunn, those are defined milestones [13:07] * mzanetti doesn't know too much about how those metrics are collected [13:07] Saviq: right, understand...but that work isn't targeting 13.04 as a whole [13:07] i'm still ok with it [13:07] hi is there a Mir for ubuntu desktop which i can try? thnx [13:07] kgunn, true, I was just adhering after the ML discussion [13:08] Saviq: [13:08] Saviq: what they get for not answering :) [13:08] i'm ok with it [13:08] kgunn, ;) [13:08] zvuci, http://unity.ubuntu.com/mir/ should help [13:08] zvuci, there's also #ubuntu-mir [13:08] zvuci: hang on digging [13:08] i was there [13:09] i mean is it working [13:09] zvuci: https://wiki.edubuntu.org/Mir/GetInvolved [13:09] like normal desktop [13:09] ok [13:11] zvuci: if you're curious about what we're trying to do and when read this http://voices.canonical.com/user/201/ [13:14] Saviq, I'm creating a fake model for dashBar, the name should be reachable via lens.name, how do I fake this? [13:14] mzanetti, a MockLens component with name as property? [13:14] rm [13:14] Cimi, ^ [13:15] mzanetti, sorry [13:16] Saviq, where is MockLens? [13:16] Cimi, there isn't [13:16] ah ok [13:16] Cimi, you need to create it [13:16] ah ok [13:16] I thought we were reusing something [13:18] thnx kgunn i get the direction [13:20] Saviq, I'm lil confused: I have ListElement { MockLens { id: lens; name: "music" } } ? [13:21] I don't think, where am I failing? [13:21] qt docs are not explaining this case [13:21] Cimi, ListElement is flat [13:21] Cimi, you can't use it like that [13:21] ah ok [13:22] Saviq, so what shall I use? [13:23] Cimi, I don't think it's possible without C++ [13:25] mzanetti, ideas ^? [13:25] mzanetti, Cimi needs a list model that will expose a role "lens" that will have properties [13:25] ok [13:26] Saviq: Cimi: hmm, I think you have to do it like we did with the filterGrid [13:26] hmm /me tries with a JS array [13:26] dashBar has source: "graphics/lensIcons/%1.png".arg(lens.name) [13:26] it's the only bit used of the model [13:26] didrocks, hey [13:30] Cimi, we'll need the mock lens in other places, too === MacSlow|lunch is now known as MacSlow [13:32] mzanetti, we didn't test the filter grid afaics [13:32] Cimi: no... not with testing. when we set them in the lens [13:33] Cimi: the ListModel only holds the string names and the are actually loaded with a Loader where you can set other properties from the ListModel [13:33] ah I see [13:34] mzanetti, like Data ? [13:34] Cimi: Data? [13:35] Cimi: Like in DashHome.qml for example [13:35] Cimi: you write the MockLens.qml as string in there and add the properties you want [13:36] Cimi: later in the Loader you load the Mocklens.qml using the value from the model and in Loader.onCompleted: you set the rest of the properties in there [13:36] something like that [13:38] hey davidcalle [13:39] * Cimi lunch [13:39] Saviq: what exactly is the InputfilterArea supposed to do? [13:40] mzanetti, it says to the input system "don't pass those events to the apps" [13:40] Saviq: I wrote tests for it... doesn't seem to worl [13:40] work [13:40] Saviq: however, seeing it imports Ubuntu.Application it might not work on desktop only [13:40] mzanetti, you'd have to test that in another application [13:41] mzanetti, and no, it won't work on desktop [13:41] Saviq: thats bad [13:41] I don't understand why we have the Ubuntu.Application not available on the desktop [13:41] it already caused tons of workarounds [13:41] mzanetti, because no one wrote it [13:41] mzanetti, we'd have to wrap BAMF and stuff [13:42] mzanetti, and anyway it needs to be rewritten on top of Mir [13:42] Saviq: no... we just do that component loading in there instead of 5 times in each app [13:42] Saviq: not saying all the functionality needs to be there [13:42] Saviq: but this component loading workaround in every app is just insane [13:42] mzanetti, of course [13:42] didrocks, how do you want to handle scopes depending on non-default music players? Depends on the music player and "enhances" it? [13:43] davidcalle: I would say "suggests" it [13:43] davidcalle: as a depends would pull it by default [13:43] mzanetti, not sure what to tell you, we need that API available on the desktop, yes [13:43] in that form or another [13:44] didrocks, I wasn't thinking of having them by default because of the depends, but indeed, suggests solves it. [13:44] davidcalle: let's have all scopes installed by default [13:44] Saviq: ok... anyways, I wrote some test but they fail of course - as the InputFilterArea does so too [13:44] davidcalle: then, you have the functionnality if it's installed [13:44] mzanetti, but it needs to lose functionality like the InputFilterArea, as that's only supposed to be available for the shell [13:45] davidcalle: you just need to ensure it won't fail if not installed :) [13:45] mzanetti, there [13:45] didrocks, tests should handle this case already. Will check. [13:46] mzanetti, current Ubuntu.Application was thrown together on an as-needed basis [13:46] with no real long-term goal behind it [13:46] davidcalle: thanks [13:47] Saviq: yeah... I just remember back in december I wanted to move the loading inside the component because in all the apps we were introducing the workaround... someone said I shouldn't do that [13:48] mzanetti, we need to reevaluate what's available in that API and move stuff that's supposed to be available to applications out [13:48] and preferably implement for X desktop [13:49] Saviq: yep. lets do that right after we are sufficient with testing [13:49] mzanetti, can you add a work item to iteration 0, please? [13:49] Saviq: in the meantime, not sure what to do with this one... https://code.launchpad.net/~mzanetti/unity/phablet-test-inputfilterarea/+merge/153803 I think we could merge nevertheless as the qmluitests are not yet executed in jenkins anyways [13:50] Saviq: yes, I'll add the work item [13:50] mzanetti, those tests wouldn't work anyway [13:50] no? [13:50] mzanetti, the InputFilterArea doesn't do anything in the scope of the current app [13:50] i.e. shell [13:50] mzanetti, it only informs the input system [13:50] to _not_ deliver those events to other apps [13:50] right... [13:51] mzanetti, that's why I said you'd need a separate app to verify that it works [13:51] got it... ok. I'll make it happen. but in that case probably only once it works [13:52] mzanetti, and testing that belongs to whatever provides that API anyway.. [13:52] * Saviq biab [14:24] mzanetti: can you review https://code.launchpad.net/~aacid/unity/phablet_hud_results_test/+merge/153816 or want me to find someone else? [14:25] tsdgeos: I can do [14:25] great :-) [14:29] tsdgeos: the test would be nicer using the _data() function... (for next time. don't need to change it now) [14:30] mzanetti: oki :-) [14:31] didrocks: mmrazik: autopilot-qt is supposed to be ready, just needs the bootstrap commit IIRC [14:31] cyphermox: FFe is accepted? [14:31] cyphermox: ok. Do you think we can get the libautopilot-qt-autopilot subpackage as well? [14:32] is that a merge pending? [14:32] too many things at once, I haven't finished going through my checklist this morning [14:39] didrocks: yeah the ffe is approved provided we can get AA review [14:40] \o/ [14:40] I'm pretty sure you will a AA review :p [14:40] I'm pretty sure I'll do it ;) === dandrader_ is now known as dandrader|afk [14:44] yeah, not worried about that [14:44] Saviq: did you have time for https://code.launchpad.net/~aacid/unity/more_build_work/+merge/153743 ? [14:44] tsdgeos, at it now [14:44] cool :-) [14:45] didrocks: https://code.launchpad.net/~mathieu-tl/autopilot-qt/bootstrap/+merge/153827 [14:45] duh, my 3G modem doesn't work with the new ModemManager :'( [14:45] cyphermox: looks good. However, i would add the bug # for the FFe while you are at it [14:46] oh shucks [14:46] of course [14:47] updated... [14:47] tsdgeos, only thing that looks weird is: "quantal=true; if (raring) quantal=false" - maybe we should have "raring=false; if (raring) raring=true" instead? ;) [14:47] didrocks: I'd add it to the qa stack now as well [14:48] tsdgeos, also, weren't you removing friends from there? [14:48] Saviq: yeah, thought it was a bit weird too when i read it, now that we have a second opinion i'll change it [14:48] didrocks: where did you move the stack config to? [14:48] Saviq: wasn't sure if i shall kill it from quantal too, i kill it too right? [14:48] cyphermox: great! so in tomorrow daily? [14:48] yeah [14:48] cyphermox: see my email a week ago, lp:cupstream2distro-config [14:48] I want it in tomorrow daily [14:48] tsdgeos, yeah, it's a soft dep, we'll talk about it in some docs [14:49] oki [14:49] gusch: saw my new comment? [14:49] cyphermox: mmrazik was talking about a new subpackage, maybe everything should land at the same time? [14:49] mzanetti: and another small one https://code.launchpad.net/~aacid/unity/phablet_test_searchbar_set_query/+merge/153828 [14:50] cyphermox: and please, unblock the current stack in manual publication mode while you are at it :) [14:51] tsdgeos: ok - but what spaces? [14:51] between the items of the carousel [14:52] e.g. with your version if i go to videos [14:52] there is spaces between them [14:52] with the current one they overlap [14:53] tsdgeos: is it a one pixel space? [14:53] gusch: no it's like 30 [14:54] i'll give you a screenshot [14:54] tsdgeos:yes, thx [14:55] Saviq: pushed the friends removal and raring/quantal logic switching [14:55] tsdgeos, cheers, can you update the [14:55] nothing [14:57] tsdgeos, actually, yeah - update debian/control with a "qt-components-ubuntu | qtdeclarative5-ubuntu-ui-toolkit-plugin" dep [14:57] and we can redo the commit message to say "prepare for package renames" [14:57] Saviq: is that the syntax? [14:57] qt-components-ubuntu (>= 0.1.5~) | qtdeclarative5-ubuntu-ui-toolkit-plugin, [14:58] tsdgeos, yup, looks good [14:58] pushed === dandrader|afk is now known as dandrader [15:02] tsdgeos: ah - I can see it - I guess it is a regression by the last change of Cimi - checking [15:02] didrocks: moo? [15:02] cyphermox: and please, unblock the current stack in manual publication mode while you are at it :) [15:02] you mean QA? [15:02] gusch: ok, i was uploading the screenshots now :D [15:02] cyphermox: what we discussed in MP, yeah, QA ;) [15:02] so done :) [15:02] alright, yeah [15:03] thanks! [15:03] tsdgeos, FYI grep -q [15:04] Saviq: ? [15:04] tsdgeos, "grep > /dev/null" == "grep -q" [15:04] ah [15:05] tvoss: can't make one on one today [15:05] the man page confuses me [15:05] tvoss: conflicting meetin [15:05] "Exit immediately with zero status if any match is found, even if an error was detected." [15:05] if there is an error do i want a 0? [15:06] kaleo, ack, same here [15:06] tsdgeos, if a match was found, yes [15:06] probably [15:06] ok, i'll change it [15:06] mzanetti, can you help me with the mocklens :D [15:06] tsdgeos, you can go one line, even [15:06] tsdgeos, if grep -q raring /etc/lsb-release; then [15:06] Cimi: whats the issue? [15:07] sure, you can do all sort of stuff on bash :D [15:07] mzanetti, I don't understand at all [15:07] i feel much more confortable with the other tbh [15:07] tsdgeos, +1 [15:09] Saviq: new grep pushed [15:09] tsdgeos, cheers, that will be all, I think [15:09] Cimi: more detailed please [15:10] mzanetti, you game me directions, a [15:10] but I don't understand what I am supposed to do [15:10] you said I should write mocklens.qml as strings and add properties [15:10] what you meant write as string, and which properties? [15:10] camerin: oh ok [15:11] camerin: sorry... should have been Cimi [15:11] why I need a loader, what I need to load [15:11] Cimi: ok.. give me a few minutes and I'll pastebin something together [15:11] mzanetti, thanks [15:14] tsdgeos: now the spacing should be fixed again as well [15:14] Cimi: hmm... actually that seems to be even easier... what exactly do you want to do? [15:16] mzanetti, dashBar needs [15:16] s/needs/uses/ [15:16] "source: "graphics/lensIcons/%1.png".arg(lens.name)" [15:17] so I guess I need a model with 5 items, music, people, home, apps, videos [15:18] Cimi: hmm... first I'd recommend to make "lens" a property of the component... we should never access variables from outside the component [15:23] Cimi: still around? [15:23] mzanetti, yes [15:24] Cimi: do you agree with my previous statement? [15:24] mzanetti, I didn't understand :) [15:24] hehe [15:25] Cimi: so... the Component DashBar.qml calls lens.something [15:25] Cimi: however, "lens" is not defined in the while DashBar.qml [15:25] mzanetti, lens is in the model [15:25] mzanetti, there is a listview, each item has index, lens [15:26] mzanetti, lens is a role [15:26] I see... sorry then [15:28] Cimi: and whats the issue with just doing this: [15:28] model: Lenses {} [15:29] gusch: ahh much bettar [15:29] tsdgeos: should 1:1 visual identical now again [15:32] mzanetti, lenses are filtered [15:33] https://code.launchpad.net/~mterry/unity/poeple-typo/+merge/153840 wops :S [15:33] Saviq: are they even if you don't wrap it in a SortFilterProxyModel? [15:33] mzanetti, well, no, then they're not [15:34] mzanetti, but TBH Lenses should be non-creatable [15:34] if we have that typo ↑↑↑ how does it work?¿ [15:34] tsdgeos, ::shrug:: [15:34] Saviq: you mean setting it by a contextProperty? [15:34] mzanetti, yes, and register as non-creatable [15:35] gusch, thanks for the fix [15:35] tsdgeos, mterry, there's two places that populate that [15:35] Saviq: yeah ok... but then that's just the same for the tests... [15:35] gusch, fun enough, I fixed locally on friday, forgot to do bzr push :) [15:35] tsdgeos, mterry, depending on whether the lens is loaded onCompleted or not [15:35] Saviq: i see, gonna approve the change then [15:35] tsdgeos, yeah, thanks [15:35] Cimi: try with using model: Lenses {} for now. and if we change them to be non-creatable we need to do the same as tsdgeos does with the HUD (mocking it all with C++) [15:35] Cimi: ah - hehe - it was too easy, so I got the fix too fast ;) [15:40] gusch: Cimi: did we find any way to evaualte if the listview is really better? [15:41] or we just assume it's better because it'll have less elements [15:41] tsdgeos, people say it will consume less memory [15:41] tsdgeos, although I don't like the workaround [15:42] and I prefer repeater coding-wise [15:42] but we don't have other choices if we want to use listview [15:42] tsdgeos: in my early test it saved a few MB (not a lot, and measurement were not very relieable) [15:42] gusch, those tests are not valid because you were using cacheBuffer I believe [15:42] tsdgeos: but anyway - Repeater does scale well (think of having 100, or even more items) [15:43] does not you meant [15:43] yeap [15:43] listview should scale better [15:43] Cimi: which "workaround" you mean? [15:43] tsdgeos, enlarging the area adding left and right negative margin [15:44] ah, ok [15:44] it's a bit weird yeah, but with qml sometimes you have to do that stuff, it's not that horrible i think [15:44] +1 [15:45] mzanetti, I've replied to your comments and updated https://code.launchpad.net/~dandrader/unity/phablet_tst_FilterGrid/+merge/153599 [15:47] dandrader: the wait(100) is a bit... lets say - not that good [15:47] :D [15:47] let me check if it works without that magic line :) [15:48] mzanetti, it does. will remove them now [15:48] mzanetti, btw, you can do "make testFilterGrid" [15:49] dandrader: if you need to wait, use "tryCompare(filtergrid.height, filtergrid.totalContentHeight)" or something like this [15:49] dandrader: albert did that in the autopilot tests and it seems to work fine [15:49] dandrader: yeah, the cmake stuff you did is very nice [15:49] mzanetti, yes, I did this tryCompare thing in my update as well [15:50] mzanetti, pushed the wait(100) removal [15:51] dandrader: it doesn't compile any more... I think you need to merge trunk and upgrade your libdee-qt-3 [15:52] yeah === alan_g is now known as alan_g|tea [15:52] s/libdee-qt5-3/libdee-qt5/ [15:52] mzanetti, ok, will check that [15:57] mzanetti, it should just work if you take lp:unity/phablet and do a "bzr merge lp:~dandrader/unity/phablet_tst_FilterGrid". As opposed to using lp:~dandrader/unity/phablet_tst_FilterGrid directly [15:58] dandrader: ok. I'll try [16:00] cyphermox, what's the story with indicator-head's red status? Is it anything for unity-head to worry about? === alan_g|tea is now known as alan_g [16:04] tsdgeos, hmm, why do I have to confirm apt-get like 6 times on initial ./build -s? [16:05] mterry: I think it's probably safe, there's a commit that can't land and that I'll need to revert, but otherwise the tests seem to be failing .. are the same as are often failing [16:05] Saviq: because we don't have any -y in the apt-get install [16:05] mterry: perhaps sil can comment [16:05] Saviq: can add [16:05] doh [16:06] tsdgeos, maybe we could have a -y option for the script... [16:06] mterry: there hasn't been meaningful changes to indicators lately anyway [16:06] tsdgeos, but adding -y everywhere sounds good enough [16:06] * tsdgeos adds [16:08] Saviq: pushed [16:08] dandrader: I agree on the ResponsiveGridView comment. And with the last comment I'm just trying to push the mindset a bit... Often its not much more efforts to just add one testrow that checks if stuff triggers a crash when setting insane values for example [16:08] dandrader: approving [16:10] mzanetti, ok, thanks [16:14] mzanetti, Lenses is in unity plugin? [16:14] Saviq: do we want something like this? https://code.launchpad.net/~juhapekka-piiroinen/ubuntu-ui-toolkit/bazaar-plugin-precommit-hook-for-makecheck/+merge/153842 [16:14] Cimi: yes [16:15] mzanetti, looks good [16:15] mzanetti, I think I need to load it somehow from the makefile [16:15] mzanetti, we should also check whitespaces :) [16:15] Cimi: I fear you have to spend the effort to mock it out in C++. There is a Hud example already [16:15] mmm ok [16:15] Saviq: where? at the end of lines? [16:16] mzanetti, and that no \t is used [16:16] Saviq: hm... could run astyle on stuff yeah [16:17] tsdgeos, did you see https://code.launchpad.net/~aacid/unity/more_build_work at the top? [16:17] mzanetti, I'll go and study a bit this HudClient then [16:17] Saviq: yeah, ignore that, it'll just work fine [16:18] Saviq: happens because i push with "bzr push --stacked-on bzr+ssh://bazaar.launchpad.net/+branch/unity/phablet/" so that it does not take hours for each new branch [16:18] tsdgeos, it doesn't work _just_ fine - bzr+http doesn't work, but yeah it works with bzr+ssh [16:18] tsdgeos, good tip [16:18] tsdgeos, wouldn't --stacked-on lp:unity/phablet work? [16:19] Saviq: i remember it gave some error [16:19] it was obviously the first thing i tried [16:19] tsdgeos, mhm [16:19] let me try again [16:19] I think I tried it too after albert gave me the above line [16:19] bzr: ERROR: Server sent an unexpected error: ('error', 'UnsupportedProtocol', 'Unsupported protocol for url "lp:unity/phablet"') [16:21] Saviq: yeah bzr+http doesn't work, i suffered that once when trying to checkout from a non logged in VM [16:21] but tbh i can live with that if it means i push in 10 seconds instead of 10 minutes [16:21] tsdgeos, guess how I found out ;) === dandrader is now known as dandrader|afk [16:32] mmrazik: rev 82, adding unity-lens-photos please :) [16:34] didrocks: done [16:34] didrocks: btw. I'm still bootstrapping the local repo and using the PPA. At one point of time I'll need to remove the ppa and use the local repo only [16:34] unfortunately daily > bzr [16:35] mmrazik: it was designed for that [16:35] so that d > b [16:35] is it a problem? things shouldn't build-dep on d* [16:35] didrocks: sure.... I mean unfortunately for the bootstrapping purposes. I can't keep the PPA _and_ the local repo and hope the PPA will be irreleveant sooner or later [16:36] mmrazik: ah, yeah, as we don't succeed a full stack build [16:36] mmrazik: you don't have the merge back [16:36] so dont' get the bumped revision [16:38] Saviq, I'm trying importing Unity from plugins dir [16:38] but I get symbols errors [16:38] Cimi, ./run [16:38] QWARN : qmltestrunner::UnknownTestFunc() file:///home/cimi/Development/phablet/phablet.dashBar_bottomswipe/tests/unittests/tst_DashBar.qml:19:1: plugin cannot be loaded for module ".home.cimi.Development.phablet.phablet.dashBar_bottomswipe.plugins.Unity": Cannot load library /home/cimi/Development/phablet/phablet.dashBar_bottomswipe/plugins/Unity/libUnity-qml.so: (/home/cimi/Development/phablet/phablet.dashBar_bottomswipe/plugins/Unity/libUnity-qml [16:38] .so: undefined symbol: _ZTIN5unity4dash13PeoplePreviewE) [16:38] import "../../plugins/Unity" [16:38] Saviq, ^ [16:38] Cimi, see what's set there [16:38] ok [16:39] Cimi, you need to use the libs from ../unity_build/build [16:39] mzanetti, maybe we need to patch the unittests to import from that dir too? [16:40] Cimi: that's already happened... should be merged soon [16:41] Cimi: it'll come with this one https://code.launchpad.net/~dandrader/unity/phablet_tst_FilterGrid/+merge/153599 [16:41] mzanetti, studying, thx [16:42] mzanetti, this is qmluitests though [16:42] mzanetti, not unittests dir [16:42] Cimi: ah ok... yeah... can you create the same for those? [16:43] sure [16:43] Cimi: it also has the advantage that "make check" gets more verbose [16:44] ok [16:47] mzanetti: since you did the greeter are you checking mterry's https://code.launchpad.net/~mterry/unity/phablet-greeter-lightdm/+merge/152288 ? [16:50] mterry, hum, autopilot/jenkins are not happy :-( [16:50] mterry, they loop on "2013-03-18 15:40:26,617 dx-autopilot-ati INFO: Caught [Errno 111] Connection refused, retrying sshcheck(180)" [16:51] mterry, same for intel and nvidia it seems [16:54] hi :)) [16:54] tsdgeos, mzanetti: While I would love a review of that, I'm currently fixing that branch's autopilot tests and adding more. But the functionality itself won't change [16:54] fginther, ^ to seb128 's comments [16:55] tsdgeos: mterry: yes, can do [16:56] tsdgeos: https://code.launchpad.net/~mzanetti/unity/phablet-make-check-hook/+merge/153868 [16:57] mzanetti, what line 77 and 82 do? [16:57] https://code.launchpad.net/~dandrader/unity/phablet_tst_FilterGrid/+merge/153599 [16:57] the if equals the elf? [16:57] *else [16:58] Cimi: 77: if (argc == 1) [16:58] Cimi: 82 } else { [16:58] ah ok [16:58] mzanetti, it's a different syntax [16:58] Cimi: 88: } [16:59] Cimi: yes. cmake syntak is a bit weird sometimes... I also think adding the condition to else() and endif() is optional, but common practice [16:59] mzanetti, never used cmake before, just automake [16:59] was curious [16:59] mzanetti: oh stealth stuff :D === cyphase is now known as cyphase_ [17:00] Cimi: if you understood automake I guess you are the one that will answer all build system questions now :D [17:00] * mzanetti bails out at latest in the 5th line of any autotools script [17:00] mzanetti, understood is a hard word :D [17:00] mzanetti, Saviq: "hud-client-1", which the build-script for unity-phablet needs... is meant to come from where? === cyphase_ is now known as cyphase [17:00] mzanetti, I used it in my libraries and cried when needed [17:00] MacSlow, it's build locally === cyphase is now known as cyphase_ [17:01] mzanetti: how does that work? do i need to do it in each of the dirs? or once i do make install once it'll work everywhere? [17:01] MacSlow, installed in ../unity_build/build/ === cyphase_ is now known as cyphase__ [17:01] MacSlow, remember to use ./build [17:01] MacSlow: did you do ./build -s ? [17:01] it sets up PKG_CONFIG_DIR [17:01] tsdgeos: see the desription [17:01] tsdgeos: you have to install manually... [17:01] mzanetti: doesn't answer my question :D [17:01] mzanetti: for each of the repos or just once? [17:02] i guess for each of the repos [17:02] tsdgeos: hmm... I think just once for all [17:02] * mzanetti tests to push something else === cyphase__ is now known as cyphase [17:02] Saviq, this is what I get... pastebin.ubuntu.com/5625708 [17:03] tsdgeos: install once, use in all... which is probably not what we want... [17:03] mzanetti: i don't want to run make qmluitests in qt-components repo [17:03] MacSlow: did you do ./build -s ? [17:03] MacSlow, go ./build_unity and see if hud is built/installed properly [17:04] tsdgeos: yes. I agree. I'll fix it [17:04] tsdgeos, bummer... thx [17:04] Saviq, ./build_unity is a script here [17:04] MacSlow: are you in raring or quantal? [17:04] MacSlow, yeah, run it [17:05] tsdgeos, this is on a fresh 12.10 to raring update [17:05] MacSlow: then you may want to wait for https://code.launchpad.net/~aacid/unity/more_build_work/+merge/153743 to be merged or merge it manually [17:05] * tsdgeos eods [17:06] afternoon/evening guys [17:06] tsdgeos, Saviq: doing the -s with ./build now [17:06] tsdgeos, good night [17:06] MacSlow, what it does is run ./build_unity -s; ./build_unity [17:06] mterry, is there anyone else than fginther that knows about utah/jenkins/autopilot there? [17:06] Saviq, I'm waiting for ./build -s to finish first [17:07] mmrazik, ^? [17:07] Saviq, I guess after that issues should be gone [17:07] MacSlow, yeah, that's what will happen [17:07] seb128, mmrazik should yeah [17:07] MacSlow, and that, in turn, builds libunity, UnityCore, hud, people lens [17:07] seb128: whats up? [17:07] and installs in ../unity_build/build/ [17:07] Saviq, I'm still used to do everything manually :) [17:07] mmrazik, hey [17:07] MacSlow, yeah we wasted too much time on doing things manually ;) [17:07] mmrazik, hum, autopilot/jenkins are not happy :-( [17:07] they loop on "2013-03-18 15:40:26,617 dx-autopilot-ati INFO: Caught [Errno 111] Connection refused, retrying sshcheck(180)" [17:07] Saviq, :) [17:08] mmrazik, e.g http://10.97.0.1:8080/job/ps-unity-autopilot-release-testing/label=autopilot-intel/118/console [17:08] Saviq, we had to suffer so our users (3rd-party devs) will have a sweet time hacking on the phone [17:09] seb128: that looks like an utah issue. Not sure If I'll be able to do something with that. Let me check on KVM if there is something obvious [17:09] mmrazik, who would? [17:09] seb128: nuclearbob, jcollado ... [17:09] gema for escalating (if you need to) [17:09] mmrazik, can you ping them? [17:11] Saviq, hm... "./build -s" tries to fetch libnux-3.0-dev ? [17:11] MacSlow, yeah, merge the branch tsdgeos mentioned [17:11] MacSlow, or run with -n [17:11] Saviq, ah ... that's that issue... I see... thx [17:11] that will _not_ do local nux [17:14] got to run... bbl [17:14] cheers === kgunn is now known as kgunnAFK === naee is now known as eean === mhall119 is now known as mhall119|lunch === rsalveti_ is now known as rsalveti === dandrader|afk is now known as dandrader === mhall119|lunch is now known as mhall119 === kgunnAFK is now known as kgunn [18:36] how do I declare a QML property that can hold any js object? [18:40] hmm, seems specifying the property type is optional [18:53] dandrader, "property var name: value" [18:54] dandrader, var can hold anything [18:54] Saviq, thanks [18:54] dandrader, http://qt-project.org/doc/qt-5.0/qtqml/qtqml-typesystem-basictypes.html [18:59] is launchpad broken for you guys too? (cant log in ... Your page was stale.) [19:01] umm [19:01] maybe it just requires 3rd party cookies, grrr [19:24] Cimi, Hi! [19:25] Cimi, the volume slider handler looks distorted and have looked like that since 12.10 Could you look into that please :) [19:26] om26er: Cimi is awfully busy on getting our UnityNext testing up to snuff [19:27] kgunn, ouch, alright I will get someone else look into that. [19:27] om26er: :) no problem [19:27] just that we really need to keep our focus [19:27] or all these folks worrying about enuff time/people to do mir/unitynext [19:28] will be proven true [19:28] om26er: and no worries...we all got needs, i understand :) [19:28] kgunn, Indeed that's a more important issue for the time being === dandrader is now known as dandrader|afk [19:35] seb128, any progress with utah/ [19:35] ? === dandrader|afk is now known as dandrader [19:47] mterry, we brough it to #qa, they think it's an installer issue, so we moved to #ubuntu-devel but they need to get debug logs for cjwatson [19:47] mterry, mmrazik was eod and I'm not sure anyone else was going to follow up on that, I will make sure to keep nagging tomorrow morning ;-) [19:48] seb128, thanks :) [19:48] mterry, installer issue: apparently the username used for preseeding is not respected [19:48] mterry, yw === kgunn is now known as kgunnAFK [21:12] mterry: looks great! [21:12] mterry: https://code.launchpad.net/~mzanetti/unity/phablet-elide-user/+merge/153934 :D === rsalveti_ is now known as rsalveti [21:20] mzanetti, I'm working on a followup branch so that we don't need to rebuild to use the mock liblightdm-qt5-2 library === salem_ is now known as _salem [21:29] mterry: hey [21:29] could you quickly review another small merge? https://code.launchpad.net/~mathieu-tl/libindicator/revert-indicator-ng/+merge/153938 [21:33] cyphermox, done