[00:14] <randy_O> I'm having trouble getting an app to compile for armhf with the Ubuntu SDK. I'm getting the error: Could not find compiled binaries for architecture 'armhf'. Any ideas for what I should check?
[07:49] <dholbach> good morning
[08:22] <dholbach> popey: do you have an example package for bug 1530894?
[08:22] <ubot5`> bug 1530894 in Canonical Click Reviewers tools ".mo files don't seem to be allowed in packages of arch 'all'" [Undecided,Confirmed] https://launchpad.net/bugs/1530894
[09:02] <popey> dholbach, yeah, grab one of the older unav packages from the store?
[09:02] <dholbach> popey: I'm already set
[09:02] <dholbach> thanks
[09:02] <popey> ok
[09:02] <popey> sorry, missed your ping
[09:03] <dholbach> https://code.launchpad.net/~dholbach/click-reviewers-tools/1530894/+merge/281730
[09:03] <dholbach> jdstrand, beuno (or anyone else really): ^
[09:03] <dholbach> popey: I wonder why this recently turned into a problem though
[09:03] <dholbach> the check has been like that for ages
[09:04] <popey> maybe click is building it differently?
[09:04] <popey> sdk changes?
[09:04] <dholbach> that'd surprise me
[09:05] <popey> do mo files always look like that?
[09:05] <popey> are they always included?
[09:05] <popey> maybe look in an older working unav?
[09:05] <dholbach> we're using python-magic which unfortunately is not as clever as file(1)
[09:06] <popey> :D
[09:06] <dholbach> so I added a check which checks if the filename ends with '.mo' and I attempt to open it using gettext and see if that works
[09:06] <dholbach> I hope that's good enough
[12:00] <popey> dholbach, what are we doing with apps currently in the queue with the .mo files issue?
[12:00] <dholbach> popey: I don't know
[12:00] <dholbach> Martin and Jamie should be up soon - let's discuss with them
[12:07] <popey> ok
[14:05] <ahayzen> faenil, o/ I'm playing about with the ListItemLayout stuff, and i was wondering if there is a way to vertically centre the labels, as some of the listitems in music have different heights so then the subtitle is touching the bottom of the listitem
[14:06] <faenil> ahayzen: they're autoamtically centered
[14:06] <ahayzen> hmmm
[14:06] <ahayzen> do i need to anchors { fill: parent } or something ?
[14:06] <faenil> ahayzen: blind guess, are you setting ListItem's height to layout.height+listitem.divider?
[14:06]  * ahayzen tried setting a height
[14:06] <ahayzen> oh its layout.height ?
[14:06] <faenil> ahayzen: check out the docs :)
[14:07] <ahayzen> hmm
[14:07] <ahayzen> but we do it the other way around... like we set the ListItem to be X high then expect the stuff inside to fit
[14:07] <ahayzen> (currently)
[14:08] <faenil> ahayzen: yeah, but you don't set Column's height, do you ;)
[14:08] <ahayzen> the column was in a loader that was verticalCenter: parent.verticalCenter
[14:08] <faenil> ahayzen: no I didn't mean your Column :)
[14:09] <faenil> it was a general statement
[14:09] <faenil> so, the issue is
[14:09] <faenil> ListItemLayout has to follow visual rules
[14:09] <ahayzen> :-)
[14:09] <faenil> like 1 or 2gu top/bottom padding depending on some conidtions and stuff
[14:09] <faenil> + it has to fit the labels
[14:10] <ahayzen> yeah that's what we expect... maybe i just need to change things around :-)
[14:10] <faenil> so you can't really restrict its height, because there would be no way to enforce that otherwise
[14:10] <ahayzen> just one of our listviews has the listitems set to 6GU in height
[14:10] <faenil> so ListItemLayout computes how much space it needs, and ListItem has to resize to show all of it
[14:10] <DS-McGuire> pmcgowan, Any chance we can see https://bugs.launchpad.net/ubuntu/+source/telephony-service/+bug/1477838 but onto a OTA milestone, the bug has been around far too long.
[14:10] <ubot5`> Launchpad bug 1477838 in Canonical System Image "[MX4] Crackling sound after playing audio and suspended" [Medium,Confirmed]
[14:11] <ahayzen> and another to 7
[14:11]  * ahayzen removes all the height stuff :-)
[14:11] <faenil> :) it has to follow layout's height
[14:11] <faenil> ahayzen: also remember to consider divider's height
[14:11] <faenil> (look at the doc, there's a whole section about height :) )
[14:11] <ahayzen> we hide the divider :-)
[14:11] <pmcgowan> DS-McGuire, I will check but I have not seen any progress either
[14:12] <DS-McGuire> pmcgowan, Thanks
[14:12] <faenil> ahayzen: I understand that this change of way of looking at things is confusing, but I couldn't find anything that worked better...if you have any idea on how to improve that just let me know ;)
[14:13] <ahayzen> faenil, no i like it, its awesome, i've hardly had to change anything for the listitems....the cards could be more interesting though :-)
[14:13] <faenil> :) cool
[14:13] <faenil> it would be even better if I find a way to remove that confusion.. :/
[14:13] <ahayzen> we are moving the cards from a custom ColumnFlow to GridView as well, so everything could be super smooth once it all lands :-)
[14:14] <faenil> :)
[14:14] <faenil> let's hope so :D
[14:14] <faenil> + there are more ListItemLayout optimizations to make (use QQuickItemListener), but I won't have time to work on that anytime soon O/
[14:14] <faenil> :/
[14:14] <ahayzen> hehe, ok it does look a bit different as the listitems are bigger, but it works
[14:14] <faenil> so it will get even a bit better :)
[14:15] <ahayzen> faenil, you can't do alias's to the title/subtitle properties right ?
[14:15] <faenil> yeah, please notice the paddings are all customizable, so if you *really* have to change it you can, once visual design acks it. So have a chat with them if their designs don't follow the rules they defined :D
[14:15] <faenil> ahayzen: me thinks
[14:16] <ahayzen> ooo, ok well our design was based of the design which got approved sooooo :-)
[14:16] <faenil> ahayzen: yeah, I mean, if the visual design you received needs customization to the listitemlayout properties, please make sure the designers know that
[14:17] <faenil> maybe the visual rules for layouts were not final when they made the music app designs
[14:17] <faenil> or something like that
[14:17] <ahayzen> i think we just had a smaller vertical spacing/padding between them, but this design is super old :-)
[14:17] <faenil> ahayzen: so you don't have a new visual design for the app?
[14:17] <ahayzen> define 'new' ;-)
[14:18] <faenil> newer than 6mo
[14:18] <faenil> :D
[14:18] <ahayzen> <3 months... don't think so, i've seen screenshots sometimes
[14:18] <ahayzen> probably not
[14:18] <faenil> mm ok
[14:18]  * ahayzen tries to remember
[14:18]  * ahayzen has been focussed on bgplaylists :-)
[14:18] <faenil> then just let designers have a look at it once you're done :)
[14:18] <faenil> hehe
[14:19] <ahayzen> i'll leave it as default for now, and see what other think :-)
[14:19] <faenil> yep ;)
[14:19] <ahayzen> faenil, but for the aliasing that didn't work... like property alias primaryText: listItemLayout.title.text; or something
[14:20] <faenil> ahayzen: I vaguely remember something, did you check the docs?
[14:20] <ahayzen> so i'm having to have a middle property string at the moment, unless i assume it'll always be model.title and model.author
[14:20] <ahayzen> i'm scanning through the docs :-)
[14:21] <faenil> me checks system settings, I think they did the same
[14:22] <faenil> ahayzen: try having a look at this https://code.launchpad.net/~phablet-team/ubuntu-system-settings/settings-listitems/+merge/278322
[14:22] <ahayzen> faenil, ok thanks :-)
[14:23] <faenil> ahayzen: so, you say the alias doesn't work at all? what's the issue
[14:23] <ahayzen> it says that isn't a valid location
[14:23] <faenil> sounds familiar...
[14:23] <ahayzen> i assume because the property doesn't exist until you query it or something ?
[14:23]  * faenil digs in his memory
[14:25] <ahayzen> faenil, they have done basically the same http://bazaar.launchpad.net/~phablet-team/ubuntu-system-settings/settings-listitems/view/head:/src/SystemSettings/ListItems/Standard.qml#L38
[14:25] <faenil> yeah I was just about to point at that
[14:25] <ahayzen> have a property string in the ListItem
[14:25] <faenil> mmm
[14:26] <ahayzen> would be cool if you could alias :-)
[14:26] <ahayzen> even less memory \o/
[14:26] <faenil> heh :)
[14:26] <faenil> I remember investigating that for sure
[14:29] <faenil> ahayzen: what if you alias title instead of title.text?
[14:29] <ahayzen> could work
[14:29]  * ahayzen tries
[14:29] <faenil> (can't find anything in my dev diary)
[14:31] <ahayzen> faenil, seems to possibly work :-) if it does it means i don't need separate properties for the colour/objectName as well \o/
[14:31] <faenil> ;)
[14:32] <ahayzen> thanks :-)
[14:32] <faenil> np!
[14:32] <faenil> ahayzen: thanks for reminding me about that :)
[14:32] <faenil> ahayzen: I definitely have to add it to the docs
[14:32] <ahayzen> maybe that should be noted in the docs
[14:32] <faenil> definitely
[14:36] <faenil> ahayzen: the alternative of course is to use slotslayout and your own labels, which is however not recommended, unless you just have 1 label and don't need a Column
[14:36] <ahayzen> yeah :-) i may need to use Slots for our Cards
[14:37] <faenil> could be, I don't remember what they look like, but sounds like a usecase for SlotsLayout, yeah
[14:37] <faenil> or some hammering work on ListITemLayout :D
[14:38] <ahayzen> well they are square/rectangular and go into the ColumnFlow or eventually GridView
[14:38] <faenil> mmm
[14:39] <faenil> kenvandine: how is the listitemlayout move coming along? any help needed to complete that?
[14:39] <faenil> or jgdx ^
[14:40] <kenvandine> stalled
[14:40] <kenvandine> nothing blocking it
[14:40] <kenvandine> just working on other stuff too
[14:40] <faenil> okay, cool
[14:40] <kenvandine> we're doing it along with refreshing the visuals throughout
[14:40] <ahayzen> faenil, the blocks in this that have album art then text below :-) https://plus.google.com/photos/photo/100887841569748798697/6229649300550663378
[14:45] <faenil> ahayzen: I see...well, definitely not a listitem :D
[14:45] <ahayzen> yah :-)
[14:45] <faenil> ahayzen: you could still use ListItemLayout for the lower part :DF
[14:45] <faenil> :D
[14:46] <ahayzen> time to find out if it breaks autopilot :-)
[14:46] <faenil> haha
[15:13] <ahayzen> balloons, jenkins is failing everything for music today, even though it says 'success' at the end? https://core-apps-jenkins.ubuntu.com/job/music-app-ci/48/console https://code.launchpad.net/~ahayzen/music-app/fix-1526274-use-layouts/+merge/281757
[15:20] <balloons> ahayzen, ohh boy.
[15:20] <balloons> ahayzen, I was playing with music yesterday a bit
[15:20] <ahayzen> faenil, so there are leading/trailing for left/right of the main, but nothing for above/below? so i'm probably going to have to just put my Column into the mainSlot...but then what advantage does that gain? From just being a Column to then being a SlotLayout with the mainSlot as the Column ?
[15:21] <ahayzen> balloons, hehe :-)
[15:21] <faenil> ahayzen: not much, aside from consistency with visual rules
[15:21] <faenil> (and it's not necessarily true that visual design wants that consistency, that's to be decided I guess)
[15:22] <faenil> if you have top/bottom stuff, you're probably creating something which is not a list item :D
[15:22] <ahayzen> but like would any rules be enforced lol what would it do differently to my column ? put padding around it? which i don't want it todo
[15:23] <ahayzen> yeah we call it a 'Card' and it goes (or will go) into a GridView
[15:23] <faenil> well, that's what listitemlayout does, handles a layout, padding/positioning
[15:23] <ahayzen> yeah :-/
[15:23] <faenil> plus is cheaper than Column + 2 labels iirc
[15:23] <faenil> (but please benchmark that if you want to go for it)
[15:23] <ahayzen> i wonder if eventually there should be a GridItemLayout or something
[15:23] <ahayzen> if design decide to use GridViews elsewhere
[15:23] <faenil> who knows :)
[15:24] <ahayzen> like parts of the scopes are similar ish
[15:24] <faenil> yeah
[15:24] <ahayzen> an Image at the top with a label below
[15:24] <faenil> though if it's just that you can use and Image + ListItemLayout, and use anchors, should be cheap that way
[15:24] <faenil> an*
[15:25] <ahayzen> hmm
[15:26] <ahayzen> so have a Columm { Image {} ListItemLayout {} } you mean ?
[15:28] <faenil> without column, just anchors, it's cheaper
[15:28] <faenil> listitemlayout.anchors.top: img.bottom
[15:29] <ahayzen> ok i'll have a play
[15:29] <faenil> :)
[15:29] <ahayzen> as we have some fun wrapping settings on the labels as well :-)
[15:29] <faenil> hehe
[15:30] <faenil> and Qt doesn't really do an awesome job with elideright + wrapping..
[15:30] <faenil> sometimes it wraps too early :/
[15:31] <faenil> (no wrapping, just elide sorry, it elides too early)
[15:31] <ahayzen> oh i saw it was doing that and just changed the setting...
[15:31] <ahayzen> faenil, try title.wrapMode: Text.WrapAnywhere
[15:31] <ahayzen> that then allows it to elide closer to the edge i found
[15:32] <faenil> ahayzen: yeah...
[15:32] <faenil> ok, so my vague memory was actually correct, it has to be default wrap setting + elide
[15:32] <faenil> :D
[15:32] <ahayzen> :-)
[15:33] <t1mp> ahayzen: hello
[15:33] <t1mp> ahayzen: I think I have a fix for https://bugs.launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/+bug/1531016
[15:33] <ahayzen> t1mp, o/
[15:33] <ahayzen> \o/
[15:33] <t1mp> you can try the attached MR
[15:33] <ahayzen> i applied your height idea and that worked for music as a workaround :-) http://bazaar.launchpad.net/~ahayzen/music-app/cards-use-gridview/revision/958
[15:34] <faenil> and that's what we have on listitemlayout by default...it probably makes sense to change the default value, at this point...
[15:34] <ahayzen> t1mp, awesome thanks, i'll try it :-)
[15:35] <t1mp> ahayzen: maybe it is also time to try out the new PageHeader :)
[15:35] <ahayzen> :-)
[15:35]  * ahayzen needs to get back to working on the convergence stuff
[15:35] <t1mp> ah, that reminds me to write a blog post about that
[15:59] <dholbach> jdstrand, beuno: I don't know why this became important recently, but I think it'd be good if we could land https://code.launchpad.net/~dholbach/click-reviewers-tools/1530894/+merge/281730 or something like it
[15:59] <dholbach> popey has been getting quite a bit of feedback about blocked uploads
[15:59] <dholbach> (not sure if Martin or Jamie are still on hols?)
[16:01] <beuno> dholbach, heya
[16:01] <beuno> yeah, I have the tab opened with some comments I haven't submitted  :)
[16:03] <balloons> ahayzen, you are going to see a few more weird things I'm guessing
[16:03] <dholbach> I should've said "I don't know why this became a problem recently" earlier
[16:03] <ahayzen> balloons, ok lol :-) are you able to fix it?
[16:04] <balloons> ahayzen, the weirdness with zero byte artifacts has FIANLLY been solved. So yes, everything should be able to come online
[16:04] <ahayzen> \o/ thanks balloons
[16:04] <balloons> I'll be at it this afternoon; I disabled it again
[16:05] <ahayzen> cool :-)
[16:05] <balloons> but notice https://core-apps-jenkins.ubuntu.com/job/adt-krillin/63/ actually ran again
[16:06] <balloons> and one more of yours that snuck in: https://core-apps-jenkins.ubuntu.com/job/adt-krillin/64/console
[16:07] <beuno> dholbach, my neither, I'd like jdstrand's input on it
[16:07] <beuno> maybe we should flat out ignore .mo's without even probing it
[16:07] <dholbach> beuno: popey asked what we do with blocked apps
[16:08] <beuno> what are blocked apps?
[16:08] <dholbach> because of this issue a bunch of apps are not let through right now
[16:08] <dholbach> they're blocked in the queue right now
[16:09] <dholbach> basically all arch=all apps with translations
[16:11] <balloons> ohh ahayzen, can you paste your adt line for running tests btw?
[16:11] <ahayzen> balloons, its in the readme.... but $ adt-run -o /tmp/music-app/output-folder . com.ubuntu.music_*_all.click --- ssh -s adb -- -p <passcode>
[16:11] <ahayzen> or
[16:12] <ahayzen> $ ADT_AUTOPILOT_MODULE="-v music_app.tests.test_music.TestEmptyLibrary.test_some_specific_test" adt-run -o /tmp/music-app/output-folder . com.ubuntu.music_*_all.click --- ssh -s adb -- -p <passcode>
[16:13] <balloons> ahayzen, I was curious about your subunit output
[16:13] <ahayzen> balloons, oh if your asking about the output, as you are in the other channel... it comes from -o
[16:13] <ahayzen> then in that folder it creates an artifacts folder
[16:13] <ahayzen> and then a subunit file
[16:13] <balloons> ahayzen, ohh, using -o will give a subunit file then eh?
[16:13] <balloons> and yea, I asked pitti for fun
[16:13] <ahayzen> :-)
[16:15] <beuno> dholbach, they are stuck in the review queue
[16:15] <beuno> and any of us can unblock it
[16:15] <beuno> if it's ok for them to go through
[16:15] <dholbach> ok, so you'd suggest we let them through?
[16:15] <beuno> we can wave them through until we figure out the automated tools
[16:17] <dholbach> popey: ^
[16:18] <beuno> are the mo binaries truly arch independant?
[16:18] <ahayzen> t1mp, that branch resolves the issue for both the test case and the music-app thanks :-)
[16:18] <ahayzen> t1mp, i assume that'll be in the OTA10 landing of the uitk ?
[16:22] <dholbach> beuno: yes - in the archive we build arch: all packages just once (let's say on i386) and use the packages on all architectures
[16:23] <beuno> dholbach, cool, so lets wave them through
[16:23] <beuno> and I'll comment on the MP that I wouldn't even probe for .mo's to be mo's
[16:23] <dholbach> so fn.endswith('.mo') would be good enough for you?
[16:29] <beuno> dholbach, it would, yes
[16:32] <t1mp> ahayzen: yes, I assume the same :)
[16:32] <ahayzen> cool thanks :-)
[17:08] <DS-McGuire> pmcgowan, Thanks for pushing that bug to OTA9 :D
[17:08] <pmcgowan> DS-McGuire, np, just reproduced it pretty reliably, not sure yet what it is
[17:09] <pmcgowan> the audi elemnt is being paused properly
[17:09] <pmcgowan> audio element
[17:09] <pmcgowan> odd I never noticed it myself
[17:09] <DS-McGuire> Yeah it is super easy to repoduce.
[17:10] <DS-McGuire> I notice it all the time, I like to work in silence with my phone on my desk and that bug makes me have to clear all notifications as soon as I get them because it just pops and cracks all night long.
[17:16] <pmcgowan> DS-McGuire, so clearing the notifications makes it stop?
[17:19] <ahayzen> faenil, using the analyse tool in QtC the listitemlayout, effectively removes the part that was in an async loader before... this then reduces the time by ~5ms to load (from ~10ms) for each delegate on mako, so will probably be more noticeable on lower powered devices :-)
[17:19] <faenil> wow, half the time just by moving to listitemlayout
[17:19] <ahayzen> yeah ish, it is really tricky to calculate
[17:20] <faenil> 5ms is huge though
[17:20] <faenil> 5ms for one delegate is a lot :/
[17:20] <ahayzen> the loader was all over the place before between 3-8ms
[17:20] <ahayzen> faenil, but its still way below 16ms :-) and this is when scrolling rapidly down the list
[17:21] <faenil> ahayzen: mmm but you don't just create 1 delegate each frame
[17:21] <faenil> and even if, you don't have 16ms, the compositor has to work on it as well...
[17:21] <ahayzen> no, and you can see the fps stays easily ~60fps
[17:22] <faenil> ok, so it probably takes way less than 5ms each delegate
[17:22] <faenil> otherwise I don't think quick scrolling would keep 60fps
[17:22] <faenil> but even relatively slow scrolling wouldn't :D
[17:22] <faenil> ahayzen: how are you computing the time?
[17:22] <ahayzen> :-) that's just what the QtC analyse thing says it takes to create it :-)
[17:23] <faenil> I see, ok...
[17:23] <faenil> mmm
[17:23] <ahayzen> it was terrible in the old days before Florian showed us some tricks :-) and now with listitemlayout its halved again \o/
[17:23] <DS-McGuire> pmcgowan, Yes, sorry I thought that was known information.
[17:23] <faenil> \o/
[17:24] <faenil> some tricks like? (I'm curious :) )
[17:24] <ahayzen> faenil, how do you usually measure the time ?
[17:24] <faenil> ahayzen: during component development I use Q_BENCHMARK
[17:24] <faenil> on a View with 5k delegates
[17:24] <ahayzen> ...there was a presentation that Gerry did as well
[17:24] <ahayzen> ah
[17:24] <ahayzen> remember our one has an Image in it as well
[17:25] <ahayzen> that it has to get from the thumbnailer
[17:25] <faenil> yeah, ofc :)
[17:25] <faenil> that's the main bottleneck most likely...
[17:25] <faenil> but hey, I don't have much info about what it takes to stay at 60fps on our devices
[17:25] <faenil> so it's very useful to get some numbers
[17:25] <ahayzen> faenil, when you have some time what this if you haven't before :-) https://www.youtube.com/watch?v=RpU6md2mMFs
[17:26] <faenil> it would be lovely to see the time the compositor needs as well
[17:27] <ahayzen> that shows using the performance monitor thing, where it was bad if it went over 16ms he said :-)
[17:27] <faenil> ahayzen: ah ok, I have already I think
[17:27] <faenil> yeah, I still believe we don't have 16ms though ;)
[17:28] <faenil> because of other stuff that needs doing to get that frame on screen
[17:28] <ahayzen> yeah idk, maybe that's all included in this somehow :-)
[17:28] <faenil> maybe greyback can give shed some light on that
[17:28] <faenil> -give
[17:29] <faenil> ahayzen: sure, it could be that the analyzer takes that into account already, don't remember
[17:29] <ahayzen> :-)
[17:30] <faenil> greyback: how much time can we spend actually doing the drawing?
[17:30] <faenil> (i.e. so that with compositor, nested servers and whatnot it is < 16ms)
[17:30] <greyback> faenil: to get 60fps, you've got 16.6ms per frame
[17:30] <ahayzen> and what does the analyse tool in QtC show?
[17:31] <ahayzen> is that the final time?
[17:31] <greyback> my follow-up to Florian's presentation: https://docs.google.com/presentation/d/1wFu6gNaaFVdTjIQYvMokeHg5iLZ_GG5xgohWQ9hwwyA/edit#slide=id.p
[17:31] <faenil> greyback: yes, but the compositor surely does some handling and wastes some of that time
[17:31] <faenil> it's surely not free :)
[17:31] <ahayzen> greyback, ah yeah was that the presentation you did at Washington ?
[17:31] <greyback> faenil: yeah, there's only one GPU, so it's scheduler manages sharing the tasks
[17:32] <faenil> greyback: yeah, but you can't work on a half finished frame
[17:32] <faenil> so you have less than 16 to draw, then send it to the compositor, and let it do its job
[17:32] <faenil> right?
[17:33] <greyback> faenil: phone GPUs make it hard to say yes or no to that. You generate gl calls, then calls swap buffers. the gpu driver only then gets to work
[17:34] <greyback> the deferred rendering architecture means it's hard to know how long it actually takes to draw that frame
[17:34] <greyback> need to use fences to accurately measure it
[17:34] <faenil> greyback: well, if you can't keep 60fps, it means it took too long :) I was wondering whether you guys had some stats about that
[17:34] <faenil> on devices like krillin or arale
[17:35] <greyback> faenil: nothing handy, sorry
[17:35] <faenil> greyback: ok, thanks anyway :) but you do agree the app has (potentially way?)-less than 16ms, right?
[17:35] <greyback> faenil: sure
[17:35] <faenil> greyback: ok, cool :)
[17:36] <greyback> but if you're anywhere near 16ms per frame, you're doing way too much
[17:36] <faenil> greyback: yeah, exactly, that was my point
[17:36] <greyback> apps at 10ms a frame should look smooth
[17:36] <faenil> greyback: if your app takes 16ms to produce a frame, that's never going to be rendered at 60fps
[17:36] <faenil> greyback: there we go, that's what I was looking for :)
[17:37] <greyback> if your compositer was free, it just about could manage it :)
[17:37] <faenil> heh, exactly ;)
[17:37] <faenil> my point :)
[17:37] <greyback> and there's situations where it is free, using hardware overlays
[17:37] <greyback> but we're not using those (yet)
[17:37] <faenil> greyback: but you still have window decorations, shadows around windows etc, don't you
[17:37] <faenil> well, not on touch maybe
[17:37] <faenil> but in the convergent world... :)
[17:38] <faenil> (not on mobile phone in mobile mode, I meant :D )
[17:38] <greyback> if the only thing on screen that changes is your surface, we can put that surface in an overlay. then the hardware will composte new frames of your surface, without redrawing everything else around it
[17:38] <greyback> it a good perf bonus
[17:38] <faenil> indeed
[17:38] <faenil> looking forward to hw overlays :D
[17:43] <faenil> ahayzen: so yeah, that's what I meant ^^
[17:43] <faenil> :)
[17:43] <ahayzen> :-) so 5ms is good then \o/
[17:44] <faenil> haha, well 5ms is just the delegate creation, then you have to paint it, and paint the other things that changed in your app (assuming an ideal renderer where exactly only the things that changed are repainted)
[17:45] <faenil> and since you're scrolling a list, you basically have to paint all the delegates which are on screen :D
[17:45] <ahayzen> yup :-)
[17:45] <faenil> so, yeah...I still think 5ms for 1 delegate creation is still a bit tight ^_^
[17:46] <ahayzen> when it was ~10ms before it would still hit ~60fps on mako, but then everything was async
[17:46] <faenil> especially because n4 is not exactly a dumb phone :D
[17:48] <ahayzen> faenil, so on the Cards one, we have it so the first line can have a maximumLineCount: 2 but when it wraps the text goes over the subtitle ?
[17:48] <ahayzen> would that be 'expected' ?
[17:49] <faenil> ahayzen: nope :)
[17:49] <faenil> I remember investigating that as well...
[17:50] <faenil> ahayzen: can you check if title.height changes when the text wraps?
[17:50] <ahayzen> i'll try :-)
[17:50] <faenil> (if it doesn't, then it's likely not my fault)
[17:50] <faenil> cool
[17:54] <ahayzen> faenil, it does change      qml: LineCount 1 height 40        qml: LineCount 2 height 80
[17:54] <faenil> ahayzen: crap :D
[17:56] <ahayzen> faenil, this is my ListItemLayout if it helps http://pastebin.ubuntu.com/14422428/
[17:57] <faenil> ahayzen: mmm you're constraining its height...
[17:57] <ahayzen> ah yeah, as the GridView requires the height to be fixed
[17:58] <ahayzen> faenil, shall i remove the bottom: anchor and see what happens?
[17:59] <faenil> ah right, gridview constraints...mmm that's interesting
[17:59] <faenil> ahayzen: yea please try, but it's probably not going to fix it
[17:59] <ahayzen> yeah thats why we had our ColumnFlow before :-)
[17:59] <ahayzen> that allowed for differing height cards
[17:59] <faenil> hehe yeah
[17:59] <faenil> I remember that wrapping issue anyway...now the point is: did I forget about fixing, or did I forget what the solution is? :D
[18:00] <ahayzen> but design finally understood we would never get the same performance so now we've been told to use GridView
[18:00] <faenil> hehe
[18:00] <ahayzen> faenil, i don't think taking the bottom off has helped... the subtitle appears in the exact place where it does on ones where the title does not wrap as well
[18:01] <faenil> ahayzen: meanwhile, I'm changing the default wrapping, as that's likely what the dev will want to use (WrapAnywhere), because what Qt does when ElideRight is used is not nice :/
[18:01] <faenil> ahayzen: yeah, as expected
[18:01] <ahayzen> yeah WrapAnywhere or Text.WrapAtWordBoundaryOrAnywhere are good :-)
[18:02] <faenil> yep
[18:04] <faenil> ahayzen: timeout for me today :) be back tomorrow, and will have a closer look at that issue and fix it if needed :)
[18:04] <ahayzen> faenil, thanks :-)
[18:04] <faenil> have a nice day o/
[18:05] <ahayzen> you too thanks for your help o/
[18:06] <faenil> nw!
[18:06] <faenil> ahayzen: ps WrapAtWordBoundaryOrAnywhere is not enough
[18:06] <faenil> it has to be anywhere
[18:06] <faenil> (just tested)
[18:06] <ahayzen> hehe :-)
[18:07] <faenil> ;D
[18:07] <ahayzen> WrapAtWordBoundaryOrAnywhere is good when you actually want to wrap across two lines
[18:11] <jdstrand> beuno: I committed dholbach's change with some changes in r564. It sounds like it would be a good time for a sync of the review tools
[18:11] <jdstrand> beuno: and hi!
[18:11] <beuno> jdstrand, o/
[18:11] <beuno> ack
[21:11] <ahayzen> balloons, i see your having fun with jenkins for music :-), i think bug 1452492 maybe a good candidate for code-in (i don't think it has already been implemented)