[01:24] thank you veebers and thomi. === jono is now known as Guest35005 === duflu_ is now known as duflu [08:12] Saviq: read the description! [08:12] tsdgeos, sooorry :D [08:13] Saviq: i tried and failed [08:13] thing is that this is executed not in sync with any call you do, so it's even hard to add a qcompare to -1 [08:14] i was hoping i could make it crash or act weird [08:14] but couldn't [08:14] maybe i'm also defending with count() == 0 or isEmpty in other parts of the code [08:14] but still shouldn't be 0 [08:18] Saviq: so did i convince you in https://code.launchpad.net/~aacid/unity8/timeformattertest_LCALL_C/+merge/200991 ? [08:19] tsdgeos, not really, especially since currently 100% of our tests should run under LC_ALL=C [08:20] tsdgeos, as we don't have any place that should be affected by the locale [08:20] Saviq: ok, so i can move it to cmake and update the CODING file? [08:23] tsdgeos, gimme a few to think what we want there [08:23] sure [08:24] tsdgeos, I've a feeling all our tests should run under LC_ALL=C currently [08:24] should as "they do" or as "we would like to do" [08:24] ? [08:24] tsdgeos, can you still run make -C builddir testfoo to run that test? [08:25] tsdgeos, we would like them to [08:27] Saviq: no, can't find a way to run it individually [08:27] only make test [08:27] or run the binary [08:27] tsdgeos, right, so that's something we should make possible [08:27] ah no [08:27] make timeformattertest [08:27] works [08:28] but doesn't get autocompleted by the bash make autocompleter [08:28] my bad [08:28] tsdgeos, should've used ninja ;) [08:28] i get no autocompletion at all with ninja [08:28] tsdgeos, oh? [08:28] and actually it gets autcompleted now :D [08:29] lol [08:29] don't know, just woke up [08:29] tsdgeos, that good enough for you? [08:30] Saviq: having the LC_ALL in the make step? yeah [08:30] tsdgeos, try and see if we can globally set that for the test env [08:31] tsdgeos, hmm doesn't look like it [08:32] why? [08:32] tsdgeos, you can set_test_properties on a per-test basis [08:32] tsdgeos, but not globally [08:34] but don't we have our own "create test" macro? [08:35] now we don't [08:35] we have parts of it scattered around [08:35] i see [08:35] i.e. set_test_properties [08:35] arg [08:36] i.e. unity8/tests/plugins/Utils/CMakeLists.txt has run_tests [08:36] but it's used there locally [08:37] tsdgeos, right, we could have a global macro for that indeed [08:38] but then it needs more careful thinking [08:38] i.e. in this case we are assuming testname == testfile+.cpp [08:38] but in some other cases we have multiple files [08:38] or different libs to link to [08:38] etx [08:38] etc [08:41] tsdgeos, sure it does :) [08:42] tsdgeos, if you don't want to get into it [08:42] tsdgeos, just move the LC_ALL into CMakeLists.txt for now [08:42] tsdgeos, for that one test [08:42] so boils down to maybe just add a warning in CODING and be done with it :D [08:42] tests are expected to run under the C locale [08:42] done [08:42] then i can blame myself for not following the CODING guidelines :D [08:43] tsdgeos, yup ;) [08:44] ok [08:44] will do that [08:47] Saviq: ok, comment added to CODING [08:48] tsdgeos, cheers [08:58] Saviq: do you want to do https://code.launchpad.net/~aacid/unity8/coding_autopilot_docu/+merge/200974 too or shall i find someone else? [08:59] tsdgeos, looking [09:00] tsdgeos, please add that if you don't `make install`, the tests will run on the system-installed version [09:00] ok [09:05] Saviq: done === om26er is now known as om26erafk [09:28] tsdgeos, https://code.launchpad.net/~saviq/unity8/forgiving-genericscopeview/+merge/201147 please [09:29] mzanetti, can you continue with https://code.launchpad.net/~unity-team/unity8/new-scopes-horizontal-card-layout/+merge/200910 please? [09:29] yes sir [09:30] Saviq: on it [09:30] now i think both my coding file changes are going to conflct... [09:30] tsdgeos, they might indeed [09:31] let's see [09:31] tsdgeos, just merge them together? [09:31] tsdgeos, neither is being -autolanded yet [09:33] Saviq: thanks for the follow up! :) [09:33] karni, sure [09:33] Saviq: ok, reapprove https://code.launchpad.net/~aacid/unity8/coding_autopilot_docu/+merge/200974 then [09:34] i cancelled the other one [09:34] Saviq: looks like good progress to me :)! [09:34] tsdgeos, thanks [09:34] karni, glad to hear that [09:35] karni, I'm flying to Cape Town tomorrow, won't be around much until the 27th, I'll leave you in tsdgeos's capable hands [09:35] karni, he's the one writing the journals and organic grid now [09:35] is anyones indicators not showing up on desktop unity8? [09:36] Saviq: ACK! Thank you :) [09:36] dednick, seems to work fine [09:36] Saviq: hm. must be something funky with mine then [09:37] Saviq: there's a lot more previewListView uses that you have not protected, no? [09:37] tsdgeos, those were the only ones that bit me, but you're right [09:37] dednick: there's the thing that closing down unity8 will kill them [09:37] dednick: so run unity8 and ctrl+c it [09:38] Saviq: i think that there are a few more that would break [09:38] forceNoClip: previewListView.onScreen [09:38] ? [09:39] and the renderloader clicked [09:39] Saviq: yeah, but it restarts them when unity8 starts [09:39] Saviq: why don't you have a previewListView, is it a test? [09:39] tsdgeos, the scope tool [09:40] tsdgeos, but yeah I'm thinking I should make it differently... just get Dash complete, and not GenericScopeView alone [09:40] +1 [09:40] or DashContent at leat [09:40] Saviq: nevermind. old qmenumodel. [09:40] that brings what you need i think [09:40] mzanetti: Could you please merge this today, so we can get it into PPA ASAP? Horizontal card layout would be very handy for my team. https://code.launchpad.net/~unity-team/unity8/new-scopes-horizontal-card-layout/+merge/200910 [09:40] jamesh__: hello! [09:40] :) [09:41] karni: yeah, on it right now. just running tests for a last time [09:41] mzanetti: sweet! thank you :) [09:42] jamesh__: I wanted to finally deal with the mediascanner-v2 release today, but I just noticed that we might want to modify the source package name [09:42] jamesh__: right now it's mediascanner2.0, but not sure if the 'source' package should have a major and minor version - so maybe mediascanner2? [09:42] tsdgeos, ok then, ignore that branch [09:43] * tsdgeos ignores [09:43] what's up with autopilot again [09:44] what :D [09:44] https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1930/artifact/results/autopilot/artifacts/unity8.shell.tests.test_greeter.TestGreeter.test_greeter_background%20%28Desktop%20Nexus%2010%29.ogv [09:44] just doesn't start :D [09:46] it segfaulted like crazy :S [09:46] /var/log/syslog: Jan 10 09:16:47 trusty-amd64-20131210-1707 kernel: [2561012.274762] QThread[29589]: segfault at 1cfb6 ip 000000000001cfb6 sp 00007f2584de7228 error 14 in unity8[400000+c000] [09:46] doesn't make any sense [09:47] tsdgeos, yeah, it's been like that for some runs it seems [09:49] :( [09:49] any clue if it's fauly hardware or something else? [09:50] tsdgeos, we definitely need someone to look at it [09:52] mzanetti: can you detach me a autopilot VM? [09:52] if so i'll have a look [09:52] tsdgeos: sure [09:52] organic grid is almost done [in my mind :D] [09:52] How do I actually work with the unity-scope-tool? [09:53] karni, right now you dont' [09:53] karni, I'm fixing [09:53] oh okay [09:53] karni, will have a branch for you to try in 3 mins [09:54] Saviq: wheee \o/ thanks Michał [09:54] * karni was wondering how to populate unity-scope-tool with an actual scope [09:54] tsdgeos: ps-trusty-server-amd64-2 is yours once the job 881 is done [09:55] tsdgeos: note that jenkins will revert the VM after the job is finished. so give it a minute before starting to work on it or else jenkins will revert your stuff too [09:57] oka [09:59] tsdgeos, https://code.launchpad.net/~saviq/unity8/tool-fulldash/+merge/201150 [10:00] ok [10:00] tsdgeos, actually need fix [10:00] but meeting first [10:00] ok² [10:02] mzanetti: even if the machine is doing qmluitests at the moment i can use it for autopilot tests, right? [10:03] tsdgeos: oh... autopilot... we don't run them in VM any more [10:03] tsdgeos: they are executed on a real machine but I don't have access to that one [10:03] mzanetti: no? [10:03] oh :_/ [10:03] mzanetti: ok, then put the thing back into the pool [10:04] done [10:04] tsdgeos: do you have autopilot failures in jenkins which you cannot reproduce locally? [10:04] mzanetti: unity8 crashing :D [10:05] hmm... but that *should* behave the same on your local machine [10:05] mzanetti: see https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1930/consoleFull for the billions of segv [10:07] i definitely don't get all these crashes [10:31] fginther: ping [10:45] tsdgeos, tool-fulldash fixed [10:47] tsdgeos, going to #ubuntu-ci-eng vanguard to take a look [10:47] oki [10:54] Unity team standup is 2:30 UTC? [10:56] Saviq: so no more scope selector and just swipe left/right? [10:56] karni, +1 [10:56] tsdgeos, yeah, or select by header [10:57] tsdgeos, felt unnecessary to have the selector now [10:57] karni: i invited you to it [10:57] tsdgeos, not entirely happy that all the scopes are loaded all the time [10:57] tsdgeos, but it works, which is more important [10:57] Saviq: but that happened before, no? [10:57] Saviq: or you mean the graphical counterpart [10:57] tsdgeos, no, before it only loaded the single dash page, yeah [10:58] can unity8 be tested on an x86 workstation? Only GUI needed , no sensors or other fancyness of course [10:58] tsdgeos: thanks :) [10:59] Saviq: why the new mouse area? [10:59] tsdgeos, 'cause otherwise I could click on items behind the controls [11:00] janimo: yes, you can run unity8 on a x86 machine [11:00] janimo, it will only run in a window for now (i.e. you can't run real applications yet) [11:00] Saviq, tsdgeos, any particular setup needed or packages not in the trusty archives? [11:01] Saviq: which items behind the controls?¿ [11:01] Saviq: you mean the right hand side controls? [11:01] tsdgeos, yes [11:01] tsdgeos, you could click items in a dash page to the right of the selected one [11:01] ahhhh [11:01] i see [11:01] janimo, nope, apt-get install unity8; unity8 [11:01] the Mir spec doc has a graphic dated May 2013 regarding Mir on the free graphics stack, how valid is that still? [11:02] janimo, you might want to take that on #ubuntu-mir [11:02] Saviq, heh, that indeed worked [11:02] Saviq, hey, they sent me here :) [11:02] janimo, and yeah, you won't be able to run unity8@Mir on x86 yet [11:02] janimo, not for the free graphics stack and Mir, they didn't ;D [11:02] Saviq, for running unity8 I meant [11:03] Saviq: does the category combobox (sorry i mean optionselector, wait Oren's gone, can we call it combobox again?) shrink up and down in size for you too when changing scopes? [11:03] tsdgeos, checking [11:03] fair enough I guess you are mostly testing on ARM/platfrom-api/Android based hw [11:03] tsdgeos, yeah [11:03] that'd be an SDK bug of cours [11:03] e [11:03] tsdgeos, yup [11:04] janimo, this cycle we'll have it running on x86 for sure [11:04] janimo, just not yet there [11:04] Saviq, do you know if there's a blueprint or some other doc specifically for that effort? [11:04] Saviq: want me to report a bug? [11:04] Saviq, I'd like to help [11:04] tsdgeos, yes please [11:05] janimo, https://blueprints.launchpad.net/ubuntu/+spec/client-1404-unity8-on-desktop - bregma is leading that work [11:05] Saviq, thanks [11:08] Saviq: i guess it changes size because you empty/fill it again? [11:09] tsdgeos, yeah, replace the model [11:12] tsdgeos: hrm. did you use michal.karnicki@canonical.com for the stand-up invite? [11:12] i think so [11:12] tsdgeos: FTR, no event in my calendar yet [11:13] interesting [11:13] tsdgeos: That's okay though, if you guys have it consistently at the same hour [11:13] i think i failed to use the google calendar ui [11:13] ^ ^ [11:13] ok [11:13] now [11:13] tsdgeos: thanks! :D [11:14] you know all those webui you never know if you have to press apply/save/ok or not [11:14] too much dynamic stuff [11:14] Saviq, looks like category expansion no longer works in the scope tool [11:14] hahah, true. notably in Gmail "Contacts". Saves on it's own, but somehow never *felt* reliable to me ;) [11:15] mhr3: in case you're talking about the tool-fulldash branch/MP, it does work for me [11:16] karni, nope, new-scopes trunk [11:16] mhr3: damnit, true :D [11:16] is this because of the thing i just approved? [11:16] or was there already? === _salem is now known as salem_ [11:16] mhr3: oh.. then he just fixed it ;D [11:16] ah was there already [11:16] tsdgeos, worked until now afaict [11:16] mhr3, I fixed it [11:16] and then the new thing fixes it [11:16] mhr3, tsdgeos broke it [11:16] mhr3: https://code.launchpad.net/~saviq/unity8/tool-fulldash/+merge/201150 [11:16] * tsdgeos read it backwards [11:17] mhr3, and now he's reviewing a fix [11:17] Saviq: you don't have tests :-P [11:17] tsdgeos, indeed I don't [11:17] Saviq: thing is, the tests we have for genericscope do the expansion thing [11:17] how do they work? [11:18] i guess we have a fake list in there? [11:18] tsdgeos, the expansion was only broken in the tool [11:18] tsdgeos, 'cause of the previewListView [11:18] tsdgeos, the MouseArea in GenericScopeView was enabled all the time [11:18] yep, the tests have their own previewListView [11:18] tsdgeos, so the expansion works, just you couldn't click it [11:18] that's why it works [11:18] tsdgeos, yup [11:18] tsdgeos, and now the tool does, too [11:19] in a sense [11:20] Saviq, hm, doesn't work for me with tool-fulldash [11:20] file:///home/miso/projects/unity8/qml/ScopeTool.qml:64:5: Type DashContent unavailable [11:21] mhr3, that's based on trunk [11:21] mhr3, merge into new-scopes [11:21] that's what i did [11:21] mhr3, there will be a conflict [11:21] mhr3: Works here [11:21] mhr3, imports need to look like so: [11:21] import Utils 0.1 [11:21] import Unity 0.2 [11:21] import "Components" [11:21] import "Dash" [11:22] got that exactly [11:22] mhr3, full log please [11:23] http://paste.ubuntu.com/6726054/ [11:23] mhr3, you on saucy, right? [11:23] ah [11:23] mhr3, you probably don't have the latest UITK [11:23] mhr3, just upgrade already [11:23] right, this isn't gcc, the first error isn't the issue :) [11:24] :) [11:24] :) [11:25] mhr3, mzanetti, tsdgeos, karni: bringing Card and CardHeader over to lp:unity8 [11:25] https://code.launchpad.net/~unity-team/unity8/dash-card-iteration0/+merge/201164 [11:25] yey :) [11:25] mzanetti, you can probably review ↑, since you already did :) [11:25] Saviq: sure [11:26] \o/ [11:29] updating the diff takes ages... I'm afraid of the size of that merge :) [11:36] karni, is this desired? http://imgur.com/etQgKSj [11:37] i mean, the first one larger than the rest? [11:39] mhr3: It's not desired, looks like a bug. Interestingly, can't find that item on my end. [11:39] grooveshark is location dependant iirc [11:39] or maybe that's u1-music [11:40] i guess it can have something to do with the two-line title [11:40] mhr3: I'll look into it [11:40] thx [11:45] mzanetti, you shouldn't be - just 800loc [11:46] mzanetti, not sure what lp is at [11:46] mzanetti, I did overwrite the branch soon after I pushed it, but seems lp got stuck on it [11:46] :) [11:46] mzanetti, can reapprove if you want [11:46] erm [11:46] resubmit [11:46] no worries [11:47] tsdgeos, think we should force-merge stuff that only fails in otto? [11:47] I'm half-way there [11:47] mzanetti, ↑ ? [11:47] we're getting queued up again [11:48] Saviq: i'd prefer to get it not to black-magicly fail :D [11:48] tsdgeos, of course, except we have no control over that [11:48] :) [11:48] yeah ;/ [11:48] tsdgeos, people are at it [11:48] * Saviq runs a suite [11:49] Saviq: i mean it's impossible my change to the CODING file or to the hjournal cause those crashes [11:49] tsdgeos, exactly [11:49] i would not cry if it gets force merged [11:49] * Saviq does [11:50] tsdgeos, and it completed on device, for that matter [11:53] mhr3: you were right, this line is causing trouble: height: template && template["card-layout"] === "horizontal" ? header.height : width / artShape.aspect [11:53] Thinking of best way to fix it. [11:55] mhr3: Basically, it's a CardHeader layout bug, and that one is actually still worked on, but I'll try to fix it since I'm already on it. [11:58] Is there a known mapping of XXS / XXXS font size to QML font pixel/pointSize ? [12:01] karni, http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.Label/ [12:01] karni, mhr3, actually that "one is bigger than the rest" is, in fact, desired [12:02] Saviq: haha, thank you :) There we go, design using xxxs that doesn't exist. I'll see what makes best sense [12:02] Saviq: Is it? Like mhr3 said, I think it's because the title is wrapped. [12:02] or is it U1MS result? :O [12:02] karni, mhr3, "Art_Header_horizontal" → "Header and Art are equal height." [12:03] Saviq: Hrm. Don't you think title overflow should not change CardHeader size? [12:03] karni, what I *think* doesn't really matter does it ;D [12:03] s/size/height [12:03] hahahaha [12:04] karni, that requires a comment on the spec that this happens [12:04] I'll add the comment [12:04] karni, and the spec needs to be adjusted, if applicable [12:04] ack [12:05] karni, it might be that we'll need to foresee the largest header height in a configuration [12:05] karni, and force it to be as high [12:05] karni, but that's not what the spec says right now [12:05] I agree [12:05] Saviq: I would think (which may not matter :D) text overflow should not cause CardHeader height change [12:06] * karni comments on the spec [12:06] karni, OTOH you don't want to make the header always have empty space at the bottom [12:06] karni, if there's never overflow [12:08] Saviq: That I didn't say ;) I'd like to do something smart about that. If you look at Michal's screen, there seems to be unnecessary padding at top (invisible at bottom, because of hidden fields). I think if there was less padding (if that makes any sense), the art would not resize because Header height would not change. [12:08] Just a thought, I know it's not us to make UI/UX decisions (usually) [12:08] karni, sure, that padding is an issue in CardHeader, I agree [12:08] karni, but that won't change the fact that the two will have different size [12:08] karni, 'cause both will lose padding [12:10] Saviq: You know I'm relatively new to the subject, but I tend to think 'RelativeLayout' in Android, it's pretty darn flexible, so is Qt/QML :) Anyways, I won't spend too much time on it now, before we get Katie speak her mind. [12:10] :) [12:10] karni, sure, everything is flexible, problem is you can't know the text layout... until you lay it out [12:10] karni, so you won't know if something wraps or not === alan_g is now known as alan_g|walk [12:11] karni, but even if you know, you'd have to interrogate all results (the not-visible ones, too), to find out whether any of them overflows [12:11] karni, and adapt the header height [12:11] Saviq: I found a way yesterday, I thought I needed it for one test. The thing is, it's a hack really (instantiate a QML object, and measure text). I can easily imagine this would have terrible influence on the performance, though. [12:11] karni, yeah exactly [12:12] karni, so no, not a *real* way [12:12] well, sh!t [12:12] Saviq: comment added ;) [12:12] mhr3: we'll have to wait for Katies input, it's a tricky bit. [12:12] karni, so we need a good-enough solution to be able to foresee what can happen [12:13] +1 [12:13] karni, the easiest would probably be to assume the largest height, basically, but that could mean we end up with space that's never used in any header in a given category [12:13] yeah, that'd sort of suck. [12:13] easy and quick, tho. [12:14] tsdgeos, did you notice that suddenly qmluitests pass 100% https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/ [12:14] well, almost, but they're pretty green [12:14] yeah [12:14] well the expand_expand was actually causing more reds than the other one [12:14] and i fixed the expand_expand [12:15] but yeah i'd still expect the one for dash scope change on load to fail a bit more reliably [12:18] Saviq: hey, the only thing I could complain is that make tryCardHeader is not doing anything. do you want to fix that or should I ignore? [12:18] mzanetti, "not doing anything"? [12:18] Saviq: well... it pops up a window with a blue rectangle. [12:18] no controls to actually try something [12:18] mzanetti, aah try* [12:18] mzanetti, tryCard does that [12:18] mzanetti: make -C builddir tryCard and change there [12:19] mzanetti, didn't make sense to have it separated out I though [12:19] t [12:19] ok... makes sense [12:22] Saviq: karni: approved [12:22] \o/ [12:22] thank you [12:22] mzanetti, thanks [12:29] Saviq: semi-random question - how heavy would an invisible, extra Label in a layout be? Besides adding one item to the traverse tree when rendering, would it be acceptably lightweight? (You can guess why I'm asking about it - test textWrap) === om26erafk is now known as om26er [12:30] karni, if it'd only be there for testing, don't [12:30] Saviq: well, that could be used to adjust CardHeader layout (not purely for test purposes, if that's what you're asking). I know it's a wild question, that's why I went ahead and asked ;) [12:30] karni, we should avoid any unnecessary objects - sure, it wouldn't be even pushed to the scenegraph or the GPU, but it would still be there in the QML tree [12:31] * karni nod [12:31] karni, I really don't think we'll go that route [12:31] ACK [12:31] karni, remember you don't even have all the items rendered at once [12:31] karni, only those that are on screen [12:31] Correct. [12:31] karni, the rest are destroyed [12:32] karni, so if at any point you start thinking "look at all the items in the view to..." - stop right there ;) [12:33] Saviq: Nopes. I was thinking in terms of adding that invisible Label to test wheter text was same as card header title, and base the card header layout on that. I also know that if I wanted to traverse all model items, I wouldn't be doing that in this part of code :) So, not what I thought, no worries :) [12:34] karni, not following - what would that invisible Label do that the visible one wouldn't? [12:35] Saviq: no Wrap, single line, possibly elide. if text in that label is !== text in title labe, means we have 2 lines in the card header title labe. [12:35] *label [12:35] Something along that line, you prolly get the point now :) [12:36] It's a hack, but dirty because (if that worked) it'd require an invisible label in the tree, which I don't like either, [12:36] but like you said, seems there's no fast way to check if the text has wrapped/there's more than a single line in title label. [12:37] oh yeah. Text.truncated: bool [12:37]