[02:34] <Deo> Hello, guys.
[02:34] <Deo> I am in some need of some serious help.
[02:35] <Deo> Anyone?
[02:35] <Deo> I'm having issues installing google chrome on Ubuntu.
[02:37] <Deo> ANYONE?!
[02:39] <Deo> Hello?
[02:53] <Deo> HELLOOOOOOOOOOOOOO
[07:50] <mzanetti> moin moin
[08:00] <Saviq> eo
[08:01] <mzanetti> are there still promoted images? the last update on my dogfooding device came in on the 29th of august
[08:02] <seb128> mzanetti, what device/channel?
[08:02] <mzanetti> mako, ubuntu-touch/utopic
[08:03] <seb128> yeah, that's right
[08:03] <seb128> the google doc says the most recent promotion on utopic is #203 and it's almost 3 weeks old
[08:04] <mzanetti> yeah... that's why I asked if we gave up on those and only focus on the RTM branches for now
[08:04] <mzanetti> basically if I should switch the dogfooding device over to the other channel
[08:08] <Saviq> mzanetti, no, we just need to get our shit together and promote something ;)
[08:11] <mzanetti> Saviq: did you then resubmit this one? https://code.launchpad.net/~mzanetti/unity/new-key-in-launcher-schema/+merge/232199
[08:11] <Saviq> mzanetti, no
[08:12] <Saviq> mzanetti, see my comment
[08:13] <mzanetti> replied
[08:13] <mzanetti> Saviq: ^
[08:13] <Saviq> mzanetti, still, we need defaults in the schema, even if we do an override
[08:13] <Saviq> mzanetti, why wouldn't we have defaults for the desktop
[08:14] <Saviq> mzanetti, think unity8 desktop session
[08:14] <mzanetti> Saviq: so what should I put in there?
[08:14] <Saviq> mzanetti, the same set we have in the override now
[08:14] <Saviq> mzanetti, even more maybe, now that we can do clicks
[08:14] <mzanetti> the override has clicks too
[08:14] <Saviq> does it?
[08:14] <mzanetti> yes
[08:14] <Saviq> doubt it
[08:14] <Saviq> we didn't support click updates
[08:15] <mzanetti> the defaults are not related to upgrades :)
[08:15] <Saviq> ok maybe that got fixed in the mean time
[08:15] <Saviq> meaning that we did not lose icons on upgrades any more
[08:16] <Saviq> but we did have camera and gallery there before
[08:16] <mzanetti> yep
[08:16] <Saviq> and removed them because they got broken on updates
[08:16] <mzanetti> ah... ok. didn't know we removed them
[08:16] <Saviq> yeah, we only have non-clicks on launcher now
[08:17] <Saviq> with your launcher rework, we're able to have clicks again, icons will get refreshed, right?
[08:17] <mzanetti> yes
[08:17] <Saviq> ok we need to find out what we want on the launcher then, can you talk to Vesa?
[08:17] <mzanetti> ok
[08:18] <Saviq> mzanetti, *and*, even if we wanted override, do you have a branch that moves the override to the new key?
[08:18] <Saviq> not that we need the override any more
[08:18] <mzanetti> Saviq: well, I keep on reading the "favorites" key if the "items" key is empty
[08:18] <mzanetti> so yes, we could drop the override
[08:19] <Saviq> mzanetti, I don't think that's necessary (to read favorites)
[08:19] <mzanetti> Saviq: works fine as an upgrade path from unity7 to unity8 though
[08:19] <Saviq> mzanetti, yeah, *if* you leave the items empty
[08:19] <mzanetti> huh?
[08:20] <Saviq> mzanetti, that would be a reply to my "why don't we have any defaults" question
[08:20] <mzanetti> ah, yes... if I put defaults in there it won't be empty
[08:20] <mzanetti> hmm... good point.
[08:20] <Saviq> mzanetti, also, application:///, not application://
[08:21] <Saviq> mzanetti, I commented before
[08:21] <Saviq> mzanetti, the problem there is that we can't use the favorites override to include appid:// entries can we
[08:22] <Saviq> mzanetti, meaning we still can't have clicks there
[08:22] <Saviq> meaning the upgrade path is a bit brokened :|
[08:22] <mzanetti> Saviq: yes, sure we can
[08:23] <Saviq> mzanetti, well, except you'll get the new default set in your unity7 if you did not change anything
[08:23] <Saviq> so you install the override and your unity7 launcher goes haywire
[08:23] <mzanetti> unity7 will just drop them
[08:23] <Saviq> yeah, but it won't have firefox or anything either
[08:23] <mzanetti> yes, if you launch unity7 on a unity8 config it'll drop clicks. but keep the rest
[08:24] <Saviq> mzanetti, no, what I mean is:
[08:24] <Saviq> "the rest" is not useful in unity7
[08:24] <mzanetti> why no?
[08:24] <Saviq> because it's phone, contacts, messages, settings, webbrowser
[08:24] <mzanetti> yeah well.
[08:24] <mzanetti> on the desktop you won't have that override installed
[08:25] <mzanetti> and I expect contacts to become useful on the desktop
[08:25] <Saviq> mzanetti, yeah, and that means your launcher is useless in your unity8 desktop session ;)
[08:25] <Saviq> mzanetti, TBH I don't think it's worth it
[08:25] <mzanetti> Saviq: the whole uity8 desktop session is useless
[08:25] <mzanetti> Saviq: we don't have an applicationmanager
[08:25] <Saviq> mzanetti, of course we do
[08:26] <mzanetti> in which case why would launching systemsettings be useless?
[08:26] <mzanetti> I don't get the problem
[08:26] <Saviq> mzanetti, I'm not talking unity8 on X11, but unity8 on Mir
[08:26] <Saviq> mzanetti, the problem is the two launcher configs are not compatible
[08:26] <mzanetti> that's why we created the new key
[08:26] <Saviq> mzanetti, yes, and my point is
[08:26] <Saviq> mzanetti, that we should not transition them
[08:27] <Saviq> mzanetti, not by way of the other key
[08:27] <mzanetti> well... just tell me what to do then
[08:27] <Saviq> mzanetti, just use items
[08:27] <Saviq> mzanetti, don't read favorites, put the defaults for items in the schema, we can then drop the override
[08:27] <mzanetti> ok
[08:28] <Saviq> mzanetti, we can have a task that will do a single-time copy of favorites (if non-default) to items
[08:28] <Saviq> mzanetti, but again, I don't think it's worth it at this point
[08:28] <mzanetti> Saviq: what is the reason of the 3 slashes?
[08:29] <mzanetti> unity7 used 2 slashes only
[08:29] <Saviq> mzanetti, uppercase
[08:29] <Saviq> mzanetti, QUrl lowercases the hostname part
[08:29] <Saviq> mzanetti, which is actually correct
[08:29] <Saviq> mzanetti, so apps with differently cased .desktop files didn't work
[08:29] <mzanetti> hah... interesting
[08:33] <mzanetti> seb128: could you remind me where I can find the phone overrides for the launcher dconf keys?
[08:33] <seb128> mzanetti, I don't think we have phone overrides?
[08:33] <mzanetti> we do... quite sure about that
[08:33] <seb128> mzanetti, we have https://launchpad.net/ubuntu/+source/gsettings-ubuntu-touch-schemas
[08:34] <seb128> but those are schemas/defaults
[08:34] <seb128> mzanetti, ubuntu-touch-settings: /usr/share/glib-2.0/schemas/10_ubuntu-touch-settings.gschema.override
[08:35] <seb128> mzanetti, so right, in ubuntu-settings
[08:35] <mzanetti> seb128: thanks!
[08:35] <seb128> mzanetti, yw!
[08:35] <mzanetti> :)
[09:01] <Cimi> Saviq, are we merging the big silo soon?
[09:03] <Saviq> Cimi, it's blocked in proposed, currently trying to resolve this, but yes, it's almost there
[09:04] <Cimi> Saviq, I would like to test flickable right speed on top of it
[09:05] <Cimi> Saviq, I did some extra testing last night, and discovered few things
[09:06] <mzanetti> seb128: seems I can't push to ubuntu-settings. would you mind dropping the launcher overrides in there for me?
[09:06] <seb128> mzanetti, can't you mp your change?
[09:07] <mzanetti> hmm... maybe if I push to some +junk branch first
[09:07]  * mzanetti tries
[09:07] <seb128> oh
[09:08] <mzanetti> hmm.. no
[09:08] <seb128> mzanetti, don't bother, I though it had a proper vcs
[09:08] <mzanetti> the "Propose for merging is missing"
[09:08] <mzanetti> the "Propose for merging" is missing
[09:08] <seb128> yeah
[09:08] <seb128> it's hosted on a +junk vcs
[09:08] <Cimi> Saviq, like the initial flick velocity is probably calculated wrong inside qt
[09:08] <seb128> mzanetti, what's the rational to drop the launcher config?
[09:09] <Saviq> Cimi, lp:~ps-jenkins/unity8/ubuntu-utopic-proposed
[09:09] <Cimi> Saviq, in any case I think the "1500" and "2500" (for deceleration and velocity) are not good default values ANYWAY, even scaled
[09:09] <mzanetti> seb128: the dconf + accounts service mix gave us a headache all the time, so we reworked that code bit. Now only using dconf, we added a new key for unity8 called "items"  instead of "favorites"
[09:09] <Saviq> Cimi, that's what's in proposed now
[09:09] <mzanetti> seb128: where we'll add the defaults just in there instead of an override
[09:09] <Cimi> Saviq, dziekuje
[09:09] <seb128> mzanetti, did that land in utopic yet?
[09:10] <Cimi> Saviq, so I think I will use a higher default value for now, and scale it
[09:10] <mzanetti> seb128: nope. I would put your branch into the same silo with the others
[09:10] <Cimi> Saviq, also inside ScopeOverviewFavourite
[09:10] <seb128> mzanetti, that's not going to be a branch but a source upload, but those changes don't need to be synced do they?
[09:10] <Cimi> Saviq, why are we not using a Row but we're calculating each x of the repeater?
[09:11] <seb128> mzanetti, you can land your change and then I can do an upload to drop the override later
[09:11] <Cimi> tried with Row, works fine
[09:11] <mzanetti> seb128: no, they don't really need to. we just need to make sure my changes are first
[09:11] <seb128> right
[09:11] <mzanetti> seb128: ok. I'll ping you again about it when my stuff has landed
[09:11] <seb128> mzanetti, thanks
[09:12] <Saviq> Cimi, most probably because of transitions
[09:12] <Saviq> Cimi, but you'd have to talk to Albert
[09:13] <Cimi> Saviq, ok
[09:39] <Cimi> Saviq, tags
[09:39] <Cimi> 0.1.16 loves u
[09:40] <Saviq> Cimi, I can't do anything until it gets into trunk
[09:40] <Cimi> ok
[09:40] <seb128> Saviq, oh, you mentioned tags yesterday, just remembering that ... what's the issue with those?
[09:40] <Saviq> seb128, I pulled settings, there's like a hundred of ? tags
[09:41] <seb128> Saviq, could be, I don't usually look at those so I probably just never noticed
[09:41] <Saviq> seb128, http://paste.ubuntu.com/8298371/
[09:41] <seb128> Saviq, does it create any practical issue?
[09:41] <seb128> do you know where they are coming from?
[09:41] <Saviq> seb128, they look citrain-y, but must've come from some other project
[09:42] <Saviq> seb128, some bad merge or so
[09:42] <seb128> k
[09:42] <Saviq> seb128, maybe the ubuntu branch?
[09:48] <mzanetti> Saviq: FYI. had a chat with Vesa. He thinks its not good to have gmail, facebook etc in there anyways and we should keep the current list of defaults.
[09:48] <Saviq> mzanetti, well... what about gallery, camera?
[09:48] <Saviq> they were there before
[09:48] <Saviq> sure we shouldn't have gmail or facebook
[09:48] <dednick> Saviq: howdy. remember talking about the lag opening the indicator panel?
[09:49] <Saviq> dednick, hey, welcome back, hit me
[09:49] <dednick> Saviq: thanks :)
[09:49] <Saviq> mzanetti, anyway, if they're good with the current default set, fine by me
[09:49] <dednick> Saviq: it's because the models for the menus are synchornous.
[09:49] <Saviq> dednick, yeah just read your reply
[09:49] <dednick> Saviq: but making them async creates the problem where we open the menus and nothing is there
[09:49] <dednick> for a second or so..
[09:50] <dednick> Saviq: right.
[09:50] <Saviq> dednick, sooo... why does it takes so long to sync? unitymenumodel slow? it's not like there's a huge amount of data
[09:50] <dednick> Saviq: i was wondering if it would create "that" much effect not disconnecting from the models
[09:50] <dednick> Saviq: no, it's actually not the models. the models run all the time
[09:50] <Saviq> dednick, ah so just the delegates?
[09:50] <dednick> Saviq: it's actually the listviews adding the delegates
[09:51] <Saviq> dednick, ouch, sounds excessive indeed
[09:51] <Saviq> dednick, but well, should be easy to check what's the impact memory-wise
[09:51] <Saviq> dednick, we sure need to set them invisible, but we might be able to keep them around inded
[09:51] <Saviq> +e
[09:52] <dednick> Saviq: ya, we can probably just set the entire panel menu to invisible
[09:57] <mzanetti> Saviq: camera and gallery are there
[09:58] <mzanetti> http://paste.ubuntu.com/8298483/
[10:03] <Cimi> Saviq, can you pls repeat how to sbuild armhf? I tried sbuild -d utopic-amd64-armhf-shm but it build amd64 debs
[10:04] <Saviq> Cimi, bug #1353855
[10:04] <Saviq> Cimi, and sbuild --help
[10:06] <Saviq> Cimi, -d is *distribution*
[10:06] <Cimi> Saviq, yes saw that
[10:06] <Cimi> using -c
[10:06] <Saviq> Cimi, you want -c for *chroot*, and you need to pass --host=armhf, otherwise it'll build amd64
[10:06] <Saviq> Cimi, how's it supposed to know what arch to build otherwise
[10:06] <Cimi> ah damn
[10:06] <Cimi> so what is the command?
[10:07] <Saviq> -c utopic-amd64-armhf-shm --host=armhf
[10:07] <Cimi> Saviq, wonderful, thanks
[10:07] <Saviq> Cimi, but you need to drop the 4.9 dependency, otherwise it'll fail to install build deps
[10:08] <Cimi> Saviq, where do I drop it? unity8?
[10:08] <Saviq> Cimi, in whatever you're building
[10:08] <Cimi> ok
[10:08] <Saviq> Cimi, just read, please
[10:09] <Cimi> Saviq, it doesn't explain which pkg I have to replace, so I just change -4.9 to 4.9 or just g++ ?
[10:10] <Saviq> Cimi, drop it altogether
[10:12] <Cimi> dednick, we don't want async then
[10:12] <Cimi> https://code.launchpad.net/~nick-dedekind/unity8/indicator-polishing/+merge/228700
[10:12] <Cimi> dednick, all indicators are async, not only message
[10:12] <dednick> Cimi: it's too laggy when opening if we dont
[10:12] <Cimi> dednick, well, we need to figure out a solution
[10:12] <dednick> Cimi: yeah, i'm trying to now.
[10:15] <Saviq> Trevinho, do you know about a bug that apps scope doesn't notice newly installed apps?
[10:31] <Cimi> Saviq, did the proposed branch have albert branch to cache more stuff?
[10:31] <Saviq> Cimi, no, see silo
[10:31] <Cimi> Saviq, ok
[10:33] <Cimi> Saviq, ok so, the reason why the horizontal swipe is slower than the vertical one, is just that our finger moves quickly in a shorter space than the vertical swipe
[10:33] <Cimi> maybe not entirely though, carousel is still so fast
[10:34] <Cimi> actually carousel speed is tweaked further if I remember
[10:34] <Saviq> it is
[10:38] <facundobatista> Holas
[10:52] <dednick> Saviq: so, the indicators when not loaded with messages or transfers takes up about 1-2MB. with a 3 completed transfers and 10 messages it was about an additional 5MB
[10:53] <Saviq> dednick, right, so as long as we use ListViews there, we should be fine
[10:53] <Saviq> so as not to create 100 messages in case someone has that many
[10:54] <Saviq> dednick, sure it'd be better if we could create the delegates dynamically, but it'd have to be much faster
[10:56] <Saviq> dednick_, what did you see last?
[10:57] <dednick_> Saviq: <Saviq> so as not to create 100 messages in case someone has that many
 dednick, sure it'd be better if we could create the delegates dynamically, but it'd have to be much faster
[10:57] <Saviq> for now I think we're fine with not unloading them
[10:57] <dednick_> Saviq: ya. perhaps the limitation should be on the backend
[10:57] <Saviq> dednick_, backend doesn't know much about the UI though
[10:58] <dednick_> Saviq: in fact there may already be one.
[10:58] <Saviq> we're going that direction in the dash as well (keeping more in mem)
[10:58] <dednick_> Saviq: meh. hard to limit on frontend since they're all the same.
[10:58] <dednick_> i mean indicators are all the same, so hard to say max of x menu items
[10:59] <dednick_> Saviq: but then this is all going to be changing again anyway right... :)
[10:59] <Saviq> dednick_, exactly, and different delegates, different sizes etc.
[10:59] <dednick_> :(!!
[10:59] <Saviq> dednick_, what I meant is that a ListView with cacheBuffer: 2*height or something should allow us to keep memory usage low while improving the UX a lot
[11:00] <dednick_> Saviq: backend limits age, so it should limit number as well
[11:00] <Saviq> dednick_, yeah, but we can't rely on that, we need to make sure in UI that stuff works still
[11:00] <dednick_> Saviq: right
[11:00] <Saviq> dednick_, so let's go for that
[11:00] <dednick_> Saviq: yeah, i was looking at that cachebuffer thing.
[11:01] <Saviq> dednick_, items in cachebuffer have the important property of being created asynchronously
[11:01] <Saviq> dednick_, so if you're not scrolling too fast, things should be smooth
[11:02] <Saviq> dednick_, you might even change the cacheBuffer on indicator open
[11:02] <Saviq> dednick_, so that we don't hold them in mem all the time, but create them async on indicator open, so that we have a buffer out of view
[11:03] <Saviq> dednick_, one important thing though - the ListView is anchored to the bottom isn't it? kinda means stuff is destroyed as you close and recreated on open anyway
[11:03] <Saviq> because as you drag the panel down, its height grows
[11:03] <Saviq> but maybe that's fine, as long as we have some cacheBuffer and the experience is good
[11:04] <dednick_> Saviq: ok, well i'll give it a go
[11:09] <Trevinho> Saviq: mh, not that I recall... It used to work. Maybe sometimes it take some time...
[11:10] <Saviq> Trevinho, I installed chrome when I pung you, still not there
[11:11] <Trevinho> Saviq: mh, ok killing the scope fixed it?
[11:11] <Saviq> Trevinho, yes
[11:12] <Saviq> /food
[11:12] <Trevinho> mh, wondering if some caching caused that... I'll check that, mh3 would have been more helpful here :/, but I'll look
[11:23] <Saviq> pete-woods, if you want, I got a script for syncing bug statuses between project and ubuntu package
[11:23] <Saviq> and creating a Ubuntu task where applicable
[11:23] <pete-woods> Saviq: thanks. I just disabled bug reports on the upstream project like was mentioned in that bug :)
[11:24] <pete-woods> apparently that's our policy now
[11:24] <Saviq> pete-woods, yeah, but you still have bugs that are only against libusermetrics
[11:24] <pete-woods> oh, I thought I moved them
[11:24] <Saviq> pete-woods, ah well, maybe you have enough bugs that you did it manually is all :D
[11:24] <pete-woods> there were only about 10 bugs
[11:24] <Saviq> pete-woods, yeah ;)
[11:25] <Saviq> pete-woods, so yeah, you're good
[11:25] <pete-woods> (no-one knows the project exists, ssssh ;) )
[11:25]  * Saviq still was unable to un-affect all the unity8 bugs, apparently not possible via the API :|
[11:25] <pete-woods> that's a shame
[11:25] <pete-woods> I'd kinda expect LP to have a bulk-edit feature in the UI
[11:25] <pete-woods> like other tools I've used in the past
[11:27] <Saviq> they do, the API ;P
[11:34] <Cimi> dandrader, try time make -B -j15 and time make -B -j8, the latter is faster to me
[11:38] <dednick_> Saviq: it's pretty jerky with the cacheBuffer lowered
[11:42] <dandrader> Cimi, "real" and "user" are faster but "sys" is slower. Whatever that means. But yeah, seems to be a bit faster
[11:50] <dandrader> Cimi, got another small one, if you have some spare minutes: https://code.launchpad.net/~dandrader/unity8/buildWithoutWarnings/+merge/233736
[11:51] <Cimi> dandrader, I have spare time
[11:51] <Cimi> currently just testing flickable speeds
[11:51] <Cimi> "just"
[11:51] <Cimi> is experimenting
[12:00] <Saviq> dednick_, in what case?
[12:00] <dednick_> Saviq: scolling messages. esspecially if you drag over bounds. it gets a bit screwed up. i think the item heights are changing.
[12:01] <Saviq> dednick_, that's weird
[12:20] <dednick_> Saviq: not really when you think about it. http://paste.ubuntu.com/8299420/
[12:20] <dednick_> i meant that the items height's were changing on purpose.
[12:20] <Saviq> dednick_, just make the Loader height: 40
[12:21] <dednick_> Saviq: Component.onCompleted: height = 60
[12:21] <dednick_> Saviq: need the loader height to follow the item height
[12:21] <Saviq> dednick_, right
[12:22] <Saviq> dednick_, yeah, ListView and changing heights isn't too great indeed
[12:22] <dednick_> Saviq: ya. the height should probably expand up if the item is above :/
[12:23] <dednick_> bit of a pain
[12:33] <dednick_> Saviq: even weirder that it doesn't happen if you use boundsBehavior: Flickable.StopAtBounds
[12:33] <Saviq> dednick_, not really
[12:33] <Saviq> dednick_, well, when you overshoot
[12:34] <dednick_> Saviq: i guess when you flick over it's removing more items then readding when it comes back into view
[12:34] <Saviq> dednick_, things get recreated
[12:34] <Saviq> dednick_, yeah, that's really a bug in ListView, it should never take overshooting into account
[12:34] <Saviq> because that's just wasting CPU
[12:34] <Saviq> and some other things
[12:53] <dednick_> Saviq: i raised a bug with qt about that issue. I think i'll just turn off the flickable overshoot until that gets fixed and mark it as fixme ?
[12:54] <Saviq> dednick_, if that's the only problem, yeah
[12:54] <dednick_> Saviq: meh. it's still a bit jerky just scrolling around
[12:55] <Saviq> dednick_, well, but it's rarely going to be the case anyway, when people have dozens of messages?
[12:55] <Saviq> or transfers?
[12:55] <dednick_> Saviq: ya
[12:56] <Cimi> sometimes restarting unity8 I have this error terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<mir::AbnormalExit> >'  what():  Exiting Mir! Reason: Nested Mir and Host Mir cannot use the same socket file to accept connections!
[12:57] <Saviq> Cimi, environment got screwed
[12:57] <Saviq> Cimi, it's trying to connect to and listen on the same socket
[12:58] <Cimi> Saviq, yes indeed
[12:58] <Cimi> Saviq, I was having the same issue when the wizard had issues with the upstart job
[12:58] <Cimi> Saviq, but all I am doing is restart unity8 as phablet
[12:58] <Cimi> and not the first time happens
[12:59] <Saviq> Cimi, yeah, we need to look at our upstart job, something wonky must be happening on restart
[13:01] <Cimi> btw I replaced the flickable with both repeater and listview insode scope favorites, still performance is not comparable to cardHorizontalList
[13:01] <Cimi> I don't know what exactly is happening here, but is not right
[13:11] <Saviq> dandrader, mzanetti found a reliable way to reproduce the mouse input issue (in the dash, not in shell)
[13:12] <Saviq> dandrader, I imagine your qtmir fix fixed it for the shell, but then the apps can still get into that state can they not?
[13:12] <mzanetti> dandrader: hi. yeah, the one I told you last week. I also wrote it to the bug report now
[13:12] <Saviq> dandrader, https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1295623/comments/20
[13:12] <dandrader> Saviq, likely. racarr is also working on the mir side of the problem
[13:14] <dandrader> if I'm not mistaken, he found out that android-input, or the evedev input device, was ending touches in a weird way. At least on krillin
[13:14] <Saviq> dednick_, so... on another topic, we have bug #1365530 again
[13:14] <Saviq> dandrader, yeah, prolly related to the buttons
[13:15] <dednick_> Saviq: happy days
[13:15] <dednick_> Saviq: or is that where it doesnt update for a little bit?
[13:15] <Saviq> dednick_, no, it will be many minutes behind until the next update comes
[13:16] <Saviq> dednick_, yeah, I think another symptom is that the blue LED lights up only after you turn the screen on (I expect the LED thingy in unity8 doesn't get the icon update)
[13:16] <dednick_> meh
[13:17] <dednick_> stupid model cache
[13:31] <greyback_> mterry: hey, would you know of a nice way for me to bring up a device replacing USC with a custom mir server? Is usc hardcoded into lightdm?
[13:33] <Saviq> greyback_, there's a usc-wrapper for our session
[13:33] <Saviq> greyback_, check out dpkg -L ubuntu-touch-session
[13:34] <greyback_> Saviq: ah there it is. Thanks!
[13:35] <mterry> greyback_, you can change the command lightdm uses, hold on
[13:35] <mterry> greyback_, look at how /usr/share/lightdm/lightdm.conf.d/52-ubuntu-touch.conf does it
[13:35] <greyback_> /usr/share/ubuntu-touch-session/usc-wrapper <- that's it I guess
[13:35] <mterry> greyback_, sure you can edit that directly
[13:35] <Cimi> Saviq, are we moving towards just bugs in the package?
[13:35] <greyback_> yep that file calls the wrapper
[13:35] <mterry> greyback_, didn't know how hacky you wanted  :)
[13:36] <Saviq> Cimi, we're not moving, we're there
[13:36] <greyback_> mterry: just for my testing, nothing more. thanks :)
[13:36] <Cimi> Saviq, just seeing you removing unity8 from bugs
[13:37] <Saviq> Cimi, yeah, project bugs were turned off last week already, I just didn't know how to batch-remove the tasks
[14:38] <Cimi> so there seems to be two different issues for our weird flicking
[14:39] <Cimi> 1st there is input lag between the touch event and the activity on screen
[14:40] <Cimi> this is probably mir related
[14:40] <Cimi> 2nd qt flick detection seems to be bugged, swipes are not consistent, sometimes goes fast sometimes everything stops or moves slowly
[14:41] <Cimi> this could be both a problem in qt and/or mir not sending all touch events (or delaying them)
[14:41] <Cimi> greyback_, dandrader Saviq ^
[14:42] <Saviq> Cimi, there's a branch for the input lag
[14:42] <Saviq> Cimi,
[14:42] <Cimi> great, I can try that to see what changes for issue 2
[14:42] <Saviq> https://code.launchpad.net/~vanvugt/mir/butter/+merge/230767
[14:43] <Saviq> Cimi, it should be in a ppa I think
[14:43] <Cimi> Saviq, mir devel?
[14:43] <Saviq> Cimi, https://launchpad.net/~mir-team/+archive/ubuntu/staging
[14:44] <Saviq> it's missing qtmir though, and has unity-mir which could be dropped
[14:44] <Saviq> camako, is ↑↑ the PPA for Mir devel?
[14:45] <camako> Saviq, yes
[14:45] <Cimi> Saviq, I am pretty sure  problem 2 has still some origins inside qt as well, because while I don't have 1st in desktop under X, I have sometimes a weird flick on desktop too
[14:45] <Saviq> Cimi, not impossible
[14:46] <Cimi> Saviq, and explains the recent patches we saw regarding my qt bug
[14:46] <Saviq> camako, you can probably drop qtmir from there, but you should add qtmir/devel-mir-next there probably
[14:46] <Saviq> Cimi, the patches only dealt with the initial threshold AFAICT
[14:46] <camako> Saviq, yea we haven't fixed it after the unity-mir qtmir switch
[14:47] <Saviq> eerm I meant drop unity-mir
[14:47] <Cimi> Saviq, indeed, with small/fast swipes the visual flick seems badly calculated
[14:47] <Cimi> Saviq, if you do a long swipe, the flick appears natural
[14:48] <Cimi> Saviq, if you start swiping like crazy, and fast, the flick gets stupid
[14:48] <Saviq> Cimi, yeah, but I don't think the patches would help, they're just about about the initial threshold before a flick even happens
[14:48] <Cimi> Saviq, on android I can flick like crazy and it does not mess up the current flick
[14:49] <Cimi> Saviq, here it feels like some detections are wrong
[14:49] <Cimi> dednick_, on your indicators polishing, is it possible to keep the models always updated, and just hide the UI with loaders?
[14:49] <Cimi> dednick_, what is the reason for the delay?
[14:50] <dednick_> Cimi: yes, well that's the way we decided earlier
[14:50] <dednick_> Cimi: because they take memory
[14:51] <Cimi> dednick_, but seeing the indicator message green, opening the menu and finding it empty is even worse
[14:51] <anpok> hm i thought butter already landed?
[14:51] <Cimi> dednick_, maybe we can add some condition to the loading, loading when there is new content?
[14:52] <Cimi> dednick_, also, what take up memory, the indicators model or the UI?
[14:53] <camako> anpok, it did... in 0.7.0
[14:57] <Saviq> Cimi, ↑ ok so nothing new in Mir devel, the input delay should be better with Mir 0.7.0 already
[14:58] <Saviq> Cimi, but it's a hw issue to some extent
[14:59] <Cimi> Saviq, I know, but not that bad
[14:59] <Saviq> Cimi, you'd be surprised ;)
[15:00] <Saviq> Cimi, some time ago we installed a multi-touch painting app on manta just to check what to expect, it was really bad
[15:00] <Saviq> on android, that is
[15:01] <Cimi> Saviq, https://code.launchpad.net/~cimi/+junk/multitouchtest
[15:01] <Cimi> hah
[15:02] <greyback_> Saviq: am sure you're busy, but did you ever get change to take a peek at lp:~gerboland/unity8/dbus-async just to see if you approve of where I put the shared library?
[15:02] <Cimi> old stuff
[15:02] <Saviq> greyback_, I even replied :)
[15:02] <greyback_> Saviq: I lost the reply then
[15:03] <greyback_> mind repeating?
[15:03] <Saviq> [16:23:20] <Saviq> greyback__, looking good, not much to comment
[15:03] <greyback_> Saviq: cool, thanks
[15:03] <MacSlow> Just curious... why do upstart-log-files use CR+LF (0x0D0A) instead of just LF (0x0A)?
[15:04] <Cimi> Saviq, ouch, there is something even weirder here
[15:04] <Cimi> Saviq, go in dash app
[15:04] <Cimi> Saviq, touch right next to a label, vertically aligned
[15:05] <Cimi> Saviq, now scroll up and see how the view disconnects from the finger of around 4-6 gu
[15:06] <Saviq> MacSlow, you sure that's the case?
[15:07] <Saviq> MacSlow, adb adds \r IIUC
[15:07] <Saviq> Cimi, not sure what you mean
[15:08] <Saviq> Cimi, ah now I get it
[15:08] <Saviq> Cimi, you mean that we don't end up in the same place that we started
[15:08] <dednick_> Cimi: the UI takes the memory (mostly)
[15:08] <MacSlow> Saviq, hm... if it's adb's fault I don't mind... just odd to see ^M in all *.log when viewing the on the device...
[15:08] <Cimi> Saviq, exactly
[15:09] <Cimi> Saviq, also happens on my android
[15:09] <dednick_> Cimi: we've already decided to keep them loaded all the time
[15:09] <Cimi> Saviq, forget about it
[15:09] <Saviq> Cimi, that's probably some filtering done in hw
[15:09] <dednick_> Cimi: we're just going to limit the number of delegates loaded
[15:09] <Saviq> MacSlow, what are you viewing with? I don't see that
[15:09] <Saviq> MacSlow, which .log file, too?
[15:09] <MacSlow> Saviq, vi
[15:09] <Saviq> MacSlow, ah indeed
[15:10] <Saviq> MacSlow, you might wanna ask jodh or just file a bug with upstart
[15:10] <MacSlow> Saviq, all... but let me be sure... just checking with using ssh to  connect to the device...
[15:10] <Saviq> MacSlow, https://bugs.launchpad.net/upstart/+bug/939316
[15:11] <Saviq> MacSlow, no no, I meant output from adb shell has \r, not if you go to the console
[15:11]  * MacSlow wonders what's wrong with his ISP today (again)
[15:15] <MacSlow> Saviq, seeing "^M" reminds me of ugly format-conversion bugs from waaaay back... no deal-breaker, just a sight that brings back bad memories :)
[15:38] <MacSlow> greyback_, what debug- or logging-means can I use on the phone (at runtime) to see things like resource/surface allocation and destruction?
[15:40] <MacSlow> Saviq, regarding LP: #1366752 I can't point out a flaw in the notification-system directly... thus I'll try to dig deeper now. Also don't see any dbus-timeouts or media-hub crashes here.
[15:41] <Saviq> MacSlow, is the Loader asynchronous in NotificationList?
[15:42] <Saviq> MacSlow, NotificationMenuItemFactory should probably just have asynchronous: true is all
[15:43] <greyback_> MacSlow: currently all debug output is enabled in qtmir, so you see messages on events like surface creation & destruction in the unity8.log
[15:43] <MacSlow> Saviq, if that's not the default (if not present) then it's missing
[15:43] <Saviq> MacSlow, it is not
[15:43] <MacSlow> greyback_, ok thx
[15:44] <MacSlow> Saviq, ok... I can add that (and will test again) but then the Loader (from NotificationMenuItemFactory.qml) is not used for notifications in question (sms -> interactive notifictaions != snap-decisions)
[15:44] <MacSlow> Saviq, and the MenuItemFactory's Loader is only used for those
[15:45] <Saviq> MacSlow, well, yeah, you might need to wrap the Notification in a Loader then to make it async
[15:45] <MacSlow> Saviq, what?! :/
[15:46] <Saviq> MacSlow, delegates within ListView bounds are created sync
[15:46] <Saviq> MacSlow, as the notifications are always in bounds, they will always be created sync
[15:46] <Saviq> MacSlow, granted, I'm starting to get worried though how heavy it seems to be to create the simplest of QML components...
[15:47] <MacSlow> Saviq, I will see if wrapping the whole Notification in a Loader eliminates the slight stutter
[15:48] <MacSlow> :q!
[15:48] <MacSlow> doh!
[15:59] <dandrader> Cimi, thanks for the review
[16:00] <Cimi> dandrader, forgot to top approve
[16:00] <Cimi> oh no
[16:00] <Cimi> is there
[16:00] <dandrader> yep
[19:40] <AlbertA2> kgunn: then sudo tail -f /var/log/lightdm/unity-system-compositor.log
[19:50] <kgunn> gotta run an errand, back ~30 min
[20:44] <Saviq> om26er, you love the code or the result (of the branch)? ;)
[20:45] <om26er> Saviq, the result, its smooth ;-)
[20:45] <Saviq> om26er, yeah, it seems in the end recreating stuff is just too heavy when scrolling
[20:45] <Saviq> which we should look into in any case
[20:46] <Saviq> but decided that if you're looking at a scope, we want to commit the memory for a better experience anywa
[20:46] <Saviq> y
[20:47] <om26er> Saviq, so does it unload when we switch to a different scope ?
[20:49] <Saviq> om26er, yes, and when you go to a different app
[20:49] <Saviq> om26er, we also wait for an item to come on screen before loading images when on reduced bandwidth to save on data