[04:20] <greyback> morning!
[06:36] <Mirv> Trevinho: morning! I just filed https://bugs.launchpad.net/unity/+bug/1211174 which is blocking releasing at the moment, can you make any sense of it?
[06:36] <Mirv> andyrock doesn't seem to be here yet
[06:39] <Mirv> not sure yet if it's something from the unity stack or if something from the platform stack (where the failing test so far was run) could cause it
[07:02] <jamesh> hi sil2100
[07:04] <mzanetti> good morning!
[07:06] <mzanetti> Saviq: hi
[07:06] <Saviq> mzanetti, mornin'
[07:06] <mzanetti> Saviq: any updates I should have?
[07:07] <Saviq> mzanetti, nothing major, only thing I think is that Rick has set our priorities for August (see ubuntu-engineering@)
[07:07] <Saviq> mzanetti, so we'll need to potentially reshuffle the work and help wherever needed to reach that
[07:08] <mzanetti> ok
[07:08]  * mzanetti reads mails
[07:08] <mzanetti> Saviq: progress on application management?
[07:08] <Saviq> mzanetti, there is
[07:09] <mzanetti> are we using mir on the phone yet?
[07:09] <Saviq> mzanetti, not by default, no
[07:09] <Saviq> mzanetti, we're hoping for the end of the week
[07:09] <mzanetti> nice
[07:10] <mzanetti> I've seen dednick workarounded the CPU battery draining issue
[07:10] <mzanetti> makes me happy :)
[07:12] <sil2100> jamesh: hi! lucene++ is waiting for sponsoring, I think someone should pick it up soon
[07:12] <sil2100> jamesh: I'll poke the patch pilot as well
[07:12] <Saviq> mzanetti, yeah, unfortunately a temporary and short-lived solution
[07:12] <mzanetti> Saviq: who's the man for the network indicator service? isn't that larsu?
[07:12] <mzanetti> maybe we should subscribe him to the bug too
[07:13] <Saviq> mzanetti, it's not a service issue
[07:13] <Saviq> mzanetti, it's a generic glib vs. Qt one
[07:13] <mzanetti> well, it seems to crash
[07:14] <jamesh> sil2100: okay, thanks
[07:15] <didrocks> sil2100: I think jamesh has other requests, I asked him to wait for you being back :)
[07:15] <jamesh> the lucene++ one is the main one, so I can clear the merge request queue
[07:16] <Saviq> mzanetti, ah, that's the "wrong" indicator backend anyway
[07:16] <Saviq> mzanetti, it's chewie-client and not indicator-network that's used, still
[07:16] <sil2100> jamesh: \o/ what's the other request? I'm back from holidays now so ready for action
[07:17] <sil2100> jamesh: btw. did you send me an e-mail with those media-scanner branches?
[07:17] <jamesh> sil2100: I may need a little more help once I've got everything merged and building in Jenkins
[07:17] <sil2100> jamesh: or is it just one branch right now?
[07:17] <mzanetti> Saviq: any pointers where to start fixing this one? https://bugs.launchpad.net/ubuntu-ux/+bug/1210200
[07:17] <sil2100> Ok
[07:18] <Saviq> mzanetti, with Mir
[07:18] <Saviq> mzanetti, shell is always just a single surface currently, so there's no way to composite them in the right  order yet
[07:19] <Saviq> mzanetti, although reaching for the launcher should dismiss the keyboard anyway
[07:19] <jamesh> sil2100: https://code.launchpad.net/hollywood/+activereviews has all the pending work.  The boost-fixes branch is probably the easiest one to do a test build against, if that's what you're after.
[07:19] <mzanetti> Saviq: should it?... not sure about that
[07:19] <mzanetti> Saviq: I wouldn't say so
[07:19] <jamesh> sil2100: they all extend the changes in the saucy-fixes branch
[07:19] <Saviq> mzanetti, add ubuntu-ux to the bug, then
[07:19] <Saviq> mzanetti, I think that's what I heard - and it kinda makes sense
[07:20] <Saviq> mzanetti, if you're going for the launcher, most of the time you'll focus another app, so OSK is out of context anyway
[07:45] <dednick> larsu: ping
[07:46] <mzanetti> MacSlow: veebers: my X crashed...
[07:46] <mzanetti> anyways, I think we were done, right?
[07:46] <MacSlow> mzanetti, yup
[07:46] <veebers> mzanetti: d'oh :-\ You didn't miss much, yeah was jsut the wrapup
[07:47] <larsu> dednick: morning
[07:52] <dednick> larsu: good morning!
[07:54] <dednick> larsu: i've proposed a couple of branches to qmenu/unitymenumodel on friday. Has to do with some leaking qobjects caused by glib callbacks issueing calls directly to qt.
[07:54] <larsu> dednick: awesome, I'll have a look in a bit. I fixed the action handling and added the parameter
[07:55] <larsu> dednick: ooh, but I didn't push it yet. Will do now
[07:55] <dednick> larsu: cool. thanks, i'll take a look at that and update unity8 to handle.
[07:56] <larsu> dednick: only use model.action.activate in menu items with a "x-canonical-type". For the normal ones, just call model.activate(). That will handle the parameter for you if the menu item has a target set
[07:58] <dednick> larsu: i'd much prefer if we can always using the action.
[08:01] <larsu> dednick: why?
[08:01] <dednick> larsu: we don't pass the root model around in qml, just the row data. so we don't have access to the model.activate function from outside the list
[08:02] <larsu> model.activate is accessible in every delegate, no?
[08:03] <larsu> there shouldn't be any reason why the menu item components need access to the root model
[08:04] <dednick> larsu: larsu because then they need to know about their own index within the model and such.
[08:05] <dednick> larsu: actually, i may change how they call activate
[08:05] <larsu> dednick: I don't understand. Are you doing something substantailly different from examples/unitymenumodel.qml?
[08:05] <dednick> might be better to signal value changes back to the delegate and let it call activate.
[08:05] <dednick> larsu: it's a hell of a lot bigger. has to be much more modular.
[08:06] <larsu> dednick: of course. I mean structurally. The components inside the delegates can always access all roles of its row, can't they?
[08:07] <larsu> and they should always have the ListView attached property
[08:07] <dednick> larsu: the delegates can, but the delegates arent the menu items.
[08:07] <dednick> larsu: nevermind. i'm going to change it.
[08:08] <dednick> i think it needs to change anyway.
[08:08] <larsu> hm, okay :)
[08:19] <dednick> larsu: actually had a q about thte x-canonical-type. there are some menus (eg mute) which don't set the type [to switch] it but have a bool state parameter. Should i be parsing the type in this case to know it's checkable?
[08:20] <dednick> *parsing the state type
[08:20] <dednick> larsu: unity7 is just a checkable menu type, but in unity8 i'm guessing we want a switch.
[08:25] <larsu> dednick: ah, right. I should be exporting that through the role, you shouldn't need to parse the state
[08:26] <dednick> larsu: ok, so it'll always be in x-canonical-type?
[08:26] <larsu> dednick: thinking about that right now
[08:27] <larsu> dednick: it's not really in the implementation, because x-canonical-type is something we added on top of gmenumodel
[08:27] <larsu> where checks and radios are in gmenumodel itself
[08:27] <larsu> but this will lead to two type systems for you...
[08:27] <larsu> kinda weird
[08:28] <dednick> larsu: hm. the radio is an intersting one.
[08:28] <larsu> dednick: is it easier for you if I consolidate everything into x-canonical-type?
[08:28] <larsu> dednick: usually, checks/radios are handled by the same widget as normal menu items
[08:28] <larsu> i.e., we just draw a check or a radio thing in the margin if gtkmenutracker tells us to
[08:29] <dednick> larsu: i so have a solution in place for the parsing type.
[08:29] <larsu> parsing type?
[08:30] <dednick> larsu: just checking if it's a boolean. if it is, pop a switch in the menu
[08:30] <larsu> dednick: don't do that, switches and checks are separate things
[08:31] <dednick> larsu: er. how so.
[08:31] <larsu> dednick: I'm sure mpt will gladly answer that one ;)
[08:32] <dednick> larsu: i'm pretty sure there are no checks in unity8
[08:32] <larsu> what do you mean? In the toolkit?
[08:33] <dednick> in the design
[08:33] <larsu> dednick: https://wiki.ubuntu.com/Sound#Phone
[08:34] <dednick> larsu: ahh. hm. ok
[08:34] <dednick> larsu: how do i know it's a check then ?
[08:35] <larsu> dednick: not at all right now, I'm trying to make up my mind about a good solution
[08:35] <larsu> dednick: we have two options:
[08:35] <larsu> (1) consolidate with x-canonical-type
[08:35] <larsu> (2) make a separate thing, as gtkmenutracker does it
[08:35] <dednick> larsu: role in unitymenumodel
[08:36] <dednick> ?
[08:36] <larsu> if you have separate widgets for check and radio menu items, (1) will be easier
[08:36] <larsu> otherwise, (2) will be easier (because all you need is a "Check { visible: model.is_check }" or some such)
[08:37] <dednick> larsu: yes, but i'm guessing we wont be able to render a radio in that case. there's no "group" role is there?
[08:37] <dednick> different'y from a check i mean
[08:37] <larsu> it would be is_check and is_radio
[08:37] <larsu> or a string property that is set to "check" or "radio"
[08:38] <larsu> whatever you prefer :)
[08:38] <dednick> larsu: sep roles probably best.
[08:39] <dednick> now i need to check if we actually do have a checkbox in sdk...
[08:39] <larsu> dednick: okay, so (2) with "is_check" and "is_radio". Coming up.
[08:39] <dednick> larsu: ta.
[08:40] <larsu> oh, isCheck and isRadio, of course
[08:40]  * larsu always forgets about the camels
[08:43] <dednick> larsu: i removed model.activate when i changed to action.activate. need to put it back?
[08:44] <larsu> dednick: I already did
[08:44] <dednick> larsu: ah. i was just looking at r100
[08:55] <larsu> dednick: done
[08:56] <dednick> larsu: that was quick. thanks.
[08:58] <Cimi> Saviq, ping :)
[08:59] <Cimi> Saviq, can you throw me all your ideas about why a signal might not be received externally by what is using a component?
[09:03] <tsdgeos> it's not well connected? the signal is not emitted?
[09:05] <Saviq> Cimi, can we see some code?
[09:05] <Cimi> Saviq, http://paste.ubuntu.com/5976602/
[09:06] <Cimi> http://paste.ubuntu.com/5976603
[09:06] <Cimi> basically I added a swapped signal
[09:06] <Cimi> and in my test case is not sent through :-\
[09:06] <Cimi> not always I mean...
[09:06] <Cimi> let me push the code
[09:07] <Cimi> Saviq, lp:~unity-team/unity/background-ugly
[09:09] <Saviq> Cimi, here's my output when setting my background to an empty string and back to the right path http://pastebin.ubuntu.com/5976613/
[09:09] <Cimi> Saviq, you see it's missing one
[09:10] <Saviq> Cimi, it's missing the "swapped" print, that it?
[09:10] <Cimi> Saviq, yeah
[09:11] <tsdgeos> the crossfadeimage thing (i.e. receiver) is nto there?
[09:13] <Cimi> tsdgeos, I have one onSwapped handler in Shell.qml
[09:13] <Cimi> tsdgeos, it's not receiving one
[09:13] <tsdgeos> ah sorry, got confused by the diff then
[09:13] <Cimi> which is problem number 1
[09:14] <Cimi> then I have problem number 2 which is understanding why the swapImage() function is not called when crossfading :)
[09:14] <Cimi> I think it might be because of the animation
[09:15] <Cimi> but that's a different thing ;)
[09:16] <Saviq> Cimi, http://paste.ubuntu.com/5976628/ seems to print "received swapped" every time
[09:17] <Cimi> Saviq, what did you change?
[09:17] <Saviq> Cimi, it's because you have wo handlers
[09:17] <Cimi> Saviq, even with one didn't change...
[09:18] <Saviq> Cimi, now I added onSwapped: in CrossFadeImage
[09:18] <Saviq> Cimi, and indeed I'm not getting the "outside" one
[09:19] <Saviq> tsdgeos, when you have Foo.qml: Item { onSomething: }; and then Foo { onSomething: }, would you expect both to be called or just the overridden one?
[09:19] <tsdgeos> Saviq: i think both are called
[09:19] <Saviq> s/overridden/overriding/
[09:19] <tsdgeos> but can't be sure tbh
[09:22] <Saviq> tsdgeos, yeah, in a simple example both are
[09:24] <Saviq> Cimi, I think your problem is that you're emitting the signal twice in a very small time window
[09:24] <Saviq> Cimi, I "reliably" see that the internal onSwapped is called twice
[09:24] <Cimi> Saviq, that's why I was trying to put wait(2000)
[09:24] <Saviq> Cimi, when the external onSwapped is only used once
[09:25] <Cimi> yes
[09:26] <Saviq> Cimi, it does feel like a bug, but I can't find an easy way to reproduce
[09:26] <Cimi> Saviq, it does feel like a bug to me too
[09:26] <Cimi> Saviq, spent hours on friday
[09:26] <Saviq> Cimi, either way, do you need the "internal" onSwapped?
[09:27] <Cimi> Saviq, I put it to test if it was printing correctly
[09:27] <Saviq> Cimi, and why did you go against the Image { } that was just testing whether the image is ok and to check its aspect ratio
[09:27] <Saviq> ?
[09:28] <Cimi> Saviq, mzanetti removed it
[09:28] <Cimi> Saviq, because this simplifies...
[09:29] <Saviq> Cimi, yeah, but that means that you would see a flicker in the crossfade, no?
[09:29] <Saviq> Cimi, or will the crossfade not happen if the "new" image is wrong?
[09:29] <Cimi> Saviq, I wanted to know when crossfadeimage correctly loaded and shown a new image
[09:30] <Cimi> if two images are correct, onStatusChanged doesn't change (always "Image.Ready" I think)
[09:30] <Cimi> Saviq, onSourceChanged is not enough to use, because it's too early to get the right status
[09:30] <Cimi> so was thinking of emitting a signal when the image is correctly loaded, that's why the "Swapped"
[09:31] <Cimi> which I could rename to loaded or so..
[09:31] <Cimi> but if it's not reliable I'm doomed
[09:32] <Saviq> Cimi, sure, I understand, I just want you to make sure that when you set an invalid background, it goes directly to the default one and not to black and then to the default one
[09:33] <Cimi> Saviq, ahh I see
[09:33] <Cimi> Saviq, this is a good reason to keep the image loader
[09:33] <Cimi> Saviq, crossfadeImage should handle that though
[09:40] <Cimi> Saviq, how about adding an image loader in crossfadeimage?
[09:40] <Cimi> Saviq, loader/tester
[09:41] <Saviq> Cimi, it should already "have" one, i.e. the "next" image - you start loading it and report status updates from that image
[09:42] <Saviq> Cimi, so when Image.Error is spat out of it, you know the source that's set is wrong
[09:44] <Cimi> Saviq, yes but I want to know the last image that was swapped correctly...
[09:44] <Saviq> Cimi, why?
[09:44] <Cimi> Saviq, so I can store it
[09:44] <Cimi> Saviq, if it fails, it reverts
[09:45] <Saviq> Cimi, you don't want to store the "last correct value", though, do you?
[09:45] <Saviq> Cimi, we want to fall back to the default
[09:45] <Cimi> Saviq, you asked to fallback to the last sane image
[09:45] <Saviq> Cimi, not for the default?
[09:45] <Cimi> like I have default, I set red, then blue, then wrong
[09:46] <Cimi> I want to go back to blue
[09:46] <Saviq> Cimi, that could be handled in CFI internally
[09:46] <Saviq> Cimi, but anyway I don't think we should just "ignore" the change
[09:46] <Saviq> Cimi, but instead go to the default
[09:46] <Saviq> Cimi, if I said otherwise, sorry, I'm an a$$
[09:47] <Cimi> no problem
[09:47] <Cimi> I discovered the craziness of qml and its signals :O
[09:52] <larsu> dednick: is the qevents branch a temporary workaround for the qt bug?
[10:03] <dednick> larsu: no, dont think qt will do anything about it.
[10:03] <dednick> larsu: that's the impression i got from them anyway
[10:04] <larsu> dednick: bummer. I assume we might hit this in other projects as well.
[10:04] <dednick> larsu: indeed.
[10:04] <larsu> dednick: anyway, I'll merge it, we need to get this rolling ;)
[10:10] <Saviq> Cimi, yeah, I think that's the correct thing to do
[10:10] <Cimi> Saviq, you mean I should revert to default without overriding the gsettings key?
[10:10] <Saviq> Cimi, yes
[10:10] <Saviq> Cimi, don't touch gsettings, but display the default
[10:11] <Cimi> Saviq, so gsettings will keep the broken image?
[10:11] <Saviq> Cimi, yes
[10:11] <Saviq> Cimi, that's the correct thing to do
[10:11] <Saviq> Cimi, we shouldn't be overwriting someone's settings just because our image failed to load
[10:12] <Saviq> Cimi, we don't know the reason why it failed to load
[10:12] <Saviq> Cimi, e.g. it might be unavailable right now, but on reboot will be there, for example
[10:14] <tsdgeos> mzanetti: Saviq: so what we do with the ofono branch?
[10:14] <Saviq> tsdgeos, let me ping jounih for feedback on it
[10:15] <tsdgeos> Saviq: btw weird thing about the qdbusxml2cpp, we (as with my kde hat) run it on compile time all the time afaik
[10:15] <tsdgeos> but not going to block on that
[10:16] <tsdgeos> maybe we need to change the copyright notice though? or?
[10:16] <Saviq> tsdgeos, yeah, was surprised to read that, but it does actually make sense
[10:16] <Saviq> tsdgeos, same for qmltypes - we should only generate them on change, not build-time
[10:17] <Saviq> (or do it build-time and compare to see if there's a difference and block on that, actually)
[10:17] <Saviq> difference between the checked-in one and the generated one, that is
[10:22] <mzanetti> Saviq: tsdgeos: for the ofono branch we have 2 main questions:
[10:23] <mzanetti> a) should it be part of unity8 or not (I'd say yes)
[10:23] <mzanetti> b) some open design figures where I would not block on as it will be refined once designers actually get it on their phones.
[10:26] <tsdgeos> mzanetti: a) looks good to me, but i agree with some of the comments in which i should be able to use my phone even without entering the sim and then i should have some kind of indicator or way to enter it once "running"
[10:26] <tsdgeos> that's how most of the phones i've had work
[10:27] <mzanetti> tsdgeos: yeah... you can cancel the PIN entry already now
[10:27] <mzanetti> tsdgeos: the only thing we need to figure is how to enter it at some later point in case it was cancelled. But we have a meeting scheduled for tomorrow for that
[10:28] <tsdgeos> ah good stuff
[10:28] <larsu> dednick: there's a FIXME before you send the datachangeevent, but it seems to work fine. Is that just a left over?
[10:29] <dednick> larsu: yeah. i think i was just tagging code that needed the events put in
[10:29] <dednick> larsu: i'll remove quick.
[10:30] <larsu> dednick: don't worry about it, I'm removing it with the merge
[10:30] <dednick> larsu: ok. thanks
[10:31] <larsu> dednick: your branches are merged. Let me just add a "isToggled" role so that you can find ääout whether to show a check by doing "visible: isChecked && isToggled"
[10:31] <larsu> oh, "isCheck" of course
[10:32] <dednick> larsu: toggle will be stored in state parameter no?
[10:33] <larsu> dednick: only for checks. For radios, you'd need to compare to "target", which "isToggled" does for you
[10:33] <tsdgeos> Saviq: greyback: so how do we fix https://launchpadlibrarian.net/147378097/buildlog_ubuntu-saucy-amd64.platform-api_1%3A0.18.3%2B13.10.20130807-0%2B201308121010~113%2B90~saucy1_FAILEDTOBUILD.txt.gz ?
[10:33] <dednick> larsu: ah. i see. ok
[10:33] <Saviq> greyback, any idea why https://code.launchpad.net/~phablet-team/+archive/mir/+sourcepub/3419610/+listing-archive-extra failed, then? and if it's the correct branch anyway?
[10:33] <Saviq> greyback, it's built from lp:platform-api via https://code.launchpad.net/~phablet-team/+recipe/platform-api-mir-daily
[10:34] <larsu> dednick: done. It's ready to merge from my side.
[10:34] <greyback> tsdgeos: I'll fix the FTBFS, I understand the Mir change that caused it
[10:34] <greyback> Saviq: ^^
[10:34] <tsdgeos> awesome :-)
[10:34] <dednick> larsu: cool. thanks for that. i'll check it all out asap
[10:35] <Saviq> greyback, cool
[10:35] <larsu> dednick: okay. I'll be gone for the next hour or so. Lunchtime :)
[10:35] <Saviq> greyback, let me know, I'll handle the recipes and the rebuilds
[10:35] <greyback> Saviq: ack
[10:36] <tsdgeos> greyback: also was talking about getting a nice autolander and CI for unity-mir, what do you think? is it too soon or can we do that already?
[10:39] <greyback> tsdgeos: I was waiting for sil2100 's go-ahead, he had to block on that for some reason.
[10:40] <greyback> sil2100: can we get auto-landing on unity-mir, pretty please?
[10:44] <tsdgeos> he ran away :D
[10:57] <tsdgeos> sil2100: did you get the "unity-mir autolanding" msg?
[10:57] <greyback_> sil2100: it was "can we get auto-landing on unity-mir, pretty please?"
[10:58] <mzanetti> Saviq: there are rumors that we want to move away from the ./build script. Is that true?
[10:59] <sil2100> greyback_: !
[10:59] <sil2100> That's music to my ears
[10:59] <sil2100> I missed it, but now I hear it
[11:00] <sil2100> greyback_: does it build with everything that's in saucy now?
[11:01] <greyback_> sil2100: ah yes, that was why we've to wait. Unfortunately not yet, ricmm has 2 MRs up to fix that
[11:01] <Saviq> mzanetti, we already can
[11:01] <Saviq> mzanetti, a simple cmake; make
[11:01] <Saviq> mzanetti, is all we need
[11:01] <Saviq> mzanetti, ./build is just a helper
[11:01] <mzanetti> Saviq: I know... I used that a lot
[11:02] <mzanetti> Saviq: still it does some other things too, doesn't it?
[11:02] <Saviq> mzanetti, it installs build and runtime deps
[11:02] <Saviq> mzanetti, but that can be done manually "the usual way"
[11:02] <Saviq> mzanetti, that's ut
[11:02] <Saviq> it
[11:02] <mzanetti> yeah... just wondering as Wellark told me it would be obsolete and will be removed "soon"
[11:02] <sil2100> greyback_: since auto-landing requires that we are able to build it without any additional PPAs - if that's possible right now, I can add it tot the config ASAP
[11:02] <Saviq> mzanetti, that's probably an incorrect statement
[11:03] <Saviq> mzanetti, I don't see a reason to remove it, really
[11:03] <Saviq> mzanetti, other than maintainership
[11:03] <greyback_> sil2100: not possible yet. When it is, you'll be first to know
[11:05] <sil2100> greyback_: awesome, waiting for the signal then ;)
[11:05] <Saviq> Wellark, I don't think we'll be removing the build script any time soon, it's just a helper script
[11:05] <Saviq> Wellark, it's not needed any more, but speeds up things
[11:05] <Saviq> we might remove the mention of it from CODING
[11:05] <mzanetti> Saviq: is there a solution (e.g. from unity7) how to generate the initial list of apps in the launcher or do we need to figure something ourselves=
[11:06] <Saviq> mzanetti, gsettings
[11:06] <mzanetti> ?
[11:06] <Saviq> mzanetti, com.canonical.Unity.Launcher favorites
[11:06] <Saviq> mzanetti, we should have an .override for it on the phone, but that's about it
[11:06] <mzanetti> Saviq: not talking about where to store them. but rather where to get a default list in case the setting is empty
[11:06] <Saviq> ↑
[11:07] <Saviq> mzanetti, from gsettings' default
[11:07] <mzanetti> ok.
[11:07] <Saviq> mzanetti, overridden by the .override file that I don't know what we'll ship it with yet
[11:07] <Saviq> seb128, larsu, any updates on the "how do we handle settings different between form factors" topic?
[11:08] <Saviq> i.e. default launcher favourites, default background and such?
[11:09] <Saviq> and whether changing a setting "propagates" to different ffactors?
[11:09] <seb128> Saviq, I've not seen any recent discussion about that, I guess it would make more sense to have the feature build into the stack (e.g having db profiles) rather than having different keys (eg Launcher.<form>) and have the code bind to the right one
[11:10] <mzanetti> Saviq: hmm... are QSettings not to be used?
[11:11] <Saviq> mzanetti, aren't QSettings being deprecated?
[11:11] <mzanetti> Saviq: that would be news to me
[11:11] <tsdgeos> Saviq: they were, but they didn't write any replacement, so they undeprecated it :D
[11:11] <Saviq> lol
[11:12] <mzanetti> oh boy... and I know the reason for all this :D
[11:12] <Saviq> mzanetti, and anyway - we use gsettings in Ubuntu extensively, so gsettings-qt is the first place to look at
[11:12] <Saviq> mzanetti, like we have for the background, for example
[11:13] <mzanetti> Saviq: not saying I would know better, but does it really make sense to switch away from everything G* while still keeping the settings?
[11:13] <Saviq> mzanetti, about that, we had to revert the background stuff - it broke autopilot, 'cause the default background wasn't there (no idea how that got through the upstream merger)
[11:13] <Saviq> mzanetti, we're not "switching away from everything G*"
[11:14] <Saviq> mzanetti, not where we're using it extensively on the desktop (like for gsettings)
[11:14] <Saviq> mzanetti, and where there isn't a real alternative
[11:14] <mzanetti> hmm... I don't know enough about GSettings to judge that
[11:15] <mzanetti> just feels weird to completely write Qt apps but then use gsettings instead of QSettings. Thinking about portability of apps for example
[11:15] <mzanetti> not a real issue with unity, I agree
[11:15] <Wellark> Saviq: ok, I will make sure unity8 launcher uses gsettings. I will check out gsettings-qt
[11:16] <Wellark> Saviq: is it in main/universe?
[11:16] <mzanetti> Wellark: we already use it in unity iirc
[11:16] <dednick> anyone know if it's possible to block signals in qml?
[11:16] <mzanetti> dednick: define "block" signals
[11:16] <greyback_> tsdgeos: Saviq: https://code.launchpad.net/~gerboland/unity-mir/fix-FTBFS-mir-951/+merge/179665
[11:17] <dednick> mzanetti: change in property value causing signal. equiv of QObject::blockSignals
[11:17] <Wellark> Saviq: do you have any other technical requirements for the launcher backend?
[11:17] <Wellark> 14:06 < Saviq> mzanetti, com.canonical.Unity.Launcher favorites
[11:18] <Wellark> Saviq: so, reuse the schema from unity7?
[11:18] <Saviq> Wellark, yes
[11:18] <Wellark> and paths
[11:18] <Saviq> Wellark, wherever it makes sense, we should use the same
[11:18] <Wellark> Saviq: do you have a spec for me or is it the old "dig the source, luke"
[11:18] <Saviq> Wellark, I have nothing, can't say there is nothing, though
[11:18] <mzanetti> dednick: what's the issue with QObject::blockSignals
[11:19] <dednick> mzanetti: ? i'm in qml...
[11:19] <tsdgeos> greyback_: shall i "auto-merge" ?
[11:19] <Saviq> didrocks, are the unity gsettings schemas documented somewhere?
[11:19] <mzanetti> dednick: ah... qml. lemme check
[11:19] <greyback_> tsdgeos: please
[11:20] <tsdgeos> done
[11:20] <Saviq> Wellark, they are effectively documented in the schema itself
[11:20] <Saviq> tsdgeos, greyback_I can trigger platform-api build?
[11:21] <Saviq> Wellark, http://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/com.canonical.Unity.gschema.xml
[11:21] <mzanetti> dednick: can't find anything integrated in QQuickItem. However, I guess you can move the onSignal: methods into a Connections {} item and set that to enabled/disabled
[11:22] <didrocks> Saviq: I don't think they are TBH :/
[11:22] <dednick> mzanetti: ah. ok, thanks.
[11:22] <Saviq> didrocks, the .xml is probably enough, really
[11:22] <Wellark> Saviq: ok, thanks!
[11:22] <Saviq> greyback_, hmm, the FTBFS was on lp:platform-api, though
[11:22] <mzanetti> dednick: if there isn't a enabled property there, you can set/unset the target property
[11:22] <Wellark> Saviq: seems the schema is installed by libunity-core-6.0-7
[11:22] <greyback_> Saviq: odd, I just checked here and it was fine
[11:22] <Saviq> Wellark, yes
[11:23] <Saviq> greyback_, https://code.launchpad.net/~phablet-team/+archive/mir/+sourcepub/3419610/+listing-archive-extra
[11:24] <Wellark> so, either, we split out the schemas to independent package, or unity8 will depend on unity-core or we do the middle ground: on systems where libunity-core is installed we use that and on systems where there is no unity7 we provide additional package to install the schema
[11:25] <Saviq> Wellark, it already depends on unity-core
[11:25] <Wellark> Saviq: or will unity8 have it's own unity-core
[11:25] <Wellark> Saviq: unity-core does not bring in any unity7 binaries?
[11:25] <Saviq> Wellark, no, it's just a utility library for "unity shells"
[11:26] <Saviq> Wellark, whether it's unity7, unity-2d or unity8
[11:26] <Saviq> Wellark, but there are plans to split the schemas out anyway, I believe
[11:27] <Wellark> Saviq: ok, sweet. I was worried if we run into trouble with pure unity8 systems or unity7/unity8 hybrids
[11:27] <Wellark> but it's taken care off
[11:36] <seb128> mzanetti, we use gsettings for system settings, not app settings
[11:36] <seb128> mzanetti, and we are talking about writting a gsettings backend for qgsettings, maybe
[11:36] <mzanetti> seb128: ah ok
[11:36] <seb128> mzanetti, gsettings has some advantage, those keys are shared being component, not a db specific to an app
[11:37] <seb128> mzanetti, they also need to have system/vendor override and lockdown support
[11:37] <seb128> mzanetti, gsettings gives us all that today
[11:37] <Wellark> seb128: sweet :)
[11:37] <mzanetti> ah, I see. thanks for clarifying
[11:37] <seb128> yw
[11:37] <Wellark> seb128, Saviq: how complete is gsettings-qt?
[11:37] <Wellark> does it give access to everything we need?
[11:37] <Saviq> Wellark, complete enough, with Qt and QML bindings
[11:38] <seb128> Wellark, define "complete", it's working and being used in system settings and phone-app
[11:38] <seb128> Wellark, it has c++ and qml apis
[11:38] <Wellark> complete as API parity with the GObject API
[11:38] <seb128> not yet
[11:38] <seb128> but you don't need most of things
[11:38] <Wellark> ok.
[11:39] <Saviq> Wellark, yeah, so in launcher-backend you'd probably use the c++ api
[11:40] <Wellark> Saviq: yeah, AFAIK all I need is a way to write a list of values and read them back
[11:40] <Saviq> Wellark, yup, that's what it'll give you
[11:40] <Wellark> and get notification if somebody else messes with the list (webapps adding launcher entries, etc)
[11:41] <Wellark> gsettings supports multiple writers, right?
[11:41] <seb128> you have read/write/notification on changes
[11:55] <larsu> Saviq, mzanetti: last I heard was that "someone" wanted to write a gsettings backend for qsettings
[11:55] <larsu> for apps
[11:56] <larsu> unity and other desktop components need more flexibility than qsettings, so they use gsettings directly (through a qt wrapper)
[12:20] <Wellark> Saviq: what package is providing the gicon qml loader?
[12:20] <Saviq> Wellark, ui toolkit plugin
[12:22] <larsu> Wellark: but but but don't use it.
[12:23] <Saviq> lol
[12:24] <larsu> ;)
[12:30] <Wellark> larsu: what should be used instead?
[12:31] <larsu> Wellark: uris. For themed icons, image://theme/<icon-name> (if someone approved my merge, that is)
[12:31] <larsu> Wellark: what do you need gicon for?
[12:32] <Wellark> larsu: well, I've seen it being used to get themed icons, but what I need it for is loading icons for launcher items based on the .desktop file Icon key
[12:33] <Wellark> or, more precisely giving mzanetti a icon URL he can load with qml
[12:33] <Wellark> what ever providers we have
[12:33] <larsu> Wellark: ya, use image://theme for that. And bother someone to approve https://code.launchpad.net/~larsu/ubuntu-ui-toolkit/add-unity-theme-icon-provider/+merge/179011
[12:33] <Wellark> image://gicon/<icon name> seems to do the trick just fine
[12:34] <Wellark> mzanetti: ^
[12:34] <larsu> Wellark: yes it does, but don't use it!
[12:34] <larsu> Wellark: consider it deprecated.
[12:34] <Wellark> larsu: that loads also from /usr/share/pixmaps ?
[12:34] <Wellark> for some reason gicon loader doesn't do that
[12:34] <larsu> Wellark: why should it?
[12:35] <Wellark> well, I was under the impression that pixmaps belongs to the theme spec and gicon would support it :)
[12:35] <Wellark> larsu: but as long as your loader supports it I don't care
[12:35] <larsu> it doesn't
[12:35] <larsu> it supports themes as per the themeing spec
[12:36] <larsu> desktop entries may be themed icons or absolute paths
[12:36] <larsu> that means for you: find out if it's an absolute path. If it is, generate a file:/ uri, else use image://theme/
[12:36] <larsu> or are you using GDesktopAppInfo?
[12:36] <mzanetti> sounds sane to me ^^
[12:36] <Wellark> larsu: http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout
[12:37] <Wellark> "and in /usr/share/pixmaps (in that order)"
[12:37] <Wellark> firefox and thunderbird install their icons under pixmaps
[12:37] <larsu> Wellark: if it's in the spec, then my loader supports it (unless qt has a bug)
[12:38] <Wellark> sweet
[12:38] <larsu> Wellark: interesting, I thought everybody just used hicolor
[12:38] <larsu> oh well, TIL.
[12:38] <Wellark> larsu: what about click? I just make sure click icons have absolute paths?
[12:38] <larsu> thanks for pointing me to that, Wellark
[12:39] <mzanetti> Wellark: yeah, absolute for click sounds fine
[12:39] <larsu> Wellark: either that, or install the icon in a directory that the theming spec mentions
[12:39] <mzanetti> Wellark: probably we don't even need the clickimageprovider
[12:39] <larsu> mzanetti: ya, that would be wrong.
[12:39] <greyback_> Wellark: did you get time to finish the .desktop file parser?
[12:40]  * larsu acts as if he didn't just read what greyback_ wrote and goes back to hacking
[12:40] <greyback_> Wellark: or what would you recommend as best tool to use to read .desktop files then?
[12:41] <mzanetti> greyback_: https://code.launchpad.net/~kaijanmaki/unity8/launcher-backend/+merge/179663
[12:41] <mzanetti> greyback_: we probably need to move it to a library
[12:41] <greyback_> mzanetti: +1
[12:42] <mzanetti> greyback_: feel free to review the parser part and add that ass a comment
[12:42] <greyback_> mzanetti: sure
[12:43] <Wellark> larsu: I'm generating some pressure on #sdk to get your MR approved.
[12:43] <larsu> Wellark: thanks!
[12:46] <Cimi> Saviq, I find it hard not having a loop here: if the status is Error I have to change the source, but this could create a binding loop
[12:46] <Wellark> larsu: please, join #sdk
[12:46] <Saviq> Cimi, don't use a binding, then, use signal handlers
[12:46] <Cimi> Saviq, I am :-\
[12:46] <Cimi> Saviq, still complains
[12:47] <Cimi> http://paste.ubuntu.com/5977163/
[12:47] <Saviq> Cimi, complains how? if there's no binding, how can it complain that there's a binding loop?
[12:47] <Cimi> Saviq, onStatusChanged: if status == error -> source = defaultbg
[12:48] <Cimi> Saviq, if defaulting is error, it loops maybe
[12:48] <Cimi> *defaultbg
[12:48] <Saviq> Cimi, well, you do protect against that in the if()
[12:49] <Saviq> Cimi, what does it complain about?
[12:49] <Cimi> Saviq, indeed, but still complains
[12:49] <Cimi> Saviq, QWARN  : qmltestrunner::Shell::test_wallpaper_wrong() file:///home/cimi/Development/unity/unity8.fix-wallpaper/Shell.qml:150:9: QML CrossFadeImage: Binding loop detected for property "status"
[12:50] <Cimi> Saviq, unless I have a different handler in crossfadeimage
[12:50] <Cimi> and they collide
[12:50] <Saviq> Cimi, it's difficult to see, push to the branch, please
[12:50] <Cimi> ok
[12:51] <Cimi> Saviq, pushed in background ugly
[12:55] <Saviq> Cimi, it doesn't build/run
[12:55] <Cimi> weird
[12:55] <Cimi> Saviq, error? build here
[12:59] <Saviq> Cimi, tests/mocks/GSettings isn't there
[12:59] <Saviq> Cimi, clean build won't work
[13:04] <Cimi> Saviq, ouch
[13:05] <Cimi> Saviq, pushed
[13:08] <Saviq> Cimi, file:///home/michal/dev/canonical/unity8/repo/Shell.qml:123:9: Cannot assign to non-existent property "onPictureUriChanged"
[13:08] <Saviq>              onPictureUriChanged: backgroundImage.source = pictureUri
[13:08] <Saviq> Cimi, there is no "onFooBarChanged" on GSettings
[13:08] <Saviq> larsu, right ↑? could there be?
[13:09] <larsu> Saviq: no there isn't, because these properties are loaded at runtime
[13:09] <larsu> Saviq: there's a onChanged(keyname) on a GSettings object
[13:09] <Cimi> so I need an extra property for that
[13:09] <Saviq> Cimi, ↑
[13:13] <tsdgeos> Saviq: there?
[13:13] <Saviq> tsdgeos, yup
[13:13] <tsdgeos> Saviq: can you add to https://code.launchpad.net/~unity-team/unity8/app-preview-data/+merge/179348 the steps to get the click scope?
[13:13] <Saviq> tsdgeos, yeah, doing
[13:13] <tsdgeos> i can't find them (you told them on friday) and i guess they'll be useful to others if they want to give it a look
[13:18] <dednick> larsu: ping
[13:19] <fginther> didrocks, hello! Is there a way to tell what bzr revision was built by a daily release build?
[13:19] <dednick> larsu: should remove theme icon provider from qmenumodel?
[13:20] <dednick> larsu: since you've proposed it to ubuntu-ui-toolkit
[13:20] <didrocks> fginther: it's in debian/changelog
[13:20] <didrocks> you will see it
[13:20] <didrocks> as well as when it's merging back
[13:20] <Saviq> tsdgeos, added to description
[13:20] <didrocks> it's part of the commit message
[13:20] <tsdgeos> awesome
[13:20] <fginther> didrocks, thx
[13:21] <didrocks> yw
[13:26] <Cimi> dunno
[13:29] <Cimi> Saviq, I skip the hangout and keep focusing here...
[13:29] <Cimi> Saviq, I don't want to lose the concentraiton
[13:29] <Saviq> Cimi, k
[13:31] <Saviq> nic-doffay, standup
[13:33] <Saviq> mterry, can you hear us?
[13:34] <Cimi> is the background property needed or not?
[13:34] <mterry> Saviq, no, hmm
[13:35] <mterry> Saviq, can now
[13:39] <dednick> larsu: also, do we need to bump qmenumodel version? or is that done automatically?
[13:43] <larsu> dednick: I wanted to remove it once it lands in ui-toolkit, but it looks like that won't happen soon, because it misses testing
[13:43] <larsu> dednick: maybe Wellark will write them...
[13:44] <tsdgeos> Saviq: on the app ppreview thing
[13:44] <tsdgeos> it's sloowwwwwwwwwwwwwwww
[13:44] <Saviq> tsdgeos, meaning?
[13:44] <tsdgeos> i.e. i click on the "Fake Calculator", wait around 2 seconds, and then the preview opens
[13:44] <Saviq> tsdgeos, yeah, we need a spinner
[13:44] <larsu> dednick: good point about the version. I'll bump it.
[13:44] <tsdgeos> is it waiting to fetch all the data for the interwebs?
[13:44] <Saviq> tsdgeos, and fix the scope, too
[13:44] <tsdgeos> yeah a spinner would help
[13:44] <Saviq> tsdgeos, yeah
[13:45] <larsu> dednick: ugh, how do I even do that? Can't find the proper line in CMakeLists.txt
[13:49] <dednick> larsu: no idea.
[13:54] <seb128> larsu, what version?
[13:55] <larsu> seb128: qmenumodel
[13:55] <larsu> seb128: we want to add unitymenumodel, and unity8 should depend on the version that has it
[13:55] <seb128> larsu, do you want to change the abi version then?
[13:57] <larsu> seb128: no,  I don't think that's necessary
[13:57] <seb128> larsu, ok, so just edit unity8's control to version the depends?
[13:58] <larsu> seb128: right, but I can't figure out where cmake sets the dep in qmenumodel
[13:58] <larsu> seb128: s/dep/version
[13:58] <seb128> larsu, just version in the packaging?
[13:59] <seb128> larsu, I'm not sure qml has proper versionning/check of versions
[13:59] <larsu> seb128: hm. Where in the packaging is the version set?
[13:59] <seb128> larsu, out of bumping the abi/import number
[14:00] <seb128> larsu,
[14:00] <seb128> $ grep qmenumodel unity8/debian/control
[14:00] <seb128> ...
[14:00] <seb128> Depends: qmenumodel-qml,
[14:00] <seb128>  
[14:00] <seb128> when unity8 starts usuing unitymenumodel change that line in
[14:01] <seb128> Depends: qmenumodel-qml (>> 20130812)
[14:01] <seb128> or whatever is the version that got the feature landed
[14:01] <larsu> seb128: ah! okay. So no changes in qmenumodel needed
[14:01] <larsu> dednick|lunch: ^^
[14:01] <larsu> seb128: thank you!
[14:19] <Cimi> Saviq, I'm doomed, still the binding loop even with the if
[14:19] <tsdgeos> what?
[14:19] <tsdgeos> http://paste.ubuntu.com/5977466/
[14:19] <tsdgeos> #1  0x49c06090 in OPENSSL_cpuid_setup () from /lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
[14:19] <Saviq> tsdgeos, yikes
[14:20] <tsdgeos> ¿?
[14:20] <Saviq> mzanetti, can you please help Cimi?
[14:20] <tsdgeos> again!
[14:20] <mzanetti> sure
[14:20] <mzanetti> Cimi: what up?
[14:20] <Cimi> mzanetti, still the problem with the background fallback
[14:20] <tsdgeos> what's wrong with my libcrypto? :(
[14:20] <Cimi> mzanetti, had multiple issues...
[14:20] <mzanetti> Cimi: ah ok
[14:22] <mzanetti> Cimi: what's the branch again?
[14:22] <Cimi> lp:~unity-team/unity/background-ugly
[14:22] <greyback_> tsdgeos: the NSA are after you, run quick!
[14:22]  * tsdgeos throws the phone out of the window
[14:22] <Cimi> mzanetti, I'm going to have lunch, s
[14:22] <mzanetti> ok
[14:22] <Cimi> mzanetti, yes, now...
[14:28] <tsdgeos> Saviq: mzanetti: greyback_: can you guys do ./run_on_device -g on a Nexus 4 (if you have one)?
[14:28] <tsdgeos> i'm getting that ssl crash
[14:28] <tsdgeos> works without the .g
[14:28]  * mzanetti tries
[14:30] <tsdgeos> :F
[14:31] <mzanetti> Cimi: when you're back, let me know what the issues are...
[14:42] <Saviq> tsdgeos, greyback_ yeah we have an image
[14:42] <greyback_> Saviq: now to see if it works..
[14:43] <tsdgeos> good
[14:43]  * tsdgeos tries
[14:55] <dednick|lunch> larsu: approved.
[14:56] <larsu> dednick: thanks!
[15:06] <sil2100> Trevinho, andyrock: ping
[15:09] <Cimi> mzanetti, back
[15:11] <Cimi> mzanetti, binding loop first of all
[15:11] <Cimi> ...
[15:12] <andyrock> sil2100, pong
[15:12] <andyrock> sil2100, welcome back! :D
[15:12] <sil2100> andyrock: thanks! ;) This week let's take care of the new compiz for saucy - but besides that, do you think you could take a look at an unity test failing?
[15:12] <sil2100> AP one
[15:14] <dednick> fginther: ping
[15:14] <andyrock> sil2100, sure
[15:15] <andyrock> sil2100, have you got a link?
[15:15] <andyrock> sil2100, with all the failures?
[15:15] <sil2100> andyrock: it's just one failure, let me fetch it
[15:15]  * andyrock missed the "an"
[15:15] <andyrock> :D
[15:16] <sil2100> andyrock: for instance here http://10.97.0.1:8080/job/autopilot-saucy-daily_release/927/
[15:17] <fginther> dednick, otp, I'll be available in a few minutes
[15:22] <andyrock> sil2100, fails here too
[15:24] <sil2100> andyrock: can you fix it? ;) It's blocking platform even!
[15:25] <andyrock> sil2100, i can try... maybe something changed in bamf and wait_utils_application_is_runnig does not work
[15:25] <sil2100> Could be!
[15:25] <larsu> didrocks: any idea what this error is? https://jenkins.qa.ubuntu.com/job/qmenumodel-saucy-armhf-autolanding/2/console
[15:25]  * larsu read daily build and thought of didrocks :)
[15:26] <didrocks> as everyone :p
[15:26] <didrocks> but I guess this just updated at the wrong time
[15:26] <didrocks> between an index refresh
[15:26] <didrocks> so no need to bother the QA team, just retry and it should be fine :)
[15:26] <sil2100> andyrock: thanks!
[15:26] <dednick> larsu, didrocks: i re-approved already
[15:26] <andyrock> np!
[15:27] <larsu> didrocks: thanks!
[15:27] <didrocks> larsu: yw ;)
[15:35] <Cimi> mzanetti, ?
[15:37] <mzanetti> Cimi: in a hangout atm
[15:37] <Cimi> ok
[15:37] <mzanetti> Cimi: but I pushed one fix already
[15:37]  * Cimi looks
[15:39] <tsdgeos> Saviq: greyback_: bad news, still black screen :'(
[15:39] <greyback_> tsdgeos: damn. You tested Mir alone, and same problem?
[15:40] <tsdgeos> greyback_: yeah, mir_demo_server + mir_client_accelerated
[15:40] <greyback_> tsdgeos: something more fundamental broken so. No messages in stdout/stderr either?
[15:40] <tsdgeos> nothing :-/
[15:51] <Cimi> mzanetti, we still have the loop though :|
[15:52] <mzanetti> Cimi: I'll check it out after the hangout...
[15:56] <dednick> Saviq: ping
[15:56]  * dednick has a present for you
[16:06] <sil2100> jamesh: if anything, the new lucene++ is in saucy now
[16:06] <sil2100> jamesh: so we can proceed with merging in all the bits and pieces for media-scanner
[16:08] <tedg> larsu, Woot!  UMM!  :-)
[16:08] <sil2100> jamesh: I'm re-running CI for your merge
[16:08] <tedg> dednick, You're now on my harass list :-)
[16:08] <larsu> tedg: ;)
[16:11] <andyrock> sil2100, fixed
[16:11] <andyrock> sil2100, is there already a bug on lp?
[16:11] <dednick> tedg: lucky me.
[16:11] <sil2100> andyrock: let me check if Mirv filled one in
[16:11] <dednick> tedg: is there anything in particular you want to harass me about? :)
[16:11] <tedg> dednick, Just the UMM branch into unity8 trunk.
[16:12] <sil2100> andyrock: yes, there seems one!
[16:12] <sil2100> andyrock: https://bugs.launchpad.net/unity/+bug/1211174
[16:12] <sil2100> andyrock: thanks a lot for fixing! Any branch I could take a look? Where was the problem?
[16:12] <didrocks> sil2100: btw, the number of AP tests failing on unity is quite high, but let's see once you have those in
[16:12] <dednick> tedg: i c. waiting on a review. :) need to harass some on from unity8 ui team.
[16:12] <didrocks> sil2100: so, I hope you can release this unity easily ;)
[16:13] <andyrock> sil2100, Trevinho changed the dbus path
[16:13] <tedg> dednick, Then we need to work on moving the indicators over as we solve integration issues.
[16:13] <didrocks> andyrock: can you check if nothing else is impacted?
[16:13] <tedg> dednick, I'd like to figure those out and get those bugs fixed ASAP.  But it's going to be harder for us until that lands.
[16:13] <andyrock> it was something like that before /Application341234
[16:13] <andyrock> now it's /Application/23424
[16:13] <andyrock> didrocks, sure
[16:13] <didrocks> thanks! :)
[16:13] <tedg> dednick, Ah, so I just need to harass someone to review it.... Saviq, do you need me to call anyone to cancel your plans for the evening?   ;-)
[16:14] <sil2100> \o/
[16:14] <didrocks> sil2100: given that information, I think you can force the publication of platform
[16:14] <didrocks> (and everything stuck on it then ;))
[16:16] <fginther> dednick, pong
[16:16] <sil2100> didrocks: hm, can I do it the old way? i.e. run cu2d-platform-head-3.0publish manually first? Since forcing publication would also force it if there were any packaging changes, right?
[16:16] <didrocks> sil2100: you can run with auto_publication
[16:16] <didrocks> or just the publish step
[16:16] <didrocks> right :)
[16:16] <didrocks> easier
[16:16] <dednick> fginther: sorry, ment to unping.
[16:17] <fginther> dednick, no worries
[16:17] <sil2100> didrocks: if, by any chance, the publish job goes green, will it trigger all the rdeps when I do it by just running the publish job?
[16:20] <sil2100> Ok, today is not a good day for me and jenkins
[16:20] <sil2100> It's already the second time I double clicked something ;/
[16:21] <andyrock> sil2100, https://code.launchpad.net/~andyrock/autopilot/fix-1211174/+merge/179742
[16:21] <didrocks> sil2100: all the rdepends will run if they were in manual publishing mode
[16:22] <sil2100> didrocks: I re-ran the publish job (twice, the second time I hope I aborted in time) ;/ Sorry about that
[16:23] <didrocks> sil2100: no worry
[16:23] <didrocks> sil2100: seems ati worked that time
[16:23] <didrocks> ah, it's still in the apps
[16:23] <didrocks> not mirslaves yet
[16:28] <sil2100> andyrock: what makes me happy is that it's in autopilot \o/
[16:28] <sil2100> andyrock: so we can get it released much faster!
[16:28] <andyrock> sil2100, :D
[16:29] <andyrock> didrocks, btw I don't see any other broken things in ap because of that bamf change
[16:29] <didrocks> andyrock: ok, so the broken tests are because of something else?
[16:29] <andyrock> didrocks, what tests?
[16:29] <didrocks> sil2100: ah, it's in AP? nice :)
[16:29] <sil2100> didrocks: yes ;) Trevi changed a path in bamf, and AP wasn't changed to fit that
[16:30] <didrocks> great ;)
[16:34] <mzanetti> Cimi: re
[16:34] <Cimi> mzanetti, here I am
[16:34] <mzanetti> Cimi: that was a meeting...
[16:34] <Cimi> hah
[16:34] <mzanetti> Cimi: so... binding loop you said
[16:34] <mzanetti> lemme check
[16:34] <Cimi> mzanetti, if defaultBackground is Image.Error basically...
[16:35] <Cimi> but actually not
[16:35] <sil2100> andyrock: top approved!
[16:35] <andyrock> sil2100, sweet thanks"
[16:35] <andyrock> !
[16:37] <mzanetti> Cimi: right... I see where it happens
[16:37] <mzanetti> Cimi: actually I think its a false positive from the QML engine
[16:37] <Cimi> hah
[16:37] <Cimi> Saviq, I can kill myself
[16:37] <Cimi> Saviq, two qml bugs in one day
[16:38] <mzanetti> because the state changes to Error, then we set another image which triggers the state change again
[16:38] <mzanetti> if we would continue to set invalid images it'd be a valid loop
[16:38] <Cimi> mzanetti, no
[16:38] <Cimi> mzanetti, because if it's error the loop stops
[16:38] <Cimi> mzanetti, since you set to defaultBg
[16:38] <Cimi> mzanetti, at that point it's either image.ready
[16:39] <Cimi> mzanetti, or image.error but doesn't go in the loop because there's source != defaultBg
[16:39] <mzanetti> exactly... so we're not really having a loop because we know we're setting a good one the second time
[16:39] <mzanetti> Cimi: so I'd say we can either ignore this warning or set the corrected image delayed to get rid of it
[16:40] <Cimi> mzanetti, delayed? how?
[16:40] <Cimi> mzanetti, with extra prop?
[16:40] <mzanetti> Cimi: as setting something in a delayed fashion is quite ugly in QML (we'd need a Timer etc) I'd vote for ignoring this warning in this case
[16:40] <mzanetti> unless Saviq objects ^^
[16:41] <Cimi> mzanetti, Saviq it actually happens only if you set an invalid image
[16:41] <Cimi> so it's not like spamming the debug every time...
[16:43] <mzanetti> hmm... well, let me try something
[16:44] <mzanetti> Cimi: ok... I just tested what happens in case the defaultBackground would be invalid (e.g. file deleted from disk)
[16:44] <mzanetti> Cimi: in that case the binding loop detection seems to do the right thing and stops calling everything
[16:45] <Cimi> mzanetti, what? :)
[16:45] <Cimi> mzanetti, if is invalid, it loops?
[16:45] <Cimi> why?
[16:46] <mzanetti> Cimi: well, in case we get Image.Error we set the defaultBackground
[16:46] <Cimi> but after that
[16:46] <Cimi> it doesn't proceed
[16:46] <Cimi> mzanetti, source will be == defaultBg
[16:46] <andyrock> sil2100, didrocks http://10.97.0.1:8080/job/autopilot-saucy-daily_release/920/label=autopilot-ati/testReport/junit/unity.tests.test_command_lens/CommandScopeSearchTests/test_run_before_refresh/  this one should be fixed too now
[16:46] <mzanetti> Cimi: assuming that would be invalid too (because the user deleted the file) we also get this warning, but in that case its valid and the image stays in Image.Error
[16:46] <mzanetti> Cimi: so that's good too
[16:47] <mzanetti> Cimi: and once we are in this state we perfectly recover because when the setting changes, we set source through an assignment (not a binding) and we enable all the stuff again
[16:47] <mzanetti> Cimi: so I can't see an error right now.
[16:48] <sil2100> andyrock: the same issue?
[16:49] <mzanetti> Cimi: just that warning from QML which is understood and doesn't hurt us. Now its just waiting for Saviq to tell us if he's fine with it or we need to get rid of the warning by using some more stuff (like a Timer to set it delayed or add back the other "useless" image just to check if it can be loaded)
[16:50] <andyrock> sil2100, yeah that test is using the same function
[16:50] <mzanetti> Cimi: were there any other issues? I fixed the one with the empty setting in the beginning
[16:52] <sil2100> andyrock: two birds with one stone ;)
[16:54] <Cimi> mzanetti, nope, now I need to see if autopilot crashes
[16:54] <mzanetti> Cimi: huh? why would that happen?
[16:54] <Cimi> we can check that early tomorrow when saviq comes back
[16:54] <Cimi> we were having autopilot issues with the greeter
[16:54] <Cimi> I don't know
[16:54] <Cimi> michal knows
[17:02] <didrocks> andyrock: ah great! :)
[17:58] <Saviq> Cimi, not crashes, fails
[18:00] <Saviq> dednick, a gift? gimme gimme! :D
[18:41] <Wellark> Saviq: is X-Ubuntu-StageHint a list?
[18:41] <Wellark> tedg: ^
[18:41] <tedg> Wellark, Not sure, sorry.  Perhaps greyback_ would know.
[18:42] <Wellark> greyback_: ^
[18:42] <Wellark> somebody who knows please comment here: https://code.launchpad.net/~kaijanmaki/unity8/launcher-backend/+merge/179663/comments/406052
[18:42] <Wellark> and also provide a list of expected values if possible
[18:42] <greyback_> Wellark: I'm not 100%, but I think no. It is a string.
[18:43] <greyback_> but best get someone who is definite to say
[18:43] <Wellark> tedg: are there any other custom keys for the click .desktop files?
[18:44] <Wellark> greyback_, Saviq: or for the unity8 in general?
[18:44] <tedg> greyback_, Is Unity going to register for the name "com.canonical.Unity.WindowStack" ?
[18:45] <tedg> Wellark, Yeah, mostly housekeeping though: http://bazaar.launchpad.net/~indicator-applet-developers/upstart-app-launch/trunk.13.10/view/head:/desktop-hook.c#L198
[18:46] <Wellark> tedg, greyback_, Saviq: all the keys I know about that are currently used in existing .desktop files are here: http://bazaar.launchpad.net/~kaijanmaki/unity8/launcher-backend/view/head:/plugins/Unity/Launcher/backend/desktop-entry.y#L102
[18:46] <Wellark> please, inform me if I'm missing any
[18:47] <tedg> Wellark, Why do we need all of them?
[18:47] <tedg> Wellark, Is there not an keyfile parser in Qt?
[18:48] <greyback_> tedg: it can, just need to change the code.
[18:48] <Wellark> tedg: because all the keys that we know about are "free"
[18:48] <tedg> greyback_, Thoughts?  I was thinking perhaps that way we could move it around if need be.
[18:48] <Wellark> tedg: X-Ubuntu-Application-ID was a new one
[18:48] <Wellark> tedg: that's the $APP_ID
[18:48] <Wellark> ?
[18:49] <tedg> Wellark, Yeah
[18:49] <Wellark> tedg: and yes, there is a "ini" file reader in Qt
[18:49] <Wellark> but it can't handle the existing .desktop files
[18:49] <Wellark> not all of them
[18:49] <greyback_> tedg: sorry, I lost you. Move what around?
[18:49] <Wellark> some translations get it confused
[18:49] <tedg> greyback_, The window list dbus infomation.  We could move it to a different process if it had its own name.
[18:50] <Wellark> tedg: what is X-Ubuntu-Old-Path ?
[18:50] <tedg> Wellark, Hmm, okay.  I would have suggested using the GLib one then :-)
[18:50] <tedg> Wellark, We override the path variable, so it just puts the value in incase that's useful.
[18:50] <tedg> Wellark, Don't think anyone would use it.
[18:51] <greyback_> tedg: it needs to be part of unity, as that's the only process which can know the app & window list.
[18:52] <tedg> greyback_, Well, it needs to be part of the piece of Unity that connects to Mir, but what we call "Unity" may shift over time.
[18:52] <tedg> It may become less... unified...

[18:54] <Wellark> tedg: gdesktopappinfo does not support custom groups
[18:54] <Wellark> nor Action definitions
[18:55] <tedg> Wellark, Sure, but GKeyFile can do the parsing.  And the latest version I think does Actions.
[18:55] <tedg> It was on the TODO list, not sure where it is.
[18:55] <greyback_> tedg: if that happens, then we'll deal with it. But right now this is the easiest implementation, and it is done. Bring it up on the ML if you want to propose it further, get other people's input
[18:55] <Wellark> tedg: and GKeyFile does not do translations
[18:56] <tedg> Wellark, https://developer.gnome.org/glib/2.30/glib-Key-value-file-parser.html#g-key-file-get-locale-string
[18:57] <Wellark> tedg: if you know the locale
[18:57] <tedg> Wellark, " If locale is NULL then the current locale is assumed. "
[18:58] <Wellark> tedg: that does not handle the in-file translations
[18:58] <Wellark> which suck
[18:58] <tedg> greyback_, To be clear, I'm not suggesting changing it today.  Just making that possible in future.
[18:58] <Wellark> but we have to support them
[18:58] <tedg> Wellark, Hmm, I'm pretty sure it does.  We've distro patched it quite a bit there.
[18:59] <tedg> Wellark, I believe it does both language packs and in file.
[18:59] <Wellark> and gkeyfile does not know anything about X-[Ubuntu|GNOME]-GettextDomain
[18:59] <greyback_> tedg: sure, it's only code, we can always change it :)
[18:59] <tedg> Wellark, Not upstream, we distro patch.
[18:59] <greyback_> tedg: can I ask you one thing about https://code.launchpad.net/~ted/upstart-app-launch/libupstart-flesh/+merge/178296/comments/406142
[19:00] <tedg> NO!
[19:00] <tedg> :-)
[19:00] <Wellark> and the last thing: gkeyfile deals with string keys in it's API and thus relies on extensive string comparison
[19:00] <tedg> greyback_, What's up?
[19:00] <Wellark> my parser uses bison/flex with zero string comparison for the preknown keys
[19:00] <greyback_> tedg: app can launch another PID. That other PID can create create a new Mir Surface. To authorize it, shell needs to know that new process' PID
[19:01] <Wellark> tedg: do you need more reasons? :)
[19:01] <greyback_> tedg: am I right, or am I missing something?
[19:01] <tedg> Wellark, Eh, I'd take a well worn parser over a faster one :-)
[19:01] <tedg> Wellark, It doesn't matter really.
[19:01] <tedg> greyback_, Sure, I think it probably does need to know that PID, but it will be the same app_id.
[19:02] <tedg> greyback_, We don't have the cgroup stuff setup today, so I don't know exactly how that'll work though.
[19:02] <tedg> greyback_, I think that the cgroup ID will be the PID of the main process.
[19:02] <greyback_> tedg: ok, so 1 app_id can have multiple PIDs, and those PIDs can all have individual surfaces if they wanted.
[19:02] <tedg> greyback_, So you'll be able to check the PIDs cgroup.
[19:03] <tedg> greyback_, Yes
[19:05] <greyback_> tedg:  If one of those PIDs creates a surface, I need to check that the PID belongs to that app_id's cgroup
[19:05] <Saviq> Wellark, re: StageHint, I'd say a list, yes
[19:05] <Saviq> greyback_, after all apps need to be able to support both stages ↑
[19:05] <greyback_> upstart has all those PIDs internally, no?. Would it be possible to have upstart-app-lib make that easy for me? :)
[19:06] <greyback_> Saviq: I thought hint was what was the preferred stage
[19:06] <greyback_> ok, I misunderstood
[19:06] <Saviq> greyback_, the first one can be the preferred
[19:06] <greyback_> Saviq: ok
[19:06] <Saviq> greyback_, but if app supports both, we need to know
[19:06] <Saviq> as we can only assume that "no hint" == "only main"
[19:07] <tedg> greyback_, In theory, I'm just not sure.  We get a set of PIDs but I'm not sure if Upstart will have all or a subset.
[19:07] <tedg> greyback_, But we could put a helper function in the library.  And then fix it there.
[19:07] <tedg> greyback_, Something like "pid_in_appid" and we can look.
[19:08] <tedg> greyback_, Then eventually we'll get cgroup support, and it should be transparent for you.
[19:08] <greyback_> tedg: yep, that would be perfect
[19:08] <greyback_> cool
[19:09] <tedg> greyback_, Does the final comment here work?  http://paste.ubuntu.com/5978379/
[19:11] <Wellark> Saviq: can you reply on the MR and provide at least some values we currently know about?
[19:11] <Saviq> Wellark, MainStage, SideStage - that's it, for the foreseeable future
[19:11] <Saviq> Wellark, with the first one being preferred, if both are given
[19:31] <dednick> Saviq: ping
[19:31] <tedg> greyback_, Hmm, so I was thinking differently.
[19:31] <tedg> greyback_, I did it as you provide the app_id and the PID
[19:31] <Saviq> dednick, pong
[19:31] <tedg> greyback_, Would that work?  In theory if they're requesting a surface, they give you the app_id, no?
[19:32] <dednick> Saviq: did you have a link to a wiki regarding the lifetime of qml objects?
[19:32] <tedg> greyback_, http://bazaar.launchpad.net/~ted/upstart-app-launch/libupstart-flesh/revision/78
[19:33] <Saviq> dednick, http://qt-project.org/wiki/SharedPointersAndQmlOwnership
[19:33] <dednick> Saviq: thanks
[19:36] <greyback_> tedg: all I get from Mir is "hey, I've been asked to create a surface by a process with pid x"
[19:41] <tedg> greyback_, Huh, interesting.
[19:42] <greyback_> tedg: yep, it's pretty limiting. But if you don't think my request is possible, I'll see if I can lean on the Mir guys for more info.
[19:43] <tedg> greyback_, It's not as easy... let me investigate a bit.
[19:43] <greyback_> tedg: ok
[19:43] <greyback_> tedg: I'm going offline now, but catch you tomorrow
[19:43] <greyback_> g'night
[20:11] <Saviq> dednick, >>= means something else than >=
[20:12] <dednick> Saviq: looked at the debian control spec. didnt seem to be documented.
[20:12] <dednick> >> is scrictly greater
[20:12] <Saviq> dednick, hmm indeed
[20:12] <Saviq> dednick, you're probably right
[20:13] <dednick> Saviq: whoop. do you think you can take a look at that MP tomorrow? thomas is pretty eager to get it in.
[20:13] <Saviq> dednick, about the unitymenumodel one?
[20:14] <Saviq> dednick, I think so, yeah
[20:14] <dednick> Saviq: yeah
[20:14] <dednick> Saviq: cool. thanks. it might have to change a bit first though. I htink it's leaking like a sieve.
[20:14] <Saviq> lol
[20:14] <dednick> unitymenumodel is anyway
[20:15] <dednick> thanks to my additions :(
[20:15] <dednick> returning new from model::data = bad.
[20:26] <Saviq> dednick, yeah, indeed ;)
[20:27] <Saviq> dednick, unless there's no parent, in which case the deleted delegate would clean them up (assuming they wont dataChanged() first, which might lead to leaks anyway)
[20:28] <dednick> Saviq: yeah.. i dont think the parent is being set on the objects that i return at all. they're being used like properties rather than objects.
[20:29] <dednick> Saviq: i'm just getting rid of the fancy stuff in unitymenumodel. not really needed anymore anyway
[20:29] <Saviq> dednick, k
[20:51] <seb128> dednick, Saviq: sorry I typoed that one, it's either >= or >> ;-)
[22:39] <Sharp1> Hi, I'm using Ubuntu 13.04 and if I set up a hotcorner to switch workspaces in Unity Tweak Tool, it doesn't work after I log out and log in again. The settings stays the same in Unity Tweak Tool, but the corner does nothing. Does anyone have a solution?