| Saviq | tsdgeos, hey, so, Omer was testing our "more async dash" silo yesterday and found that switching left/right between scopes is actually worse than in current rtm when all the scopes are loaded already | 08:37 |
|---|---|---|
| tsdgeos | what's the definition of "worse"? | 08:38 |
| tsdgeos | more jumpy? | 08:38 |
| Saviq | tsdgeos, it improves things for initial loading (and I imagine for refreshing then, too) | 08:38 |
| Saviq | tsdgeos, and yeah, there's more stuttering after they're all loaded | 08:38 |
| tsdgeos | it may be because of the bug i found yesterday | 08:39 |
| Saviq | tsdgeos, do you think what you discovered yesterday would have impact? also, I started thinking maybe we should not do anything with the delegates when we change the current scope to avoid any operations blocking the animation | 08:40 |
| Saviq | tsdgeos, right, that's what I was thinking | 08:40 |
| tsdgeos | well it's creating more things than needed | 08:40 |
| tsdgeos | we're not doign stuff when changing delegates | 08:41 |
| tsdgeos | or at least that's what the code tries to do | 08:41 |
| tsdgeos | there may be bugs of course, but i remember trying it | 08:41 |
| Saviq | tsdgeos, are we not basing the size of the cache buffer on isCurrent? | 08:42 |
| Saviq | tsdgeos, GSV.qml:412 seems to say so | 08:43 |
| tsdgeos | yes, but cachebuffer is async "should not" affect performance and only do stuff in the background | 08:43 |
| tsdgeos | but i see what you mean | 08:43 |
| tsdgeos | can try not modifying stuff if the parent dashcontent is not settled | 08:44 |
| Saviq | tsdgeos, yeah, please have a look at this today, anything I can take off your hands to not distract you? | 08:44 |
| tsdgeos | i'm actually looking at another thing that makes the dash bad | 08:45 |
| Saviq | the thing we talked about yesterday/ | 08:45 |
| tsdgeos | the carousel cachebuffer, displayMargins are badly set | 08:45 |
| Saviq | ? | 08:45 |
| Saviq | okies | 08:45 |
| tsdgeos | since they assume a vertical growing pattern | 08:45 |
| tsdgeos | not an horizontal one | 08:45 |
| tsdgeos | so basically we're loading all the stuff on the carousel | 08:46 |
| tsdgeos | for every single carousel out there | 08:46 |
| tsdgeos | which is not bad in real life since we don't use them much | 08:46 |
| Saviq | right, why do they stutter when scrolling then ¿? | 08:46 |
| tsdgeos | but it's what makes the dashcontent test slow to settle | 08:46 |
| tsdgeos | carousels stutter? | 08:47 |
| Saviq | yeah | 08:47 |
| tsdgeos | well it must be something else being awful | 08:47 |
| Saviq | at least the music one does for me | 08:47 |
| tsdgeos | the delegates are all created | 08:47 |
| Saviq | that might be the thumbnail image provider | 08:48 |
| tsdgeos | if you put a | 08:48 |
| tsdgeos | Component.onCompleted: console.log("CC Create", index, cardCarousel.objectName) | 08:48 |
| tsdgeos | Component.onDestruction: console.log("CC Destroy", index, cardCarousel.objectName) | 08:48 |
| tsdgeos | on the Loader of CardCarousel.qml you'll see lots of stuff in the log | 08:48 |
| tsdgeos | ah wait, no they're not all loaded | 08:48 |
| tsdgeos | sorry, there's still a cachebuffer | 08:48 |
| Saviq | yeah I understand, we're deferring the images are we not | 08:48 |
| tsdgeos | it's just that those out of view still think they are in view and thus load themselves | 08:49 |
| tsdgeos | when they should not | 08:49 |
| tsdgeos | cacheBuffer is still set to 1404 | 08:49 |
| Saviq | I think it's the image loading itself (I can see them showing up late) that causes the stutter | 08:49 |
| Saviq | tsdgeos, yeah, anyway, you know best what to do, let me know if I can help | 08:50 |
| tsdgeos | we need to sit down and try to write unit tests for this stuff | 08:50 |
| tsdgeos | but it's hard :/ | 08:50 |
| tsdgeos | Saviq: so there's 3 different bugs/issues, i'll report them so we have a paper trail of what's going on, ok? | 08:54 |
| Saviq | tsdgeos, yeah, thanks | 08:55 |
| mzanetti | Saviq: re drag-to-refresh minimum velocity | 09:05 |
| Saviq | maximum, rather :) | 09:06 |
| mzanetti | in my experience the best is if you require the finger release to happen while being dragged | 09:06 |
| mzanetti | with min distance | 09:06 |
| mzanetti | but no velocity | 09:06 |
| Saviq | mzanetti, I trigger the refresh multiple times a day when just flicking up/down in the dash | 09:07 |
| Saviq | +accidentally | 09:07 |
| mzanetti | sure | 09:07 |
| mzanetti | but the current code doesn't require you to press, drag a certain ditance and then release, does it? | 09:08 |
| Saviq | it does | 09:08 |
| mzanetti | hmm ok... true | 09:08 |
| Saviq | just as long as you drag down a certain distance it will refresh, without it even being able to show you the "release to refresh" string | 09:08 |
| mzanetti | ah ok... maximum velocity might help | 09:09 |
| Saviq | yeah, just don't trigger unless the velocity at release time is < foo | 09:09 |
| mzanetti | Saviq: what would also help is if the content would only disappear once the new content is here | 09:10 |
| mzanetti | and not clear -> load -> show | 09:10 |
| Saviq | yeah, there's a bug about that | 09:10 |
| Saviq | but it would only help with the perception, not with the fact :) | 09:10 |
| mzanetti | true | 09:11 |
| mzanetti | but it's all about the perception :) | 09:11 |
| Saviq | tsdgeos, I was thinking that instead of on isCurrentChanged, we could increase the cache buffer (if necessary, depending on memory and visual impact) on first scroll in a scope, otherwise we create and destroy delegates all the time without them being ever displayed | 09:25 |
| Saviq | that's assuming we can't deal with a static cacheBuffer all along | 09:25 |
| tsdgeos | that's right, when you switch scope we're creating delegates you may not need | 09:26 |
| tsdgeos | but i'm pretty sure that if you do it on scroll | 09:26 |
| tsdgeos | it is not going to work | 09:26 |
| tsdgeos | in fact it's why we create them before hand | 09:26 |
| tsdgeos | :D | 09:26 |
| Saviq | yeah, that was /me just thinking, you know better :) | 09:27 |
| tsdgeos | don't think i do much better, only a bit :D | 09:27 |
| Saviq | paulliu, did you get help on flashing yesterday? | 10:11 |
| Saviq | dandrader, can you please follow up on https://code.launchpad.net/~josharenson/unity8/physical_keys_filter/+merge/244244 | 10:12 |
| dandrader | Saviq, ok | 10:13 |
| paulliu | Saviq: yes. Now it it solved. There are some lock file left in cache. | 10:40 |
| Saviq | paulliu, glad | 10:40 |
| paulliu | Saviq: I removed those files and it get worked. | 10:40 |
| Saviq | Cimi, Wellark, can you please update the status of bug #1363400 and add appropriate tasks, comment on what's required to fix the bug | 10:44 |
| ubot5 | bug 1363400 in ubuntu-system-settings (Ubuntu RTM) "[wizard] allows to "Continue" without connecting to network" [High,Triaged] https://launchpad.net/bugs/1363400 | 10:44 |
| === duflu_ is now known as duflu | ||
| Saviq | dednick, can you please explain https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/lp1378821.time-translation/+merge/246194 a bit? we don't care about that label overflow? | 10:55 |
| === Malsasa_ is now known as Malsasa | ||
| dednick | Saviq: it's something funky with labels which are right aligned. changing the text doesn't seem to adjust it's size in a layout correctly iirc. So if the text changed from "" -> "Sat 10:30am" the text would start off the page on the right. Need to replicate and log with qt | 10:58 |
| Saviq | dednick, ah, so a problem with layouts | 10:58 |
| dednick | Saviq: yeah, or text areas. not sure which. | 10:59 |
| dednick | only seems to happen with right aligned text areas... | 10:59 |
| dednick | or only visible with them anyway | 10:59 |
| Saviq | dednick, hmm, at least looking at the code it could never have gotten right-aligned because the Label was never wider than the text, so there was no right-alignment possible | 11:04 |
| Saviq | dednick, what I mean is Layouts don't "stretch" items | 11:04 |
| mzanetti | dandrader: hey, I just installed shellrotation on the nexus7 | 11:05 |
| mzanetti | dandrader: it breaks windowed mode | 11:05 |
| Saviq | dednick, i.e. http://paste.ubuntu.com/9728215/ works fine | 11:06 |
| dednick | Saviq: ok, but why was it screwing up? | 11:08 |
| Saviq | dednick, that is a good question, I'll try and reproduce here | 11:09 |
| dednick | actually, i think i remember why i put in the right align. because the text did not resize if the time changed. in which case, the text could get smaller than the label. | 11:10 |
| dednick | Saviq: ^ | 11:10 |
| dednick | or seomthing | 11:11 |
| Saviq | yeah in any case I can see the current code not doing the right thing | 11:11 |
| dandrader | mzanetti, what did you do to switch to windowed mode on the N7? | 11:12 |
| Saviq | but I'd say just growing the Label should do (not that anchoring to the right isn't better anyway in this case, assuming we're not afraid of overflow) | 11:12 |
| Saviq | dandrader, there's a gsetting | 11:12 |
| mzanetti | dandrader: gsettings set com.canonical.Unity8 usage-mode Windowed | 11:13 |
| dandrader | mzanetti, so I guess it remained in tablet mode? | 11:13 |
| mzanetti | yes | 11:13 |
| Saviq | dednick, btw https://code.launchpad.net/~nick-dedekind/ubuntu-ui-toolkit/lp1378821.time-translation/+merge/246191/comments/608254 | 11:14 |
| dednick | Saviq: i think i removed the elide because of the non-growing promlem. or just the fact that eliding on the right is shite for time stamps | 11:14 |
| dednick | Saviq: ta | 11:14 |
| Saviq | dednick, that latter part makes sense :) | 11:15 |
| Cimi | Saviq, aanti might be on holiday | 11:15 |
| Cimi | Saviq, I tried pinging him since yesterday morning | 11:15 |
| Saviq | dednick, btw, to update the .api file there's a script in tests/ that creates a .new file I think | 11:22 |
| dednick | Saviq: yup. thanks | 11:23 |
| Saviq | just diff the files and if correct, check in | 11:23 |
| dednick | Saviq: hm. can't seem to get the api thingo working. keeps giving me "COmponent is not ready" | 11:40 |
| tsdgeos | Saviq: https://code.launchpad.net/~aacid/unity8/dash_ranges_on_move/+merge/246286 should make that no items are created/destroyed because of the scopes list being moved horizontally | 11:58 |
| tsdgeos | it can still happen though that if you change scopes fast the cacheBuffer ones for the current one are in creation process | 11:59 |
| tsdgeos | can't think of a way to make that not happen with our current infra | 11:59 |
| greyback_ | mzanetti: have done a little work on https://code.launchpad.net/~gerboland/qtmir/acquire-wakelock/+merge/245942 - but unable to repro your issue. Could you try again please? | 12:00 |
| greyback_ | and if you do repro your bug again, please ssh in and get the output of "sudo powerd-cli list" | 12:00 |
| === MacSlow is now known as MacSlow|lunch | ||
| mzanetti | greyback_: well, sshing in is not that easy :) | 12:06 |
| mzanetti | greyback_: as it only happens if unplugged | 12:06 |
| greyback_ | mzanetti: ssh over wifi works! | 12:07 |
| mzanetti | doesn't that get cut off in the deep sleep phase? | 12:07 |
| mzanetti | anyways, I'll try | 12:07 |
| === bpierre_ is now known as bpierre | ||
| greyback_ | mostly works | 12:07 |
| === dandrader is now known as dandrader|bbl | ||
| Saviq | tsdgeos, FAIL! : qmltestrunner::DashContent::test_noDelegateCreationDestructionOnMove() 'verify()' returned FALSE. () | 12:42 |
| greyback_ | https://code.launchpad.net/~gerboland/unity8/async-dbus-dashcomm/+merge/244892 - could I get a review of this please? I'm unable to reproduce the CI test fails locally, are our tests stable in CI right now? | 12:44 |
| Saviq | greyback_, they're not | 12:45 |
| greyback_ | Saviq: ok, good to know | 12:45 |
| Saviq | greyback_, yeah, DashContent tests take too long there and fail, Albert's looking into improving that | 12:46 |
| Saviq | dednick, mzanetti, who wants to review greyback_'s branch ↑? | 12:46 |
| greyback_ | Lorn already +1ed it | 12:46 |
| greyback_ | but happy to get more eyes on it | 12:47 |
| dednick | Saviq: i can, but just about to start making lunch. | 12:47 |
| dednick | once my eyes see food, i can't stop :) | 12:47 |
| Saviq | dednick, enjoy, not too pressing | 12:48 |
| mzanetti | well, as the dash doesn't get suspended any more... is this needed? | 12:50 |
| Saviq | greyback_, ↑ | 12:56 |
| greyback_ | mzanetti: yes, the main loop blocking is still a bad thing, which impacts code I want to propose after | 12:57 |
| === alan_g is now known as alan_g|lunch | ||
| Saviq | tsdgeos, FYI: bug #1410260 | 13:37 |
| ubot5 | bug 1410260 in thumbnailer (Ubuntu) "Image provider blocking the UI thread" [Undecided,New] https://launchpad.net/bugs/1410260 | 13:37 |
| tsdgeos | hmmm | 13:42 |
| davidcalle | sil2100, ping | 13:42 |
| tsdgeos | Saviq: hmmm, may be, they should probably want to use my code | 13:42 |
| tsdgeos | Saviq: fails for you? or in CI? | 13:42 |
| Saviq | tsdgeos, for me, some others failed in CI | 13:43 |
| Saviq | tsdgeos, but what's worse, it fails IRL | 13:43 |
| tsdgeos | ? | 13:43 |
| tsdgeos | you mean when using it? or the test on your pc? | 13:43 |
| Saviq | tsdgeos, commented on the MP | 13:43 |
| tsdgeos | ok | 13:43 |
| Saviq | tsdgeos, using | 13:43 |
| tsdgeos | that's confusing | 13:43 |
| tsdgeos | very confusing | 13:44 |
| * tsdgeos tries to find out what's wrong | 13:45 | |
| Saviq | tsdgeos, let me know if can help | 13:45 |
| tsdgeos | Saviq: did you try that on vivid or rtm? | 13:45 |
| Saviq | tsdgeos, both, actually | 13:45 |
| Saviq | tsdgeos, with debugging on rtm I think, but locally on desktop on vivid+trunk, too | 13:46 |
| tsdgeos | i don't knwo what's rtm | 13:46 |
| tsdgeos | has all the stuff for the dash been merged? | 13:46 |
| === alan_g|lunch is now known as alan_g | ||
| tsdgeos | i don't see how it can fail in the test either | 13:47 |
| tsdgeos | Saviq: can you add the debugs in the test? | 13:48 |
| Saviq | tsdgeos, rtm + the silo, so all the stuff for dash in there | 13:48 |
| tsdgeos | right | 13:48 |
| Saviq | tsdgeos, I did, just let me know what and where | 13:48 |
| Saviq | s/did/can/ | 13:48 |
| === dandrader|bbl is now known as dandrader | ||
| tsdgeos | ok, give me a sec, maybe i can reproduce too | 13:48 |
| Saviq | I looked at the arrays and got ~1200 vs. ~600 items | 13:48 |
| tsdgeos | 1275 | 13:49 |
| tsdgeos | that's how i get here in both | 13:50 |
| Saviq | let me see | 13:52 |
| Saviq | tsdgeos, btw, you say "Wait for the buttons to settle..." when in fact you just get them, don't wait for anything? | 13:52 |
| tsdgeos | Saviq: i do | 13:53 |
| tsdgeos | there's a 250 msec loop above | 13:53 |
| Saviq | ah now I see | 13:53 |
| Saviq | yeah ok | 13:53 |
| sil2100 | davidcalle: pong | 13:53 |
| Saviq | tsdgeos, 1379 vs. 1395 now | 13:55 |
| Saviq | tsdgeos, and that seems to be stable now | 13:55 |
| tsdgeos | Saviq: can you try making that 250 msec 1000 | 13:55 |
| tsdgeos | just in case | 13:55 |
| Saviq | tsdgeos, yeah, passed | 13:56 |
| tsdgeos | really? | 13:56 |
| tsdgeos | 1395 vs 1305 ? | 13:56 |
| tsdgeos | i mean 1395 both? | 13:56 |
| davidcalle | sil2100, hey :) I would need your input to update this dev doc page : https://developer.ubuntu.com/en/start/ubuntu-for-devices/image-channels . In the "Ubuntu channels" section, is it useful to list the <release name> channel and the <release name>-proposed ? I would assume aliases are enough. | 13:56 |
| Saviq | tsdgeos, yeah, test passed | 13:57 |
| Saviq | tsdgeos, 500 not enough, 750 enough | 13:58 |
| tsdgeos | meh | 13:58 |
| tsdgeos | what takes 750ms to create | 13:58 |
| === MacSlow|lunch is now known as MacSlow | ||
| Saviq | tsdgeos, in any case, should we really have that many items? | 13:59 |
| tsdgeos | no | 13:59 |
| Saviq | or is that the carousels? | 13:59 |
| tsdgeos | but that's the carousel problem in part | 13:59 |
| tsdgeos | a substantial part i'd say | 14:00 |
| sil2100 | davidcalle: looking | 14:01 |
| tsdgeos | but anyway that's not the problem | 14:01 |
| tsdgeos | the problem is that it doesn't seem to work as you say on the phone | 14:01 |
| tsdgeos | well it worked for me on a quick test | 14:02 |
| tsdgeos | let me try again | 14:02 |
| Saviq | tsdgeos, not on my desktop either, just add http://paste.ubuntu.com/9729959/ and see what happens when you switch scopes | 14:02 |
| sil2100 | davidcalle: I would personally leave those there, but maybe change them to really something like "<series>" and "<series>-proposed", indicating that we have a channel for every series we support | 14:03 |
| tsdgeos | Saviq: nothing | 14:03 |
| Saviq | tsdgeos, make? | 14:04 |
| tsdgeos | Saviq: note this is when switching scopes, not after the scope has switched | 14:04 |
| tsdgeos | obviously after the scope has switched there will be items being created and destroyed | 14:04 |
| Saviq | tsdgeos, well, ok, that's where I think the problem lies then | 14:05 |
| tsdgeos | you are getting this while you drag the scope? | 14:05 |
| tsdgeos | why? | 14:05 |
| tsdgeos | there's no movement | 14:05 |
| tsdgeos | at that point | 14:05 |
| tsdgeos | so what's the problem? | 14:05 |
| Saviq | tsdgeos, there is, because you're swiping to the next scope by that time | 14:05 |
| tsdgeos | ah sure | 14:05 |
| tsdgeos | this doesn't fix that | 14:05 |
| davidcalle | sil2100, cool, that's what I have on my draft :) Also, if you see potentially outdated stuff, in the doc, please tell me, thanks! | 14:05 |
| tsdgeos | Saviq: i already mentioned that, no? Or maybe i didn't | 14:06 |
| Saviq | tsdgeos, and anyway, I see creates/destroys while I hold my mouse down | 14:06 |
| tsdgeos | Saviq: from which scope to which? | 14:06 |
| Saviq | tsdgeos, first to second | 14:06 |
| Saviq | tsdgeos, *but* | 14:06 |
| Saviq | tsdgeos, I mean that's happening for me in the real scopes | 14:07 |
| sil2100 | davidcalle: there's actually one thing I was thinking of changing since I already have you around ;) | 14:07 |
| Saviq | that's probably the plugin | 14:07 |
| sil2100 | davidcalle: there's the "Channel selection guide" there | 14:07 |
| tsdgeos | what do you mean it's the plugin? | 14:07 |
| Saviq | tsdgeos, the plugin queries scopes onIsActiveChanged | 14:07 |
| sil2100 | davidcalle: I would actually recomment setting ubuntu-touch/ubuntu/devel as the preferred channel for Nexus 7 and 10 | 14:07 |
| davidcalle | sil2100, ok | 14:08 |
| sil2100 | davidcalle: in our current process we only do sanity testing for rtm for mako, emulator and krillin | 14:08 |
| tsdgeos | Saviq: didn't we remove that code? | 14:08 |
| sil2100 | davidcalle: so we have no guarantee that the rtm images are working on those supported devices - on the other hand, the devel channel requires QA to do testing on all supported devices | 14:08 |
| Saviq | tsdgeos, the shell plugin only queries the first two scopes on startup, then queries the "next" one as you change the active scope | 14:08 |
| tsdgeos | ah, i see, that's something that is being done behind our backs | 14:09 |
| Saviq | yes | 14:09 |
| Saviq | tsdgeos, but my subjective feeling was that stuff got worse, let me try again | 14:11 |
| tsdgeos | it can't turn worse | 14:11 |
| Saviq | ;) | 14:11 |
| Saviq | tsdgeos, it's better after scopes are loaded, but it felt worse while they were loading | 14:12 |
| tsdgeos | well there's a few more connections | 14:12 |
| tsdgeos | but that should be peanuts | 14:12 |
| tsdgeos | the code is the same it was with the exception of the next scope doesn't get the new big cachebuffer that caused stuff to be created | 14:12 |
| davidcalle | sil2100, when you have 5 more min, please tell me if it's ok to close this bug now : https://bugs.launchpad.net/developer-ubuntu-com/+bug/1403642 :) | 14:17 |
| ubot5 | Launchpad bug 1403642 in Ubuntu App Developer site "ubuntu-touch/stable description is no longer valid, other descriptions need updating as well" [Medium,Triaged] | 14:17 |
| Saviq | tsdgeos, ok, to improve things a little, should we maybe delay us changing the margins for a split second so that you only trigger it if you've stayed on a scope a moment | 14:19 |
| Saviq | ? | 14:19 |
| Saviq | and maybe base isCurrent on that, too? | 14:19 |
| Saviq | → isActive | 14:19 |
| Saviq | tsdgeos, but I'm actually OK to delay, let me just confirm that this fixes what Omer reported | 14:20 |
| Saviq | tsdgeos, and we can follow up later | 14:20 |
| tsdgeos | i'm not sure i wouldn't go that way | 14:21 |
| Saviq | tsdgeos, any idea about the test failures though? | 14:21 |
| tsdgeos | what we need to make is just make the whole thing faster creating items | 14:21 |
| tsdgeos | not find workarounds and workaroudns of worksrounds | 14:21 |
| Saviq | tsdgeos, sure ;) | 14:21 |
| sil2100 | davidcalle: almost perfect, I was only wondering if maybe the /stable channel description could mention that currently it's pointing to /14.09? I know this would get outdated if we change rtm to a different series, but this way at least it will be clear that it's best using /stable | 14:22 |
| sil2100 | davidcalle: or maybe differently! | 14:23 |
| sil2100 | davidcalle: if you could add in 14.09 that it's best to use /stable instead, that would be awesome | 14:23 |
| davidcalle | sil2100, agreed, doing that | 14:24 |
| Saviq | tsdgeos, but, TBH we should not claim to have fixed bug #1384374 then... | 14:29 |
| ubot5 | bug 1384374 in unity8 (Ubuntu RTM) "Dash pauses/stutters during scope switching left/right" [High,In progress] https://launchpad.net/bugs/1384374 | 14:29 |
| tsdgeos | maybe no | 14:29 |
| tsdgeos | it's just an unfixable bug | 14:29 |
| Saviq | yeah, we just need to strike a balance and do our best to improve | 14:29 |
| tsdgeos | unless you throw away all we have and go back to something sane like a alll the phones do and have a static dash | 14:30 |
| * tsdgeos hides :D | 14:30 | |
| tsdgeos | Saviq: well there's one thing we can do at some point, not sure how hard it is | 14:30 |
| tsdgeos | and is add our own incubator | 14:30 |
| Saviq | tsdgeos, don't worry, we'll be rendering the bits out of process and compositing them soon enough, we'll be able to make the side-swiping perfectly smooth ;) | 14:30 |
| tsdgeos | that doesn't incubate at all | 14:30 |
| tsdgeos | when you're swiping | 14:31 |
| greyback_ | Saviq: "rendering the bits out of process" - yeah? | 14:31 |
| greyback_ | surface per scope? | 14:31 |
| tsdgeos | what would solve your problem of swiping while the current cached items of the scope are being incubated | 14:31 |
| tsdgeos | as far as i understand that should be possible | 14:31 |
| sil2100 | davidcalle: thanks! :) | 14:32 |
| tsdgeos | Saviq: i can try looking into that if you want | 14:32 |
| Saviq | greyback_, that's what we seem to be going towards, yes | 14:32 |
| greyback_ | Saviq: ok | 14:32 |
| davidcalle | sil2100, np, thanks to you :) | 14:33 |
| tsdgeos | Saviq: ok, so i work on the "not load all carousels at once", now, ye? | 14:53 |
| Saviq | tsdgeos, are you fine with the tests on that MP though? | 14:55 |
| tsdgeos | Saviq: i made the wait bigger | 14:55 |
| Saviq | tsdgeos, ok | 14:55 |
| tsdgeos | nasty and lam | 14:55 |
| tsdgeos | e | 14:55 |
| tsdgeos | as i can see it is either that or remove them | 14:56 |
| tsdgeos | we can keep them and if they fail all the time | 14:56 |
| tsdgeos | remove it and try to spend time to find a smarter way | 14:56 |
| sterns | good day. I am doing some research for a software development project. My question pertains to the use of the favorites/launcher bar. When some programs are running, they do not create additional favorites entries, but instead stack on the existing icon. How does one control that behavior? The program currently has a separate (running) icon on the favorites bar, and I would like it to stack. | 15:02 |
| Cimi | mterry, ping | 15:04 |
| mterry | Cimi, heyo | 15:09 |
| Cimi | mterry, morning :) any update on the first branch from design? | 15:09 |
| mterry | Cimi, I believe they are going to go over it "this week" | 15:10 |
| greyback_ | oh yay, "g++4.9:native" works with my Xcompiling chroots | 15:10 |
| Cimi | mterry, "okay" | 15:11 |
| Saviq | greyback_, yeah, it's a nasty workaround, but there's nothing better yet | 15:11 |
| mterry | Cimi, :) I just meant I don't know more specifics than a whole week | 15:11 |
| kgunn | dandrader: hey, is the rotation ppa good to go ? | 15:33 |
| kgunn | i've got richard pinging me | 15:33 |
| dandrader | kgunn, it seemed to be yesterday, but today greyback_ told me it has visual glitches | 15:34 |
| kgunn | dednick: on the laggy backend bug and doing a deeper dive, is that something we need design input on? or is it mainly a | 15:39 |
| kgunn | technical frontend/backend rework | 15:39 |
| kgunn | re-arch | 15:39 |
| dednick | kgunn: not sure we need design input. unless we want to display something fancy while we wait for confirmation. | 15:41 |
| dednick | *validation | 15:41 |
| kgunn | dednick: ack...sounds like it can be an engineering solved prob then... | 15:43 |
| tsdgeos | Cimi: the carousel thing is more a problem on how i set the cachebuffer from the outside than a carousel bug by itself | 15:43 |
| tsdgeos | i can give you some insight if you want but i *think* i know how to fix it | 15:43 |
| Cimi | tsdgeos, thought it was a carousel bug... | 15:44 |
| Cimi | :P | 15:44 |
| Cimi | tsdgeos, well I can test it then | 15:44 |
| tsdgeos | nah, it's more a "how do we use the carousel in the big picture" | 15:44 |
| tsdgeos | that'd be great | 15:44 |
| Cimi | this one is easy https://code.launchpad.net/~cimi/unity8/fix-1393008/+merge/246138 | 15:48 |
| dandrader | Saviq, did the power button usage got worse recently (not blanking or turning the display on rapidly and consistently)? | 16:04 |
| === dandrader is now known as dandrader|afk | ||
| Saviq | dandrader|afk, not that I know of | 16:11 |
| Saviq | Cimi, got one for you, should be somewhat simple, too | 16:12 |
| Saviq | 1410337 | 16:12 |
| Saviq | bug #1410337 | 16:12 |
| ubot5 | bug 1410337 in unity8 (Ubuntu) "Launching a scope once installed is broken" [High,Triaged] https://launchpad.net/bugs/1410337 | 16:12 |
| Cimi | Saviq, cool | 16:12 |
| Saviq | tsdgeos, I was wondering, is there a chance non-current scopes still load its delegates synchronously? the amount of blocking on initial swipes is just crazy :/ | 16:13 |
| tsdgeos | Saviq: there is | 16:13 |
| tsdgeos | i'm sure some of them are | 16:13 |
| tsdgeos | but most of them shouldn't | 16:13 |
| tsdgeos | thing is you need a patched Qt to debug that out | 16:15 |
| greyback_ | bregma: hey, this might be of interest to you: https://code.launchpad.net/~gerboland/qtmir/fix-GTK-rendering/+merge/246201 | 16:15 |
| tsdgeos | since there's really no way to know if somethign was done async or not otherwise | 16:15 |
| greyback_ | bregma: it's removing the hack you made to fix GL rendering. In my testing it works everywhere now without the hack - why, I've no real idea | 16:16 |
| bregma | hmm, we shall see.... | 16:16 |
| greyback_ | bregma: I checked it on my nvidia & amd machines, emulator and phone. But I'd really appreciate a sanity check | 16:17 |
| bregma | did maybe some fix to Qt sneak in so it doesn;t use an enum any more? | 16:17 |
| greyback_ | bregma: Not a clue. I'd have to dig. | 16:21 |
| Saviq | tsdgeos, well, I'm sure you can gdb it ;) | 16:24 |
| tsdgeos | Saviq: kind of yeah | 16:24 |
| === dandrader|afk is now known as dandrader | ||
| tsdgeos | cimi: there? | 16:47 |
| tsdgeos | Cimi: i'd like to know a way to know the width of the items on the viewport of a carousel | 16:50 |
| tsdgeos | that is, if the carousel is 200 width | 16:50 |
| tsdgeos | we're still cramming more items inside those 200 pixels because of the translations | 16:50 |
| tsdgeos | so i'f need to know if it's 250 pixels or what were putting inside those 200 | 16:50 |
| tsdgeos | not sure if i'm making sense | 16:51 |
| popey | greyback_: yo, i flashed my flo and updated as per https://wiki.ubuntu.com/Unity8/FullShellRotation but the dash is always landscape. | 16:51 |
| popey | greyback_: known issue? | 16:51 |
| greyback_ | popey: intended | 16:52 |
| popey | oh okay. | 16:52 |
| greyback_ | popey: was asked to make it landscape only anyway. Can be undone fairly easily | 16:53 |
| Saviq | om26er_, as you might've seen, we've fixed the issue you reported on silo 12, and decided to not say we've fixed the stutter bug when we really need more time and work to investigate | 16:58 |
| Cimi | tsdgeos, sorry I should not update kernel without checking compatibility :) | 16:59 |
| Cimi | tsdgeos, mumble? | 16:59 |
| tsdgeos | Cimi: i have to run now | 16:59 |
| tsdgeos | tomorrow? | 16:59 |
| Cimi | tsdgeos, ok, or ping me later | 17:00 |
| om26er_ | Saviq, good, i'll retest. | 17:08 |
| popey | greyback_: is there a bit I can flip on my own device? | 17:09 |
| greyback_ | popey: edit /usr/share/applications/unity8-dash.desktop, and remove the "X-Ubuntu-Supported-Orientations=primary" line - then restart unity8 | 17:10 |
| greyback_ | should work in theory, not tested | 17:10 |
| Saviq | (restart uniity8-dash should be enough, no?) | 17:10 |
| greyback_ | Saviq: unity8 deas the desktop file of unity8-dash | 17:10 |
| greyback_ | s/deas/reads/ | 17:11 |
| Saviq | greyback_, well, yeah, but it will re-read it when the app restarts? | 17:13 |
| greyback_ | Saviq: true | 17:13 |
| === Guest56__ is now known as LouWebb | ||
| === Guest34 is now known as digitalalex | ||
| popey | greyback_: works, but yeah... ☻ | 17:28 |
| greyback_ | popey: that bad?? /me tries | 17:29 |
| greyback_ | guessing slow resize, so breaks animation | 17:29 |
| greyback_ | yep | 17:30 |
| greyback_ | dash resize is painfully slow for some reason | 17:30 |
| Saviq | I know the reason ;) | 17:31 |
| Saviq | it's a painfully complex UI | 17:31 |
| greyback_ | it's a freaking grid :D | 17:32 |
| Saviq | greyback_, it is freaking, that's for sure | 17:32 |
| Saviq | greyback_, prepping a unity8 silo, got qtmir? (like :native) | 17:32 |
| Saviq | (for vivid) | 17:33 |
| greyback_ | Saviq: yes, but CI failed https://code.launchpad.net/~gerboland/qtmir/gcc4.9-crosscompile/+merge/246316 | 17:33 |
| greyback_ | some udev package weirdness | 17:33 |
| greyback_ | I had to muck around in my chroots to fix it locally | 17:34 |
| Saviq | greyback_, it's actually not a udev issue | 17:35 |
| Saviq | greyback_, your CI job needs updating | 17:35 |
| greyback_ | Saviq: ah boo. Who can do that? | 17:35 |
| Saviq | greyback_, you need H10strip_native_depends to be added to hooks | 17:36 |
| Saviq | greyback_, my PoC is fginther | 17:36 |
| greyback_ | ok will poke him | 17:36 |
| greyback_ | t | 17:36 |
| greyback_ | aa | 17:36 |
| Saviq | greyback_, basically, there's still a bunch of tools that don't understand :native - pbuilder is one of them | 17:37 |
| Saviq | greyback_, any reason not to land the two remaining ACK-ed MPs for qtmir? | 17:41 |
| greyback_ | Saviq: none at all. I hoped you were just including them | 17:41 |
| Saviq | greyback_, am, was just confirming | 17:43 |
| Saviq | greyback_, should bug #1389189 make its way into rtm? | 17:44 |
| ubot5 | bug 1389189 in QtMir "event area not filled in by Mir" [Medium,In progress] https://launchpad.net/bugs/1389189 | 17:44 |
| Saviq | or the fix for, rather | 17:44 |
| greyback_ | Saviq: I don't really see it being RTM necessary really. | 17:45 |
| greyback_ | really | 17:45 |
| Saviq | k | 17:54 |
| === alan_g is now known as alan_g|EOD | ||
| om26er_ | Saviq, the changelog for silo12 looks a bit scary, is there anything except for the TestPlan that I should be testing ? | 19:34 |
| Saviq | om26er_, that changelog is a bug | 19:35 |
| Saviq | om26er_, in the train | 19:35 |
| Saviq | om26er_, ah wait | 19:35 |
| om26er_ | Saviq, sorry, I meant the diff | 19:35 |
| Saviq | om26er_, no, it all impacts the dash, and only the "surface" of it, i.e. list of results | 19:36 |
| Saviq | om26er_, it's been in vivid for two months now or so | 19:36 |
| om26er_ | yeah but not many are running vivid :) | 19:36 |
| Saviq | om26er_, more than you think :) | 19:37 |
| Saviq | om26er_, in any case, if you have not found anything wrong when just browsing through the dash, that's your confirmation | 19:37 |
| Saviq | it should all behave slightly better, less stutter when swiping up/down | 19:38 |
| om26er_ | Saviq, I have confirmed the fixes and nothing looks wrong in the dash, I'll just go ahead with approving that | 19:39 |
| Saviq | om26er_, we're confident with those changes, have tested them thoroughly, too | 19:39 |
| om26er_ | curious though why is the unity8 TestPlan on the wiki short. | 19:39 |
| Saviq | om26er_, thanks | 19:39 |
| Saviq | om26er_, we have a rather extensive set of qml tests | 19:40 |
| om26er_ | Great! | 19:40 |
| Saviq | om26er_, so manual testing is basically just having a play with the phone and verifying the few journeys that we want to confirm are fine | 19:41 |
| om26er_ | Saviq, the loading of current view *3 shows blank pictures if quickly flicked from top to bottom in flicr | 19:44 |
| om26er_ | I guess that's a compromise we are gonna have to live | 19:45 |
| Saviq | om26er_, yeah, it's either that | 19:47 |
| Saviq | om26er_, or the view being stuck | 19:47 |
| Saviq | om26er_, but the time it takes to load the images we still have ways to improve | 19:47 |
| Saviq | om26er_, probably the biggest UX impact would be to actually show the empty shapes | 19:47 |
| Saviq | but there's other issues, including in Qt, that we need to work on to speed this stuff up | 19:48 |
| om26er_ | Saviq, hmm, so perhaps a bug report will help us track of this, so that it doesn't get forgotten | 19:48 |
| Saviq | om26er_, there are a few already, actually :) | 19:49 |
| Saviq | om26er_, we can have a over-arching one "Improve image loading performance", but I think that does not require a bug for us to remember it ;) | 19:49 |
| om26er_ | Saviq, did you consider increasing the loaded area to view*4 ? | 19:52 |
| om26er_ | that might minimize this visual problem | 19:52 |
| om26er_ | Saviq, I am just trying to make sure we are not regressing something for little gains ? | 19:53 |
| kgunn | greyback_: on this wakelock bug, i'm was gonna be a third set of eyes...trying to repro on vivid/mako before i test your fix | 19:57 |
| kgunn | i only saw the camera app take a minute to render after my first boot/flash... | 19:58 |
| kgunn | i've rebooted a couple of times, and every unlock i end up seeing the dash | 19:58 |
| kgunn | is there some other symptom you're using/seeing reliably ? | 19:58 |
| kgunn | ...the bug says happens after reboot, but is it really only after 1st boot/flash | 19:59 |
| kgunn | ...ah nvmd, i see something listed in your first comment on the MP | 20:00 |
| Saviq | om26er_, that's not going to improve things | 20:03 |
| Saviq | om26er_, as loading just takes more time than scrolling | 20:03 |
| Saviq | om26er_, we need to, at least: cache lower size images; improve Qt to parallelize (and cancel) image provider requests | 20:04 |
| Saviq | om26er_, and then there's the adverse effect of memory consumption | 20:05 |
| om26er_ | I think that potential improvement have been identified for a long time, perhaps from the time when scrolling in the dash was jerky ? | 20:05 |
| Saviq | yeah, this silo is fixing that adverse effect of too high memory consumption when we were loading too many items | 20:06 |
| Saviq | and slaps on more asynchronicity, which is why you can swipe the my photos scope at all | 20:06 |
| Saviq | instead of waiting multiple seconds for it to load (and kill multiple background apps in the process, wasting CPU etc.) of images that you might not even want to see | 20:07 |
| Saviq | -of | 20:07 |
| om26er_ | I understand and somewhat convinced that we should land this ;) | 20:08 |
| === boiko_ is now known as boiko | ||
| === popey_ is now known as popey | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!