[00:58] <inder_gt> hey guys, whats the better way to do indicator applets, pygtk or pygi?
[07:39] <Saviq> Wellark, well, yeah, it was top-approved, and I asked mterry whether it was ok to land...
[08:40] <Cimi> Saviq, do we have anything to review?
[08:41] <Cimi> alt nav but I thought you were doing shader?
[08:41] <Saviq> Cimi, yeah, you still didn't get me the shader code though, anpok_'s solution didn't work...
[08:41] <Saviq> Cimi, but there's plenty in https://code.launchpad.net/~unity-team/unity8/trunk/+activereviews
[08:42] <Cimi> Saviq, there's only two
[08:42] <Saviq> Cimi, huh>
[08:42] <Cimi> "reviews I can do"
[08:42] <Saviq> Cimi, there's also "I am not actively reviewing"
[08:42] <Cimi> one is no lock during call
[08:43] <Cimi> Saviq, but that means someone else is already reviewing
[08:43] <Saviq> Cimi, yeah, tsdgeos's hijacking everything by just doing "conflicts"
[08:43] <Cimi> Saviq, and we assign ourselves reviews for a reason
[08:43] <Cimi> hah, he loves karma we know...
[08:43] <Saviq> tsdgeos, I think you shouldn't put a vote up when reporting conflicts
[08:44] <tsdgeos> Saviq: i'm not hijacking anything, i go back to abstrain when conflicts are fixed
[08:44] <Saviq> tsdgeos, that still marks you as the reviewer out of "unity team"
[08:44] <Saviq> tsdgeos, so there's no longer a request for the team to review, so it doesn't show up in "reviews I could do"
[08:45] <tsdgeos> Saviq: i don't think i've marked any of those that wasn't already reviewed by someone and if i had i followed it up
[08:45] <tsdgeos> https://code.launchpad.net/~nick-dedekind/unity8/indicator-polishing/+merge/228700 you
[08:45] <tsdgeos> https://code.launchpad.net/~macslow/unity8/fix-1348092/+merge/228090 Daniel
[08:45] <tsdgeos> https://code.launchpad.net/~unity-team/unity8/alt_nav_support/+merge/230782 Cimi
[08:45] <tsdgeos> https://code.launchpad.net/~nick-dedekind/unity8/prompt-surface-model/+merge/230813 Gerry
[08:46] <tsdgeos> https://code.launchpad.net/~mterry/unity8/interactive-while-locked/+merge/231253 me, haven't followed up yet
[08:46] <Saviq> tsdgeos, I'm not blaming you :)
[08:46] <tsdgeos> https://code.launchpad.net/~mterry/unity8/no-lock-during-call/+merge/227996 You
[08:46] <tsdgeos> Saviq: well you are suggesting me a behaviour change when i don't have that behaviour
[08:46] <Saviq> tsdgeos, just talking in general, I think there's no need for a Needs fixing vote when you're just seeing a conflict, is all
[08:47] <Saviq> tsdgeos, since then you need to take it back... dunno
[08:47] <tsdgeos> ok
[08:47] <tsdgeos> btw why is the unlocker so ugly now?
[08:47] <Saviq> tsdgeos, you mean it's pretty now?
[08:47] <Saviq> [...] and it might cause confusion that you're actually reviewing
[08:48] <tsdgeos> and besides being ugly is wrong
[08:48] <tsdgeos> says "Enter your PIN"
[08:48] <tsdgeos> when it's not my PIN
[08:49] <tsdgeos> Saviq: i'll stop doing conflict comments
[08:49] <tsdgeos> if you want
[08:49] <tsdgeos> i thought it was useful
[08:50] <Saviq> tsdgeos, *comments* are useful, sure
[08:51] <tsdgeos> ok
[08:51] <Saviq> tsdgeos, although I'd rather LP do them ;)
[08:51] <tsdgeos> ok
[08:51] <Saviq> dandrader, /build/buildd/unity8-8.00+14.10.20140825/tests/qmltests/Stages/tst_SurfaceContainer.qml: bad whitespace in line 144
[08:51] <Saviq> greyback, so, bad news redux
[08:52] <Saviq> greyback, we had to pull initial surface size, it (seldom, but still) caused deadlocks
[08:52] <dandrader> dang it
[08:52] <tsdgeos> Saviq: now serious, is the new locker considered to be more beatiful?
[08:52] <greyback> Saviq: feck
[08:53] <tsdgeos> that x in the middle of nowhere is totally weird
[08:53] <Saviq> greyback, check thread 9 http://paste.ubuntu.com/8117691/
[08:53] <Cimi> Saviq, so how about alt nav?
[08:53] <dandrader> Saviq, fixed
[08:53] <Cimi> Saviq, why do we need a shader first of all?
[08:53] <Cimi> Saviq, I'd like to understand which situation is broken for us now
[08:53] <Saviq> tsdgeos, that's the new design, yes
[08:54] <Saviq> tsdgeos, to be more in concert with the dialer
[08:54] <tsdgeos> makes my brain unhappy
[08:54] <tsdgeos> http://i.imgur.com/JORXscB.png
[08:54] <tsdgeos> lost X in the space
[08:55] <Saviq> tsdgeos, there's a corresponding ✓ when it's a SIM PIN
[08:55] <Saviq> tsdgeos, but for device PIN there's autoconfirm
[08:55] <Saviq> tsdgeos, and mzanetti put a greyed-out one in that case, but design was adamant that it shouldn't be there
[08:56] <Saviq> woohoo 5.5GB free on krillin
[08:56] <Saviq> that's much better
[08:57] <tsdgeos> Saviq: ok, more cases me and design disagree then :)
[08:58] <Cimi> tsdgeos, yup, not liking it
[08:59] <Cimi> tsdgeos, what is this X?
[08:59] <Saviq> tsdgeos, although I'm not sure the missymmetry itself was thought through
[08:59] <Saviq> Cimi, cancel
[08:59] <tsdgeos> it's design by discoverability
[08:59] <tsdgeos> you have no clue, click on it, and then you see what it is
[08:59] <tsdgeos> it's what i did :D
[09:00] <Cimi> Saviq, tsdgeos so it should appear when I actually start typing
[09:00] <Cimi> so I have a visual clue it must be to clear or delete the typed char
[09:00] <tsdgeos> Cimi: no, that is "Cancel last keypress" and does show on top when you actually start typing
[09:00] <tsdgeos> this is "cancel cancel"
[09:00] <tsdgeos> i.e. go back
[09:00] <Cimi> tsdgeos, clear all you mean
[09:00] <Cimi> ?
[09:00] <tsdgeos> no
[09:01] <tsdgeos> i mean go back
[09:01] <Cimi> go back where?
[09:01] <tsdgeos> to the locker locker
[09:01] <tsdgeos> instead of locker enterpin
[09:01] <Saviq> Cimi, a bit extreme, but conceivable http://imgur.com/Xezpv3B :P
[09:01] <tsdgeos> i.e. the round thing
[09:01] <Saviq> tsdgeos, welcome screen
[09:01] <Saviq> tsdgeos, greeter
[09:01] <tsdgeos> that thing
[09:02] <Cimi> let me setup a pin and see
[09:02] <tsdgeos> btw it's *not* a pin
[09:02] <tsdgeos> that's the other bug
[09:02] <tsdgeos> it's a passcode
[09:03] <Cimi> how do I add one?
[09:03] <Cimi> if I tap on security in system settings nothing happens
[09:03] <tsdgeos> yeah
[09:03] <tsdgeos> tap on the thing below
[09:03] <Cimi> ouch, tapping on "lock phone after 1 minute" reveals the passcode
[09:03] <Cimi> wtf
[09:03] <tsdgeos> yep
[09:04] <Cimi> I would never had guess that
[09:04] <Cimi> I thought it was to change the time
[09:04] <Cimi> filing a bug
[09:15] <Cimi> how do I screenshot?
[09:15] <Saviq> Cimi, phablet-screenshot
[09:16] <Saviq> tsdgeos, PIN vs. passcode is another one into the same bucket, kemmko was confident it should say PIN
[09:17] <tsdgeos> ok
[09:17] <tsdgeos> then make the system settings say ping
[09:17] <tsdgeos> not passcode
[09:17] <tsdgeos> you can't ask me for passcode in one place
[09:18] <tsdgeos> and pin in another
[09:18] <tsdgeos> i'll go crazy and return the phone
[09:19] <Cimi> the tool says FACTOR to resize the image, while is not a factor but the width
[09:19] <Saviq> tsdgeos, sure, that I agree with
[09:19] <Cimi> phablet-screenshot that is
[09:21] <Saviq> Cimi, huh?
[09:21] <Saviq> Cimi, don't think that option is used tbh
[09:25] <Cimi> https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings/+bug/1361127
[09:25] <Cimi> gonna file a suggestion for our lockscreen soon
[09:26] <tsdgeos> Saviq: so what's going to happen when i have a SIM PIN and a passcode?
[09:26] <tsdgeos> i get the enter PIN dialog twice in a row?
[09:26] <Saviq> tsdgeos, or even three times if you have two SIMs
[09:26] <Cimi> tsdgeos, at first boot, yes
[09:27] <Saviq> tsdgeos, but it will say "SIM PIN"
[09:27] <Saviq> tsdgeos, and ideally even the name you gave to that SIM
[09:27] <Cimi> then I suppose your sim is unlocked for the session
[09:27] <tsdgeos> ok
[09:27] <Saviq> yeah of course
[09:27] <Saviq> tsdgeos, Cimi, there's a twist... the X means "skip" in the case of a SIM PIN dialog :|
[09:28] <tsdgeos> well, it means cancel
[09:28] <tsdgeos> you can cancel sim pin
[09:28] <tsdgeos> but not unlock pin
[09:28] <Cimi> we should put it in the header
[09:28] <Cimi> a back button like in our UI
[09:30] <Saviq> tsdgeos, well, the result is different, with device PIN you're taken back to the lockscreen, with SIM PIN you're let through...
[09:30] <Saviq> tsdgeos, you and me know the difference, it's not common knowledge
[09:30] <tsdgeos> which would be pretty obvious if it said "Cancel" instead of "X"
[09:31] <Saviq> tsdgeos, IMO for SIM PIN it should say "Skip", not "Cancel", if it allows you to go through
[09:31] <tsdgeos> or that
[09:31] <tsdgeos> what's the package that gives me the apps scope?
[09:31] <tsdgeos> i can't seem to find it
[09:31] <Saviq> tsdgeos, unity-scope-click
[09:32] <tsdgeos> ah yes
[09:32] <tsdgeos> that thing that wants to install urfkill
[09:32] <tsdgeos> that's why i don't have it installed
[09:33] <tsdgeos> it's very strange, on the phone there's 3 icons from the click scope
[09:33] <tsdgeos> that don't work with the sourceSize Item i'm coding
[09:33] <tsdgeos> i don't see why
[09:34] <dandrader> greyback, I'm a bit confused about the structure of qtmir tests. They're all under "modules" and it's one directory per class.
[09:34] <dandrader> s/class/class under test
[09:34] <tsdgeos> obviously i don't get those on the desktop
[09:34] <tsdgeos> in case i thought it'd be easy to debug
[09:35] <dandrader> greyback, could we at least skip the "modules" subdir. It doesn't seem useful. at least as it is currently
[09:39] <tsdgeos> Saviq: do you know where's the image://theme code?
[09:39] <Saviq> tsdgeos, UITK
[09:39] <Saviq> tsdgeos, themeimageprovider
[09:40] <tsdgeos> ok
[09:40] <tsdgeos> tx
[09:40] <tsdgeos> looks like they have a bug :/
[09:40]  * tsdgeos checks
[09:41] <Wellark> Saviq: as long as this gets dealt with ASAP I'm fine: https://bugs.launchpad.net/unity8/+bug/1360703
[09:41] <Wellark> I will postpone the announcement of the API
[09:41] <Cimi> https://bugs.launchpad.net/unity8/+bug/1361132
[09:41] <Saviq> Wellark, I'm really not sure what's the rush?
[09:41] <Saviq> Wellark, if it's unity8's private plugin, and we're not using Ubuntu.Connectivity
[09:41] <Saviq> Wellark, what does that mean for you?
[09:43] <Wellark> Saviq: once the public plugin is installed on the system
[09:43] <Wellark> unity8 fails to load Shell.qml
[09:44] <Wellark> as the public path becomes before the private one
[09:44] <Wellark> when qmlengine is resolving it's plugin paths trying to find "Ubuntu.Connectivity"
[09:44] <Wellark> it takes the first one
[09:44] <Wellark> which is the public
[09:44] <Wellark> which does not provide "0.1"
[09:44] <Wellark> and fails
[09:44] <Wellark> and does not keep searching if it could find another "Ubuntu.Connectivity"
[09:44] <Wellark> that provides 0.1
[09:45] <Wellark> it's an import name clash
[09:45] <pstolowski> tsdgeos, hey, there's a conflict of your resetMeansCountChanged with my https://code.launchpad.net/~stolowski/unity-scopes-shell/favorite-scopes/+merge/230824
[09:45] <Wellark> Saviq: so as soon as qml-module-ubuntu-connectivity gets pulled to the image, unity8 stops working
[09:45] <Wellark> so, let's fix this before the package gets seede
[09:45] <Wellark> *seeded
[09:45] <pstolowski> tsdgeos, and i think that your change is not needed anymore; could you please take a look at my branch and confirm?
[09:45] <Cimi> Saviq, https://bugs.launchpad.net/unity8/+bug/1361114 wontfix?
[09:45] <Wellark> at it will get seeded as soon as somebody depends on it
[09:46] <tsdgeos> pstolowski: it is needed
[09:46] <Wellark> and dekko package is already working for the support
[09:46] <Wellark> actually, dekko will use the c++ binding, so we are good there
[09:46] <Cimi> Saviq, we should just say enter your code or sth else
[09:46] <Wellark> but really, this needs to be fixed
[09:46] <tsdgeos> pstolowski: writing why is needed...
[09:46] <Cimi> PIN is another thing
[09:46] <Saviq> Wellark, oh, that seems wrong, our private path should be first
[09:46] <pstolowski> tsdgeos, hmm, only if m_results is empty at the beginning of the mehtod
[09:46] <pstolowski> ?
[09:47] <tsdgeos> pstolowski: no, and in the bottom too
[09:47] <Wellark> Saviq: well, you can fix it right that. and hope no component inside unity8 will ever want to use the public module
[09:47] <tsdgeos> pstolowski: count is *our* property
[09:47] <tsdgeos> qabstractitemmodel knows nothing about it
[09:47] <Saviq> Wellark, sure, I agree we should rename it anyway, just didn't know that's the fallout
[09:47] <tsdgeos> so if you insert rows you have to say the count changed too
[09:47] <Wellark> Saviq: the real fix is to place the private unity modules inside Unity.Private. module import space
[09:47] <tsdgeos> pstolowski: another option is this
[09:47] <Saviq> Wellark, it should probably be Unity.Connectivity anyway
[09:48] <Saviq> Wellark, yeah, something like that
[09:48] <tsdgeos> pstolowski: http://paste.ubuntu.com/8139241/ in the constructor
[09:48] <Wellark> Unity.Private.Connectivity would do it just fine
[09:48] <Wellark> or even. Unity.Private.Ubuntu.Connectivity
[09:48] <Saviq> Wellark, they are installed in a private import path so I'm not sure prepending everything with Private is overly useful
[09:48] <greyback> dandrader: original idea was to distinguish the qml module tests from the QPA plugin tests
[09:48] <Saviq> Wellark, "Unity" should be private already
[09:48] <pstolowski> tsdgeos, ah, makes sense then. ok, i'll keep Q_EMIT at the bottom
[09:49] <tsdgeos> pstolowski: and in the if branch
[09:49] <Saviq> Wellark, anything that's public should be Ubuntu
[09:49] <Wellark> Saviq: no, we also have unity API's coming from unity-api-team
[09:49] <pstolowski> tsdgeos, good point!
[09:49] <Wellark> Saviq: like Unity.Action
[09:49] <Wellark> which is a public API
[09:49] <Saviq> Wellark, well, that should be Ubuntu IMO
[09:49] <Saviq> Wellark, which, btw, conflicts with Ubuntu.Components' Action already
[09:50] <Saviq> Wellark, IMO things should integrate with Ubuntu, not with Unity
[09:50] <Wellark> Saviq: no it does not. Ubuntu.Component action actually inherit Unity.Action
[09:50] <Saviq> Wellark, then Unity.Action shouldn't be public
[09:50] <dandrader> greyback, ah, ok
[09:50] <Wellark> Saviq: ok, we need to have a meeting about module namespacing after the RTM.
[09:50] <Wellark> it's a wild west right now
[09:50] <Saviq> Wellark, yeah we do ;)
[09:51] <greyback> dandrader: we just don't have QPA tests yet. There is that MR by racarr though
[09:51] <Saviq> Wellark, I'll prep a fix and land it asap
[09:52] <Wellark> Saviq: thanks!
[09:56] <pstolowski> tsdgeos, could you ack this change? https://code.launchpad.net/~stolowski/unity-scopes-shell/favorite-scopes/+merge/232050 (it was already reviewed by Saviq)
[09:56] <pstolowski> Saviq, ^ i had to re-submit that MP to resolve conflicts with tsdgeos' branch
[09:57] <tsdgeos> pstolowski: r147 has lots of diff changes beside the emits?¿
[09:59] <pstolowski> hmm
[10:02] <pstolowski> tsdgeos, these came through your branch (trunk changes), apparently mine branch was behind trunk. the diff looks fine
[10:03] <tsdgeos> pstolowski: ah, i see
[10:04] <tsdgeos> pstolowski: approved
[10:04] <pstolowski> tsdgeos, thanks
[10:06] <Wellark> Saviq: the automatic unlocking is causing troubles
[10:06] <Wellark> Saviq: do you have any unity8 brances going in that could carry a oneliner to disable it for now?
[10:11] <Wellark> Saviq: https://code.launchpad.net/~unity-api-team/unity8/disable_automatic_pin_unlocking/+merge/232054
[10:15] <Saviq> Wellark, why is it causing troubles?
[10:16] <Saviq> mzanetti, greyback, tsdgeos, would like your opinion on bug #1361149
[10:16] <Wellark> Saviq: it was prematurely landed
[10:16] <Saviq> dandrader, ↑↑
[10:16] <Saviq> Wellark, yeah, but while the interface's not there it shouldn't matter?
[10:16] <Wellark> Saviq: the interface is there
[10:16] <Saviq> Wellark, or are you saying that you're adding the interface but it's not good enough yet?
[10:17] <Wellark> and they are not working properly together
[10:17] <Saviq> Wellark, "is there" or "will be"?
[10:17] <tsdgeos> Saviq: no opinion on what should take precedence, imho we should simply not collide and that's it :D
[10:17] <Wellark> and the idea was to land the dual sim unlock dialog with that call in unity8 together so that they are also tested together
[10:17] <Wellark> Saviq: the dbus interface is there
[10:18] <Saviq> Wellark, ok, so comm fail
[10:18] <Saviq> Wellark, I'll squash that change into my plugin rename
[10:18] <Wellark> Saviq: ok, thanks! as long as it lands today
[10:19] <Wellark> as I'm going to get a lot of heat as it seems indicator-network is totally broken atm :)
[10:19] <mzanetti> Saviq: yeah... I guess that's valid
[10:19] <mzanetti> but didn't do extensive research :)
[10:20] <Saviq> tsdgeos, it *could* give us a way to override system-wide imports for $reason, too
[10:20] <tsdgeos> Saviq: i don't see $reason
[10:20] <Saviq> tsdgeos, while I know we shouldn't have anything like that, having a way out seems useful
[10:20] <tsdgeos> everything there would be bad
[10:20] <Saviq> tsdgeos, I know
[10:23] <tsdgeos> Cimi: the two comments you did in https://code.launchpad.net/~aacid/unity8/croppedImageMinimumSourceSize/+merge/232043 are the ones for unwanted space changes?
[10:23] <tsdgeos> the in line comment thing in launchpad is still a bit confusing sometimes
[10:23] <Saviq> Wellark, https://code.launchpad.net/~saviq/unity8/rename-connectivity/+merge/232058
[10:24] <Saviq> mzanetti, can you ↑
[10:24] <mzanetti> sure
[10:25] <mzanetti> Saviq: why are you disabling the unlockallmodems?
[10:27] <dandrader> Saviq, what did I do?
[10:28] <tsdgeos> Saviq: ok, the sourceSize texture image reduction is up for review, unfortunately i stumbled upon a SDK bug, so it's not easy to land
[10:30] <Saviq> mzanetti, because that doesn't work yet
[10:30] <Wellark> mzanetti: it's because https://code.launchpad.net/~unity-api-team/unity8/disable_automatic_pin_unlocking/+merge/232054
[10:30] <Saviq> mzanetti, at Wellark's request
[10:30] <Saviq> mzanetti, undoing the Unity qmltypes change now...
[10:34] <Saviq> Wellark, btw, put it in silo 4 already, will release asap
[10:34] <Saviq> mzanetti, there's a new commit from dandrader on the lifecycle branch if you could have a look
[10:35] <tsdgeos> Saviq: is it you that wrote "scrolling up in a scope causes a lot of clipping areas to kick in, are they all needed? (QSG_VISUALIZE=clip)" ?
[10:36] <greyback> tsdgeos: was me
[10:36] <tsdgeos> damned colors :D
[10:36] <tsdgeos> greyback: i can't see that many
[10:36] <greyback> tsdgeos: I'm unsure of the impact of all those clipping areas. I'm told some GPUs can deal with it easy, some not
[10:36] <tsdgeos> otoh maybe i'm misinterpretting the thing
[10:37] <greyback> tsdgeos: the more reddish, the more overlapping clipping areas
[10:37] <tsdgeos> greyback: i only see 1 clipping are to kick in on scroll
[10:37] <tsdgeos> which ones did you see?
[10:37] <tsdgeos> are -> area
[10:38] <greyback> tsdgeos: gimme a minute, I'll try on the phone, I can't recall clearly any more
[10:40] <greyback> tsdgeos:  initctl set-env --global QSG_VISUALIZE=clip <- you use this so it turned on for both dash & shell?
[10:41] <tsdgeos> greyback: i'm only having a look at the dash
[10:41] <tsdgeos> greyback: and only on the desktop, didn't think clip areas would be different on the pohne
[10:43] <greyback> tsdgeos: ah ok. Well on phone, there's a red rectangle being shown always under the panel (might be part of shell). Then if I scroll the dash, I see up to 2 levels of red - mostly when scrolling it up
[10:44] <tsdgeos> ok, two levels
[10:44] <tsdgeos> "lot of clipping areas" seemeed like 10 to me
[10:45] <tsdgeos> well that's lvwph
[10:45] <tsdgeos> can't make the header come back without clipping the other stuff
[10:46] <greyback> tsdgeos: sure I know some clipping has to be done, but wanted to question the 2 levels
[10:47] <greyback> of all the suggestions I made, it would be one I'm least expecting a big improvement from though
[10:49] <tsdgeos> now when changing from scope to scope
[10:49] <tsdgeos> there's really weird stuff happening
[10:55] <Saviq> /food
[11:05] <facundobatista> Holas
[11:07] <Cimi> tsdgeos, we need to limit whitespace changes
[11:07] <Cimi> tsdgeos, I thought I pressed enter before :)
[11:07] <Cimi> I left the reply on the entry box
[11:08] <tsdgeos> Cimi: yes yes, i am asking if the two comments are just about the whitespace changes or if there's something esle
[11:08] <tsdgeos> find it hard sometimes to find all the inline comments
[11:08] <Cimi> tsdgeos, just whitespaces
[11:08] <tsdgeos> oki :)
[11:08] <Cimi> tsdgeos, grep for Cimi on the launchpad
[11:08] <tsdgeos> sure
[11:08] <Cimi> after showing diff comments
[11:08] <tsdgeos> but then there's various revisions
[11:08] <tsdgeos> with the combo
[11:08] <Cimi> yeah too
[11:08] <Cimi> anyway
[11:08] <tsdgeos> and can never be sure if i got them all easily
[11:09] <Cimi> was thinking if we can avoid two boolean for the cropped image component
[11:09] <Cimi> maybe not though
[11:09] <Cimi> only thing we might do is having a status instead two boolean
[11:10] <Cimi> "none" "processing" "processed"
[11:10]  * Cimi wish we could have enums in qml
[11:13] <Cimi> tsdgeos, ok when you comment for conflicts then you abstain
[11:13] <Cimi> tsdgeos, please remark it to unity-ui-team?
[11:14] <tsdgeos> Cimi: don't worry i won't do needs-fixing anymore
[11:14] <Cimi> tsdgeos, your needs fixing is fine
[11:14] <Cimi> tsdgeos, as long as later we see it needs review
[11:29] <Cimi> Saviq, yeah I think way to shade the color correctly is converting to a different colorspace
[11:31] <Cimi> or actually, from wikipedia "new intensity = current intensity * (1 - shade factor)"
[11:31] <Cimi> intensity is each R G B value
[11:32] <Cimi> so color.r = color.r * (1 - shadeFactor)
[11:32] <Cimi> we should try to see how shadeFactor relates to changes in V or L for HSV and HSL colorspaces
[11:33] <Cimi> I guess I could try a test app for that
[12:05] <Saviq> greyback, so, any idea about the deadlock?
[12:06] <greyback> Saviq: not a clue. It's not the first time I use a blockingqueuedconnection
[12:06] <greyback> it's as if the receiving thread event loop isn't spinning, which can't be the case
[12:06] <Saviq> greyback, yeah, and it was quite a difficult thing to pinpoint, like say it was happening reliably for 5 ap runs of a certain test
[12:07] <Saviq> greyback, and then suddenly everything became fine
[12:07] <greyback> hmm yeah, as I'd tested it by hand and never hit it
[12:07] <Saviq> greyback, so race
[12:07] <Saviq> greyback, I wonder if autopilot has anything to do with it
[12:08] <Saviq> greyback, like if introspection could cause it to go into the deadlock
[12:08] <greyback> only thing I can think of is AP sending sigstop to u8 at critical time, just while u8 is shutting down and hasn't told Mir to shut down yet
[12:08] <Saviq> greyback, no, it's not on shutdown
[12:08] <greyback> so u8 event loop stopped, while Mir still running
[12:08] <Saviq> greyback, and ap never sending sigstop, only sigterm/sigkill through upstart
[12:09] <greyback> greyback.ideas.pop()
[12:09] <greyback> err, sigterm I meant
[12:09] <Saviq> greyback, but in any case, this was just happening in the middle of a test, not at the end of it
[12:09] <greyback> well I'll keep digging
[12:10] <greyback> but the change isn't a critical feature, so might postpone it a bit
[12:10] <Saviq> yeah, if it doesn't have to do with the wrong surface size on emu / restart, we should
[12:10] <Saviq> (postpone)
[12:11] <greyback> I'm certain that can be fixed in another way, so I don't see this blocking it
[12:11] <greyback> but the visual glitch on startup makes me sad
[12:24] <Cimi> Saviq, bzr branch lp:~cimi/+junk/color-shades
[12:25] <Cimi> qmlscene ColorShades.qml
[12:26] <Cimi> here we see the limit of the RGB intensity play... if you cap the intensity you should reduce the saturation of the other color components imho
[12:26] <Saviq> Cimi, yeah, and where's my shader code?
[12:26] <Cimi> Saviq, you can do shader code by converting to hsv
[12:26] <Cimi> Saviq, but I'd much rather do in rgb
[12:27] <Saviq> Cimi, *I* can't
[12:27] <Cimi> Saviq, thus I started this playground
[12:27] <Cimi> Saviq, why you can't? it's just expensive
[12:27] <Cimi> we don't want that, I agree
[12:27] <Saviq> Cimi, I mean *I*, *Saviq* cannot
[12:27] <Cimi> Saviq, what you cannot?
[12:28] <Saviq> Cimi, do what you said in shader code :P
[12:28] <Saviq> Cimi, and yes, would not, either
[12:28] <Saviq> Cimi, converting every pixel to hsl/v really doesn't seem like the right thing to do
[12:29] <Cimi> Saviq, http://gamedev.stackexchange.com/questions/28782/hue-saturation-brightness-contrast-effect-in-hlsl
[12:30] <Saviq> Cimi, by "give me the shader code" I really meant "give me the shader code"
[12:30] <Cimi> Saviq, ok
[12:30] <Cimi> Saviq, first we need to find algorithm for rgb shading
[12:30] <Saviq> Cimi, it doesn't make sense for us both chasing this
[12:30] <Cimi> Saviq, I am on this rgb shading
[12:30] <Cimi> without conversion
[12:31] <Cimi> otherwise plain semitransparent bright line
[12:32] <Saviq> Cimi, but you really should find someone who knows about glsl rather than trying to come up with the algorithm yourself
[12:33] <Cimi> Saviq, glsl isn't like in rgb?
[12:33] <Saviq> Cimi, there's better ways to do things in shader code than just multiplying r,g,b values or something
[12:33] <Cimi> I see
[12:33] <Saviq> Cimi, faster, more convenient
[12:34] <Cimi> I will study shaders then
[12:34] <Saviq> Cimi, no
[12:34] <Saviq> Cimi, what part of "find someone who knows about glsl" did you not get?
[12:34] <Cimi> Saviq, I am way less scared to study shaders than C++
[12:35] <Cimi> it's math after all :)
[12:35] <Cimi> at least sth I studied in uni
[12:35] <Saviq> Cimi, you might be less scared
[12:35] <Saviq> Cimi, but we still do not have time right now for you to be doing it
[12:35] <Cimi> k
[12:43] <Saviq> dandrader, do we really consider lifecycle branches fixing bug #1359819 ?
[12:43] <Saviq> dandrader, it feels like we should only mark ↑ fixed after we have the desaturation and things
[12:53] <dandrader> Saviq, I think it does fix as the report is not asking for a specific splash screen. It just asks for something instead of that black flicker
[12:53] <dandrader> Saviq, but either way works for me
[12:55] <Wellark> Saviq: FYI: bug #1361074
[12:55] <Wellark> I will get that done this week
[12:56] <Wellark> we just need to coordinate the landing to the RTM image once we land to trunks
[12:57] <Wellark> I will also debug and fix bug #1336675 on the same go
[12:58] <Saviq> Wellark, I'm not doing 1:1 RTM landings, so yeah, just let me know when
[12:59] <Wellark> Saviq: ack.
[13:03] <Saviq> mzanetti, pushed a commit to rename-connectivity, please re-review
[13:09] <Saviq> Cimi, settings re-reviewed, not complete, will complete after you've replied
[13:10] <Cimi> Saviq, yes, I would have them separate for the overview cases
[13:11] <Saviq> Cimi, but why?
[13:11] <Cimi> does it hurts?
[13:11] <Saviq> Cimi, yes, there's like 6 or 7 places where they're duplicate
[13:11] <Cimi> anyway will be back in one hour, starving -> pasta time
[13:11] <Saviq> Cimi, why wouldn't overview use the same SubPage mechanism?
[13:12] <Saviq> Cimi, sure, it might not ever use settings, so waht
[13:12] <Saviq> what
[13:20] <dandrader> greyback, are qtmir tests run automatically by CI?
[13:21] <cwayne> Saviq: is there any way to trim down silo 17 to land some stuff faster?
[13:21] <greyback> dandrader: I think yes, as they're run during package build
[13:21] <Saviq> cwayne, it should be ready to land tomorrow latest
[13:24] <dandrader> greyback, hmm, so all tests run by "make check" should not do any fancy thing such as creating a window etc (like unity8's qmluitests)
[13:25] <greyback> dandrader: right, else they'd fail on CI
[13:25] <greyback> until we get test harness in place for that
[13:25] <greyback> which is a longer term TODO for me
[13:25] <greyback> as I want to write a bunch of integration tests for qtmir
[13:26] <dandrader> greyback, ok. so I will sitk with a strict unit test then
[13:26] <dandrader> stick
[13:34] <Saviq> mzanetti, that test failure is what I just fixed
[13:34] <Saviq> re: rename-connectivity
[13:34] <mzanetti> ah, I c
[13:34] <Saviq> is what I asked you to re-review
[13:40] <tsdgeos> pstolowski: should i reject https://code.launchpad.net/~aacid/unity-scopes-shell/resetMeansCountChanged then?
[13:41] <kgunn> : ) i see lifecycle still didn't make it yet
[13:42] <pstolowski> tsdgeos, i don't think so, i merged it into my branch, but set yours as a prerequisite
[13:42] <tsdgeos> pstolowski: ah, ok
[14:04] <mhall119> thostr_: ping
[14:05] <kgunn> Saviq: are we testing silo4 ?
[14:06] <Saviq> kgunn, oh it built
[14:06] <Saviq> kgunn, it's tested, I only added a small test fix
[14:07] <Saviq> mzanetti, can I get ACK on https://code.launchpad.net/~saviq/unity8/rename-connectivity/+merge/232058 then?
[14:07] <mzanetti> Saviq: wanted to wait on jenkins... but if its urgent, I guess its fine
[14:08] <Saviq> mzanetti, you could always just test locally ;)
[14:08] <mzanetti> Saviq: true. but didn't think this is urgent
[14:10] <tsdgeos> so it's interesting
[14:10] <tsdgeos> i removed the UbuntuShape from teh dash art
[14:10] <tsdgeos> and i can still scrooll and see icons poping up later
[14:10] <mzanetti> tsdgeos: yeah, its the async loading
[14:11] <tsdgeos> mzanetti: async loading just means its async, not "make it slow"
[14:11] <tsdgeos> ;)
[14:11] <mzanetti> tsdgeos: it kinda does
[14:11] <mzanetti> in some circumstances
[14:11] <tsdgeos> if you see it happening it's because it's slow
[14:11] <tsdgeos> not because it's async
[14:12] <mzanetti> tsdgeos: in that game I'm writing for instance, I create a bunch of enemies. having their images load sync causes the ui to freeze for ~0.25s
[14:12] <mzanetti> tsdgeos: having the images load async causes some enemies only to load after >2secs
[14:13] <tsdgeos> well, that's a bug then ;)
[14:13] <tsdgeos> i see no reason for that to happe
[14:13] <tsdgeos> n
[14:14] <mzanetti> different priorities/queuing
[14:14] <tsdgeos> not buying it :)
[14:18] <tsdgeos> i mean not saying you're liying
[14:18] <tsdgeos> just that i don't see why making it async should make it 10 times slower
[14:19] <mzanetti> tsdgeos: well, the total time of the operation might be the same, just happening "10 times later"
[14:19] <mzanetti> because there's other, more important things to do before doing the queued async things
[14:19] <Saviq> tsdgeos, it might be they get scheduled for later as they're async
[14:19] <tsdgeos> well if they get schedule for later
[14:19] <tsdgeos> is because there's something else to schedule
[14:19] <mzanetti> right
[14:20] <tsdgeos> that something else is not being scehduled then on those 0.25 secs?
[14:20] <mzanetti> but visually its not necessarily the order we want
[14:20] <tsdgeos> where did it come from?
[14:20] <Saviq> tsdgeos, for scrolling in dash though, we probably don't have enough cacheBuffer is one, two is that we should not be destroying the category delegates (or any delegates even?) until we "unfocus" the scope
[14:20] <mzanetti> well, in my example the first enemies start running, which consumes some juice
[14:20] <Saviq> tsdgeos, as we discussed before, I think we should commit memory to the scope you're looking at
[14:21] <Saviq> tsdgeos, only defer loading images until they're not on screen to reduce data usage (but for apps we should probably be more aggressive even and just load them all and keep them in memory always)
[14:21] <mzanetti> and in the scope example I guess the queing of more async operations already slows down the execution of the queued ones, besides other things
[14:22] <Saviq> aaand then if any provider comes into play, only one image is loaded at a time....
[14:23] <tsdgeos> which doesn't make any sense
[14:24] <mhall119> is there any documentation on customizing a scope's header?
[14:24] <tsdgeos> they have a threaded flag, no?
[14:24] <Saviq> tsdgeos, yeah
[14:24] <Saviq> mhall119, check out http://developer.ubuntu.com/api/devel/ubuntu-14.10/cplusplus/unity-scopes/index.html#deployment
[14:24] <tsdgeos> but it's only to not block the main thread
[14:25] <Saviq> mhall119, not everything's implemented yet, but real close
[14:25] <tsdgeos> not to run various at the same time
[14:25] <Saviq> mhall119, i.e. it's in silo 17 already, just we need to tweak a few things and land it
[14:26] <mhall119> Saviq: ah,thanks, didn't know it was in the .ini file
[14:33] <mzanetti> dandrader: hey, do you have an idea why the OSK won't work with run_on_device?
[14:40] <dandrader> mzanetti, let me read that script. I can't remember the last time I used it
[14:40] <dandrader> mzanetti, it was working fine before qtcomp?
[14:41] <mzanetti> dandrader: yes, iirc
[14:42] <dandrader> mzanetti, iinm, maliit-server should be started after unity8. not sure if it's happening there
[14:43] <mzanetti> dandrader: ah, probably doesn't... but then, I guess that's a bug in maliit's upstart script
[14:44] <Saviq> mzanetti, dandrader yes it is
[14:44] <mzanetti> dandrader: hmm... reading /usr/share/upstart/sessions/maliit-server.conf everything looks fine
[14:45] <thostr_> mhall119: pong
[14:46] <dandrader> mzanetti, Saviq, http://paste.ubuntu.com/8141277/
[14:46] <mhall119> thostr_: I was going to get an update on the work to allow running scopes form Qtc
[14:46] <dandrader> to me it reads like "start maliit-server first, then unity8"
[14:47] <larsu> QT += svg
[14:47] <mhall119> zbenjamin updated me on some of it, that marcustomlinson has code ready to land which I think enabled the debug mode for scopes
[14:47] <larsu> Project ERROR: Unknown module(s) in QT: svg
[14:47] <Saviq> dandrader, the "start unity8" is there for going back to the system wide unity8
[14:47] <mhall119> but he's still waiting on some dash work to allow loading them from Qtc
[14:47] <larsu> anyone know what happened to the svg module? ^^
[14:47] <Saviq> dandrader, the maliit- ones shouldn't be necessary really
[14:47] <Saviq> dandrader, but yeah, that looks wrong
[14:47] <thostr_> mhall119: we got all the code... we "just" need to get it landed... fighting this right now
[14:48] <mhall119> thostr_: even the dash stuff that Saviq and tedg are working on?
[14:48] <dandrader> Saviq, I would expect line 2 to come after line 3
[14:48] <dandrader> Saviq, actually, nevermind
[14:48] <thostr_> mhall119: there are two silo's full of changes
[14:48] <dandrader> Saviq, as script will be stuck on line 3 until unity8 quits, right?
[14:49] <Saviq> dandrader, yes
[14:49] <thostr_> mhall119: but we're having build failures we don't see locally...
[14:49] <mhall119> thostr_: ok, thanks for the update
[14:49] <Saviq> dandrader, but that's when maliit shouldn't be running any more anyway
[14:49] <Saviq> dandrader, that's why I'm saying line 2 and 4 should not be needed any more
[14:49] <dandrader> Saviq, run.sh summons maliit somehow?
[14:50] <Saviq> dandrader, run.sh runs unity8 with upstart
[14:50] <Saviq> dandrader, and maliit starts on unity8 started
[14:51] <tsdgeos> larsu: you don't have it installed?
[14:51] <dandrader> Saviq, ah ok. then removing lines 2 and 4 should fix it
[14:51] <dandrader> indeed
[14:51] <Saviq> dandrader, shouldn't really fix it, it actually shouldn't matter ;)
[14:52] <Saviq> dandrader, as maliit should've started and stopped itself during line 3 anyway
[14:52] <Saviq> dandrader, ah but maybe
[14:52] <Saviq> dandrader, the start actually makes it go into a broken loop
[14:52] <Saviq> dandrader, and then it doesn't get the updated env when unity8 starts again
[15:00] <larsu> tsdgeos: oops you're right, the -dev was missing
[15:00] <larsu> thanks
[15:00] <tsdgeos> larsu: easy one :)
[15:01] <tedg> Saviq, Random though, when I process a scope:// URI do you need me to request a focus for the dash?
[15:01] <tedg> thought
[15:01] <Saviq> tedg, yes
[15:02] <tedg> K
[15:06] <Saviq> dandrader, mzanetti, btw, I've a branch lp:~saviq/unity8/tweak-runscript that does a thing or two to try and make the run scripts behave again
[15:06] <Saviq> but didn't finish it
[15:07] <mzanetti> Saviq: ah ok... cool. I volunteer to review when you finish it *hint* ;)
[15:08] <dandrader> :)
[15:10] <Saviq> mzanetti, seems dandrader is interested to take over, I didn't have time to investigate why it didn't work on device ;)
[15:11] <mzanetti> ah, great too
[15:12] <Saviq> lol
[15:12] <dandrader> 😒
[16:12] <Cimi> Saviq, you ask me to reinitialize initialIndex
[16:12] <Cimi> Saviq, but this is a binding from the Loader, it will break the binding
[16:13] <Saviq> Cimi, and?
[16:13] <Saviq> Cimi, if it switched to the initialScope, it should not switch any more
[16:13] <Saviq> Cimi, the binding makes sense in case it changes outside still
[16:13] <Saviq> Cimi, but once it switched, there's no point
[16:14] <Cimi> Saviq, so it should not be a binding from the loader
[16:14] <Cimi> I should just copy the value over, no?
[16:14] <Saviq> Cimi, no, it can be a loader
[16:15] <Saviq> erm
[16:15] <Saviq> binding
[16:15] <Saviq> Cimi, the thing that breaks the binding is when the onCount kicks in
[16:15] <Saviq> Cimi, in case the original value still changes between onLoaded and onCountChanged
[16:15] <Saviq> Cimi, you want the binding
[16:34] <Saviq> tedg, do we want a bug to track scope:// progress?
[16:35] <tedg> Saviq, Uhm, okay. I've got a post-it, which is enough for me, but if we need more visibility that's fine.
[16:41] <Cimi> Saviq, currently preview and settings tests fail moving open inside onLoaded...
[16:41] <Cimi> trying debugging
[16:42] <Cimi> that's why I am quiet
[17:00] <Cimi> Saviq, that initialIndex change messes up things
[17:00] <Cimi> don't ask me why
[17:00] <Cimi> maybe because the binding breaks
[17:01] <Cimi> just fixed, I like ideas flowing when I speak
[17:02] <Saviq> Cimi, you need a #Cimi channel ;P
[17:02] <Cimi> Saviq, good idea
[17:02] <Saviq> more tomorrow o/
[17:03] <Cimi> someone to join my channel pls
[17:03] <Cimi> Saviq, pa pa
[17:06] <Cimi> Saviq, pushed and fixed
[17:06] <Cimi> (opposite)
[17:11] <larsu> Saviq: finally got this finished today. Fixed the lookup-bug as well. Review is appreciated: https://code.launchpad.net/~larsu/ubuntu-ui-toolkit/custom-icon-lookup/+merge/232115
[18:36] <mzanetti> tedg: what was the reason again why the launcher's dbus interface needs a countVisible property instead of just displaying everything > 0?
[18:37] <tedg> mzanetti, So that it can have negative counts. For instance temperature.
[18:37] <mzanetti> ah right... that was it
[18:37] <mzanetti> thanks
[20:06] <Saviq> tedg, ah, the long-promised bug #1361349
[20:07] <tedg> Saviq, Are you going to put bug tasks there for adding the FD.o interface in dash, or has that landed?
[20:08] <Saviq> tedg, right, lemme
[20:09] <Saviq> tedg, done
[20:10] <tedg> Saviq, Actually, let's leave the url-dispatcher in that file.
[20:10] <tedg> Saviq, I'll just custom handle the unity8-dash part, then you can configure other URLs if needed.
[20:11] <tedg> url-dispatcher file in that MR.
[20:11] <tedg> What I meant :-)
[20:12] <Saviq> tedg, ah ok, can you comment on that then?
[20:12] <tedg> Sure
[20:15] <tedg> Saviq, I expect that branch to work, though it needs tests. If you guys want to play with it.
[20:16] <Saviq> tedg, awesome, I know Ben will be thankful