[07:47] <tsdgeos> Saviq: i can't change the dash while it's rebounding :S
[07:54] <mzanetti> o/
[07:54] <greyback> \o
[07:54] <mzanetti> Saviq: any high priority issue to tackle or should I continue with fixing the preview stuff?
[08:03] <tsdgeos> can any of you guys try to repro https://bugs.launchpad.net/unity8/+bug/1238094 ?
[08:03] <tsdgeos> i don't seem to be able to sweep horizontally while it's rebounding
[08:06] <tsdgeos> oh
[08:06] <greyback> tsdgeos: I managed something
[08:06] <tsdgeos> i can if the scope doesn't fill all the screen
[08:06] <tsdgeos> interesting
[08:06] <tsdgeos> not anymor
[08:07] <tsdgeos> and now i can again
[08:09] <tsdgeos> the question is, do we always want to simply disable h-swiping while rebounding or we always want to enable it?
[08:11] <om26er> we are not caching thumbnails ? if I expand the 'more suggestions' category everytime there are blank icons and they load after a few seconds. that looks ugly
[08:12] <om26er> the same happens in the Music scope or video
[08:12] <om26er> s/or/and
[08:16] <mhr3> tsdgeos, any ideas about https://bugs.launchpad.net/unity8/+bug/1238302 ?
[08:16] <tsdgeos> hmmm
[08:16] <tsdgeos> nope, but it's interesting
[08:17]  * tsdgeos has a look while someone who can decide what we want to do with #1238094 comes up (i.e. Saviq) :D
[08:18] <tsdgeos> mhr3: how do you reproduce exactly? can't seem to unerstand the bug text :-S
[08:19] <mhr3> tsdgeos, yea.. my bug reporting skills are low at midnight :/
[08:19] <mhr3> let me try again
[08:22] <mhr3> tsdgeos, perhaps now
[08:22] <Saviq> bug #1238094
[08:23] <Saviq> tsdgeos, yeah, me neither
[08:23] <tsdgeos> mhr3: should the application category even be there?
[08:24] <mhr3> tsdgeos, well it shouldn't be overridden, but we're probably not going to fix that for 13.10
[08:24] <tsdgeos> Saviq: thing is, you can only swipe horizontally if you drag from an "empty space", i.e. if there's a category you can not drag horizontally to change the scope while it's vertically rebounding
[08:24] <Saviq> tsdgeos, ah
[08:25] <tsdgeos> Saviq: so basically i'd say "disable horizontal scrolling enterely" when we are rebounding
[08:25] <tsdgeos> saves us a lot of pain
[08:25] <Saviq> tsdgeos, huuh, btw, do you have like 6 horizontal dividers below "Apps" in home scope?
[08:25] <Saviq> tsdgeos, +1 - when it's moving - no moving to the sides
[08:25] <tsdgeos> Saviq: nope
[08:26] <tsdgeos> Saviq: but i saw that regularly before we fixed the bug in qsortproxymodel
[08:26]  * Saviq flashes
[08:26] <tsdgeos> Saviq: maybe there's still something that needs more kicking in there? or your qt is old?
[08:26] <Saviq> tsdgeos, flashed yesterday...
[08:26] <tsdgeos> ok, then it's defenitely not your qt
[08:26] <Saviq> tsdgeos, either way - I can't see any glitches when I *do* manage to swipe the dash while it's moving
[08:27] <tsdgeos> Saviq: sometimes the header gets in the middle
[08:27] <tsdgeos> it's maybe even easier if you do in applications scope
[08:27] <tsdgeos> scroll it up, then quickly left from the botto
[08:27] <tsdgeos> come back
[08:27] <tsdgeos> the header is in the middle
[08:28] <Saviq> tsdgeos, I can see it behaving weirdly while it moves - but never did get it to end up in the middle
[08:29] <tsdgeos> i can repro quite easily here
[08:29] <tsdgeos> but tbh i agree we should just disable h-swipe if it's moving vertically
[08:29] <Saviq> tsdgeos, anyway +1 on disabling ←→ while ↓↑
[08:29] <tsdgeos> since we kind of half do that already
[08:29]  * tsdgeos gets on it
[08:31] <Saviq> veebers, thanks for digging for input
[08:33] <Saviq> veebers, dashboard, fortunately, runs just one test at a time ;)
[08:43] <tvoss_> Saviq, good morning. Anything you want me to test or look into for u8?
[08:44] <Saviq> tvoss_, veebers did some digging for https://bugs.launchpad.net/mir/+bug/1238417
[08:45] <Saviq> tvoss_, and what's more - found a workaround
[08:45] <tvoss_> woot
[08:45] <Saviq> tvoss_, I filed some crashers bug #1238287 bug #1238116 bug #1238107 - some of them you saw already
[08:46] <Saviq> mzanetti, there?
[08:46] <mzanetti> Saviq: yes
[08:46] <Saviq> mzanetti, re: https://code.launchpad.net/~mzanetti/unity-mir/fix-appid-parsing/+merge/190419
[08:46] <Saviq> mzanetti, we need to make sure everything works as it did
[08:47] <Saviq> mzanetti, i.e. launching with --desktop-file-hint=/full/path
[08:47] <Saviq> erm _ _
[08:47] <mzanetti> Saviq: yes. this is exactly what it fixes
[08:47] <Saviq> mzanetti, or --desktop_file_hint=basename.desktop
[08:47] <mzanetti> oh... is that supposed to work?
[08:47] <Saviq> as well as application:///full/path.desktop and application:///appid.desktop
[08:47] <mzanetti> mhm... ok. need to check again
[08:47] <mzanetti> will do now
[08:48] <Saviq> mzanetti, we did enable it for *some* reason
[08:48] <Saviq> mzanetti, obviously won't be able to tell you what the reason was
[08:48] <Saviq> mzanetti, but while we have this, let's not break it
[08:48] <mzanetti> sure
[08:48] <Saviq> mzanetti, we also need to make sure it all works on sflinger
[08:48] <mzanetti> Saviq: this code isn't used with SF at all
[08:49] <Saviq> mzanetti, right, of course ;)
[08:49] <mzanetti> Saviq: and is only used when calling something from cmdline with --desktop_file_hint. but yeah. It probably breaks the two above
[08:49] <mzanetti> will fix
[08:51] <Saviq> mzanetti, truth is, maybe we should adapt sflinger's appmanager to store the app id and not the desktop file path, but I'm not entirely sure we want to open that pandora's box
[08:51] <mzanetti> Saviq: not sure I understand... we DO use the appId. that's exactly the issue it fixes
[08:52] <Saviq> mzanetti, aah, but we didn't in unity-mir?
[08:52] <Saviq> mzanetti, k
[08:52] <tvoss_> Saviq, asked pitti to help with https://bugs.launchpad.net/mir/+bug/1238417
[08:52] <mzanetti> Saviq: current code has an issue that it uses the full .desktop path when calling from cmdline
[08:52] <mzanetti> Saviq: but uses the appid everywhere else
[08:52] <Saviq> mzanetti, right, 'stood
[08:52] <Saviq> mzanetti, anyway, I'll stop now :)
[08:53] <mzanetti> lemme add some better description to the MR
[08:54] <tvoss_> Saviq, got a better stack trace for https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238287
[08:54] <tvoss_> ?
[08:55] <Saviq> tvoss_, I *did*, but f*cking retracing service removed it apparently
[08:55] <Saviq> tvoss_, when it decided to mark as dupe
[08:55] <tvoss_> Saviq, damn it
[08:56] <Saviq> tvoss_,  but I could easily reproduce it - let me try again
[08:56] <Saviq> yup, there it goes
[08:56] <Saviq> will be with you in 5
[08:57] <tvoss_> Saviq, thx
[08:57] <tvoss_> Saviq, see #ubuntu-mir
[08:58] <tvoss_> Saviq, https://launchpadlibrarian.net/153403487/StacktraceSource.txt indicates that maliit is trying to start, not to stop
[08:58] <tvoss_> which contradicts the bug description
[08:59] <Saviq> tvoss_, thing is this happens when unity8 is being stopped sometimes
[08:59] <Saviq> tvoss_, maliit spins the CPU
[08:59] <Saviq> tvoss_, and prevents unity8 from exiting
[08:59] <Saviq> tvoss_, but maybe the trace isn't right
[08:59] <tvoss_> Saviq, sure, but the stack trace is not the one of a spinning maliit, but the one of a restarting maliit wihtout u8
[09:00] <tvoss_> running
[09:00] <Saviq> btb
[09:00] <Saviq> brb
[09:03] <dednick> Cimi: https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/qmltest.deps/+merge/190557
[09:04] <dednick> when you get a minute :)
[09:09] <mzanetti> Saviq: hmm... just checked with the currently released code. none of those examples you made works right now
[09:10] <mzanetti> Saviq: and frankly, they seem wrong :D
[09:10] <Cimi> dednick, ok
[09:14] <tvoss_> Saviq, mzanetti so the root cause of https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238116
[09:15] <tvoss_> seems to be that an icon owns the icon engine it has been loaded from and deletes the engine in its private dtor, which in turn makes the engine delete all its associated icons ...
[09:16] <tvoss_> Saviq, mzanetti this happens after main, when destructing globals, i.e., the icon cache, which has already been cleared by a post routine
[09:16]  * mzanetti reads through the bug
[09:17] <mzanetti> mhm... I see
[09:19] <tsdgeos> Saviq: are we not using DashVideos and DashMusic anymore?
[09:19] <tsdgeos> or desktop != phone in this regar
[09:19] <tsdgeos> d
[09:21] <mzanetti> tsdgeos: afaik at least DasVideos is obsolete
[09:21] <tvoss_> mzanetti, I don't understand why QIConPrivate should delete the engine pointer
[09:21] <mzanetti> tsdgeos: and the whole Dash directory seems to desperately need a cleanup
[09:21] <tsdgeos> mzanetti: +1 :D
[09:22] <tvoss_> mzanetti, a quick fix would be: make the engine pointer a QSharedPointer in https://qt.gitorious.org/qt/qt/source/e709077eff4d8b05cc9022d85dcb48587d96c720:src/gui/image/qicon.cpp#L109
[09:22] <tvoss_> mzanetti, with that, we do not need to worry about deallocation at all, and the last icon will automatically take the engine down
[09:23] <mzanetti> tvoss_: hmm... not sure... but I don't think that's something new.
[09:23] <tsdgeos> tvoss_: because it's how it works :D
[09:23] <Saviq> tsdgeos, no, we're not using them
[09:23] <tsdgeos> tvoss_: it's a QIconEngine not a QIconsEngine, i.e. it's for this particular icon
[09:24] <tvoss_> tsdgeos, not according to https://launchpadlibrarian.net/153404403/Stacktrace.txt
[09:25] <Saviq> mzanetti, wtym "none work"? :D
[09:25] <tsdgeos> Saviq: ok, so i'll propose a merge to kill them it's pretty confusing to still them have around
[09:25] <Saviq> tsdgeos, +1
[09:25] <mzanetti> Saviq: log in your mir enabled phoen and try to launch some binary with --desktop_file_hint holding something else than an absolute file path
[09:25] <mzanetti> Saviq: won't work right now
[09:26] <tsdgeos> tvoss_: what makes you say from that backtrace that there are two icons with the same icon engine?
[09:26] <mzanetti> Saviq: and imho --desktop_file_hint=application:///appId.desktop is plain wrong. same with application:///full/path.desktop
[09:26] <Saviq> mzanetti, `webbrowser-app --desktop_file_hint=webbrowser-app` worked for me
[09:27] <Saviq> mzanetti, right, of course, /me stupid
[09:27] <Saviq> mzanetti, the application:/// things were about using them in activation
[09:27] <Saviq> mzanetti, not with desktop hints
[09:27] <Saviq> mzanetti, like from the launcher or dash home apps
[09:27] <mzanetti> Saviq: right... true. the correct appId should work
[09:27] <mzanetti> Saviq: I can reenable that one as it doesn't seem totally wrong (just a little)
[09:29] <tvoss_> tsdgeos, hang on, reading through source code
[09:29] <tsdgeos> tvoss_: i agree it could be that, but is not necesarily that
[09:30] <tvoss_> tsdgeos, looking what the engine is doing
[09:35] <tvoss_> tsdgeos, yup, circular delete. QIconLoaderEngine has multiple entries (ScalableEntry, which have a QIcon member), so we have a one-to-many-relation, which contradicts every icon exclusively owning the engine
[09:35] <tsdgeos> tvoss_: not really, it's icon has it's own engine
[09:36] <tsdgeos> tvoss_: check the code on how can you end up with different icons having the same engine
[09:36] <tsdgeos> you can't
[09:36] <tsdgeos> there's like 5 places where the engine is set, and it's always "new fooEngine"
[09:37] <mzanetti> Saviq: "fixed"
[09:39] <Saviq> mzanetti, not happy? ;)
[09:39] <tvoss_> tsdgeos, but https://qt.gitorious.org/qt/qtbase/source/6c06e14a49773ce5572935864ed6b9be219c6103:src/gui/image/qiconloader.cpp
[09:39] <Saviq> mzanetti, I'm generally of the opinion that we need to take a step back and stop parsing all that in 5 different places
[09:39] <tvoss_> tsdgeos, clearly says that the loader engine can have multiple entries ... which makes sense
[09:39] <mzanetti> Saviq: it feels still wrong to give some else than a desktop file in --desktop_file_hint :)
[09:39] <Saviq> mzanetti, *all* apps should be launched via url-dispatcher
[09:40] <Cimi> which are the id I can access from one component of the shell?
[09:40] <Cimi> I know I can access shell
[09:40] <mzanetti> Saviq: yes. I agree
[09:40] <Cimi> can I access the lock screen as well?
[09:40] <Saviq> mzanetti, as I said - I'm not even sure we need it, but we did enable it somewhere - maybe you can find the commit?
[09:40] <Cimi> with id lock screen?
[09:40] <mzanetti> Saviq: well, of course we should still support running them in the command line
[09:40] <Saviq> mzanetti, through upstart
[09:40] <Saviq> mzanetti, or url-dispatcher
[09:41] <tsdgeos> tvoss_: what line exactly?
[09:41] <tvoss_> tsdgeos, 332
[09:41] <Saviq> mzanetti, that's going to be the only way to launch apps - we need a single point where that happens - and match PIDs to app ids
[09:41] <Saviq> mzanetti, otherwise we'll end up with BAMF again
[09:42] <mzanetti> Saviq: wasn't there something new in the f.d.o spec that would solve that issue?
[09:42] <Saviq> mzanetti, yeah, launching via application:///
[09:42] <Saviq> mzanetti, or something
[09:42] <Saviq> mzanetti, either way - on Ubuntu it'll end up going through upstart
[09:43] <tvoss_> Saviq, why do we still need the desktop file hint?
[09:43] <Saviq> tvoss_, legacy
[09:43] <tsdgeos> tvoss_: sure, a QIconLoaderEngine can have multiple m_entries which are QThemeIconEntries, some of them are QIcons and those will have different QIconEngines, that is all fine still, i don't see how it will end up in circular deletion
[09:43] <Saviq> tvoss_, just a workaround until we say "now it's over"
[09:43] <tvoss_> Saviq, ack
[09:44] <mzanetti> Saviq: well, anyways, my branch now shouldn't break anything existing any more and still fix the --desktop_file_hint thingie (and with it the autopilot tests)
[09:44] <Saviq> mzanetti, \o/
[09:53] <Saviq> greyback, o/
[09:53] <tvoss_> tsdgeos, hmmm, just found a ocmment: simply reuse svg icon engine
[09:53] <tvoss_> greyback, o/
[09:54] <tsdgeos> tvoss_: where's that?
[09:54] <tvoss_> tsdgeos, https://qt.gitorious.org/qt/qtbase/source/6c06e14a49773ce5572935864ed6b9be219c6103:src/gui/image/qiconloader.cpp
[09:54] <tvoss_> line 531
[09:55] <greyback> Saviq: tvoss_ hi!
[09:55] <Saviq> greyback, see, and we don't even want anything from you!
[09:55] <Saviq> at least not straight away
[09:56] <greyback> I find that hard to believe
[09:56] <greyback> :)
[09:56] <tsdgeos> tvoss_: the comment looks scary indeed, but then the code doesn't seem like it does anything scary :D
[09:57] <tsdgeos> tvoss_: btw i'm not saying there's no bug, i'm saying i just don't see how it could happen by reading the code
[09:57] <tvoss_> tsdgeos, there has to be an engine being reused behind the scenes, otherwise, no icon would be loaded
[09:57] <tvoss_> tsdgeos, yup :) trying to convince you
[09:57] <tsdgeos> tvoss_: why do you say the engine has to be reused?
[09:57] <tvoss_> tsdgeos, and I have a suspicion that a global instance is reused somewhere
[09:58] <tsdgeos> there is a global cache of QIcons, that is true
[09:58] <tvoss_> tsdgeos for the icon to load anything it needs an engine instance: https://qt.gitorious.org/qt/qt/source/e709077eff4d8b05cc9022d85dcb48587d96c720:src/gui/image/qicon.cpp#L109
[09:58] <tsdgeos> yes, that's the global icon cache
[09:59] <tsdgeos> QCache<QString, QIcon> IconCache;
[10:00] <tsdgeos> and yes every QIcon has an engine to load stuff, but still from what i can see, every QIconPrivate has it's own engine
[10:05] <Saviq> mzanetti, can you see what you get with your fix and https://code.launchpad.net/~saviq/unity8/workaround-lp1238417/+merge/190574 on the device?
[10:06] <Saviq> mzanetti, the only remaining issues it seems would be crashes/hangs
[10:07] <mzanetti> Saviq: ack
[10:08] <Saviq> mzanetti, other than that - fix switching previews please!
[10:09] <mzanetti> Saviq: ok
[10:09] <Saviq> mzanetti, would be awesome to get them n
[10:09] <Saviq> in
[10:10] <mzanetti> Saviq: I agree it would be nice, didn't seem like top priority to me though. but if we're mostly good otherwise, I'm happy to fix them
[10:10] <MacSlow> Saviq, did you get a change to try out the sim-unlocking?
[10:10] <Saviq> MacSlow, yeah +1'd
[10:10] <Saviq> MacSlow, and it's merged, AFAIK
[10:10] <MacSlow> Saviq, :)
[10:10] <Saviq> MacSlow, notifications look awful on top of indicators though
[10:11] <Saviq> MacSlow, bug #1238174
[10:11] <MacSlow> Saviq, *shrugg*
[10:11] <Saviq> MacSlow, also bug #1238182
[10:11] <Saviq> MacSlow, but not critical of course
[10:12] <Saviq> greyback, can do https://code.launchpad.net/~mzanetti/unity-mir/fix-appid-parsing then?
[10:12] <MacSlow> Saviq, I'm in review/testing mode still... but if you want me to chase that I can
[10:12] <Saviq> greyback, didn't get to it
[10:12] <Saviq> MacSlow, no no
[10:13] <Saviq> MacSlow, just filed them so that we don't forget
[10:13] <greyback> Saviq: please do
[10:13] <MacSlow> Saviq, ok... looks certainly like something for Design to look over
[10:13] <Saviq> greyback, that was a "can you... do?" ;)
[10:13] <greyback> Saviq: oh, sure, yes I'll look after it then
[10:14] <MacSlow> Saviq, maybe it'll become less of issue once the much updated UbuntuShape lands in tookit trunk
[10:14] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/dash_disable_hswipe_on_vswipe/+merge/190576
[10:14] <tvoss_> tsdgeos, I'm not referring to the global cache, the qiconloader engine has got multiple entries carrying a QICon, too
[10:14] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/remove_unusued_dash_videos_music/+merge/190588
[10:15] <MacSlow> Saviq, with that outter shadows will be possible... probably providing some more contrast against the background... we'll see
[10:16] <tsdgeos> tvoss_: yes, but for the crash to happen, the QIconPrivate of those QIcon should have as engine the same QIconLoaderEngine that is trying to delete them, and as far as i can see i see nowhere were QIcon*Engine are reused in different QIconPrivate
[10:17] <Saviq> MacSlow, yup
[10:19] <tvoss_> tsdgeos, well, it is already weird that the global dtor is actually finding icons in the cache, as the post cleanup function should already have cleared the cache
[10:21] <tsdgeos> tvoss_: that is also true
[10:21] <tsdgeos> wonder if it's just crashing there because of bad luck
[10:21] <tvoss_> tsdgeos, it's weird that there is a cleanup function and a global static deleter wrapper thingy
[10:21] <tsdgeos> and it's just that memory is just broken already before reaching there
[10:22] <tsdgeos> tvoss_: maybe one predates the other :D
[10:22] <tsdgeos> s/maybe/probably
[10:22] <tvoss_> tsdgeos, yup
[10:22] <tsdgeos> actually it's not until qt5 that they have static deleters afaik, copied/inspired by kde having them
[10:23] <tvoss_> tsdgeos, perhaps removing the cleanup handler would already work
[10:24] <tsdgeos> work as in "fix the crash" or work as in "still do what it's supposed to do"?
[10:30] <tsdgeos> tvoss_: i guess we don't have the core file that caused that backtrace, no?
[10:30] <tvoss_> tsdgeos, that's a question for saviq
[10:30] <Saviq> tsdgeos, just start unity8 and stop unity8
[10:30] <Saviq> tsdgeos, under Mir
[10:31] <Saviq> tsdgeos, if it's not attached to the bug, that is
[10:31] <tsdgeos> Saviq: crashes all the time? some? half?
[10:31] <Saviq> tsdgeos, all
[10:31] <Saviq> tsdgeos, although sometimes differently
[10:31] <tsdgeos> ok
[10:31] <Saviq> tsdgeos, but if you just stop unity8; unity8; ^C
[10:31] <Saviq> tsdgeos, you should get it
[10:31] <tsdgeos> ok
[10:34] <tvoss_> Saviq, I thought you said https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1238287 had a better stacktrace now?
[10:35] <Saviq> tvoss_, didn't retrace it yet
[10:35] <tvoss_> Saviq, ah
[10:35] <Saviq> tvoss_, or, the retrace failed
[10:35] <Saviq> tvoss_, but easy to repro, so I'll get it
[10:35] <tvoss_> Saviq, great, thx
[10:46] <om26er> MacSlow, suggestion. When the password dialog for wifi network appears. the focus should be on the password field so that OSK automatically appears :)
[10:47] <MacSlow> om26er, true
[10:55] <Saviq> MacSlow, om26er might be kinda tricky when there's more input fields
[10:55] <Saviq> MacSlow, om26er, maybe the indicator should mark one of the fields to be focused
[10:55] <om26er> Saviq, in that case focus the first input box
[10:55] <Saviq> om26er, yeah, we don't know how many there are ;)
[10:55] <Saviq> om26er, or the order they come in
[10:55] <MacSlow> Saviq, don't be the devil's advocate... more than two text-entries?! :)
[10:56] <Saviq> MacSlow, two is enough to not know :)
[10:56] <Saviq> IMO indicator should mark one that's supposed to be focused on creation
[10:57] <tsdgeos> ah
[10:57] <tsdgeos> no ah
[10:57] <Saviq> tvoss_, uploade a retraced .crash file to bug #1238287
[10:57] <Saviq> tsdgeos, rofl
[10:57] <om26er> MacSlow, slow if the password box appears and I tap 'Cancel' the dialog should vanish. right now it asks the password again
[10:57] <om26er> *also :)
[10:58] <MacSlow> om26er, that's the triggering app not the notifications
[10:59] <MacSlow> reponsibility
[10:59] <om26er> aah
[10:59] <MacSlow> responsibility even
[11:00] <MacSlow> om26er, remember... notifications are not domain/context-aware
[11:07] <Saviq> om26er, there's a bug
[11:08] <Saviq> om26er, bug #1236386
[11:08] <om26er> Saviq, cool. I have very small testing on a secure wifi network. I just happened to be at a place where the network was password projected so faced that issue
[11:09] <Saviq> om26er, scary, as mentioned ;)
[11:09] <Saviq> om26er, you know securing networks is not about people not being able to "steal your internet" but "steal your data" instead? ;)
[11:10] <om26er> Saviq, I think no one in the neighborhood have those skills but I get your point :)
[11:11] <Saviq> om26er, "skills"? like connect to your network and access the services you left unintentionally open? ;)
[11:12] <om26er> Saviq, I don't mind they use some of the free internet ;). also this house is big even I don't get signals in some rooms..
[11:12] <om26er> i should enable password still..
[11:13] <Saviq> :D
[11:16] <Saviq> didrocks, can we get the Qt fix in today?
[11:17] <didrocks> Saviq: which qt fix? we have 4 in flight :p
[11:17] <Saviq> didrocks, ah, the looping
[11:17] <Saviq> didrocks, bug #1236765
[11:17] <didrocks> Saviq: already in proposed
[11:17] <mzanetti> Saviq: this is with our branches combined: http://paste.ubuntu.com/6221959
[11:17] <Saviq> didrocks, awesome
[11:18] <Saviq> mzanetti, how about the rest of the tests? :D
[11:18] <Saviq> mzanetti, but yeah, means it's working
[11:18] <Saviq> mzanetti, approve/merge, then?
[11:18] <mzanetti> Saviq: yeah... exactly... not sure, did tsdgeos fix the others yet?
[11:18] <mzanetti> Saviq: yep, can approve yours
[11:18] <Saviq> mzanetti, there were no other real failures
[11:18] <mzanetti> ah ok
[11:18] <Saviq> mzanetti, only crashes and stuff
[11:18] <mzanetti> right... I had one crash too
[11:19] <mzanetti> Saviq: ah I think I'm close in reproducing the edge drag crash
[11:19] <mzanetti> Saviq: can reproduce it by frequently tapping 2 edges (e.g. left + right)
[11:19] <Saviq> mzanetti, oh good, if you get a .crash at any point
[11:19] <Saviq> mzanetti, send it to me
[11:19] <tsdgeos> tvoss_: you know what's interesting? in the desktop that cache is not destructed if you kill -15 the process, just if you shut down it properly (i.e. alt+f4)
[11:19] <mzanetti> Saviq: well, I do have a quite useful crash trace.
[11:20] <mzanetti> Saviq: but reading through the code I'm not sure how we could end up in that situation
[11:20] <Saviq> mzanetti, ah
[11:20] <tsdgeos> tvoss_: my current guess is that the thing is being executed when it should not, and the svg lib is already unloaded and thus can't delete properly the QSvgIconEngine because it has no clue on how to do it
[11:20] <tsdgeos> tvoss_: but not sure if it can be possible that the svglib is already unloaded and no idea how to check if it has happened
[11:21] <tsdgeos> anyone knows enough about C++/elf app shutdown to say how/if libs are unloaded on shutdown?
[11:21] <tvoss_> tsdgeos, why kill -15? kill -9 should be enough
[11:22] <mzanetti> Saviq: this is it btw: http://paste.ubuntu.com/6133905/
[11:22] <tvoss_> tsdgeos, I would think getting rid of the cleanup should help
[11:22] <tsdgeos> of course would help
[11:22] <tsdgeos> but it's the wrong thing to do :D
[11:22] <mzanetti> Saviq: so what happens is that we get an invalid touch event in touchEvent_recognized(event *)
[11:22] <tvoss_> tsdgeos, not really, because the cache is destructed anyway in qt5
[11:22] <tsdgeos> tvoss_: wait, with cleanup you mean that
[11:22] <Saviq> mzanetti, :/
[11:22] <tvoss_> tsdgeos, post main, that is
[11:22] <tsdgeos> tvoss_: no it won't help, that code is not executed on the phone
[11:22] <mzanetti> Saviq: would be easy to fix by adding a check there. but doesn't feel like its the right place to fix it
[11:23] <tvoss_> tsdgeos, ?
[11:23] <tsdgeos> because that code only executes on "correct" shutdown
[11:23] <tsdgeos> and we're killing it
[11:23] <tsdgeos> not doing correct shutdown
[11:23] <tvoss_> tsdgeos, we are really just kill -9'ing it?
[11:24] <tsdgeos> tvoss_: not sure what "stop unity8" does, but i guess something along the lines
[11:24] <tsdgeos> i mean how do you stop it otherwise?
[11:24] <tvoss_> tsdgeos, I would assume it sends a friendly sigterm first, before it gets out the gun
[11:24] <tsdgeos> sure
[11:24] <tsdgeos> -15
[11:25] <tsdgeos> that's what i said
[11:25] <tvoss_> tsdgeos, ah, sorry
[11:25] <tsdgeos> anyhow
[11:25] <tsdgeos> when we -15 it
[11:25] <tvoss_> tsdgeos, but the cleanup handler should run with -15, too
[11:25] <tsdgeos> it doesn't execute QCoreApplication deletion
[11:25] <tsdgeos> so the postroutines are not executed
[11:26] <tsdgeos> only the static deletion ones
[11:26] <Cimi> no idea what I'm doing wrong
[11:26] <Cimi> I'm trying to connect the genericscopeview with the shell or greeter
[11:26] <Cimi> I have this connection with proper target, nothing works
[11:34] <tsdgeos> Cimi: code?
[11:35] <Saviq> oh interesting
[11:35] <Saviq> mzanetti, can you try: stop maliit-server; autopilot run unity8.shell.tests.test_lock_screen.TestLockscreen.test_can_unlock_passphrase_screen
[11:35] <Saviq> mzanetti, and do the same after starting maliit again
[11:35] <mzanetti> Saviq: sure
[11:35] <Cimi> tsdgeos, with surprise I realised the unlock signal of lock screen and greeter is not what I thought it was
[11:36] <Cimi> I don't think it's emitted when I slide the lockscreen
[11:36] <Saviq> mzanetti, for me I'm not getting keyboard input unless maliit is up
[11:38] <mzanetti> Saviq: confirmed
[11:38] <mzanetti> which seems really weird tho
[11:38] <Saviq> indeed
[11:39] <mzanetti> Saviq: I think there was some WIP to actually use maliit to inject the events. no idea how far that got
[11:40] <mzanetti> I thought we'd still use /dev/uinput
[11:40] <Saviq> mzanetti, not that it should matter anyway
[11:40] <Saviq> mzanetti, yeah we are
[11:41] <mzanetti> Saviq: must be something in the the qpa. as it obviously works on the desktop without maliit being up
[11:41] <mzanetti> Saviq: probably some if (!maliit.connected()) return
[11:45] <om26er> https://code.launchpad.net/~om26er/unity8/header_height_dash_5gu/+merge/190622
[11:48] <Saviq> thanks om26er
[11:48] <greyback> Saviq: hey, I've 2 branches attached to https://bugs.launchpad.net/unity8/+bug/1237850 - who can review?
[11:48] <Cimi> Saviq, is that assigned to me? https://bugs.launchpad.net/unity8/+bug/1226221
[11:52] <Saviq> mzanetti, you gonna merge the autopilot workaround or am I?
[11:53] <mzanetti> Saviq: this?
[11:53] <mzanetti> https://code.launchpad.net/~saviq/unity8/workaround-lp1238417/+merge/190574
[11:53] <Saviq> mzanetti, yes
[11:53] <mzanetti> already approved
[11:53] <Saviq> mzanetti, and merge?
[11:54] <Saviq> mzanetti, we don't have automerging
[11:54] <mzanetti> oh... missed that
[11:54] <mzanetti> Saviq: since when?
[11:54] <Saviq> mzanetti, oh right
[11:54] <Mirv> bregma: congrats btw, I got the best autopilot results so far that I've had today on local machine
[11:54] <Saviq> mzanetti, since Tuesday or so
[11:54] <Saviq> mzanetti, and until we get the dashboard green for unity8
[11:54] <mzanetti> mhm...
[11:55] <Saviq> mzanetti, I'll merge
[11:55]  * mzanetti doesn't really see why manual merging would make a difference, but ok
[11:56] <Saviq> mzanetti, it does
[11:56] <Saviq> mzanetti, no tests are run
[11:56] <Saviq> before merging
[11:56] <Saviq> mzanetti, so yeah - it's better that way - no failures
[11:56] <mzanetti> but... how do failing merge tests have any impact on the dashboard?
[11:57] <mzanetti> wouldn't it actually increase the risk of something failing in the dashboard?
[12:00] <Saviq> mzanetti, you tell me
[12:03] <mzanetti> oh well... sometimes it's better not to ask I guess
[12:03] <Saviq> he won't
[12:17] <mzanetti> who wants this one? https://code.launchpad.net/~mzanetti/unity8/fix-greeter-time-update/+merge/190636
[12:19] <om26er> mzanetti, I have a bug number for that. linked now.
[12:19] <om26er> there. did my part :)
[12:20] <mzanetti> om26er: ;) thanks
[12:20] <Saviq> mzanetti, hmm, I can't seem to reproduce the keyboard issue with a python console :/
[12:20] <mzanetti> Saviq: hum? what exactly do you try?
[12:21] <mzanetti> Saviq: opening a python console and injecting stuff through uinput?
[12:21] <Saviq> mzanetti, through autopilot, yeah
[12:21] <mzanetti> Saviq: yeah... you're not using the qpa plugin in that case
[12:21] <Saviq> mzanetti, hmm
[12:22] <Saviq> mzanetti, think the maliit input happened indeed?
[12:22] <bregma> sil2100, didrocks, if I couild get a moment of your tmie to look after https://code.launchpad.net/~bregma/cupstream2distro-config/branch-unity7-for-saucy/+merge/190409
[12:23] <mzanetti> Saviq: no. I think the mir-only qpa plugin has something like "if (!maliit.connected()) return;" which stops processing input even from uinput.
[12:23] <mzanetti> its still only a guess tho ^^
[12:24] <Saviq> mzanetti, k, so you think an autopilot/qpa bug
[12:24] <mzanetti> Saviq: unity-mir would be the place I'd start looking
[12:26] <Saviq> mzanetti, but then it wouldn't work from a python autopilot console
[12:26] <Saviq> mzanetti, and it does work just fine
[12:27] <mzanetti> Saviq: maybe I understood you wrong. so you stop maliit, start unity8 and then inject something into /dev/uinput with some python stuff?
[12:27] <Saviq> mzanetti, yes, and it works
[12:27] <mzanetti> ok... agreed, then my suspicion is wrong
[12:27] <Saviq> mzanetti, not directly, from autopilot.input.Keyboard, but yes - that's the net result
[12:28] <Cimi> Saviq, https://bugs.launchpad.net/unity8/+bug/1083221
[12:28] <Cimi> Saviq, there are many ways to do this
[12:28] <Saviq> Cimi, I know ;)
[12:29] <mzanetti> to me this seems quite intended behavior tbh
[12:29] <mzanetti> it indicates that if you release now, that item is triggered
[12:30] <Cimi> mmm
[12:30] <Cimi> good point
[12:30] <Saviq> Cimi, but http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-flickable.html#pressDelay-prop is probably the right way
[12:30] <Saviq> mzanetti, no, it's about when you want to flick
[12:30] <Saviq> mzanetti, and stuff blink below your finger
[12:30] <mzanetti> yeah... seems still ok to me
[12:31] <Cimi> Saviq, I can add a proxy boolean
[12:31] <Cimi> Saviq, delayedPressed
[12:31] <Cimi> Saviq, with that
[12:31] <Cimi> when pressed is true, timer...
[12:31] <Saviq> Cimi, no
[12:31] <Saviq> Cimi, just use the property from Flickable
[12:31] <Cimi> Saviq, another idea is tweaking the behaviour :)
[12:32] <Cimi> Saviq, so when you click a tile
[12:32] <Saviq> mzanetti, we don't see it much now
[12:32] <Saviq> mzanetti, but with the people lens we had a big area highlighting
[12:32] <Saviq> mzanetti, it wasn't nice
[12:32] <Cimi> http://paste.ubuntu.com/6222187/
[12:32] <Cimi> Saviq, ^
[12:32] <Cimi> on our tileStyle
[12:33] <Cimi> for pressed
[12:34] <Saviq> Cimi, ugh http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-pauseanimation.html
[12:34] <Saviq> Cimi, and no, because this way you can get it activated without visual feedback
[12:34] <Saviq> Cimi, that's not something the guys want
[12:35] <Saviq> Cimi, BUTT
[12:35] <mzanetti> lol
[12:35] <Saviq> Cimi, we should probably revisit with the designers if that's actually still an issue
[12:35] <mzanetti> as I said... seems really like the correct behavior to me right now
[12:35] <Saviq> mzanetti, yeah, with the tiles it's probably fine
[12:36] <mzanetti> it's also "correct" with the ole people lens...
[12:36] <mzanetti> the issue might be that the highlight effect was too intrusive
[12:36] <Cimi> Saviq, even now it can get activated without visual feedback
[12:36] <Cimi> Saviq, PauseAnimation is clever :P
[12:36] <Cimi> Saviq, but mines is better
[12:36] <Saviq> Cimi, probably too long for the opacity
[12:36] <Cimi> Saviq, because it gets activated only when opacity is 0
[12:37] <Cimi> Saviq, at which point you'll say I could disable the pause animation when opacity is != 0
[12:38] <Cimi> (is it possible?)
[12:38] <Cimi> might confuse with betaviours
[12:38] <Saviq> Cimi, you can't disable animations, no
[12:39] <Saviq> Cimi, anyway - I put the bug as incomplete for us - let's get a confirmation from design folk
[12:45] <Cimi> Saviq, explain https://bugs.launchpad.net/unity8/+bug/1195349
[12:45] <Saviq> Cimi, isn't it explained already?
[12:45] <Saviq> Cimi, tap on first and second item
[12:45] <Cimi> Saviq, I don't see the visual glitch
[12:45] <Saviq> Cimi, let me find a carousel
[12:46] <Cimi> Saviq, music
[12:46] <Cimi> add songs
[12:49] <Cimi> Saviq, might be possible that with the list view is gone
[12:49] <Saviq> Cimi, if you click on 3rd or 4th item
[12:49] <Saviq> Cimi, the list scrolls to the side and only then the new item goes to the front
[12:50] <sil2100> bregma: we'll take a look at that today, thanks@
[12:50] <Saviq> Cimi, if you click on 1st or 2nd
[12:50] <Saviq> Cimi, it happens in parallel
[12:50] <Saviq> Cimi, which means the two items swap where they overlap
[12:50] <Cimi> Saviq, ah ok
[13:06] <nic-doffay> Saviq, mind giving further thoughts on this? https://code.launchpad.net/~nicolas-doffay/unity8/expansion-transition-fix/+merge/189872
[13:06] <nic-doffay> Looking for more opinions from people with huge file scopes.
[13:06] <Saviq> nic-doffay, don't set duration at all
[13:07] <nic-doffay> Saviq, I'm not.
[13:07] <Saviq> nic-doffay, duration: -1 ?
[13:07] <nic-doffay> Saviq, that disables the duration...
[13:07] <Saviq> nic-doffay, that's the default value
[13:07] <nic-doffay> If not it gets set to a default duration.
[13:07] <nic-doffay> Saviq, ah.
[13:08] <Saviq> nic-doffay, http://qt-project.org/doc/qt-5.0/qtquick/qml-qtquick2-smoothedanimation.html#duration-prop
[13:08] <nic-doffay> Saviq, are you happy with the functionality?
[13:08] <Saviq> nic-doffay, yeah, that's what the bug was about
[13:09] <nic-doffay> Saviq, mind giving the MP another look, I'd like to move on to another one on the list.
[13:14] <didrocks> bregma: we don't do those branching yet. everyone needs to focus on saucy until end of next week
[13:14] <didrocks> sil2100: FYI ^
[13:14] <Saviq> nic-doffay, merged
[13:15] <kgunn> Saviq: is there someone free-ish to jump on this one ? https://bugs.launchpad.net/qtcreator-plugin-ubuntu/+bug/1238031
[13:15] <kgunn> appearantly we broke their run on device
[13:16] <kgunn> actually...will the socket moving solve this ?
[13:18] <Saviq> mzanetti, can you look ↑?
[13:19] <mzanetti> yes
[13:20] <MacSlow> kgunn, I still can't edit the spreadsheet
[13:21] <Saviq> MacSlow, I think kgunn didn't get to that email yet ;)
[13:21] <Saviq> kgunn, we have no write access to the sprint spreadsheet...
[13:21] <MacSlow> Saviq, some folks do already
[13:22] <Saviq> MacSlow, sure you're on @canonical.com account? work
[13:22] <Saviq> s here
[13:22] <MacSlow> Saviq, kgunn: working now... thx
[13:23] <MacSlow> Saviq, just got a new link
[13:36] <Tak> so is there a sane way to programmatically set an application's icon and have it look nice in the launcher/switcher/etc.?
[13:37] <mterry> MacSlow, I could do some reviews, if you want to look at bug 1238098 as a change of pace
[13:37] <Tak> if I set via XWMHints or _NET_WM_ICON, the icon in the switcher looks like it was upscaled from 32x32
[13:37] <Tak> (using a 256x256 icon to test)
[13:37] <MacSlow> mterry, ok
[13:41] <MacSlow> Ctrl-W'ed the wrong window...
[13:42] <mterry> MacSlow, heh, I hate that.  Also the closeness of Ctrl+Q
[13:42]  * Tak always ctrl-q when I mean to ctrl-w
[13:42] <mterry> MacSlow, so if you like, throw me some review branches you want to offload
[13:43] <MacSlow> mterry, I only pick/claim one at a time... to avoid anybody from taking up the ones I'm not doing...
[13:44] <MacSlow> mterry, so I'll finish mzanetti's fix-greeter-time-update and switch to the #1238098
[13:44] <mterry> MacSlow, ok, sure
[13:44]  * mterry looks at queue
[13:47] <tsdgeos> can anyone quick review https://code.launchpad.net/~aacid/unity8/fix_uninit_var_scope/+merge/190660 ?
[13:47] <tsdgeos> i can merge it myself if you guys prefer
[13:48] <tsdgeos> pstolowski: mhr3: Saviq: ↑↑↑
[13:49] <mhr3> acked
[13:50] <tsdgeos> tx, pushed
[13:50]  * Saviq fail
[13:51] <Saviq> in both code and review ↑↑ ;)
[13:51] <mzanetti> lol
[13:51] <tsdgeos> sad thing is, i can't find how to tell valgrind how to pass the sigterm to the app
[13:51] <mzanetti> Saviq and his special chars
[13:51] <tsdgeos> so not useful for the crash we have on shutdown
[13:51] <Saviq> ☺
[13:51] <tsdgeos> ei, those are my special chars
[13:51] <tsdgeos> ←↓→↑
[13:52] <mzanetti> tsdgeos: check the sprint doc
[13:52] <Saviq> tsdgeos, nah, he meant in the spreadshit
[13:52] <tsdgeos> seen then
[13:52] <tsdgeos> -n+m
[13:53] <tsdgeos> oh, actually the sigterm is supposed to be passed
[13:53] <tsdgeos> it's just valgrind general slowness
[13:53] <tsdgeos> :D
[13:55] <dandrader> Saviq, is the mir socket file also going to follow that XDG_RUNTIME_DIR path?
[13:57] <Saviq> dandrader, already is
[13:57] <Saviq> dandrader, btw, #1238451
[13:57] <Saviq> bug #1238451
[13:57] <Saviq> dandrader, is what I mentioned on the MP
[13:58] <Saviq> dandrader, we need a non-blocking input area on top of the OSK maybe?
[13:58] <Saviq> dandrader, so that you can both tap on the buttons and dismiss the keyboard easier
[14:00] <mzanetti> Mirv: ping
[14:00] <dandrader> Saviq, I don't know. it's all a big hack. So I don't think it makes sense to spend time fine-tuning a hack. we would be better of spending our time working towards getting the proper architecture in place (OSK being a non-fullscreen mir surface, etc)
[14:01] <dandrader> Saviq, so our unity-mir code is to just have things usable while we work towards our goal
[14:01] <Mirv> mzanetti: kind of pong
[14:01] <Saviq> dandrader, it needs to be able to be fullscreen
[14:01] <Saviq> dandrader, anyway, we regressed - and that's not a nice one
[14:01] <mzanetti> Mirv: where can I find the repository for this? /usr/share/qtcreator/ubuntu/scripts/qtc_device_run_app
[14:02] <Saviq> dandrader, and we won't get the correct architecture in place for yesterday
[14:02] <Saviq> dandrader, and that's when we need it fixed I'm afraid
[14:02] <Mirv> mzanetti: lp:qtcreator-plugin-ubuntu , fixes to run apps under Mir absolutely welcome :)
[14:02] <mzanetti> Mirv: yeah. I have it working here. will propose a branch
[14:04] <Mirv> mzanetti: note the trunk needs that you use ppa:ubuntu-sdk-team/ppa already (QtC 2.8)
[14:04] <Mirv> mzanetti: but when the branch gets approved + merged, it gets autobuilt to every SDK PPA user for all ubuntu versions
[14:05] <mzanetti> Mirv: the fix is so simple, I don't think I need to bother
[14:06] <Saviq> dandrader, ah, so it'd be a Qt.inputMethod issue that we don't get updates about stopped maliit, of course, sorry
[14:06] <mzanetti> Mirv: https://code.launchpad.net/~mzanetti/qtcreator-plugin-ubuntu/fix-device_run_app-for-mir/+merge/190677
[14:08]  * mzanetti wonders why we use "-platform ubuntu" for surfaceflinger instead of mir :D
[14:08] <Mirv> mzanetti: can you get someone to test/approve it, I can't at the moment?
[14:08] <mzanetti> Mirv: sure
[14:09] <pstolowski> rsalveti, ping
[14:09] <rsalveti> pstolowski: pong
[14:09] <pstolowski> rsalveti, i've been debugging another crash in mediascanner, and it looks like it's coming from gst as well; does it ring any bells? http://pastebin.ubuntu.com/6222543/
[14:11] <pstolowski> rsalveti, so, "%s: overflow allocating %u*%u bytes" coming from libgstandroidmedia I guess
[14:11] <rsalveti> pstolowski: that should be improved with next version as well
[14:11] <rsalveti> just building locally to test, and will push
[14:12] <pstolowski> rsalveti, great, thanks
[14:15] <Saviq> greyback, re: https://code.launchpad.net/~gerboland/unity-mir/add-focus-requested-signal/+merge/190620/comments/437632
[14:15] <Saviq> greyback, let's drop the other signal indeed
[14:16] <greyback> Saviq: ack
[14:26] <kgunn> greyback: ...so i was tinkering with collecting data with qml renderer timing....something i didn't expect...there's no rendering on rotates.(?)
[14:27] <greyback> kgunn: shell doesn't do anything on rotation, only the app
[14:27] <greyback> kgunn: unless you've the OSK up. Shell, might render then, as it needs to reposition the keyboard
[14:27] <kgunn> greyback: yeah....but i would have thot i would get _all_ rendering data with that flag
[14:28] <kgunn> greyback: i'll leave you be...
[14:28] <greyback> kgunn: how are you using it? "stop unity8" and "QML_RENDERER_TIMING=1 unity8" ?
[14:28] <kgunn> greyback: yes
[14:29] <greyback> kgunn: yeah, in that case only unity8 will have that var set in it's env. Upstart launches the apps, so those apps don't get that flag. upstart redirects the app output to the .cache/log/ directory also
[14:29] <greyback> s/it's/its/
[14:31] <kgunn> greyback: oh...not sorry, to be more correct, i do export the QML_RENDERER_TIMING....but then upon unity8 restart its "QT_QPA_PLATFORM=ubuntumirserver unity8"
[14:32] <kgunn> which i suppose the result is the same...only unty8 gets the flag set
[14:33] <greyback> kgunn: I believe so, yes. If you stick QML_RENDERER_TIMING in /etc/environment, upstart might use it. Then you'll need to keep eye on the log for the timing output.
[14:33] <kgunn> greyback: thanks...
[14:34] <greyback> kgunn: else you can launch the app manually with the desktop_file_hint flag
[14:36] <kgunn> greyback: thanks...that all makes alot more sense now
[14:36] <greyback> kgunn: any time
[14:41] <greyback> mterry: you comment has been addressed, thanks: https://code.launchpad.net/~gerboland/unity-mir/add-focus-requested-signal/+merge/190620
[14:41] <dednick> Saviq: fix for bug #1236249 . https://code.launchpad.net/~nick-dedekind/unity8/lp1236249/+merge/190687
[14:43] <mterry> greyback, awesome.  I probably shouldn't do actual review, but seems fine
[14:43] <Saviq> dednick, tx
[14:43] <Saviq> mterry, greyback I'm on it
[14:49] <seb128> mterry, if the lock screen in unity8?
[14:50] <mterry> seb128, yeah
[14:50] <mterry> seb128, if you mean, is the source in unity8
[14:50] <mterry> seb128, v1 doesn't use a lock screen
[14:50] <seb128> mterry, well, I was looking for debug output
[14:50] <seb128> so unity8.log it is
[14:50] <mterry> seb128, yup
[14:51] <seb128> mterry, I still have the issue that "apt-get install ubuntu-wallpapers-saucy; gdbus call --system -d org.freedesktop.Accounts -o /org/freedesktop/Accounts/User32011 -m org.freedesktop.Accounts.User.SetBackgroundFile '/usr/share/backgrounds/163_by_e4v.jpg'" gives me an empty background
[14:51] <seb128> mterry, the image is there and a jpg
[14:52] <mterry> seb128, :-/  I'll look at it later, but sounds like it's not super critical if we copy the image over via the picker
[14:52] <mterry> seb128, maybe file a bug?
[14:52] <seb128> mterry, yeah, it's a detail, I just wanted to see if I did something stupid
[14:52] <mterry> seb128, no, I guess there
[14:52] <seb128> mterry, I'm going to open a bug for next cycle, as you said, it's minor
[14:52] <mterry> is a real bug, but not sure how, we just ask qt to load the image
[14:53] <dednick> mterry: are you revieing one of my branches?
[14:53] <mterry> dednick, yeah was going to do https://code.launchpad.net/~nick-dedekind/unity8/lp1236249/+merge/190687
[14:53] <dednick> mterry: can you hold off? i want to make some changes. I think I can do something better.
[14:53] <mterry> dednick, OK
[14:54] <dednick> mterry: thanks
[14:54] <mterry> dednick, poke me when ready
[15:07] <kgunn> Saviq: is someone on unity or  mir team already looking at the thing veebers mailed about ? (second unity8 proc doesn't get inputs)
[15:07] <kgunn> https://bugs.launchpad.net/mir/+bug/1238417
[15:07] <Saviq> kgunn, we have a workaround
[15:07] <Saviq> kgunn, in unity8 trunk already
[15:07] <kgunn> Saviq: thanks alot...already in ask sheet ?
[15:08] <Saviq> kgunn, no, I disregarded the ask sheet recently
[15:08] <Saviq> kgunn, and it wouldn't matter
[15:08] <kgunn> Saviq: ;D...i'll add
[15:08] <Saviq> kgunn, 'cause except for 1, the rest of the tests were run alone
[15:08] <Saviq> kgunn, bug #1238645 could get eyes on first - as it has no workaround
[15:09] <Saviq> dandrader, will you look into increasing the "handle" for dismissing OSK?
[15:10] <dandrader> Saviq, yes, It's on my queue
[15:10] <Saviq> dandrader, ok thank you
[15:10] <dandrader> Saviq, it that more important than kbd rotation?
[15:10] <Saviq> dandrader, probably not
[15:10] <Saviq> dandrader, as you can dismiss it, only it's more difficult
[15:10] <Saviq> dandrader, I know it's frustrating to work on such temporary stuff...
[15:11] <Saviq> dandrader, it's just that time of the year...
[15:12] <dandrader> Saviq, and that extra area will have events going both to osk and app behind it, right?
[15:13] <dandrader> looks like a good case for the future gesture accept/reject scheme....
[15:14] <Saviq> dandrader, exactly
[15:16] <mzanetti> Saviq: need some of your braincells, the jumping arrow in the carousel happens because the arrow's position has an animation but also the center property moves as the carousel moves
[15:16] <mzanetti> Saviq: so it's colliding animations so to say. I still don't really know a way around that in QML. did you find something in the meantime?
[15:17] <Saviq> mzanetti, thought so
[15:17] <mzanetti> Saviq: a hacky solution would be not to animation the arrow in case of the carousel, that would cause it to immediately jump to the newly selected item and then move along with that
[15:17] <Saviq> mzanetti, maybe we should be waiting for the view to settle
[15:18] <Saviq> mzanetti, obviously it'd be best if they met in the middle ;)
[15:18] <Saviq> mzanetti, but I know how it is
[15:19] <mzanetti> dammit... this is a topic to discuss with qml experts from digia... forgot that @ the devdays
[15:20] <om26er> Saviq, re: shell does not get keyboard input if maliit not running. I think that's because autopilot uses maliit backend to type stuff on touch devices
[15:20] <mzanetti> om26er: oh... does it already. yeah, we were wondering about that earlier today
[15:20] <Saviq> om26er, does it? not uinput directly?
[15:20] <Saviq> om26er, that new?
[15:21] <om26er> Saviq, its been like that for 1 month atleast.
[15:22] <Saviq> om26er, ok, that's weird IMO
[15:22]  * Saviq starts maliit in unity8 tests
[15:23] <mterry> MacSlow, when does your extended snap decisions2 branch come into play?   Like, how do I test?
[15:23] <dednick> mterry: poke. MP is ready now.
[15:23] <mterry> dednick, ok
[15:24] <MacSlow> mterry, since - according to Saviq - there's no "user" of it (and it's regarded a feature rather than a bugfix) it won't land soon... which is a pity since it was quite a battle to get it where it is now :)
[15:24] <mterry> dednick, why drop the "m_menu->disconnect(this)" bit?
[15:25] <mterry> (in your most recent change, in the destructor)
[15:25] <om26er> mzanetti, here: https://code.launchpad.net/~veebers/autopilot/add_OSK_keyboard_backend/+merge/181456
[15:25] <mterry> MacSlow, ah ok.  Marked WIP then
[15:25] <dednick> mterry: it's automatically done when the object is destroyed.
[15:25] <Saviq> MacSlow, dednick unless you tell me network indicator can do it now (and apps can request network, for that matter)
[15:25] <Saviq> mterry, ↑ rather
[15:25] <mterry> dednick, that's part of Qt machinery?  OK
[15:26] <dednick> Saviq: how far up?
[15:26] <Saviq> dednick, not at all
[15:26] <mzanetti> om26er: cool stuff
[15:26] <Saviq> dednick, was about wifi selection snap decision
[15:26] <MacSlow> mterry, so landing is still some weeks away I fear... but if you want to give it a spin out of curiosity... grab lp:~macslow/unity-notifications/extended-snap-decisions-part2 and lp:~macslow/unity8/extended-snap-decisions-part2
[15:26] <MacSlow> mterry, compile/install unity-notifications/extended-snap-decisions-part2 on the device directly...
[15:26] <Saviq> mzanetti, so you were right ;)
[15:27] <dednick> Saviq: no, i dont think there's anything that will trigger it atm.
[15:27] <mzanetti> Saviq: maybe that was even the reason why we had all those typing failures some weeks back
[15:28] <MacSlow> mterry, unity8/extended-snap-decisions-part2 would get the usual run_on_device treatment... and then trigger examples/sd-example-wifi-selection.py from the unity-notifications branch
[15:29] <MacSlow> mterry, it's not really WIP as it works/is done
[15:29] <mterry> MacSlow, yeah but it's not landable, so it's not "ready for review" either
[15:30] <mterry> MacSlow, I thought it was typical practice to use WIP to get branches off the active review board
[15:30] <MacSlow> mterry, I always took wip for what it really stands for :)
[15:31] <MacSlow> mterry, this is just cheating to get the review-board look cleaner ;)
[15:31] <mterry> MacSlow, well, maybe that's a distro thing
[15:31] <MacSlow> mterry, but j/k :)
[15:31] <mterry> MacSlow, review-board should be clean!  :)
[15:34] <kgunn> greyback: i was gonna queue up unity-mir...you gonna have any mp merge today ? if so i'll wait a bit
[15:36] <greyback> kgunn: yep have https://code.launchpad.net/~gerboland/unity-mir/add-focus-requested-signal/+merge/190620
[15:37] <greyback> kgunn: please wait until that lands
[15:37] <dandrader> Saviq, https://code.launchpad.net/~dandrader/ubuntu-keyboard/improve_kbd_info_ipc/+merge/190418 and https://code.launchpad.net/~dandrader/unity-mir/improve_osk_ipc/+merge/190417 have been updated
[15:38] <kgunn> greyback: np
[15:40] <Saviq> dandrader, thanks
[15:46] <Saviq> greyback, 122	+ print("focus request:", appId) ?
[15:46] <greyback> Saviq: doh
[15:46] <Saviq> ah test
[15:46] <Saviq> greyback, that's in a test
[15:46] <Saviq> greyback, /me d'oh
[15:46] <greyback> Saviq: undoh
[15:49] <mterry> dednick, I commented on some style issues, but the branch seems to work fine
[15:50] <dednick> mterry: cool. will check it out
[15:52] <Saviq> kgunn, fix for bug #1237850 is in trunks
[15:53] <kgunn> ta
[15:56] <Saviq> fginther, is merger for ubuntu-keyboard enabled?
[15:58] <fginther> Saviq, yes, there is a job running
[15:58] <Saviq> fginther, right, it started just after I asked ;)
[15:58] <Saviq> fginther, thanks
[15:59]  * tsdgeos declares win over the QIcon crash
[15:59] <Saviq> fginther, ah no, I was just looking at the public jenkins <facepalm>
[15:59] <tsdgeos> \o/
[15:59] <Saviq> tsdgeos, awesome!
[15:59] <Saviq> tsdgeos, EOD? ;D
[15:59]  * tsdgeos pushes some branches
[15:59] <Saviq> tsdgeos, you got 10s
[15:59] <tsdgeos> :D
[15:59] <Saviq> now
[16:00] <tsdgeos> and you know what, the qicon was totally a red herring
[16:00] <tsdgeos> damn **** :D
[16:00] <Saviq> :D
[16:00] <Saviq> kgunn, you should merge the two asks for keyboard and unity-mir/unity8
[16:00] <Saviq> kgunn, unity-mir has all in trunk already, so they should land in concert
[16:01] <kgunn> Saviq: i was actually doing that
[16:01] <Saviq> !
[16:01] <kgunn> i'll add a note to be clear tho
[16:07] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity-mir/waitforme/+merge/190716
[16:07] <tsdgeos> Saviq: https://code.launchpad.net/~aacid/unity8/phone_crash_cleanup/+merge/190717
[16:07] <tsdgeos> Saviq: with those two it does not crash anymore on exit
[16:07] <tsdgeos> Saviq: though once it was stuck in a phtread_join inside mir's code
[16:08] <tsdgeos> i'm calling that one NOTOURBUG
[16:08] <Saviq> tsdgeos, cool
[16:08] <tsdgeos> of course still can have a look on monday
[16:08] <tsdgeos> but it was much less frequent
[16:09] <tsdgeos> greyback: https://code.launchpad.net/~aacid/unity-mir/waitforme/+merge/190716 for you if you have time
[16:09] <greyback> tsdgeos: on it
[16:09] <kgunn> hey mzanetti would this https://code.launchpad.net/~mzanetti/unity-mir/fix-appid-parsing/+merge/190419 fix this bug 1238832
[16:10] <mzanetti> kgunn: very likely
[16:10] <mzanetti> kgunn: the description doesn't give enough details to be 100% sure tho
[16:11] <tsdgeos> Saviq: btw now that 5.2 alpha is out someone should have a look at how much if at all we make the new V4 engine crash and report it with enough time so [hopefully] they fix it :D
[16:11] <Saviq> tsdgeos, lol yeah :)
[16:14]  * tsdgeos takes a shower, leaving this open in case you find something wrong with my code once i finish
[16:17] <kgunn> bbiab
[16:19]  * mterry is worried latest unity-mir/unity8 requestFocus changes messed up receiving calls in greeter again.  will test
[16:25] <greyback> mterry: oh feck, I forgot greeter uses unity-mir now. I will add testing greeter workflow from now on
[16:26] <mterry> greyback, well, this is an odd case
[16:28] <sil2100> jamesh: hi!
[16:29] <sil2100> jamesh: are you still around?
[16:30] <nic-doffay> pete-woods, ping
[16:31] <sil2100> jamesh: we have a ftbfs of mediascanner on powerpc due to a unit test failing
[16:31] <sil2100> jamesh: https://launchpadlibrarian.net/153485520/buildlog_ubuntu-saucy-powerpc.mediascanner_0.3.93%2B13.10.20131011-0ubuntu1_FAILEDTOBUILD.txt.gz
[16:32] <mzanetti> Saviq: fixed most of the switching-preview issues. replied to the others
[16:36] <Saviq> mzanetti, cool!
[16:36] <Saviq> mzanetti, lp says conflict?
[16:37] <pete-woods> nic-doffay: hi
[16:46] <Saviq> mzanetti, re: pointer - tried SmoothedAnimation?
[16:47] <Saviq> bzr revert
[16:47] <nic-doffay> pete-woods, got time for a small infographics related review?
[16:47] <pete-woods> nic-doffay: sure
[16:47] <nic-doffay> pete-woods, cheers : https://code.launchpad.net/~nicolas-doffay/unity8/infographics-font-fix/+merge/190725
[16:47] <nic-doffay> hella small
[16:48] <nic-doffay> :P
[16:50] <mzanetti> Saviq: d'oh... will merge
[16:51] <pete-woods> nic-doffay: done!
[16:52] <pete-woods> nic-doffay: have you checked that this works on the tablet, btw? I guess it's not important right now, but I bet you need to come back and fix the font size for that
[16:55] <tsdgeos> greyback: last chance, want to discuss something or next week?
[16:56] <nic-doffay> pete-woods, I don't have a tablet sadly :/
[16:57] <greyback> tsdgeos: next week
[16:57] <tsdgeos> okidoki
[16:57]  * tsdgeos waves
[17:03] <mzanetti> Saviq: ouch... conflict is a bad one
[17:03] <Saviq> mzanetti, next week, then
[17:11] <sergiusens> Saviq, now that I think of it, the workaroudn won't work as the maliit-server is started on started unity8
[17:11] <sergiusens> Saviq, so you'll need to cli launch it
[17:12] <mzanetti> Saviq: managed to catch a unity8 freeze on the desktop. this is the stacktrace when attaching: http://paste.ubuntu.com/6223360/
[17:12] <mzanetti> Saviq: any ideas how to get more information?
[17:12] <mzanetti> or better: if there's something useful I should try to collect
[17:13] <dednick> mzanetti: looks like Shell qmltests arent working in trunk
[17:13] <sergiusens> Saviq, ignore that; should work
[17:13] <mzanetti> dednick: ok. will fix
[17:14] <Saviq> mzanetti, it might be Albert's fix for the loop in incubation
[17:14] <Saviq> mzanetti, qt fix not released yet
[17:14] <Saviq> sergiusens, yeah it does sork
[17:14] <Saviq> *work
[17:14] <dednick> mzanetti: i think Unity.Indicators mock is missing the CachedUnityMenuModel
[17:15] <sergiusens> Saviq, my phone is overheating and not unlocking the greeter during tests though; got me confused on the wrong path :-/
[17:16] <sergiusens> Saviq, I found out why _usr_bin_unity-scope-loader.32011.crash _usr_bin_unity8.32011.crash
[17:16] <sergiusens> Saviq, let me flash again
[17:20] <mzanetti> dednick: they seem to work here even after removing the datetime indicator
[17:20] <dednick> mzanetti: make testShell works?
[17:21] <mzanetti> oh... I only tried make testClock as that's the one I changed
[17:21] <dednick> mzanetti: Added the Unity.Indicator module to the imports. the mocks in the shell tests override the plugins
[17:22] <dednick> mzanetti: i can sort it out if you want. I'm fixing up other breakages realated to it in another branch.
[17:23] <mzanetti> dednick: ok, thanks a lot
[18:15] <kgunn> Saviq: so do you agree or disagree that the shell has any responsibility wrt saving user settings ?
[18:15] <kgunn> couldn't see a resolution to the exchange you had in #ubuntu-desktop
[18:24] <sergiusens> Saviq, ok, added a comment
[18:35] <kgunn> mterry: just curious...any news on the bottom bar reveal issue during qa lab tests ?
[18:36] <mterry> kgunn, they seemed to go away
[18:36] <kgunn> ...seems rumor yesterday might be an update was needed?
[18:36] <mterry> kgunn, we could never reproduce them out of lab and even lab isn't seeing them
[18:36] <kgunn> mterry: ah...my favorite...
[18:36] <mterry> anymore
[18:36] <mterry> kgunn, yeah...  so there may indeed be a problem, but it's hard to track
[18:36] <kgunn> mterry: well there's been a heap of good stuff land...
[18:38] <om26er> Cimi, if you have not already fixed bug 1238837 I have a branch for that else please ignore.
[18:39] <robotfuel> kgunn: mterry: I found my devices had an old version of libgl, which a distupgrade fixed. I wonder if that was the upgrade rumor.  There was also a restarting unity8 with -testablility timing issue where the tests started before it was ready for action.
[18:40] <om26er> https://code.launchpad.net/~om26er/unity8/fix_1238837/+merge/190743
[18:40] <kgunn> robotfuel: mmm, could be...we should keep an eye out...but yeah, lots of good stuff happened recently
[18:52] <sergiusens> Saviq, https://code.launchpad.net/~saviq/unity8/workaround-lp1238645/+merge/190724
[19:26] <Saviq> sergiusens, right, thanks
[19:34] <Saviq> fginther, hey, a question for the end of the day
[19:34] <fginther> Saviq, so I can wait to answer it :-)
[19:35] <Saviq> fginther, do you think we could inherit daily releases' approach to builders
[19:35] <Saviq> fginther, so that we'd have a per-stack PPA instead of the mbs repo
[19:35] <Saviq> fginther, would reduce the load on jenkins'n'friends, improve the transparency slightly - and provide a "staging" PPA for all the stacks
[19:37] <fginther> Saviq, that's something to consider
[19:37] <Saviq> fginther, to me that's one of the things that felt "right" in daily release :)
[19:37] <Saviq> fginther, would reduce the burden of maintaining pbuilder-jenkins and the complication of the jobs
[19:38] <fginther> Saviq, are you suggesting just to replace the mbs repo with a ppa or something more?
[19:38] <Saviq> fginther, I would think that anything that builds packages in -ci or -autolanding jobs
[19:38] <Saviq> or well
[19:38] <Saviq> at least -autolanding
[19:39] <Saviq> -ci would have to be per-project PPA, so probably too much - or would it...
[19:39] <Saviq> fginther, [...] could be replaced by PPAs
[19:39] <Saviq> fginther, something to talk over in OAK?
[19:39] <Saviq> fginther, you coming?
[19:40] <fginther> Saviq, right, I agree that some things are replaceable by a ppa, the mbs functionality is combersome
[19:40] <Saviq> fginther, I think the mbs would be just a perfect example for a PPA - per-stack
[19:40] <fginther> Saviq, there is a upstream-merger 2.0 vision that involves moving everything to prodstack and ideally using a 'buildd'-stack as well
[19:40] <Saviq> fginther, sure - that'd be nice
[19:41] <Saviq> fginther, especially for -ci where we don't want the results to really be persistent between runs
[19:41] <fginther> Saviq, I haven't been invited to OAK
[19:41] <Saviq> fginther, we need a temporary build
[19:41] <Saviq> fginther, bummer
[19:41] <Saviq> fginther, UDS session then
[19:41]  * Saviq notes
[19:41] <fginther> Saviq, yes
[19:42] <fginther> Saviq, I'll try to keep you in the loop with things, you have a pretty good idea of what a consumer needs
[19:42] <Saviq> :)
[19:43] <Saviq> not sure which track... client? foundations?
[19:43] <Saviq> community?
[19:43]  * Saviq puts as client to start with, wonder whether we need a QA track...
[19:46] <Saviq> fginther, https://blueprints.launchpad.net/ubuntu/+spec/client-1311-upstream-merger-20
[19:46] <fginther> client sounds good for now
[19:47] <fginther> Saviq, thanks
[19:48] <Saviq> kgunn, one thing just occured to me
[19:48] <Saviq> kgunn, UDS is 11/19-21
[19:49] <Saviq> ↑ see, I can do US dates (for dates > 12...)
[19:49] <Saviq> kgunn, so we probably try and avoid that for the possible sprint dates
[19:49] <kgunn> Saviq: mmm, thanks....yeah....1st week of dec looking best anyway
[19:49] <Saviq> kgunn, yeah exactly
[19:51] <Saviq> fginther, added some topics to the whiteboard
[19:53] <Saviq> kgunn, saw you've been registering blueprints - some of them could use a UDS session maybe?
[19:54] <kgunn> Saviq: yep...going to be a few more...we can decide in a bit which we want to have for session
[19:54] <Saviq> kgunn, yeah, OAK?
[19:54] <Saviq> jeez that's in two weeks already...
[19:54] <kgunn> i know....feeling really behind
[19:55] <kgunn> xmir, then phone v1....i'm kinda tired
[19:55] <kgunn> can't imagine how you guys feel
[19:55] <Saviq> kgunn, hint:                                     ↑↑↑
[19:55] <Saviq> oops
[19:55] <Saviq>                             ↑↑↑
[19:55] <Saviq>                                     ↑↑↑
[19:55] <Saviq> almost :D
[19:56] <Saviq> ok, xchat gone craazy
[19:56] <kgunn> Saviq:  go have a weekend already
[19:56] <Saviq> kgunn, trying, but the wife fell asleep - boring ;d
[19:56]  * Saviq needs a beer
[19:56] <kgunn> :))
[19:57] <mhall119> Saviq: previous vUDS we just spanned QA across all the tracks were appropriate
[19:57] <Saviq> mhall119, yeah... put it in client, although could be community
[20:00] <Saviq> kgunn, ah btw... I'm *not* going on holiday next week - managed to get confused enough with msm that was not cancelled ;)
[20:00] <Saviq> or maybe managed to confuse msm enough...
[20:00] <kgunn> ok