[07:17] <Saviq> mzanetti, hey, it shouldn't be difficult to apply a different OOM score to the dash should it? see bug #1379296
[08:33] <tsdgeos> vesar: did JMulholland have a chance to try the bottom list thing? any input?
[08:33] <tsdgeos> i think the wizard just crashed on me
[08:34] <tsdgeos> when trying to select the language
[08:36] <tsdgeos> _usr_sbin_unity-system-compositor.0.crash
[08:42] <tsdgeos> MacSlow: do you know anything about a volume notification that appears one passing the first screen of the wizard?
[08:42] <tsdgeos> feels pretty weird
[08:43] <mzanetti> Saviq: ack, can look into that today
[08:43] <Saviq> mzanetti, too lat
[08:43] <Saviq> e
[08:44] <Saviq> mzanetti, https://code.launchpad.net/~unity-team/qtmir/dash-killed-less-likely/+merge/237915
[08:44] <Saviq> with a test and all!
[08:44]  * Saviq happy to know that he can still write some code (or at least copy-paste it :P)
[08:45] <mzanetti> hehe
[08:45] <mzanetti> congrats
[08:48] <MacSlow> tsdgeos, the welcome-wizard?!
[08:48] <tsdgeos> MacSlow: yep
[08:49] <MacSlow> tsdgeos, did you press the any of the volume-keys?
[08:49] <tsdgeos> MacSlow: i'm pretty sure i did not
[08:49] <Saviq> MacSlow, tsdgeos, there's a bug
[08:49] <tsdgeos> i've had that twice or three times already
[08:49] <tsdgeos> Saviq: ah ok
[08:49] <greyback> ensureProcessABitMoreLikelyToBeKilledThanShellButNotMuch
[08:49] <MacSlow> tsdgeos, Saviq: oh... that's news to me
[08:49] <tsdgeos> Saviq: bug # ?
[08:49] <Saviq> bug #1379287
[08:50] <Saviq> update your sound indicator and it should be gone
[08:50] <MacSlow> Saviq, tsdgeos: ah... I'm pretty sure I know what's causing this
[08:51] <Saviq> MacSlow, ted reverted the bubbles in i-sound trunk already, and has a new branch: https://code.launchpad.net/~ted/indicator-sound/synchronous-notification/+merge/237666
[08:51] <MacSlow> Saviq, tsdgeos: my initial indicator-sound branch was reverted... yeah that
[08:52] <MacSlow> Saviq, tsdgeos: among the sync. notification/max-volume-warning work I'm also working on a new indicator-sound branch, which will avoid that from happening again
[08:52] <Saviq> MacSlow, make sure you sync with ted's branch then
[08:52] <MacSlow> Saviq, yup
[08:52] <Saviq> tsdgeos, you not working on the qmltest fail are you?
[08:53] <tsdgeos> Saviq: the ShellWithPin::test_factoryReset  ? no i'm testing touchOwnership for the last time
[08:54] <Saviq> tsdgeos, kk, I'll look to fix the test then
[08:58] <Saviq> tsdgeos, btw, I had a look at dash mem usage between pre and post more-in-mem... couldn't see a real difference... if anything it's using less memory now :P
[08:58] <tsdgeos> :D
[08:59] <tsdgeos> Saviq: ok, so i approved touchOwnership, do you want me to top approve or want someone to have another look?
[08:59] <Saviq> tsdgeos, I think functional testing in silo will be enouh
[08:59] <Saviq> enough
[09:00] <tsdgeos> ok
[09:00] <tsdgeos> there we go
[09:21] <Saviq> mzanetti, I blame you https://code.launchpad.net/~saviq/unity8/fix-shellwithpin-test/+merge/237922 :P
[09:21] <mzanetti> Saviq: why would you do that?
[09:22] <Saviq> mzanetti, blame you? because you reviewed mterry's branch which broke this
[09:22] <Saviq> tablet-security
[09:22] <Saviq> although somehow it passed in ci
[09:26] <Saviq> Wellark, wasn't the "I see white before I see the SIM PIN dialog" supposed to be fixed already?
[09:35] <Wellark> Saviq: ask MacSlow
[09:35] <Wellark> Saviq: my take on that is that let's leave it unfixed, as it will be a PITA
[09:35] <Wellark> it's just a brief clitch
[09:35] <Saviq> Wellark, well, *you* told me that it doesn't matter, because it will be fixed with your stuff ;P
[09:36] <Saviq> Wellark, still, it's going to be the first thing you see on your phone when you turn it on...
[09:36] <Wellark> Saviq: with my stuff we fixed the flickering while using the dialog
[09:36] <Saviq> kk, we need to fix the flickering when opening, too
[09:36] <Wellark> it used to flicker and sometimes break completely if you entered your pin wrong
[09:36] <MacSlow> Wellark, Saviq: such tiny glitches don't fit in the current notification-feature demand :)
[09:36] <Saviq> yeah ok
[09:36] <Saviq> MacSlow, not a feature ;P
[09:36] <Wellark> Saviq: it's PITA to fix
[09:37] <MacSlow> and that too
[09:37] <Saviq> MacSlow, can't we delay showing the notification until the model is loaded or something?
[09:37] <Wellark> as the pin unlock is the only fullscreen snap decision
[09:37] <Wellark> and yes, the clitch comes from the fact that the "fullscreen" property is not ready until the Loader finishes to load the pin-unlock snap decision
[09:37] <MacSlow> Saviq, I learned that one can't poke into models
[09:38] <MacSlow> Saviq, without really digging into it I can't tell if one could fix that or not
[09:38] <vesar> tsdgeos, I just saw him checking your implementation and expect him to get back to you with his comments soon. JMulholland^
[09:38] <Wellark> Saviq: there are just too many loaders involved
[09:39] <Saviq> MacSlow, k, let's look into it once we got the more pressing things in
[09:39] <JMulholland> tsdgeos: We’ve taken a look, need to put together some feedback but impressive progress so far!
[09:39] <Wellark> Saviq: +1
[09:39] <Saviq> Wellark, let's uninvolve them then ;P
[09:39] <MacSlow> Saviq, Wellark: yup
[09:39] <Wellark> Saviq: well, why did you allow the unity8 tree to have Loaders everywhere? ;)
[09:39] <Wellark> I hate the things
[09:40] <Saviq> Wellark, because we like to be able to run apps
[09:40] <Wellark> Saviq: just grep unity8 for "Loader" and see the results ;)
[09:40] <Wellark> Saviq: I'm not saying they should be removed completely
[09:40] <Saviq> Wellark, yes, again, because we like to be able to run apps
[09:40] <Wellark> but I'm sensing a slight overuse ;)
[09:41] <Wellark> anywayw
[09:41] <Wellark> we are not even close to a point of starting to think such optimizations
[09:41] <Wellark> so let's just have the loaders and acknowledge that we might have slight clitches
[09:42] <Wellark> Saviq: btw, do we have any sane QML profiling tools already?
[09:42] <Wellark> something that draws pretty pictures?
[09:42] <Saviq> Wellark, you mean like QtCreator's profiler that's there from when we started?
[09:43] <Wellark> Saviq: If I remember correctly the qtcreator profiler could not dig into the c++ side of the calls or anything?
[09:43] <Saviq> Wellark, if you want C++ calls, there's any number of profiler tools out there
[09:44] <Wellark> Saviq: both combined: the QML side and C++ side
[09:45] <larsu> Saviq: no dednick today? Do you know who I could assign bug #1369737 to?
[09:45] <Wellark> not separately
[09:45] <Saviq> Wellark, combined, no, not that I know of
[09:45] <Saviq> larsu, he's around, just went out to bring a friend to the emergency room....
[09:46] <larsu> Saviq: oh, hope he's ok. I'll assign to him
[09:46] <Wellark> larsu: are you close on the Final Solution of the toggle switches getting out of sync?
[09:46] <larsu> Saviq: thanks
[09:46] <larsu> Wellark: that's a question for dednick. We decided that he'll add a timeout on the switch and reset it if the service didn't change state
[09:52] <Saviq> larsu, Wellark, there's a branch https://code.launchpad.net/~nick-dedekind/unity8/lp1336715.server-value-reassert/+merge/237822
[09:52] <Wellark> larsu: so this solution is not changing the semantics of the switches as seen from GAction API point of view?
[09:53] <larsu> Wellark: yes, the semantics are quite fine, the UI didn't react right
[09:54] <Wellark> larsu: <3
[10:16] <tsdgeos> Saviq: can you try to reproduce https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1251597 with http://jenkins.qa.ubuntu.com/job/generic-mediumtests-builder-utopic-armhf/7001/artifact/work/output/*zip*/output.zip ?
[10:16] <tsdgeos> i can't
[10:17] <Saviq> tsdgeos, didn't try, but it makes sense, just link the bug'n'branch
[10:17] <tsdgeos> ok
[10:25] <tsdgeos> Cimi: https://code.launchpad.net/~unity-team/unity8/flickables-speed-workaround/+merge/234298 ?
[10:25] <tsdgeos> larsu: https://code.launchpad.net/~larsu/unity8/stop-using-statusicon/+merge/234502 ?
[10:26] <Cimi> tsdgeos, ouch
[10:26] <tsdgeos> Saviq: i don't have a x-compile setup, but now that CI passes i guess we can just approve https://code.launchpad.net/~dobey/unity8/fix-cross/+merge/234818 ?
[10:27] <Saviq> tsdgeos, well, not according to Colin...
[10:27] <Saviq> tsdgeos, I'll have a chat with him it's good enough for now
[10:27] <tsdgeos> ok
[10:27] <Saviq> if
[10:28] <larsu> tsdgeos: should be fixed once https://code.launchpad.net/~larsu/ubuntu-ui-toolkit/icons/+merge/236497 lands
[10:29] <tsdgeos> larsu: ok
[10:35] <larsu> how do you handle showing times in the correct locale? messaging menu does it the wrong way according to bug #1372061
[10:35] <larsu> it uses QDateTime::fromString()
[10:35] <larsu> the reporter suggest making the format string translatable, but that sounds wrong to me...
[10:37] <larsu> QLocale::toString() ?
[10:41] <tsdgeos> larsu: QDateTime::toString ?
[10:42] <larsu> tsdgeos: sorry that's what I meant.
[10:42] <tsdgeos> larsu: that one should work
[10:43] <larsu> tsdgeos: it doesn't respect locale according to the bug (which makes sense, we pass a fixed format into it)
[10:43] <tsdgeos> larsu: well, don't :D
[10:43] <tsdgeos> larsu: there's a version that does it right
[10:44] <larsu> tsdgeos: I think we did that because design...
[10:44] <tsdgeos> larsu: if the available Qt::DateFormat don't suit you, then yes you'll have to make the string translatable
[10:44] <tsdgeos> but someone from design should be told not to invent time formats
[10:45] <tsdgeos> or at least if we're going to invent them
[10:45] <tsdgeos> centralize them on the SDK
[10:45] <larsu> right, that makes a lot of sense
[10:45] <larsu> thanks for the info
[10:47] <Saviq> oh look, I wonder who created a blueprint for that a year ago https://blueprints.launchpad.net/ubuntu-ui-toolkit/+spec/time-formatter
[10:49] <tsdgeos> wohohoho
[10:49] <tsdgeos> :D
[10:58] <larsu> Saviq: right, this is timeformatter.cpp in unity8
[10:58] <larsu> Saviq: which already does the automatically-update-when-timezone-changes part
[10:58] <Saviq> larsu, yeah, but shouldn't exist in unity8 at all
[10:59] <larsu> Saviq: unity8 is the only consumer of this right now. If we like the API and there's something else that wants to use it, let's move it to the toolkit
[10:59] <larsu> apparently we shouldn't yet, because it does the wrong thing with the format
[10:59] <larsu> ;)
[11:00] <Saviq> larsu, sure, it does some wrong things, and some others - not at all
[11:00] <Saviq> larsu, which is why it's not in the toolkit yet
[11:05] <larsu> Saviq: that's what I just said?!
[11:05] <Saviq> larsu, possibly
[11:06] <mzanetti> do we have a color definition for the popver color in here? https://launchpadlibrarian.net/185198724/launcher_standard-menu.jpg
[11:12] <Saviq> mzanetti, UbuntuColors.lightGrey I think?
[11:12] <Saviq> mzanetti, actually probably not
[11:12] <Saviq> mzanetti, since dash has f5f5f5 hardcoded
[11:13] <Cimi> tsdgeos, fixed
[11:14] <mzanetti> Saviq: no f5f5f5 in UbuntuColors
[11:14] <mzanetti> lightGrey is 929292
[11:24] <dandrader> tsdgeos, do you know/recall what I have to pass to qmake in qtdeclarative-opensource-src-5.3.0 to have the tests built?
[11:25] <tsdgeos> so it's developer-build on qtbase
[11:25] <tsdgeos> not sure what in qtdeclarative
[11:25] <tsdgeos> dandrader: you can also just go to the folder you want and run qmake
[11:27] <dandrader> tsdgeos, I mean I did "apt-get souece qtdeclarative-opensource-src;mkdir qtdeclarative-build;cd qtdeclarative-build;qmake CONFIG+=debug ../qtdeclarative-opensource-src-5.3.0"
[11:27] <tsdgeos> sure now go to tests and just run qmake there
[11:27] <tsdgeos> or qmake CONFIG+=debug if you want
[11:28] <dandrader> tsdgeos, no tests dir in there http://paste.ubuntu.com/8532319/
[11:28] <tsdgeos> dandrader: you're on the build dir
[11:28] <tsdgeos> you need to run qmake over the source dir
[11:28] <tsdgeos> or do
[11:28] <dandrader> tsdgeos, I remember there was some magic variable I would pass to the qmake command to have the tests built as well
[11:28] <tsdgeos> mkdir test_build
[11:29] <tsdgeos> and run qmake there with ../omething/tests
[11:29] <tsdgeos> dandrader: there probably is
[11:29] <dandrader> tsdgeos, it took me quite a bit of research. but it was a while ago and I didn't write it down. so now I forgot it :/
[11:29] <tsdgeos> dandrader: anything against just running qmake?
[11:30] <tsdgeos> Cimi: your merge is quite weird
[11:30] <tsdgeos> Cimi: shows me changes in .po files
[11:32] <dandrader> tsdgeos, I don't understand how the separate tests build dir would relate to the lib build dir
[11:32] <facundobatista> Holas
[11:32] <dandrader> tsdgeos, but I will try it :)
[11:34] <dandrader> tsdgeos, hmm, kinda works. but it only builds a very small percentage of the tests. it's missing the bulk of it, the so called "private tests"
[11:35] <dandrader> tsdgeos, which are probably the tests that make use of the private apis
[11:35] <dandrader> the search continues....
[11:36] <tsdgeos> dandrader: ah right, add private_tests to CONFIG and you should get them
[11:41] <Cimi> tsdgeos, I redid... maybe was because was based on more things on memory
[11:42] <Cimi> tsdgeos, nope :\
[11:42] <tsdgeos> Cimi: have you really merged unity8 and not some other branch?
[11:42] <Cimi> tsdgeos, how I do now? I download the po for unity8 trunk and overwrite?
[11:42] <tsdgeos> Cimi: just merge unity8 again :d
[11:42] <tsdgeos> or that
[11:43] <Cimi> tsdgeos, nothing to do :D
[11:43] <Cimi> tsdgeos, I try to overwrite
[11:44] <mzanetti> err... why is there an activityIndactor above all tests now?
[11:44] <mzanetti> is that intentional?
[11:47] <tsdgeos> yeah....
[11:47] <tsdgeos> makes them faster
[11:47] <tsdgeos> ....
[11:47] <tsdgeos> :D
[11:47] <dandrader> mzanetti, it's to make waitForRendering(window) pass "immediately"
[11:47] <Cimi> tsdgeos, is fine now!
[11:48] <mzanetti> mhm...
[11:48] <tsdgeos> Cimi: good!
[11:49] <tsdgeos> food
[13:15]  * tsdgeos had an infection of tags
[13:15]  * tsdgeos nukes everything
[13:15] <tsdgeos> careful in case you had been in contact with me branches
[13:24] <Zephyr1139> Has anyone else ever encountered an empty desktop with just a mouse cursor after an install of ubuntu 14.04?
[13:30] <tsdgeos> Saviq: Cimi: so is https://code.launchpad.net/~unity-team/unity8/flickables-speed-workaround/+merge/237944 something we want for rtm or just unity9?
[13:30] <tsdgeos> -1
[13:32] <Cimi> tsdgeos, rtm
[13:32] <tsdgeos> Cimi: it has no critical bug linked
[13:33] <Cimi> tsdgeos, well the toolkit has bug
[13:33] <tsdgeos> well no bug at all
[13:33] <Cimi> tsdgeos, not unity8...
[13:33] <Cimi> tsdgeos, but it won't happen for rtm the toolkit
[13:33] <Cimi> I highly doubt it...
[13:36] <tsdgeos> Cimi: i'd still want a bug attached to it or something for everything we're going to land for rtm tbh
[13:37] <greyback> Zephyr1139: that often means that the unity plugin for compiz failed to start. You'd get more help from the folks in #ubuntu-desktop
[13:37] <Cimi> tsdgeos,  * Are there any related MPs required for this MP to build/function as expected? Please list.
[13:37] <Cimi>  * Did you perform an exploratory manual test run of your code change and any related functionality?
[13:37] <Cimi>  * Did you make sure that your branch does not contain spurious tags?
[13:37] <Cimi>  * If you changed the packaging (debian), did you subscribe the ubuntu-unity team to this MP?
[13:37] <Cimi>  * If you changed the UI, has there been a design review?
[13:37] <Cimi> ops
[13:37] <Cimi> https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1348557
[13:37] <Cimi> ahaha
[13:39] <Cimi> tsdgeos, if is not rtm, I have to patch few of them...
[13:39] <tsdgeos> Cimi: why added "import Ubuntu.Components 1.1" ?
[13:39] <Cimi> tsdgeos, grid unit
[13:40] <tsdgeos> Cimi: in qml/Dash/ScopesOverviewFavorites.qml ?
[13:40] <tsdgeos> but you're right
[13:40] <tsdgeos> why did it work?
[13:41] <Cimi> tsdgeos, did I forget to add it here?
[13:41] <tsdgeos> no no
[13:41] <tsdgeos> i'm just asking why you added it
[13:41] <tsdgeos> when it wasn't there before
[13:41] <tsdgeos> but it's right that it's weird it did work before
[13:42] <Cimi> tsdgeos, because it gets from the parent probably...
[13:48] <Zephyr1139> greyback, thanks.  I'll ask there too.
[13:55] <tsdgeos> Cimi: so your branch changes some of the defined values, i understand the benefit of having teh same everywhere, but those values maybe were there because they were better? what's your opinion
[13:55] <tsdgeos> ?
[13:55] <Cimi> tsdgeos, because who of us wrote then didn't know they could have done them resolution independent
[13:56] <Cimi> them
[13:56] <Cimi> me included (see carousel)
[14:00] <Cimi> tsdgeos, linked to the bug report
[14:11] <tsdgeos> dednick: can you merge the expanded-panel-design branch?
[14:12] <dednick> tsdgeos: moved back to WIP. there are some problems with it still
[14:13] <tsdgeos> dednick: ok
[14:17] <Saviq> mterry, you know why I had to do more changes to fix the shell PIN test?
[14:17] <mterry> Saviq, I understand that the visuals were messed up, yeah.  I'd like my tap() improvements to eventually make it in, but I'm fine with your branch instead.  As long as the test gets fixed
[14:18] <Saviq> mterry, already in my MP
[14:18] <Saviq> mterry, it's not about the visuals even, it's the fact that it was unreliable still
[14:18] <mterry> Saviq, oh then I didn't understand that.  I ran it a bunch and didn't see a failure
[14:18] <Saviq> mterry, the popup got messed up, so the button inside it was messed up
[14:18] <Saviq> mterry, yeah, well, it worked by chance :)
[14:19] <Saviq> mterry, because the Popup tried to anchor.fill the root element
[14:19] <mterry> Saviq, sure, and it's a row so it can't
[14:19] <Saviq> mterry, but the root element was a Row, that doesn't like anchoring horizontally
[14:19] <mterry> Saviq, but why was it clickable at all?
[14:19] <mterry> Saviq, I ran in xvfbtest mode, so I didn't see what it looked like
[14:20] <Saviq> mterry, well, because it existed, and by chance had some size
[14:20] <Saviq> mterry, in try, if you worked through the test, you could see stuff getting broken
[14:20] <Saviq> mterry, and in test (no xvfb) the window just disappeared when Popup happened
[14:23] <Saviq> jeez what happened with AP? :/
[14:24] <mzanetti> don't act like you'd be surprised :P
[14:24] <Cimi> ahah
[14:32] <Saviq> @unity: I'm prepping a silo for unity8, qtmir, papi (?), let me know if there's anything that's not top-acked that should go in
[14:32] <mzanetti> Saviq: have my launcher-dconf branches?
[14:33] <dandrader> Saviq, are you putting touchOwnership there?
[14:33] <Saviq> dandrader, it's ACK'ed, so yeah
[14:34] <mzanetti> uuhh.. the kraken is about to be relased!
[14:34] <dandrader> you never know, it's a huge one. might have scared you away :)
[14:34] <mzanetti> it should!
[14:34] <mzanetti> :)
[14:34] <dandrader> :)
[14:35] <dandrader> Saviq, release the Kraken!
[14:35] <Saviq> ;)
[14:39] <Saviq> lp:~mterry/unity8/greeter-profiles: 0.1.16
[14:40] <mterry> Saviq, guh
[14:40] <mterry> Saviq, fixed
[14:40] <Saviq> larsu, can you please run http://people.canonical.com/~msawicz/unity8/strip-u8-tags.py on your status-icon branch (and any local checkouts of unity8 you might have)
[14:41] <Saviq> lp:~mterry/unity8/dbus-race-fix: 0.1.16
[14:41] <Saviq> and that's that
[14:41] <mterry> Saviq, did that tag sneak into trunk?  I probably missed it on a merge from trunk
[14:41] <mterry> Saviq, dbus-race-fix tag deleted
[14:42] <larsu> Saviq: can I also just delete the local branches and check them back out?
[14:42] <Saviq> mterry, yeah it did
[14:42] <Saviq> larsu, sure you can :)
[14:42] <Saviq> larsu, but the remote one you need to clear
[14:42] <larsu> Saviq: cool
[14:43] <larsu> Saviq: ah, right
[14:43] <mterry> Saviq, bzr has local hook support, right?  Couldn't we whip up a hook to strip tags on push?
[14:43] <mterry> (for dev local machines)
[14:43] <Saviq> mterry, it doesn't have a push hook
[14:43] <mterry> I realize having jenkins do it is harder
[14:43] <Saviq> mterry, just a commit hook
[14:43] <mterry> Saviq, bummer
[14:44] <Saviq> mterry, but yeah, we have a plan for a pre_push script or so
[14:44] <mterry> Saviq, even so...  the latest version of strip tags is very fast.  I probably wouldn't particular notice if it was in the commit hook
[14:44] <larsu> Saviq: pushing the branch after stripping the tags doesn't seem to work: No new revisions or tags to push.
[14:45] <Saviq> larsu, you need to point the script at the remote branch
[14:45] <Saviq> larsu, bzr doesn't keep history of tags
[14:45] <Saviq> larsu, they're viral
[14:45] <Saviq> which is why we're in this state in the first place :|
[14:46] <larsu> how do I do that?
[14:46] <Saviq> larsu, on the command line
[14:46] <larsu> ah, the script accepts a branch param
[14:46] <Saviq> larsu, yeah, a list
[14:47] <Saviq> larsu, yeah, I know, it should complain if you don't, and it should have a --help, but you know, it was only supposed to live for a week :P
[14:47] <larsu> right
[14:50] <larsu> okay, done.
[14:50] <Saviq> larsu, thanks
[14:51] <Saviq> tsdgeos, we should bump qtmir in https://code.launchpad.net/~dandrader/qtmir/UbuntuKeyboardInfoQMLSingleton/+merge/236151 should we not? and depend on it in u8?
[14:51] <Saviq> dandrader|afk, when you're back ↑
[14:54] <tsdgeos> Saviq: hmmm
[14:55] <tsdgeos> probably
[14:57] <dandrader> Saviq, ok, will do that now
[14:59] <Saviq> @unity: here's my list, if something's missing please let me know http://pastebin.ubuntu.com/8533419/
[15:01] <mzanetti> Saviq: the launcher-dconf one has related in the description... they are not *really* necessary, but would be nice to land together
[15:02] <mterry> Saviq, no greeter-profiles?
[15:02] <Saviq> mterry, just discussing with ted
[15:05] <Saviq> dandrader, sorry, touchOwnership will have to wait for another round, mterry's ↑ branch is ready to go with some indicator changes, and for yours we need to wait for Mir to unblock qtmir
[15:05] <dandrader> Saviq bumped qtmir version as requested
[15:05] <dandrader> Saviq :-(
[15:17] <Saviq> dednick, https://code.launchpad.net/~nick-dedekind/unity8/lp1336715.server-value-reassert/+merge/237822/comments/583596 please
[15:17] <Saviq> dandrader|afk, and this is fixed by your request, too https://code.launchpad.net/~saviq/unity8/fix-shellwithpin-test/+merge/237922
[15:17] <dednick> Saviq: you mean in the proposal, or in the code?
[15:17] <Saviq> dednick, code better
[15:18] <Saviq> I knew it
[15:20] <Saviq> dandrader|afk, ah you did abstain
[15:20] <Saviq> as you were, then
[15:22] <dednick> Saviq: done.
[15:23] <Saviq> dednick, thanks
[15:23] <dednick> although my spelling suck. one miunute
[15:23] <dednick> meh
[15:23] <Saviq> dednick, it does ;)
[15:24] <Saviq> dednick, and why 1500, that a magic value that Just Works™? and can't we get a "fuck off" signal from indicators instead and reset the value then?
[15:25] <dednick> Saviq: 1500=magic. and no, it would seem that we can't
[15:25] <dednick> since it's just dbus activations
[15:26] <Saviq> :/
[15:28] <dednick> larsu: is there a hardcoded timeout for unifying the action state change updates into a single signal?
[15:29] <dednick> larsu: re the state change problem we are seeing with activations.
[15:30] <dednick> larsu: as in -> state change true ->false -> true -> false -> true -> false" sends only one signal after x seconds?
[15:53] <Cimi> hey tedg, can you please help us how to change role for audio? comment #4 https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1378920
[15:53] <tedg> Cimi, I think rsalveti is the guy you want.
[15:54] <tedg> You tag the stream in GStreamer, but there may be a Qt API for it as well.
[15:54] <rsalveti> yeah, we can do that on Qt or QML
[15:55] <Cimi> rsalveti, how? :)
[15:55] <Cimi> rsalveti, so far, from what I can see in the code, we have just an Audio qml component
[15:55] <tsdgeos> mzanetti: something broke in the launcher quicklist with utf chars
[15:56] <rsalveti> audioRole: MediaPlayer.alert
[15:56] <rsalveti> on the Audio component
[15:56] <rsalveti> we have that on system-settings
[15:56] <tsdgeos> i get CA!mara
[15:56] <tsdgeos> instead of Cámara
[15:56] <mzanetti> hmm
[15:56] <mzanetti> tsdgeos: and idea when it happened?
[15:56] <mzanetti> s/and/any/
[15:56] <tsdgeos> mzanetti: nope :/
[15:56] <mzanetti> ok. will find out
[15:56] <mzanetti> thanks
[15:57] <tedg> tsdgeos, We made camera more exciting by adding !
[15:59] <tedg> mpt, On your high volume mock up have a "headphones" label in the sound indicator, which we don't do today.
[15:59] <tedg> mpt, I mean the label over the slider.
[16:00] <tedg> mpt, I don't see that elsewhere in the spec though
[16:01] <mpt> tedg, https://wiki.ubuntu.com/Sound#notification
[16:01] <mpt> The visual design and wireframe+text aren’t in sync yet, sorry
[16:02] <tedg> mpt, Yes, I was meaning on the menu: https://wiki.ubuntu.com/Sound?action=AttachFile&do=get&target=sound-settings-volume-high.phone.png
[16:02] <tedg> mpt, Not the notification
[16:02] <mpt> oh, sorry
[16:03] <Cimi> rsalveti, do we patch qt?
[16:03] <mpt> tedg, I’ll need to discuss that with Patti, but tbh that’s a bit down my priority list
[16:04] <tedg> mpt, Oh, wait, is that supposed to be a system settings screenshot?
[16:04] <Cimi> rsalveti, I see this audioRole in system settings, but cannot find the property on qt doc
[16:04] <mpt> tedg, yes, System Settings
[16:05] <mpt> tedg, that’s why it continues onto “Phone calls:…” :-)
[16:05] <tedg> mpt, So then in the indicator we just need the caption, not the lable.
[16:05] <tedg> label
[16:05] <mpt> yep
[16:05] <tedg> mpt, Yeah, just noticed that. :-)
[16:05] <tedg> K, cool.
[17:07] <dednick> larsu: hey. know much about g_dbus_action_group_get ? :)
[17:20] <rsalveti> Cimi: part of qt multimedia
[17:21] <rsalveti> Cimi: if you want to do in qt itself, you can check how that was done in telephony-service
[17:21] <rsalveti> yeah, the api is something we added, not upstream yet