[07:47] <tsdgeos> haleluya a merge \o/
[07:52] <tsdgeos> Saviq: so which channel do i use for an utopic image? devel-proposed? ubuntu-touch/devel-proposed ?
[07:52] <Saviq> tsdgeos, they're the same
[07:52] <Saviq> tsdgeos, but the latter is more future-proof
[07:52] <tsdgeos> ok, i remember someone mentioning a difference
[07:52] <tsdgeos> maybe it was about something else
[08:03] <tsdgeos> Saviq: got https://code.launchpad.net/~aacid/unity8/killqt51/+merge/217391 remerged
[08:03] <tsdgeos> should hopefully not conflict anymore...
[08:03] <Saviq> tsdgeos, devel vs. devel-proposed is different
[08:03] <tsdgeos> ah sure
[08:03] <Saviq> tsdgeos, devel-proposed == utopic-proposed now
[08:03] <tsdgeos> maybe that was the message about and i misread
[08:03] <Saviq> it was == trusty-proposed before
[08:04] <tsdgeos> okidoki
[08:04] <Saviq> tsdgeos, looks good, no conflict merging on trunk
[08:26] <Saviq> MacSlow, I went through your doc, put some comments down
[08:27] <Saviq> MacSlow, were you tasked with actually writing that backend?
[08:27] <MacSlow> Saviq, thx... will look through them in a few minutes
[08:27] <Saviq> this would get us on the path of maintaining more, instead of less, of that whole system...
[08:28] <MacSlow> Saviq, indirectly
[08:29] <MacSlow> Saviq, I don't know what else to do to try to fight notifications being abused as dialogs
[08:30] <MacSlow> Saviq, it's causing problems
[08:30] <Saviq> MacSlow, that fight needs to happen on design level first
[08:30] <Saviq> MacSlow, but anyway, I've commented on the doc, this is the time when the api team should take it over, not later
[08:30] <Saviq> IMO
[08:31] <MacSlow> Saviq, sure... I just needed to start something to get the ball rolling
[08:33] <Saviq> MacSlow, kk
[09:07] <Cimi> tsdgeos, Saviq you know how much data a qt multimedia player uses?
[09:07] <Cimi> I am trying to look into the source but maybe you know
[09:07] <Saviq> Cimi, the source won't help you, I really doubt it's static
[09:07] <Cimi> Saviq, thought might be a percentage
[09:07] <Cimi> of the file
[09:07] <Cimi> or so
[09:08] <Saviq> Cimi, it's the playback engine that buffers, Qt is only the messenger
[09:08] <Saviq> Cimi, in our case, it's stagefright
[09:08] <Cimi> or right
[09:08] <Cimi> so what do I do?
[09:08] <Cimi> youtube-alike?
[09:09] <Cimi> a small progressbar ahead the playback?
[09:09] <Saviq> Cimi, I asked jhodapp yesterday, but missed him
[09:09] <Saviq> Cimi, there's http://qt-project.org/doc/qt-5/qmediaplayercontrol.html#availablePlaybackRanges, but it's not exposed to QML
[09:09] <Saviq> and I'm not even sure it's supported in our implementation...
[09:11] <Saviq> Cimi, TBH I'm not sure what bufferProgress is useful for, it's effectively a random 0..1 number that doesn't mean anything...
[09:11] <Saviq> Cimi, I'd say that warrants a QTBUG
[09:13] <tsdgeos> damn qml is hard sometimes for no reason
[09:13] <Cimi> Saviq, it is not random
[09:14] <Cimi> Saviq, can be used for a label imho
[09:14] <Cimi> "Buffering 0..15...100%"
[09:14] <tsdgeos> so my CardCreatorCache is a singleton which means i have to register it wiht qmlRegisterSingletonType which i can do in main.cpp but where do i do it for tests?
[09:14] <tsdgeos> or we need to make Dash stuff a plugin :S
[09:15] <tsdgeos> Saviq: ideas? ↑
[09:16] <Saviq> Cimi, but what does 100% mean in that case - it is random, if you don't know what 100% is
[09:16] <Saviq> tsdgeos, make it a plugin, why not?
[09:16] <Cimi> Saviq, yeah just means the player completed buffering
[09:16] <Saviq> tsdgeos, we already have DashViews plugin, maybe we need to recommission it?
[09:16] <Cimi> Saviq, but is useless
[09:16] <Saviq> Cimi, exactly
[09:16] <tsdgeos> Saviq: ok, let me see if i can add it there
[09:17] <Cimi> Saviq, I did try it with my slow 3G sim card on purpose
[09:17] <Cimi> Saviq, and it reaches 100% super quickly anyway
[09:19] <Saviq> Cimi, yeah, uselesss
[09:27] <Cimi> Saviq, https://bugreports.qt-project.org/browse/QTBUG-38688
[09:29] <tsdgeos> did i break all the tryXYZ?¿
[09:29] <Cimi> tsdgeos, where?
[09:30] <tsdgeos> unity8
[09:31] <tsdgeos> ok, no it works
[09:31] <Cimi> Saviq, make progress widget half-wide
[09:32] <Cimi> Saviq, designs?
[09:40] <Saviq> Cimi, https://docs.google.com/a/canonical.com/file/d/0B-a_7E3tDxOgVzlJZEdtNEJ3NDQ/edit
[09:40] <mhr3> ah, you were faster
[09:42] <Cimi> Saviq, where can I download spotify for ubuntu touch? :P
[09:42] <Saviq> Cimi, from the cloud ;)
[09:43] <Cimi> Saviq, ah in my dreams :D
[09:43] <Saviq> Cimi, exactly! :)
[09:53] <tsdgeos> Saviq: i'll rename the plugin from DashViews to Dash, ok?
[09:53] <tsdgeos> since i moved the card creator singleton there
[09:53] <tsdgeos> or you prefer to keep the DashViews name?
[09:58] <Saviq> tsdgeos, rename away
[10:10] <MacSlow> Saviq, I did a quick test and added sound- and haptics-support to notifications (on the frontend) just to see how straight forward it is. Turns out to be pretty easy. If we can agree on a way to pass a haptics-effect-description via a hint, implementing support for sound and feedback won't be that much work. The sound-hint-value is obvious (string representing a filename).
[10:12] <MacSlow> Saviq, although I'd rather see modal snap-decisions landing first, before starting something new :)
[10:24] <Cimi> Saviq, basically it has to have same dimensions of the button?
[10:25] <Cimi> but it is still higher than the button
[10:25] <Cimi> taller
[10:25] <Cimi> it will look weird
[10:26] <Saviq> MacSlow|lunch, yeah, I'll tackle modals after SDK lands its unity8 tweak
[10:30] <MacSlow|lunch> Saviq, ok
[10:30] <dednick> bah, silly utopic upgrade hosed ns lookup!
[10:31] <Saviq> MacSlow|lunch, eat your lunch!
[10:54] <Saviq> Cimi, same size as button
[10:54] <Cimi> Saviq, done
[10:56] <Cimi> Saviq, https://code.launchpad.net/~cimi/unity8/half-progress/+merge/217742
[10:58] <Saviq> tsdgeos, "use back chevron everywhere" task for dash... it's rather done, isn't it?
[10:59] <Cimi> I'd center the chevron
[10:59] <Cimi> the back chevron
[10:59] <Cimi> there is lots of padding on the left
[10:59] <Cimi> looks weird
[10:59] <Cimi> also, it behaves like a button but has no int of being a button
[11:00] <Cimi> it should have a frame around it or something clear to distinguish is clickable
[11:00] <Cimi> what you guys think?
[11:01] <Saviq> Cimi, it'll all be a header thing, it will come from SDK
[11:01] <Cimi> ok
[11:01] <Saviq> pete-woods, can you comment on "make infographic configurable" task in https://blueprints.launchpad.net/ubuntu/+spec/client-1410-unity-ui-infographics ?
[11:01] <Saviq> pete-woods, is it different than the settings-app task below?
[11:02] <tsdgeos> Saviq: yeah i saw that yesterday too
[11:02] <pete-woods> Saviq: well at the moment, it just shows all the infographics you have installed
[11:03] <tsdgeos> Saviq: i guess yes
[11:03] <Saviq> tsdgeos, ok, marking DONE
[11:03] <tsdgeos> Saviq: i think we don't support ultra embedded stuff though
[11:03] <Saviq> tsdgeos, huh?
[11:03] <tsdgeos> like a scope embedding a scope embedding a scope
[11:03] <pete-woods> Saviq: in the old infographic, the "settings" were basically just "do you want infographics at all or not"
[11:04] <pete-woods> and that was handled in the shell
[11:04] <Saviq> pete-woods, yeah, there's two tasks though:
[11:04] <Saviq> [pete-woods] make currently shown infographic configurable: INPROGRESS
[11:04] <Saviq> [seb128] add infographic to settings app (similar to background image), only show settings if not explicitly prevented (by OEM): TODO
[11:04] <tsdgeos> Saviq: and a preview embedding a preview
[11:04] <tsdgeos> but should not be hard to fix
[11:04] <tsdgeos> once somebody needs it
[11:04] <tsdgeos> so yeah mark it as DONE
[11:04] <Saviq> tsdgeos, and a different task anyway
[11:05] <pete-woods> Saviq: I guess what I'm saying is that I made it so you can pick your infographic from a list of installed ones, it just uses them all
[11:05] <Saviq> pete-woods, sure, we just want the task clarified (see kgunn's question in whiteboard), as we're not sure what that task entails?
[11:06] <pete-woods> if we need to make it "configurable" (obvs I'd like to know exactly what that means), then I'll do that
[11:06] <pete-woods> Saviq: I have no idea what it means
[11:06] <pete-woods> I didn't add that task (unless my brain is totally fried)
[11:08] <Saviq> :D
[11:08] <Saviq> pete-woods, guess what, I added it ;)
[11:09] <pete-woods> :)
[11:10] <Saviq> pete-woods, I think I copied it from the old blueprint
[11:10] <pete-woods> hmm
[11:10] <pete-woods> that would make sense
[11:10] <Saviq> hah!
[11:10] <pete-woods> I still don't know what it means, though
[11:10] <Saviq> thostr_, added it initially :D
[11:10] <pete-woods> it probably came from a whiteboarding session
[11:11] <Saviq> thostr_, "make currently shown infographic configurable: TODO", what does that mean? :)
[11:11] <thostr_> Saviq: assume you have 10 infographics installed
[11:11] <thostr_> which one to display?
[11:12] <thostr_> I think it can be as easy of just remember the last one that was shown
[11:12] <thostr_> as the user can anyway swipe through all infographics on the greeter
[11:12] <thostr_> at least that was the plan AFAICT
[11:13] <pete-woods> thostr_: there's a slight complication, in that some infographics can produce more than one SVG
[11:14] <Saviq> thostr_, so you mean to remember the last displayed one?
[11:14] <Saviq> thostr_, because there's also:
[11:14] <Saviq> [seb128] add infographic to settings app (similar to background image), only show settings if not explicitly prevented (by OEM): TODO
[11:14] <pete-woods> e.g. infographics that iterate through all the data of a particular "type", like the timeseries data from the usermetricsinput libraru
[11:14] <Saviq> thostr_, could you reply in the bp whiteboard please https://blueprints.launchpad.net/ubuntu/+spec/client-1410-unity-ui-infographics ?
[11:25] <thostr_> Saviq: done.
[11:26] <thostr_> pete-woods: from practical POV wouldn't it be ok to ignore the fact that one infographic has "subgraphics"?
[11:26] <pete-woods> thostr_: sure, we could just remember the producer of the particular SVG we were looking at, and remember that
[11:26] <thostr_> pete-woods: in the end, the purpose and user interaction is the same: browsing through different graphics
[11:27] <Saviq> thostr_, thanks
[11:27] <thostr_> pete-woods: yes, we'd remember producer + index
[11:27] <pete-woods> thostr_: from my perspective, I just want to know what behaviour is wanted (and for that behaviour to be fairly simple)
[11:27] <Saviq> pete-woods, why couldn't we remember the actual "subgraphic"?
[11:27] <pete-woods> Saviq: sure, we could do that, too
[11:27] <thostr_> pete-woods: then let's do that
[11:28] <pete-woods> thostr_: so are we looking for a settings panel for this? or just remembering the last viewed infographic?
[11:29] <pete-woods> the panel would seem redundant to me, but obviously it's not my choice
[11:29] <thostr_> pete-woods: I'd just remember the last one
[11:29] <pete-woods> as long as that's my official requirement, then I'm happy
[11:29] <pete-woods> i.e. let's make sure the blueprint says that's what I have to do
[11:30] <thostr_> pete-woods: alternative would be: from all the installed infographics, the setting would define which ones to make available to greeter. one the greeter itself we'd remember the last one.
[11:30] <pete-woods> sure, I don't really care *too* much, I just want to know what I have to implement
[11:31] <thostr_> pete-woods: I'll drop a mail to design
[11:42] <greyback> Is it known issue that flicking vertically in the dash is weird. The velocity on finger release doesn't look right
[11:43] <greyback> tsdgeos: ^^
[11:43] <Saviq> pete-woods, that'd be our task then
[11:43] <tsdgeos> greyback: nothing specifically on finger release, no
[11:43] <Saviq> pete-woods, I don't think we need to remember it across reboots? thostr_?
[11:44] <pete-woods> Saviq: sure, just need to know exactly what to do
[11:44] <pete-woods> Saviq: thostr_ has sent an email to John about it
[11:44] <pete-woods> we could easily store this in a GSetting
[11:44] <pete-woods> it doesn't have to be visible in the settings app
[11:44] <Saviq> pete-woods, indeed
[11:45] <Saviq> pete-woods, only potential issue would be that if we'd store index, it could be a different one, otherwise if we store a name, we'd need to look for it in the model every time...
[11:45] <Saviq> pete-woods, but yeah, we'll manage somehow
[11:45] <greyback> tsdgeos: I should have said /after/ finger release. Sometimes it appear to accelerate a little after finger release, before it starts to decelerate
[11:46] <pete-woods> Saviq: the model internally is stored as infographic-name/hash
[11:46] <greyback> tsdgeos: might just be me
[11:46] <pete-woods> where the hash is computed consistently from the data source name
[11:46] <Saviq> pete-woods, mhm
[11:47] <pete-woods> so a simple index would remain valid only as long as you didn't add more sources
[11:47] <pete-woods> but yeah, we could figure something out, I'm sure
[11:48] <pete-woods> the only real question, as far as I'm concerned, is if we want the settings app to allow the user to enable / disable different infographics
[11:48] <pete-woods> or if we should just say you have to uninstall them
[11:51] <pete-woods> Saviq: thinking about it, we could just store the hash prefix of the filename, that would never change as long as that data source was present, then on first load we could just search through the list of SVGs for that one
[11:53] <Saviq> pete-woods, yeah, "search through the list" is what worries me ;)
[11:54] <Saviq> pete-woods, and it's not on first load, but on every load, 'cause we're destroying the greeter when it's not on screen
[11:54] <pete-woods> Saviq: well you'd only have to search through the SVGs for a single infographic, as you could store that, too
[11:55] <pete-woods> but sure, it's something to be aware of
[11:55] <Saviq> pete-woods, yeah, we'll get there once we know the requirements
[11:55] <pete-woods> yep
[11:55] <Saviq> Cimi, wanna do changes to infographics?
[11:57] <Cimi> Saviq, sure
[11:57] <Cimi> Saviq, doing the card touch down effect
[11:57] <Cimi> wil be finished before the standup
[11:58] <Saviq> Cimi, make sure to not conflict with tsdgeos's changes to how cards are created, where are you doing the touchdown?
[11:58] <Cimi> Saviq, Card.qml
[11:58] <Saviq> Cimi, then don't
[11:59] <seb128> Saviq, where is that workitem coming from? I've no recollection discussing that topic/taking that action item
[11:59] <Saviq> Cimi, Card.qml is going away
[11:59] <Saviq> seb128, https://blueprints.launchpad.net/ubuntu/+spec/client-1410-unity-ui-infographics
[11:59] <Cimi> Saviq, ah cool
[11:59] <seb128> Saviq, did somebody volunteer me without tell me?
[11:59] <seb128> telling
[11:59] <Saviq> seb128, possibly :)
[11:59] <Saviq> seb128, it's for "later" currently, not hugely important
[11:59] <seb128> k
[12:00] <Saviq> seb128, should probably be blocked on design, actually
[12:01] <Saviq> Cimi, so, new infographics → silo 010
[12:01] <seb128> Saviq, yeah, we need design for that ... we also need to know if users are going to be able to select a bg image for the dash again to update the design
[12:01] <Saviq> seb128, indeed
[12:02] <Saviq> Cimi, the backend part is https://code.launchpad.net/~unity-team/libusermetrics/file-based-infographics/+merge/21402
[12:02] <Cimi> Saviq, let me finish the touchdown before
[12:02] <Saviq> Cimi, didn't I say "don't"?
[12:02] <Cimi> tsdgeos, where is your refactoring branch for how cards are created?
[12:02] <Saviq> Cimi, Card.qml is going away ;)
[12:03] <Saviq> Cimi, shelve it for now, wait until that refactor is done
[12:03] <Cimi> ok
[12:03] <Saviq> Cimi, net result is that we get a model of svg filenames to display, and switch between them by double-tap
[12:03] <Saviq> Cimi, probably a fade-out+fade-in is in order
[12:04] <Saviq> pete-woods, you said there's command line to fake data for infographics?
[12:04] <pete-woods> Saviq: yeah, the usermetricsinput command
[12:04] <seb128> Saviq, my emails tell me you volunteered me for that workitem a week ago ... ;-)
[12:05] <Saviq> seb128, ha! not true ;) it was in https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-infographic before
[12:05] <seb128> Saviq, anyway, good that mentioned it, I didn't notice it due to the batch of changes in unity8 blueprints, I just mark them read
[12:05] <seb128> oh ok
[12:05] <seb128> well, at least I know about it now ;-)
[12:05] <pete-woods> Saviq: if Cimi is working on this, them I'm sure we can communicate to get the right information across
[12:05] <pete-woods> *then
[12:05] <Saviq> pete-woods, yup, I'm sure, too :)
[12:06] <Saviq> seb128, thostr_ volunteered you last July ;), it was even targeted for 13.08 milestone :D
[12:08] <seb128> Saviq, k, maybe I knew about it back then, it has been a while, lot going on ... ;-)
[12:08] <Saviq> indeed
[12:08] <Saviq> seb128, got POSTPONED soon after, and got back again very recently
[12:08] <seb128> k
[12:08] <seb128> thanks for the status update!
[12:30] <karni> alecu: elopio: I think that is exactly what I needed http://developer.ubuntu.com/api/devel/ubuntu-14.04/cplusplus/unity-scopes/index.html#scopetesting
[12:31] <karni> alecu: what did you mean by getting rid of 'qtisms' from the scope code?
[12:31] <alecu> karni: we have qt's signals and slots in too many layers of the code
[12:32] <alecu> karni: we'd like to move them lower, so they are only in the layer that uses qnetwork
[12:32] <karni> alecu: I see
[12:32] <alecu> karni: and, after that, we'll probably replace qnetwork with netcpp
[12:33] <karni> interesting!
[12:56] <karni> suppose I have a reference to CategorisedResult - how do I set arbitrary result data on it, other than set_{uri, title, art, dnd_uri} ?
[12:56] <karni> k, that was easier than expected. always answering my questions ;) result["price"] = Variant(price.toStdString());
[12:57] <mhr3> karni, you're welcome :)
[12:57] <karni> mhr3: hehe. I thank my rubber duck ;D
[12:58] <mhr3> karni, btw solved your yesterday's QMirServer... crash?
[12:58] <karni> mhr3: yes, just install unity8-fake-env :)
[12:58] <karni> mhr3: I actually told you yesterday, maybe you missed it
[12:58] <mhr3> karni, i guess, didn't see it
[12:58] <karni> mhr3: Saviq knew the answer from the top of his head, known issue
[12:59] <tsdgeos> Cimi:  lp:~aacid/unity8/dynamic_specialized_cards
[12:59] <mhr3> Saviq, is that cause something from scope-tool imports the app manager?
[12:59] <Saviq> mhr3, yeah :(
[12:59] <Saviq> mhr3, DashApps
[12:59] <mhr3> Saviq, hm, shouldn't those be instantiated only if you have click scope running?
[13:00] <Saviq> mhr3, if you launch the tool manually with no options
[13:00] <Saviq> mhr3, and you have click scope installed
[13:00] <mhr3> but karni was launching it via sdk
[13:00] <mhr3> that should launch just the one scope
[13:01] <Saviq> then yeah, should not happen
[13:01] <karni> correct. but because there's no redirect of scope debug output, I'm back to launching it from CLI
[13:01] <mhr3> oh well, adding todo to look at it
[13:01] <Saviq> mhr3, actually we're importing it in GenericScopeView
[13:01] <Saviq> mhr3, but anyway
[13:01] <mhr3> Saviq, that explains it then
[13:02] <Saviq> mhr3, it can only happen if you have libunity-mir1 installed already
[13:02] <Saviq> mhr3, it doesn't pull -fake-env then, otherwise -fake-env is default
[13:02] <mhr3> i see
[13:02] <mhr3> anyway, lunch /me bbiab
[13:03]  * Saviq biab, too
[13:23] <paulliu> Do I have any method to get the console log of unity8 running on phone?
[13:28] <kgunn> dandrader: greyback just a note, the input dispatcher stuff landed on mir dev branch, is there anything else you want landed before we tag & promote the next one?
[13:28] <kgunn> i'd like the next promotion to have all you need for qt comp
[13:28] <greyback> kgunn: unfortunately I mis-understood. One more branch is needed for qt comp, which isn't proposed yet
[13:28] <kgunn> hope to land 0.1.9 today, mir team have like 1 more branch to land then we're gonna go to 0.2.0 <- so that'd be the one i hope for
[13:29] <dandrader> kgunn, we need the other input stuff anpok is currently working on
[13:29] <kgunn> ok
[13:39] <kgunn> tsdgeos: i know you're still working on some of the card loading optimization...but we landed some optimization for the scope scrolling correct ?
[13:40] <tsdgeos> kgunn: scope scrolling effect?
[13:40] <tsdgeos> as in "it's jaggy"?
[13:40] <kgunn> yes :)
[13:40] <tsdgeos> we landed some small stuff back then
[13:40] <tsdgeos> but what i have now is better
[13:40] <kgunn> got it
[13:40] <tsdgeos> jsut unfinished
[13:44] <kgunn> mterry: were you wanting to target split greeter for landing? or am i making stuff up ?
[13:44] <kgunn> ...maybe it was just retarget at utopic
[13:45] <mterry> kgunn, I'm waiting on blocker branches to land -- we need a small telepathy-service fix (should poke someone for that today), a QA test harness fix, and a Mir fix
[13:46] <mterry> kgunn, but I did want to retarget for utopic
[13:47] <kgunn> mterry: ....oh is that all ...lol, short list i see
[13:48] <mterry> kgunn, it keeps growing as the changes happen around split branches  :-/
[13:49] <kgunn> i know...it's like trying to cross a highway as a pedestrian
[13:49] <mterry> kgunn, from Mir side, a solution for bug 1313832 would help us get around a design feedback problem
[13:49] <mterry> No bot?
[13:49] <mterry> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1313832
[13:49] <kgunn> i know...
[13:49] <kgunn> hmmpf
[13:53] <paulliu> tsdgeos: Fixed the pan over the bound problem. https://code.launchpad.net/~paulliu/unity8/zoomImage/+merge/207941
[13:53] <paulliu> tsdgeos: please re-review it.
[13:53] <tsdgeos> paulliu: cool, will try to find time later today
[13:53] <paulliu> tsdgeos: ok. Thanks a lot.
[13:58] <paulliu> Saviq: so should I move the Logout dbus interface to unity8/plugins/Unity/Logout ?
[13:58] <Saviq> paulliu, as I said in the MP, I don't really care :D, decide within yourselves
[13:58] <paulliu> Saviq: ok. Got it!
[14:01] <Saviq> paulliu, name it unity8/plugins/Unity/Session or unity8/plugins/Session, not Logout :)
[14:01] <paulliu> Saviq: ok.
[14:06] <mhr3> dpm, ping?
[14:07] <mhr3> dpm, do the scopes docs on duc still auto update? and from utopic?
[14:07] <mhr3> dpm, and how often? :)
[14:10] <karni> Is there any limitation on how many text fields I can put into a preview? seems 4th one doesn't want to show up. http://paste.ubuntu.com/7366536/
[14:11] <dpm> mhr3, otp, can you check with mhall119 in the meantime?
[14:11] <karni> nvm, line 30, s/remarks/store
[14:12] <mhr3> mhall119, ^^^?
[14:12] <mhr3> karni, and again, you're welcome :)
[14:13] <mhr3> you use this channel as your debug teddybear
[14:13] <karni> mhr3: I should shut myself with rubber duck in a room, and only leave 1 hour before EOD. I would probably stop talking at all ;D
[14:13] <Saviq> ;D
[14:18] <mhall119> mhr3: in UE Live! broadcast, will come back and read the backlog in a bit
[14:25] <Cimi> Saviq, pete-woods is there a doc of infographics without reading the merge review?
[14:32] <pete-woods> Cimi: there are docs, but as far as I'm aware they are wrong
[14:32] <pete-woods> Cimi: the shell facing API is essentially a list of SVGs as strings
[14:32] <pete-woods> and you need to move through them on double tap
[14:33] <Cimi> ok
[14:33] <pete-woods> Cimi: https://docs.google.com/a/canonical.com/document/d/1VajNkWbBH61iVixXJAmOvNGiG__GWQTMXGNOZijXWJw/edit#heading=h.uvcw591kzumb
[14:33] <pete-woods> but as I say, that doc is very different to what Mark has asked for
[14:35] <pete-woods> Cimi: the only input the API needs is the user's UID
[14:36] <pete-woods> which is just a plain old property
[14:36] <mhall119> mhr3: currently scopes API docs don't auto-update, but we can change that
[14:37] <mhall119> mhr3: I have a script and the server has an API, we just need to get it integrated into your workflow so that it gets run whenever you have a successful build
[14:39] <mhr3> mhall119, i thought it's hooked to the pkg in distro/
[14:39] <mhr3> ?
[14:40] <mhall119> mhr3: nope
[14:41] <mhr3> mhall119, any reason why not do that?
[14:41] <mhall119> it could be, I suppose, the script can be run anytime as long as the doc files are available, but I don't have the knowledge/access to do the hooking
[14:42] <mhall119> I'll gladly provide the script and instructions on on using it to anybody who can do that though
[14:43] <mhr3> mhall119, so none of the docs auto-update?
[14:43] <mhr3> from talking to dpm i thought this stuff is automated
[14:48] <mhall119> mhr3: not curretly, no, I wrote the code to allow it to happen, but I need somebody involve in each project's workflow to actually put the pieces together
[15:00] <mhr3> saviq, should https://bugs.launchpad.net/unity-scopes-shell/+bug/1260020 be retargetted to unity8?
[15:02] <Saviq> mhr3, it probably should just be marked fixed?
[15:02] <mhr3> saviq, do we have an ap test for it now?
[15:02] <Saviq> mhr3, no
[15:02] <mhr3> saviq, in that case it isn't fixed
[15:03] <Saviq> mhr3, no, that bug is fixed - there's another that there isn't a test, but it's not a unity8 bug either ;)
[15:03] <mhr3> the plugin passes a string to shell, it doesn't know if shell is able to do something about it
[15:03] <Saviq> mhr3, but a ubuntu-integration-tests one ;)
[15:04] <mhr3> saviq, ow, for a moment i thought such a thing actually exists
[15:32] <Saviq> early EOD today, see you tomorrow
[15:59] <mhr3> saviq, seeing some slowness when previewing albums
[16:00] <mhr3> saviq, and i'm wondering whether we didn't do async stuff properly, or whether it's qml
[16:00] <mhr3> saviq, but i guess all those Audio{} elements could be it
[16:11] <dednick> Saviq: you've updated to utopic?
[16:24] <alesage> finding that my unity8 upstart scripts are unresponsive while trying to run an autopilot test, how to debug?
[16:24] <alesage> the logs in .cache/upstart appear untouched
[16:24] <alesage> evil sorcery afoot
[16:26] <mhr3> dpm, i set auto transl exports for scopes scope
[16:26] <mhr3> apparently i don't have permissions to do it for the rest :/
[16:50] <dpm> mhr3, awesome, thanks. Which one is the one you need permissions for?
[16:50] <mhr3> dpm, -mediascanner
[17:41] <dpm> mhr3, ok, let me see who's the maintainer for that project...
[17:42] <mhr3> dpm, jamesh is
[17:43] <dpm> mhr3, he's probably not around now, is he? I'm away tomorrow, could you follow up with him to set the exports branch tomorrow?
[17:43] <mhr3> dpm, sure, will do
[17:43]  * mhr3 out
[17:43] <dpm> excellent, thanks!
[19:17] <kgunn> greyback: you thinkin' much about how to optimize the side channel ?
[19:17] <kgunn> or is it just b/c we've glommed onto life cycle
[19:17] <kgunn> that it seems to lag a bit
[19:21] <greyback> kgunn: it's laggy? How
[19:21] <Saviq> dednick, yes
[19:21] <kgunn> well..so there's the video case...
[19:21] <Saviq> mhr3, there's only one Audio {} element per preview
[19:22] <kgunn> but then also, i was just noticing on a game like wind (or whatever its called)
[19:22] <Saviq> mhr3, or well, per audio widget (but there's only one)
[19:22] <kgunn> you put it to the back i was "killed"
[19:22] <kgunn> cause it keeps rendering for a bit
[19:22] <greyback> kgunn: it's per-app, they need to support being told you've been made hidden or not
[19:23] <greyback> it may not be rendering, but the logic is still moving
[19:23] <greyback> if not supported, only the lifecycle sigstop actually stops the logic
[19:23] <kgunn> got it
[19:24] <greyback> so yeah, need a list of those apps to fix
[19:24] <greyback> kgunn: I guess the PPA is built with it?
[19:24]  * kgunn thinks...this is going to be one of those not so fun, fun things
[19:24] <kgunn> yes~
[19:24] <kgunn> or i meant yes! (with excitement)
[19:24] <greyback> nice try..
[19:25] <kgunn> i'm done with manual testing on n4 & n10...just need to run thru AP testing...then i'm done
[19:25] <kgunn> its looking good...same as before
[19:25] <greyback> sweet
[19:25] <kgunn> i noticed you can get grooveshark into more f'd state than before :)
[19:25] <kgunn> but its not us
[19:26] <kgunn> one other bug i notice, gallery/camera combo can get into a bad state...but only on n10, n4 works like a champ
[19:27] <kgunn> not sure if the camera subsystem is good on n10 ?
[19:27] <kgunn> or if its known to have issues...
[19:27] <greyback> nor am I, sorry
[19:27] <kgunn> i'll log a bug, but i don't think its our issue
[19:33] <kgunn> greyback: back to the educating apps...do we just need to broadcast this http://qt-project.org/doc/qt-5/qwindow.html#visibility-and-windowing-system-exposure
[19:34] <kgunn> via the sdk team?
[19:34] <kgunn> or what are your thots ?
[19:34] <kgunn> ...wonder if apps do like a weekly video...
[19:35] <kgunn> mhall119: ^ thots on that ?
[19:36] <kgunn> "that" being best/good ways to communicate to app developers they need to consider their occlusion wrt state
[19:36] <greyback> kgunn: this is the property in QML to listen to: https://qt-project.org/doc/qt-5/qml-qtqml-qt.html#application-prop
[19:36] <kgunn> ah sorry...the one i did was for native
[19:36] <kgunn> i suppose
[19:36] <greyback> kgunn: it's a really a per-app thing, so yeah the only choice is t oeducate developers
[19:37] <greyback> not much the SDK can do, aside from documenting clearly that devs should use it
[19:38] <greyback> so some sort of "hey guys, please update our apps to react to Qt.application.state property" publicity would be important
[20:05] <mhall119> kgunn: sorry, can you tl;dr that for me?
[20:09] <kgunn> mhall119: finding some apps that aren't paying attn to having focus/visibility....in these cases, you can (depending on the app)
[20:10] <kgunn> get a sense of lag, since they're "stopped" by life cycle, rather than themselves...thru "doing the right thing" by reacting programmitcally to
[20:10] <kgunn> https://qt-project.org/doc/qt-5/qml-qtqml-qt.html#application-prop
[20:11] <kgunn> ..before, blocking swap buffers kinda hid this, but with non-blocking swap on its way to archive..some apps ignoring this will exhibit said behavior
[20:11] <kgunn> so...what's the best way to educate mhall119 ?
[20:25] <mhall119> kgunn: I'm afraid you're gonna have to dumb it down even more than that for me, what would a QML app need to do with this propery and why?
[20:41] <greyback> mhall119: an app can have logic running continuously, yet is is not visible on screen. e.g. a game
[20:42] <greyback> mhall119: currently that's not a problem, as due to implementation details, when app was not visible, that running logic was forcibly stopped.
[20:42] <greyback> but that forced stop has consequences - one example being unable to adjust music volume when screen is off
[20:43] <greyback> or next track failing to load, again with screen off
[20:43] <greyback> so we have decided that forced stop is not desirable
[20:43] <greyback> as a result, now if an application is not visible, it's internal logic continues to run
[20:44] <greyback> there are times when an app developer may not want that to be the case however - take a game
[20:45] <greyback> so the Qt.application.state property is what developers should write code to listen to, and when it is set to inactive, the internal logic should be paused, until that property set to running again
[20:46] <mhall119> greyback: hold on, we decided that force stop isn't desirable now?
[20:47] <greyback> mhall119: note, this is very different to the app lifecycle system
[20:48] <mhall119> ok, now I'm *more* confused....are we going to allow apps to continue running when they don't have focus on phone, or not?
[20:49] <greyback> mhall119: for this conversation, app lifecyle is not effected. Apps are suspended and resumed as they are now
[20:49] <greyback> mhall119: this is to deal with other situations where apps are not suspended, but need to pause their internal logic for other reasons
[20:50] <greyback> example case: you're playing a game, and you open your indicators - that should pause the game
[20:50] <greyback> game is not lifecycled
[20:50] <greyback> but it still should pause, as the user is interacting with the indicators, not the game itself
[20:51] <greyback> the second use-case is that there is a 3 second delay from app being made invisible, to app being lifecycle suspended
[20:52] <greyback> so for a game, it has proceeded 3 seconds further, without the users knowledge
[20:53] <greyback> mhall119: those problems make sense to you?
[20:53] <mhall119> greyback: ah, yes, ok, so instances where the app isn't in the background, but still isn't necessarily visible
[20:53] <greyback> mhall119: right
[20:54] <mhall119> and the answer is to do what, exactly?
[20:55] <greyback> https://qt-project.org/doc/qt-5/qml-qtqml-qt.html#application-prop <- this property notifies the app if it is in foreground or not
[20:56] <mhall119> nitpick: http://developer.ubuntu.com/api/qml/sdk-14.04/QtQml.Qt/#application-prop we have those docs :)
[20:56] <greyback> we should have app writers know about this property, so that they can pause their internal logic if their app is not visible/visible
[20:56] <greyback> mhall119: those docs are old. We're using Qt5.2, those are 5.0 docs
[20:56] <mhall119> is there any way to pause internal logic for them, by default, and allow them to override the behavior if they want something to keep running?
[20:56] <greyback> mhall119: no
[20:57] <mhall119> greyback: ubuntu-sdk-14.04 framework has Qt 5.2?
[20:57] <greyback> mhall119: the phone trusty image is running qt5.2, that's all I know
[20:57] <mhall119> ok, I'll make a note to myself to update the docs then
[20:58] <mhall119> so app developers need to Connect that propery to a handler function, correct?
[20:59] <greyback> mhall119: so there's a reason I'm telling you this now. We're making a change in Mir, with the result that app which do _not_ listen for Qt.applicaiton.state changes, will keep running
[20:59] <greyback> right now, they just stop (due to implementation details)
[20:59] <greyback> but soon, they won't
[20:59] <mhall119> ok, so best thing we can do is to get bzoltan to change the QML template to add this connection and a handler function that does nothing, but has comments explaining what should be in it
[21:00] <mhall119> that should make it obvious for new apps
[21:00] <greyback> I suppose so yes
[21:00] <mhall119> popey can let the Core Apps developers know about the pending change and for those that have something to pause they can implement it
[21:00] <greyback> great
[21:00] <mhall119> for the rest, we can blog about it
[21:01] <mhall119> add a short guide or "cookbook recipe" to the devportal too
[21:01] <greyback> yeah, just need to get the word out there. The apps which are badly behaved will be noticed pretty quick
[21:01] <mhall119> yup
[21:01] <mhall119> we can pre-emptively add an askubuntu question with answer too
[21:02] <mhall119> can you email popey and I with an example of what the QML code for an app would need to be?
[21:03] <greyback> sure
[21:03] <mhall119> thanks
[21:51] <Saviq> greyback, we won't be SIGSTOPing apps??
[21:53] <greyback> Saviq: we are
[21:54] <greyback> Saviq: this is the render thread blocking thing. New Mir won't block render thread any more, so the GUI thread is not blocked. But some apps were relying on that blocking
[22:03] <Saviq> greyback, yeah well, they'll only have 5s or so to do their business anyway :)
[22:03] <Saviq> but yeah, sure, they should know about us suspending them