[01:24] <elopio> thank you veebers and thomi.
[08:12] <tsdgeos> Saviq: read the description!
[08:12] <Saviq> tsdgeos, sooorry :D
[08:13] <tsdgeos> Saviq: i tried and failed
[08:13] <tsdgeos> 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] <tsdgeos> i was hoping i could make it crash or act weird
[08:14] <tsdgeos> but couldn't
[08:14] <tsdgeos> maybe i'm also defending with count() == 0 or isEmpty in other parts of the code
[08:14] <tsdgeos> but still shouldn't be 0
[08:18] <tsdgeos> Saviq: so did i convince you in https://code.launchpad.net/~aacid/unity8/timeformattertest_LCALL_C/+merge/200991 ?
[08:19] <Saviq> tsdgeos, not really, especially since currently 100% of our tests should run under LC_ALL=C
[08:20] <Saviq> tsdgeos, as we don't have any place that should be affected by the locale
[08:20] <tsdgeos> Saviq: ok, so i can move it to cmake and update the CODING file?
[08:23] <Saviq> tsdgeos, gimme a few to think what we want there
[08:23] <tsdgeos> sure
[08:24] <Saviq> tsdgeos, I've a feeling all our tests should run under LC_ALL=C currently
[08:24] <tsdgeos> should as "they do" or as "we would like to do"
[08:24] <tsdgeos> ?
[08:24] <Saviq> tsdgeos, can you still run make -C builddir testfoo to run that test?
[08:25] <Saviq> tsdgeos, we would like them to
[08:27] <tsdgeos> Saviq: no, can't find a way to run it individually
[08:27] <tsdgeos> only make test
[08:27] <tsdgeos> or run the binary
[08:27] <Saviq> tsdgeos, right, so that's something we should make possible
[08:27] <tsdgeos> ah no
[08:27] <tsdgeos> make timeformattertest
[08:27] <tsdgeos> works
[08:28] <tsdgeos> but doesn't get autocompleted by the bash make autocompleter
[08:28] <tsdgeos> my bad
[08:28] <Saviq> tsdgeos, should've used ninja ;)
[08:28] <tsdgeos> i get no autocompletion at all with ninja
[08:28] <Saviq> tsdgeos, oh?
[08:28] <tsdgeos> and actually it gets autcompleted now :D
[08:29] <Saviq> lol
[08:29] <tsdgeos> don't know, just woke up
[08:29] <Saviq> tsdgeos, that good enough for you?
[08:30] <tsdgeos> Saviq: having the LC_ALL in the make step? yeah
[08:30] <Saviq> tsdgeos, try and see if we can globally set that for the test env
[08:31] <Saviq> tsdgeos, hmm doesn't look like it
[08:32] <tsdgeos> why?
[08:32] <Saviq> tsdgeos, you can set_test_properties on a per-test basis
[08:32] <Saviq> tsdgeos, but not globally
[08:34] <tsdgeos> but don't we have our own "create test" macro?
[08:35] <tsdgeos> now we don't
[08:35] <tsdgeos> we have parts of it scattered around
[08:35] <tsdgeos> i see
[08:35] <tsdgeos> i.e. set_test_properties
[08:35] <tsdgeos> arg
[08:36] <tsdgeos> i.e. unity8/tests/plugins/Utils/CMakeLists.txt has run_tests
[08:36] <tsdgeos> but it's used there locally
[08:37] <Saviq> tsdgeos, right, we could have a global macro for that indeed
[08:38] <tsdgeos> but then it needs more careful thinking
[08:38] <tsdgeos> i.e. in this case we are assuming testname == testfile+.cpp
[08:38] <tsdgeos> but in some other cases we have multiple files
[08:38] <tsdgeos> or different libs to link to
[08:38] <tsdgeos> etx
[08:38] <tsdgeos> etc
[08:41] <Saviq> tsdgeos, sure it does :)
[08:42] <Saviq> tsdgeos, if you don't want to get into it
[08:42] <Saviq> tsdgeos, just move the LC_ALL into CMakeLists.txt for now
[08:42] <Saviq> tsdgeos, for that one test
[08:42] <tsdgeos> so boils down to maybe just add a warning in CODING and be done with it :D
[08:42] <tsdgeos> tests are expected to run under the C locale
[08:42] <tsdgeos> done
[08:42] <tsdgeos> then i can blame myself for not following the CODING guidelines :D
[08:43] <Saviq> tsdgeos, yup ;)
[08:44] <tsdgeos> ok
[08:44] <tsdgeos> will do that
[08:47] <tsdgeos> Saviq: ok, comment added to CODING
[08:48] <Saviq> tsdgeos, cheers
[08:58] <tsdgeos> 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] <Saviq> tsdgeos, looking
[09:00] <Saviq> tsdgeos, please add that if you don't `make install`, the tests will run on the system-installed version
[09:00] <tsdgeos> ok
[09:05] <tsdgeos> Saviq: done
[09:28] <Saviq> tsdgeos, https://code.launchpad.net/~saviq/unity8/forgiving-genericscopeview/+merge/201147 please
[09:29] <Saviq> mzanetti, can you continue with https://code.launchpad.net/~unity-team/unity8/new-scopes-horizontal-card-layout/+merge/200910 please?
[09:29] <mzanetti> yes sir
[09:30] <tsdgeos> Saviq: on it
[09:30] <tsdgeos> now i think both my coding file changes are going to conflct...
[09:30] <Saviq> tsdgeos, they might indeed
[09:31] <tsdgeos> let's see
[09:31] <Saviq> tsdgeos, just merge them together?
[09:31] <Saviq> tsdgeos, neither is being -autolanded yet
[09:33] <karni> Saviq: thanks for the follow up! :)
[09:33] <Saviq> karni, sure
[09:33] <tsdgeos> Saviq: ok, reapprove https://code.launchpad.net/~aacid/unity8/coding_autopilot_docu/+merge/200974 then
[09:34] <tsdgeos> i cancelled the other one
[09:34] <karni> Saviq: looks like good progress to me :)!
[09:34] <Saviq> tsdgeos, thanks
[09:34] <Saviq> karni, glad to hear that
[09:35] <Saviq> 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] <Saviq> karni, he's the one writing the journals and organic grid now
[09:35] <dednick> is anyones indicators not showing up on desktop unity8?
[09:36] <karni> Saviq: ACK! Thank you :)
[09:36] <Saviq> dednick, seems to work fine
[09:36] <dednick> Saviq: hm. must be something funky with mine then
[09:37] <tsdgeos> Saviq: there's a lot more previewListView uses that you have not protected, no?
[09:37] <Saviq> tsdgeos, those were the only ones that bit me, but you're right
[09:37] <tsdgeos> dednick: there's the thing that closing down unity8 will kill them
[09:37] <tsdgeos> dednick: so run unity8 and ctrl+c it
[09:38] <tsdgeos> Saviq: i think that there are a few more that would break
[09:38] <tsdgeos>         forceNoClip: previewListView.onScreen
[09:38] <tsdgeos> ?
[09:39] <tsdgeos> and the renderloader clicked
[09:39] <dednick> Saviq: yeah, but it restarts them when unity8 starts
[09:39] <tsdgeos> Saviq: why don't you have a previewListView, is it a test?
[09:39] <Saviq> tsdgeos, the scope tool
[09:40] <Saviq> tsdgeos, but yeah I'm thinking I should make it differently... just get Dash complete, and not GenericScopeView alone
[09:40] <tsdgeos> +1
[09:40] <tsdgeos> or DashContent at leat
[09:40] <dednick> Saviq: nevermind. old qmenumodel.
[09:40] <tsdgeos> that brings what you need i think
[09:40] <karni> 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] <sil2100> jamesh__: hello!
[09:40] <karni> :)
[09:41] <mzanetti> karni: yeah, on it right now. just running tests for a last time
[09:41] <karni> mzanetti: sweet! thank you :)
[09:42] <sil2100> 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] <sil2100> 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] <Saviq> tsdgeos, ok then, ignore that branch
[09:43]  * tsdgeos ignores
[09:43] <tsdgeos> what's up with autopilot again
[09:44] <tsdgeos> what :D
[09:44] <tsdgeos> 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] <tsdgeos> just doesn't start :D
[09:46] <tsdgeos> it segfaulted like crazy :S
[09:46] <tsdgeos> /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] <tsdgeos> doesn't make any sense
[09:47] <Saviq> tsdgeos, yeah, it's been like that for some runs it seems
[09:49] <tsdgeos> :(
[09:49] <tsdgeos> any clue if it's fauly hardware or something else?
[09:50] <Saviq> tsdgeos, we definitely need someone to look at it
[09:52] <tsdgeos> mzanetti: can you detach me a autopilot VM?
[09:52] <tsdgeos> if so i'll have a look
[09:52] <mzanetti> tsdgeos: sure
[09:52] <tsdgeos> organic grid is almost done [in my mind :D]
[09:52] <karni> How do I actually work with the unity-scope-tool?
[09:53] <Saviq> karni, right now you dont'
[09:53] <Saviq> karni, I'm fixing
[09:53] <karni> oh okay
[09:53] <Saviq> karni, will have a branch for you to try in 3 mins
[09:54] <karni> Saviq: wheee \o/ thanks Michał
[09:54]  * karni was wondering how to populate unity-scope-tool with an actual scope
[09:54] <mzanetti> tsdgeos: ps-trusty-server-amd64-2 is yours once the job 881 is done
[09:55] <mzanetti> 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] <tsdgeos> oka
[09:59] <Saviq> tsdgeos, https://code.launchpad.net/~saviq/unity8/tool-fulldash/+merge/201150
[10:00] <tsdgeos> ok
[10:00] <Saviq> tsdgeos, actually need fix
[10:00] <Saviq> but meeting first
[10:00] <tsdgeos> ok²
[10:02] <tsdgeos> mzanetti: even if the machine is doing qmluitests at the moment i can use it for autopilot tests, right?
[10:03] <mzanetti> tsdgeos: oh... autopilot... we don't run them in VM any more
[10:03] <mzanetti> tsdgeos: they are executed on a real machine but I don't have access to that one
[10:03] <tsdgeos> mzanetti: no?
[10:03] <tsdgeos> oh :_/
[10:03] <tsdgeos> mzanetti: ok, then put the thing back into the pool
[10:04] <mzanetti> done
[10:04] <mzanetti> tsdgeos: do you have autopilot failures in jenkins which you cannot reproduce locally?
[10:04] <tsdgeos> mzanetti: unity8 crashing :D
[10:05] <mzanetti> hmm... but that *should* behave the same on your local machine
[10:05] <tsdgeos> mzanetti: see https://jenkins.qa.ubuntu.com/job/autopilot-testrunner-otto-trusty/1930/consoleFull for the billions of segv
[10:07] <tsdgeos> i definitely don't get all these crashes
[10:31] <tsdgeos> fginther: ping
[10:45] <Saviq> tsdgeos, tool-fulldash fixed
[10:47] <Saviq> tsdgeos, going to #ubuntu-ci-eng vanguard to take a look
[10:47] <tsdgeos> oki
[10:54] <karni> Unity team standup is 2:30 UTC?
[10:56] <tsdgeos> Saviq: so no more scope selector and just swipe left/right?
[10:56] <Saviq> karni, +1
[10:56] <Saviq> tsdgeos, yeah, or select by header
[10:57] <Saviq> tsdgeos, felt unnecessary to have the selector now
[10:57] <tsdgeos> karni: i invited you to it
[10:57] <Saviq> tsdgeos, not entirely happy that all the scopes are loaded all the time
[10:57] <Saviq> tsdgeos, but it works, which is more important
[10:57] <tsdgeos> Saviq: but that happened before, no?
[10:57] <tsdgeos> Saviq: or you mean the graphical counterpart
[10:57] <Saviq> tsdgeos, no, before it only loaded the single dash page, yeah
[10:58] <janimo> can unity8 be tested on an x86 workstation? Only GUI needed , no sensors or other fancyness of course
[10:58] <karni> tsdgeos: thanks :)
[10:59] <tsdgeos> Saviq: why the new mouse area?
[10:59] <Saviq> tsdgeos, 'cause otherwise I could click on items behind the controls
[11:00] <tsdgeos> janimo: yes, you can run unity8 on a x86 machine
[11:00] <Saviq> janimo, it will only run in a window for now (i.e. you can't run real applications yet)
[11:00] <janimo> Saviq, tsdgeos, any particular setup needed or packages not in the trusty archives?
[11:01] <tsdgeos> Saviq: which items behind the controls?¿
[11:01] <tsdgeos> Saviq: you mean the right hand side controls?
[11:01] <Saviq> tsdgeos, yes
[11:01] <Saviq> tsdgeos, you could click items in a dash page to the right of the selected one
[11:01] <tsdgeos> ahhhh
[11:01] <tsdgeos> i see
[11:01] <Saviq> janimo, nope, apt-get install unity8; unity8
[11:01] <janimo> the Mir spec doc has a graphic dated May 2013 regarding Mir on the free graphics stack, how valid is that still?
[11:02] <Saviq> janimo, you might want to take that on #ubuntu-mir
[11:02] <janimo> Saviq, heh, that indeed worked
[11:02] <janimo> Saviq, hey, they sent me here :)
[11:02] <Saviq> janimo, and yeah, you won't be able to run unity8@Mir on x86 yet
[11:02] <Saviq> janimo, not for the free graphics stack and Mir, they didn't ;D
[11:02] <janimo> Saviq, for running unity8 I meant
[11:03] <tsdgeos> 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] <Saviq> tsdgeos, checking
[11:03] <janimo> fair enough I guess you are mostly testing on ARM/platfrom-api/Android based hw
[11:03] <Saviq> tsdgeos, yeah
[11:03] <tsdgeos> that'd be an SDK bug of cours
[11:03] <tsdgeos> e
[11:03] <Saviq> tsdgeos, yup
[11:04] <Saviq> janimo, this cycle we'll have it running on x86 for sure
[11:04] <Saviq> janimo, just not yet there
[11:04] <janimo> Saviq, do you know if there's a blueprint or some other doc specifically for that effort?
[11:04] <tsdgeos> Saviq: want me to report a bug?
[11:04] <janimo> Saviq, I'd like to help
[11:04] <Saviq> tsdgeos, yes please
[11:05] <Saviq> janimo, https://blueprints.launchpad.net/ubuntu/+spec/client-1404-unity8-on-desktop - bregma is leading that work
[11:05] <janimo> Saviq, thanks
[11:08] <tsdgeos> Saviq: i guess it changes size because you empty/fill it again?
[11:09] <Saviq> tsdgeos, yeah, replace the model
[11:12] <karni> tsdgeos: hrm. did you use michal.karnicki@canonical.com for the stand-up invite?
[11:12] <tsdgeos> i think so
[11:12] <karni> tsdgeos: FTR, no event in my calendar yet
[11:13] <tsdgeos> interesting
[11:13] <karni> tsdgeos: That's okay though, if you guys have it consistently at the same hour
[11:13] <tsdgeos> i think i failed to use the google calendar ui
[11:13] <karni> ^ ^
[11:13] <tsdgeos> ok
[11:13] <tsdgeos> now
[11:13] <karni> tsdgeos: thanks! :D
[11:14] <tsdgeos> you know all those webui you never know if you have to press apply/save/ok or not
[11:14] <tsdgeos> too much dynamic stuff
[11:14] <mhr3> Saviq, looks like category expansion no longer works in the scope tool
[11:14] <karni> hahah, true. notably in Gmail "Contacts". Saves on it's own, but somehow never *felt* reliable to me ;)
[11:15] <karni> mhr3: in case you're talking about the tool-fulldash branch/MP, it does work for me
[11:16] <mhr3> karni, nope, new-scopes trunk
[11:16] <tsdgeos> mhr3: damnit, true :D
[11:16] <tsdgeos> is this because of the thing i just approved?
[11:16] <tsdgeos> or was there already?
[11:16] <karni> mhr3: oh.. then he just fixed it ;D
[11:16] <tsdgeos> ah was there already
[11:16] <mhr3> tsdgeos, worked until now afaict
[11:16] <Saviq> mhr3, I fixed it
[11:16] <tsdgeos> and then the new thing fixes it
[11:16] <Saviq> mhr3, tsdgeos broke it
[11:16] <karni> mhr3: https://code.launchpad.net/~saviq/unity8/tool-fulldash/+merge/201150
[11:16]  * tsdgeos read it backwards
[11:17] <Saviq> mhr3, and now he's reviewing a fix
[11:17] <tsdgeos> Saviq: you don't have tests :-P
[11:17] <Saviq> tsdgeos, indeed I don't
[11:17] <tsdgeos> Saviq: thing is, the tests we have for genericscope do the expansion thing
[11:17] <tsdgeos> how do they work?
[11:18] <tsdgeos> i guess we have a fake list in there?
[11:18] <Saviq> tsdgeos, the expansion was only broken in the tool
[11:18] <Saviq> tsdgeos, 'cause of the previewListView
[11:18] <Saviq> tsdgeos, the MouseArea in GenericScopeView was enabled all the time
[11:18] <tsdgeos> yep, the tests have their own previewListView
[11:18] <Saviq> tsdgeos, so the expansion works, just you couldn't click it
[11:18] <tsdgeos> that's why it works
[11:18] <Saviq> tsdgeos, yup
[11:18] <Saviq> tsdgeos, and now the tool does, too
[11:19] <Saviq> in a sense
[11:20] <mhr3> Saviq, hm, doesn't work for me with tool-fulldash
[11:20] <mhr3> file:///home/miso/projects/unity8/qml/ScopeTool.qml:64:5: Type DashContent unavailable
[11:21] <Saviq> mhr3, that's based on trunk
[11:21] <Saviq> mhr3, merge into new-scopes
[11:21] <mhr3> that's what i did
[11:21] <Saviq> mhr3, there will be a conflict
[11:21] <karni> mhr3: Works here
[11:21] <Saviq> mhr3, imports need to look like so:
[11:21] <Saviq>  import Utils 0.1
[11:21] <Saviq>  import Unity 0.2
[11:21] <Saviq>  import "Components"
[11:21] <Saviq>  import "Dash"
[11:22] <mhr3> got that exactly
[11:22] <Saviq> mhr3, full log please
[11:23] <mhr3> http://paste.ubuntu.com/6726054/
[11:23] <Saviq> mhr3, you on saucy, right?
[11:23] <mhr3> ah
[11:23] <Saviq> mhr3, you probably don't have the latest UITK
[11:23] <Saviq> mhr3, just upgrade already
[11:23] <mhr3> right, this isn't gcc, the first error isn't the issue :)
[11:24] <Saviq> :)
[11:24] <karni> :)
[11:25] <Saviq> mhr3, mzanetti, tsdgeos, karni: bringing Card and CardHeader over to lp:unity8
[11:25] <Saviq> https://code.launchpad.net/~unity-team/unity8/dash-card-iteration0/+merge/201164
[11:25] <mhr3> yey :)
[11:25] <Saviq> mzanetti, you can probably review ↑, since you already did :)
[11:25] <mzanetti> Saviq: sure
[11:26] <karni> \o/
[11:29] <mzanetti> updating the diff takes ages... I'm afraid of the size of that merge :)
[11:36] <mhr3> karni, is this desired? http://imgur.com/etQgKSj
[11:37] <mhr3> i mean, the first one larger than the rest?
[11:39] <karni> mhr3: It's not desired, looks like a bug. Interestingly, can't find that item on my end.
[11:39] <mhr3> grooveshark is location dependant iirc
[11:39] <mhr3> or maybe that's u1-music
[11:40] <mhr3> i guess it can have something to do with the two-line title
[11:40] <karni> mhr3: I'll look into it
[11:40] <mhr3> thx
[11:45] <Saviq> mzanetti, you shouldn't be - just 800loc
[11:46] <Saviq> mzanetti, not sure what lp is at
[11:46] <Saviq> mzanetti, I did overwrite the branch soon after I pushed it, but seems lp got stuck on it
[11:46] <mzanetti> :)
[11:46] <Saviq> mzanetti, can reapprove if you want
[11:46] <Saviq> erm
[11:46] <Saviq> resubmit
[11:46] <mzanetti> no worries
[11:47] <Saviq> tsdgeos, think we should force-merge stuff that only fails in otto?
[11:47] <Saviq> I'm half-way there
[11:47] <Saviq> mzanetti, ↑ ?
[11:47] <Saviq> we're getting queued up again
[11:48] <tsdgeos> Saviq: i'd prefer to get it not to black-magicly fail :D
[11:48] <Saviq> tsdgeos, of course, except we have no control over that
[11:48] <mzanetti> :)
[11:48] <tsdgeos> yeah ;/
[11:48] <Saviq> tsdgeos, people are at it
[11:48]  * Saviq runs a suite
[11:49] <tsdgeos> Saviq: i mean it's impossible my change to the CODING file or to the hjournal cause those crashes
[11:49] <Saviq> tsdgeos, exactly
[11:49] <tsdgeos> i would not cry if it gets force merged
[11:49]  * Saviq does
[11:50] <Saviq> tsdgeos, and it completed on device, for that matter
[11:53] <karni> mhr3: you were right, this line is causing trouble: height: template && template["card-layout"] [11:53] <karni> Thinking of best way to fix it.
[11:55] <karni> 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] <karni> Is there a known mapping of XXS / XXXS font size to QML font pixel/pointSize ?
[12:01] <Saviq> karni, http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Components.Label/
[12:01] <Saviq> karni, mhr3, actually that "one is bigger than the rest" is, in fact, desired
[12:02] <karni> Saviq: haha, thank you :) There we go, design using xxxs that doesn't exist. I'll see what makes best sense
[12:02] <karni> Saviq: Is it? Like mhr3 said, I think it's because the title is wrapped.
[12:02] <karni> or is it U1MS result? :O
[12:02] <Saviq> karni, mhr3, "Art_Header_horizontal" → "Header and Art are equal height."
[12:03] <karni> Saviq: Hrm. Don't you think title overflow should not change CardHeader size?
[12:03] <Saviq> karni, what I *think* doesn't really matter does it ;D
[12:03] <karni> s/size/height
[12:03] <karni> hahahaha
[12:04] <Saviq> karni, that requires a comment on the spec that this happens
[12:04] <karni> I'll add the comment
[12:04] <Saviq> karni, and the spec needs to be adjusted, if applicable
[12:04] <karni> ack
[12:05] <Saviq> karni, it might be that we'll need to foresee the largest header height in a configuration
[12:05] <Saviq> karni, and force it to be as high
[12:05] <Saviq> karni, but that's not what the spec says right now
[12:05] <karni> I agree
[12:05] <karni> 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] <Saviq> karni, OTOH you don't want to make the header always have empty space at the bottom
[12:06] <Saviq> karni, if there's never overflow
[12:08] <karni> 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] <karni> Just a thought, I know it's not us to make UI/UX decisions (usually)
[12:08] <Saviq> karni, sure, that padding is an issue in CardHeader, I agree
[12:08] <Saviq> karni, but that won't change the fact that the two will have different size
[12:08] <Saviq> karni, 'cause both will lose padding
[12:10] <karni> 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] <karni> :)
[12:10] <Saviq> karni, sure, everything is flexible, problem is you can't know the text layout... until you lay it out
[12:10] <Saviq> karni, so you won't know if something wraps or not
[12:11] <Saviq> 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] <Saviq> karni, and adapt the header height
[12:11] <karni> 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] <Saviq> karni, yeah exactly
[12:12] <Saviq> karni, so no, not a *real* way
[12:12] <karni> well, sh!t
[12:12] <karni> Saviq: comment added ;)
[12:12] <karni> mhr3: we'll have to wait for Katies input, it's a tricky bit.
[12:12] <Saviq> karni, so we need a good-enough solution to be able to foresee what can happen
[12:13] <karni> +1
[12:13] <Saviq> 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] <karni> yeah, that'd sort of suck.
[12:13] <karni> easy and quick, tho.
[12:14] <Saviq> tsdgeos, did you notice that suddenly qmluitests pass 100% https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-trusty/
[12:14] <Saviq> well, almost, but they're pretty green
[12:14] <tsdgeos> yeah
[12:14] <tsdgeos> well the expand_expand was actually causing more reds than the other one
[12:14] <tsdgeos> and i fixed the expand_expand
[12:15] <tsdgeos> but yeah i'd still expect the one for dash scope change on load to fail a bit more reliably
[12:18] <mzanetti> 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] <Saviq> mzanetti, "not doing anything"?
[12:18] <mzanetti> Saviq: well... it pops up a window with a blue rectangle.
[12:18] <mzanetti> no controls to actually try something
[12:18] <Saviq> mzanetti, aah try*
[12:18] <Saviq> mzanetti, tryCard does that
[12:18] <karni> mzanetti: make -C builddir tryCard and change there
[12:19] <Saviq> mzanetti, didn't make sense to have it separated out I though
[12:19] <Saviq> t
[12:19] <mzanetti> ok... makes sense
[12:22] <mzanetti> Saviq: karni: approved
[12:22] <karni> \o/
[12:22] <karni> thank you
[12:22] <Saviq> mzanetti, thanks
[12:29] <karni> 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)
[12:30] <Saviq> karni, if it'd only be there for testing, don't
[12:30] <karni> 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] <Saviq> 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] <Saviq> karni, I really don't think we'll go that route
[12:31] <karni> ACK
[12:31] <Saviq> karni, remember you don't even have all the items rendered at once
[12:31] <Saviq> karni, only those that are on screen
[12:31] <karni> Correct.
[12:31] <Saviq> karni, the rest are destroyed
[12:32] <Saviq> karni, so if at any point you start thinking "look at all the items in the view to..." - stop right there ;)
[12:33] <karni> 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] <Saviq> karni, not following - what would that invisible Label do that the visible one wouldn't?
[12:35] <karni> 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] <karni> *label
[12:35] <karni> Something along that line, you prolly get the point now :)
[12:36] <karni> 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] <karni> 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] <karni> oh yeah. Text.truncated: bool
[12:37] <Saviq> karni, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-text.html#lineCount-prop
[12:37] <karni> haha omg. Can I hide now ;)?
[12:38] <Saviq> karni, ;)
[12:38] <karni> Saviq: does that in fact return 2 for wrapped label? if so, I probably wasted ~15 of thinking. It was fun, nevertheless ;)
[12:38]  * karni notes to really look better (or sleep longer)
[12:39] <Saviq> karni, yes it does
[12:39] <karni> neat
[13:51] <Saviq> mhr3, https://launchpadlibrarian.net/162016552/buildlog_ubuntu-trusty-armhf.unity-scopes-shell_1%3A0.1.1%2B14.04.20131219.1-0~36~ubuntu14.04.1_FAILEDTOBUILD.txt.gz
[13:51] <Saviq> mhr3, that means there's some version mismatch between -api and -shell, doesn't it?
[13:52] <mhr3> Saviq, yea, some massive renaming was merged into -api
[13:52] <mhr3> yey! :/
[13:52]  * Saviq wonders why it passed on i386
[13:53] <Saviq> mhr3, care to comment on bug #1267831 ?
[13:53] <Saviq> mhr3, maybe -shell needs a dependency version bump?
[13:53] <mhr3> Saviq, wait, yea, this is weird
[13:54] <mhr3> it's not about the renaming
[13:54] <mhr3> Saviq, what is this even?
[13:54] <mhr3> it's not trunks
[13:54] <mhr3> of neither shell nor api
[13:54] <Saviq> mhr3, https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+sourcepub/3765701/+listing-archive-extra
[13:55] <Saviq> mhr3, might be we need -api there as well, not just -shell?
[13:55] <mhr3> pff, week old branches, don't you know we change everything every week? :)
[13:55] <Saviq> mhr3, 'cause it builds -shell trunk against -api released?
[13:55] <Saviq> yeah
[13:55] <mhr3> Saviq, it also need new unity-api
[13:56] <mhr3> but with latest unity-scopes-api, -shell won't build
[13:56] <Saviq> mhr3, ok be back in a few
[14:02] <fginther> tsdgeos, pong
[14:02] <tsdgeos> fginther: we've been having some weird results in autopiltot runs but people from #ubuntu-ci-eng are already looking into it
[14:02] <tsdgeos> so nothing
[14:03] <tsdgeos> :)
[14:03] <fginther> tsdgeos, ok, I'll check with ci
[14:15] <darklight_> Is there a chance of the panel shortcuts finally being customizable in 14.04 ? seriously why was that design ever approved in the first plae
[14:16] <darklight_> s/of/for
[14:18] <darklight_> Not only it's a bad design and can really anny regualr users but it can be a real showstopper for people with disabilities
[14:23] <Saviq> fginther, ev registered it at https://app.asana.com/0/9505407366941/9504356304887
[14:24]  * Saviq is not sure what to do with that...
[14:24] <fginther> Saviq, I see it, I'm going to rerun an older unity8 binary package to see if something changed on the test system
[14:25] <fginther> Saviq, or possibly a dependency
[14:26] <elopio> tsdgeos: this is now ready to land:
[14:26] <elopio> https://code.launchpad.net/~elopio/unity8/open_scope/+merge/201107
[14:27] <darklight_> Who could I contact about this? there are bugs open but they are ignored on the target mileston has been postponed for years
[14:27] <tsdgeos> elopio: cool
[14:28] <Saviq> darklight_, if it's a design issue, #ubuntu-design is the place to go
[14:29] <greyback> Saviq: ever seen this before: http://pastebin.ubuntu.com/6726838/
[14:29] <greyback> I'm trying to run AP on a pretty clean image. unity8-autopilot package is installed
[14:29] <Saviq> greyback, yeah, your command is wrong
[14:29] <Saviq> greyback, -p -v unity8-autopilot
[14:29] <darklight_> Saviq: well design as in feature missing or better badly implemented, would that be the best place where to ask ?
[14:30] <Saviq> so it tries to install "-v" and then run "unity8-autopilot" test suite as opposed to "unity8"
[14:30] <greyback> Saviq: what? That's ridiculous. -v switch is in the help
[14:30] <Saviq> darklight_, I'm not sure what issue you're talking about, but sounds like yes - this needs to be looked at by designers, only then will code change
[14:30] <Saviq> greyback, ORDER
[14:30] <Saviq> -p -v
[14:31] <Saviq> --package=-v
[14:31] <greyback> Saviq: OBJECTION
[14:31] <greyback> ah
[14:31] <jamesh> sil2100: hi.  sorry I missed your ping -- I've been at a conference all week.  Package name change sounds fine.
[14:31] <Saviq> greyback, STANDUP
[14:31] <darklight_> Saviq: ok thanks, just to clarify the issue is the hardcoded shortcuts in unity
[14:31] <Saviq> darklight_, got it
[14:31] <sil2100> jamesh: hi! No problem, Satoris already commented - the package is preNEWed and soon it will land in the new queue
[14:32] <Saviq> greyback, NOTES
[14:32] <jamesh> awesome!
[14:32] <Saviq> greyback, you coming?
[14:32] <jamesh> was having drinks with Lennart Potering tonight, and we managed to stay civil the whole way through
[14:32] <Saviq> greyback, can you hear us?
[14:35] <Saviq> mhr3, added -scopes-api to the PPA, -api is already there
[14:36] <mhr3> Saviq, how high prio is it to make -shell buildable again?
[14:36] <mhr3> we're in the process of even more api changes
[14:37] <Saviq> mhr3, ah so it's not gonna build anyway?
[14:37] <mhr3> not right now, no
[14:37] <Saviq> mhr3, whenever you're ready basically
[14:37] <mhr3> would build yesterday :)
[14:37] <Saviq> right ;)
[14:52] <karni> Saviq: Should "card-size" have no influcence on the size of horizontal card size?
[14:52] <Saviq> karni, it does, in vertical
[14:52] <karni> Saviq: but not for horizontal cards, right?
[14:52] <Saviq> karni, in horizontal the card width is hardcoded at 40GU
[14:53] <karni> sweet ;)
[14:53] <Saviq> or 38
[14:53] <Saviq> large
[14:53] <karni> right
[15:20] <fginther> Saviq, have you any clue as to what the unity8 SEGVs are caused by?
[15:23] <tsdgeos> fginther: i don't think we do
[15:23] <tsdgeos> fginther: as a matter of fact stuff works in our desktops just fine
[15:23] <tsdgeos> fginther: and there's no backtrace logging in those machines, is there?
[15:23] <fginther> Saviq, I reran a test that passed before, and now it fails. I also looked at the installed packages between a good and bad run and found no differences. Even checked that the test machine was the same
[15:25] <fginther> tsdgeos, there is no reason for crashes to be disabled here, but perhaps they are. I'll check into it
[15:31] <tsdgeos> or at least i couldn't find where they were stored :D
[15:36] <Saviq> fginther, yeah, I'm completely lost, it just started happening overnight
[15:37] <Saviq> fginther, if possible, it would be good to take down a machine to try and reproduce on it to at least get the .crash file
[15:39] <tsdgeos> dandrader: https://code.launchpad.net/~aacid/unity8/journal_test_cmake_bugfix/+merge/201202
[15:41] <tsdgeos> and i think i found another
[15:41] <tsdgeos> you shouldn't ask for those last minute refactoring things :D
[15:43] <Saviq> mhr3, does that FTBFS ring a bell https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2/+sourcepub/3811744/+listing-archive-extra ?
[15:45] <karni> mhr3: Just FYI, had this tiny patch for that first item being large (wrapped title) but it fails miserably a potential OEM customization. We'll need to measure it once for the whole category instead as Michal suggested, so that change would be elsewhere :( http://paste.ubuntu.com/6726961/
[15:45] <tsdgeos> Saviq: have you manually merged https://code.launchpad.net/~aacid/unity8/journal_test_cmake_bugfix/+merge/201202 alraedy?
[15:45] <Saviq> tsdgeos, no
[15:45] <mhr3> Saviq, unfortunately, no
[15:45] <Saviq> tsdgeos, I wait for the autolanding job to complete
[15:45] <tsdgeos> Saviq: ok, because i just added a new fix
[15:45] <mhr3> Saviq, opening bug about it
[15:46] <mhr3> karni, eeek :P
[15:47] <mhr3> karni, i guess we shouldn't use grid if we want it to look good
[15:47] <mhr3> needs something more dynamic
[15:48] <karni> mhr3: Well, I was assuming you specifically wanted to test the grid with horizontal cards. That is, indeed, a bug. Just needs to be solved elsewhere.
[15:48] <karni> mhr3: That's a configuration a 3rd party dev can choose, thus we need to get it right (at some point in time)
[15:48] <karni> :)
[15:49] <mhr3> karni, i was just testing the horizontal layout, but i guess that grid implies that each item is same height and therefore this can happen
[15:50] <karni> mhr3: ok, I realized you meant that all cards have same height because of the first one. right.
[15:51] <mhr3> still, you're right that the cards should try to look similar when possible :)
[15:53] <karni> mhr3: I think we'll fix this on the category/card level, so a grid with horizontal cards would look just fine. Nevertheless, it would be interesting to allow horizontal cards of different heights indeed.
[15:53] <mhr3> +1
[15:54] <Saviq> karni, it's allowed already - just add a summary of different length
[15:54] <Saviq> karni, that's one of the use cases for VJournal
[15:54] <karni> d'oh, of course :)
[15:55] <Saviq> karni, but TBH I'm starting to feel like the "mascot is the height of the header" rule is just wrong
[15:55] <mhr3> Saviq, that build was with 5.2, right?
[15:56] <karni> Saviq: I don't think I have an opinion on that ATM.
[16:16] <sil2100> jamesh: are you still around?
[16:54] <fginther> Saviq, tsdgeos, I'm not much closer on the unity8 problem. There is apparently just updated today version of apport that should help to collect the crash, but I've got to put some work into setting this up
[16:54] <fginther> Saviq, tsdgeos, if you need to make progress on unity8 MPs, we may need to disable that job
[16:54] <Saviq> fginther, we're fine
[16:55] <Saviq> fginther, I've been forcing generic-land
[16:55] <Saviq> fginther, so it's not blocking us
[16:55] <Saviq> fginther, and it's EOW now
[16:56] <fginther> Saviq, thanks, I'll send an update if I get anywhere today