[04:20] morning! [06:36] 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] Launchpad bug 1211174 in Unity "unity.tests.test_home_lens failing" [Critical,New] [06:36] andyrock doesn't seem to be here yet [06:39] 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] hi sil2100 [07:04] good morning! [07:06] Saviq: hi [07:06] mzanetti, mornin' [07:06] Saviq: any updates I should have? [07:07] mzanetti, nothing major, only thing I think is that Rick has set our priorities for August (see ubuntu-engineering@) [07:07] mzanetti, so we'll need to potentially reshuffle the work and help wherever needed to reach that [07:08] ok [07:08] * mzanetti reads mails [07:08] Saviq: progress on application management? [07:08] mzanetti, there is [07:09] are we using mir on the phone yet? [07:09] mzanetti, not by default, no [07:09] mzanetti, we're hoping for the end of the week [07:09] nice [07:10] I've seen dednick workarounded the CPU battery draining issue [07:10] makes me happy :) [07:12] jamesh: hi! lucene++ is waiting for sponsoring, I think someone should pick it up soon [07:12] jamesh: I'll poke the patch pilot as well [07:12] mzanetti, yeah, unfortunately a temporary and short-lived solution [07:12] Saviq: who's the man for the network indicator service? isn't that larsu? [07:12] maybe we should subscribe him to the bug too [07:13] mzanetti, it's not a service issue [07:13] mzanetti, it's a generic glib vs. Qt one [07:13] well, it seems to crash [07:14] sil2100: okay, thanks [07:15] sil2100: I think jamesh has other requests, I asked him to wait for you being back :) [07:15] the lucene++ one is the main one, so I can clear the merge request queue [07:16] mzanetti, ah, that's the "wrong" indicator backend anyway [07:16] mzanetti, it's chewie-client and not indicator-network that's used, still [07:16] jamesh: \o/ what's the other request? I'm back from holidays now so ready for action [07:17] jamesh: btw. did you send me an e-mail with those media-scanner branches? [07:17] sil2100: I may need a little more help once I've got everything merged and building in Jenkins [07:17] jamesh: or is it just one branch right now? [07:17] Saviq: any pointers where to start fixing this one? https://bugs.launchpad.net/ubuntu-ux/+bug/1210200 [07:17] Ok [07:17] Launchpad bug 1210200 in Ubuntu UX "[osk] OSK overlaps launcher when on an app and then navgiate to launcher" [High,New] [07:18] mzanetti, with Mir [07:18] mzanetti, shell is always just a single surface currently, so there's no way to composite them in the right order yet [07:19] mzanetti, although reaching for the launcher should dismiss the keyboard anyway [07:19] 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] Saviq: should it?... not sure about that [07:19] Saviq: I wouldn't say so [07:19] sil2100: they all extend the changes in the saucy-fixes branch [07:19] mzanetti, add ubuntu-ux to the bug, then [07:19] mzanetti, I think that's what I heard - and it kinda makes sense [07:20] 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] larsu: ping [07:46] MacSlow: veebers: my X crashed... [07:46] anyways, I think we were done, right? [07:46] mzanetti, yup [07:46] mzanetti: d'oh :-\ You didn't miss much, yeah was jsut the wrapup [07:47] dednick: morning [07:52] larsu: good morning! [07:54] 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] dednick: awesome, I'll have a look in a bit. I fixed the action handling and added the parameter [07:55] dednick: ooh, but I didn't push it yet. Will do now [07:55] larsu: cool. thanks, i'll take a look at that and update unity8 to handle. [07:56] 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] larsu: i'd much prefer if we can always using the action. [08:01] dednick: why? [08:01] 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] model.activate is accessible in every delegate, no? [08:03] there shouldn't be any reason why the menu item components need access to the root model [08:04] larsu: larsu because then they need to know about their own index within the model and such. [08:05] larsu: actually, i may change how they call activate [08:05] dednick: I don't understand. Are you doing something substantailly different from examples/unitymenumodel.qml? [08:05] might be better to signal value changes back to the delegate and let it call activate. [08:05] larsu: it's a hell of a lot bigger. has to be much more modular. [08:06] dednick: of course. I mean structurally. The components inside the delegates can always access all roles of its row, can't they? [08:07] and they should always have the ListView attached property [08:07] larsu: the delegates can, but the delegates arent the menu items. [08:07] larsu: nevermind. i'm going to change it. [08:08] i think it needs to change anyway. [08:08] hm, okay :) [08:19] 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] *parsing the state type [08:20] larsu: unity7 is just a checkable menu type, but in unity8 i'm guessing we want a switch. [08:25] dednick: ah, right. I should be exporting that through the role, you shouldn't need to parse the state [08:26] larsu: ok, so it'll always be in x-canonical-type? [08:26] dednick: thinking about that right now [08:27] dednick: it's not really in the implementation, because x-canonical-type is something we added on top of gmenumodel [08:27] where checks and radios are in gmenumodel itself [08:27] but this will lead to two type systems for you... [08:27] kinda weird [08:28] larsu: hm. the radio is an intersting one. [08:28] dednick: is it easier for you if I consolidate everything into x-canonical-type? [08:28] dednick: usually, checks/radios are handled by the same widget as normal menu items [08:28] i.e., we just draw a check or a radio thing in the margin if gtkmenutracker tells us to [08:29] larsu: i so have a solution in place for the parsing type. [08:29] parsing type? [08:30] larsu: just checking if it's a boolean. if it is, pop a switch in the menu [08:30] dednick: don't do that, switches and checks are separate things [08:31] larsu: er. how so. [08:31] dednick: I'm sure mpt will gladly answer that one ;) [08:32] larsu: i'm pretty sure there are no checks in unity8 [08:32] what do you mean? In the toolkit? [08:33] in the design [08:33] dednick: https://wiki.ubuntu.com/Sound#Phone [08:34] larsu: ahh. hm. ok [08:34] larsu: how do i know it's a check then ? [08:35] dednick: not at all right now, I'm trying to make up my mind about a good solution [08:35] dednick: we have two options: [08:35] (1) consolidate with x-canonical-type [08:35] (2) make a separate thing, as gtkmenutracker does it [08:35] larsu: role in unitymenumodel [08:36] ? [08:36] if you have separate widgets for check and radio menu items, (1) will be easier [08:36] otherwise, (2) will be easier (because all you need is a "Check { visible: model.is_check }" or some such) [08:37] 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] different'y from a check i mean [08:37] it would be is_check and is_radio [08:37] or a string property that is set to "check" or "radio" [08:38] whatever you prefer :) [08:38] larsu: sep roles probably best. [08:39] now i need to check if we actually do have a checkbox in sdk... [08:39] dednick: okay, so (2) with "is_check" and "is_radio". Coming up. [08:39] larsu: ta. [08:40] oh, isCheck and isRadio, of course [08:40] * larsu always forgets about the camels [08:43] larsu: i removed model.activate when i changed to action.activate. need to put it back? [08:44] dednick: I already did [08:44] larsu: ah. i was just looking at r100 [08:55] dednick: done [08:56] larsu: that was quick. thanks. [08:58] Saviq, ping :) [08:59] 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] it's not well connected? the signal is not emitted? [09:05] Cimi, can we see some code? [09:05] Saviq, http://paste.ubuntu.com/5976602/ [09:06] http://paste.ubuntu.com/5976603 [09:06] basically I added a swapped signal [09:06] and in my test case is not sent through :-\ [09:06] not always I mean... [09:06] let me push the code [09:07] Saviq, lp:~unity-team/unity/background-ugly [09:09] 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] Saviq, you see it's missing one [09:10] Cimi, it's missing the "swapped" print, that it? [09:10] Saviq, yeah [09:11] the crossfadeimage thing (i.e. receiver) is nto there? [09:13] tsdgeos, I have one onSwapped handler in Shell.qml [09:13] tsdgeos, it's not receiving one [09:13] ah sorry, got confused by the diff then [09:13] which is problem number 1 [09:14] then I have problem number 2 which is understanding why the swapImage() function is not called when crossfading :) [09:14] I think it might be because of the animation [09:15] but that's a different thing ;) [09:16] Cimi, http://paste.ubuntu.com/5976628/ seems to print "received swapped" every time [09:17] Saviq, what did you change? [09:17] Cimi, it's because you have wo handlers [09:17] Saviq, even with one didn't change... [09:18] Cimi, now I added onSwapped: in CrossFadeImage [09:18] Cimi, and indeed I'm not getting the "outside" one [09:19] 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] Saviq: i think both are called [09:19] s/overridden/overriding/ [09:19] but can't be sure tbh [09:22] tsdgeos, yeah, in a simple example both are [09:24] Cimi, I think your problem is that you're emitting the signal twice in a very small time window [09:24] Cimi, I "reliably" see that the internal onSwapped is called twice [09:24] Saviq, that's why I was trying to put wait(2000) [09:24] Cimi, when the external onSwapped is only used once [09:25] yes [09:26] Cimi, it does feel like a bug, but I can't find an easy way to reproduce [09:26] Saviq, it does feel like a bug to me too [09:26] Saviq, spent hours on friday [09:26] Cimi, either way, do you need the "internal" onSwapped? [09:27] Saviq, I put it to test if it was printing correctly [09:27] 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] ? [09:28] Saviq, mzanetti removed it [09:28] Saviq, because this simplifies... [09:29] Cimi, yeah, but that means that you would see a flicker in the crossfade, no? [09:29] Cimi, or will the crossfade not happen if the "new" image is wrong? [09:29] Saviq, I wanted to know when crossfadeimage correctly loaded and shown a new image [09:30] if two images are correct, onStatusChanged doesn't change (always "Image.Ready" I think) [09:30] Saviq, onSourceChanged is not enough to use, because it's too early to get the right status [09:30] so was thinking of emitting a signal when the image is correctly loaded, that's why the "Swapped" [09:31] which I could rename to loaded or so.. [09:31] but if it's not reliable I'm doomed [09:32] 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] Saviq, ahh I see [09:33] Saviq, this is a good reason to keep the image loader [09:33] Saviq, crossfadeImage should handle that though [09:40] Saviq, how about adding an image loader in crossfadeimage? [09:40] Saviq, loader/tester [09:41] Cimi, it should already "have" one, i.e. the "next" image - you start loading it and report status updates from that image [09:42] Cimi, so when Image.Error is spat out of it, you know the source that's set is wrong [09:44] Saviq, yes but I want to know the last image that was swapped correctly... [09:44] Cimi, why? [09:44] Saviq, so I can store it [09:44] Saviq, if it fails, it reverts [09:45] Cimi, you don't want to store the "last correct value", though, do you? [09:45] Cimi, we want to fall back to the default [09:45] Saviq, you asked to fallback to the last sane image [09:45] Cimi, not for the default? [09:45] like I have default, I set red, then blue, then wrong [09:46] I want to go back to blue [09:46] Cimi, that could be handled in CFI internally [09:46] Cimi, but anyway I don't think we should just "ignore" the change [09:46] Cimi, but instead go to the default [09:46] Cimi, if I said otherwise, sorry, I'm an a$$ [09:47] no problem [09:47] I discovered the craziness of qml and its signals :O [09:52] dednick: is the qevents branch a temporary workaround for the qt bug? [10:03] larsu: no, dont think qt will do anything about it. [10:03] larsu: that's the impression i got from them anyway [10:04] dednick: bummer. I assume we might hit this in other projects as well. [10:04] larsu: indeed. [10:04] dednick: anyway, I'll merge it, we need to get this rolling ;) [10:10] Cimi, yeah, I think that's the correct thing to do [10:10] Saviq, you mean I should revert to default without overriding the gsettings key? [10:10] Cimi, yes [10:10] Cimi, don't touch gsettings, but display the default [10:11] Saviq, so gsettings will keep the broken image? [10:11] Cimi, yes [10:11] Cimi, that's the correct thing to do [10:11] Cimi, we shouldn't be overwriting someone's settings just because our image failed to load [10:12] Cimi, we don't know the reason why it failed to load [10:12] Cimi, e.g. it might be unavailable right now, but on reboot will be there, for example [10:14] mzanetti: Saviq: so what we do with the ofono branch? [10:14] tsdgeos, let me ping jounih for feedback on it [10:15] Saviq: btw weird thing about the qdbusxml2cpp, we (as with my kde hat) run it on compile time all the time afaik [10:15] but not going to block on that [10:16] maybe we need to change the copyright notice though? or? [10:16] tsdgeos, yeah, was surprised to read that, but it does actually make sense [10:16] tsdgeos, same for qmltypes - we should only generate them on change, not build-time [10:17] (or do it build-time and compare to see if there's a difference and block on that, actually) [10:17] difference between the checked-in one and the generated one, that is [10:22] Saviq: tsdgeos: for the ofono branch we have 2 main questions: [10:23] a) should it be part of unity8 or not (I'd say yes) [10:23] 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] 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] that's how most of the phones i've had work [10:27] tsdgeos: yeah... you can cancel the PIN entry already now [10:27] 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] ah good stuff [10:28] dednick: there's a FIXME before you send the datachangeevent, but it seems to work fine. Is that just a left over? [10:29] larsu: yeah. i think i was just tagging code that needed the events put in [10:29] larsu: i'll remove quick. [10:30] dednick: don't worry about it, I'm removing it with the merge [10:30] larsu: ok. thanks [10:31] 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] oh, "isCheck" of course [10:32] larsu: toggle will be stored in state parameter no? [10:33] dednick: only for checks. For radios, you'd need to compare to "target", which "isToggled" does for you [10:33] 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] larsu: ah. i see. ok [10:33] 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] greyback, it's built from lp:platform-api via https://code.launchpad.net/~phablet-team/+recipe/platform-api-mir-daily [10:34] dednick: done. It's ready to merge from my side. [10:34] tsdgeos: I'll fix the FTBFS, I understand the Mir change that caused it [10:34] Saviq: ^^ [10:34] awesome :-) [10:34] larsu: cool. thanks for that. i'll check it all out asap [10:35] greyback, cool [10:35] dednick: okay. I'll be gone for the next hour or so. Lunchtime :) [10:35] greyback, let me know, I'll handle the recipes and the rebuilds [10:35] Saviq: ack [10:36] 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] tsdgeos: I was waiting for sil2100 's go-ahead, he had to block on that for some reason. [10:40] sil2100: can we get auto-landing on unity-mir, pretty please? [10:44] he ran away :D [10:57] sil2100: did you get the "unity-mir autolanding" msg? [10:57] sil2100: it was "can we get auto-landing on unity-mir, pretty please?" [10:58] Saviq: there are rumors that we want to move away from the ./build script. Is that true? [10:59] greyback_: ! [10:59] That's music to my ears [10:59] I missed it, but now I hear it [11:00] greyback_: does it build with everything that's in saucy now? [11:01] sil2100: ah yes, that was why we've to wait. Unfortunately not yet, ricmm has 2 MRs up to fix that [11:01] mzanetti, we already can [11:01] mzanetti, a simple cmake; make [11:01] mzanetti, is all we need [11:01] mzanetti, ./build is just a helper [11:01] Saviq: I know... I used that a lot [11:02] Saviq: still it does some other things too, doesn't it? [11:02] mzanetti, it installs build and runtime deps [11:02] mzanetti, but that can be done manually "the usual way" [11:02] mzanetti, that's ut [11:02] it [11:02] yeah... just wondering as Wellark told me it would be obsolete and will be removed "soon" [11:02] 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] mzanetti, that's probably an incorrect statement [11:03] mzanetti, I don't see a reason to remove it, really [11:03] mzanetti, other than maintainership [11:03] sil2100: not possible yet. When it is, you'll be first to know [11:05] greyback_: awesome, waiting for the signal then ;) [11:05] Wellark, I don't think we'll be removing the build script any time soon, it's just a helper script [11:05] Wellark, it's not needed any more, but speeds up things [11:05] we might remove the mention of it from CODING [11:05] 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] mzanetti, gsettings [11:06] ? [11:06] mzanetti, com.canonical.Unity.Launcher favorites [11:06] mzanetti, we should have an .override for it on the phone, but that's about it [11:06] Saviq: not talking about where to store them. but rather where to get a default list in case the setting is empty [11:06] ↑ [11:07] mzanetti, from gsettings' default [11:07] ok. [11:07] mzanetti, overridden by the .override file that I don't know what we'll ship it with yet [11:07] seb128, larsu, any updates on the "how do we handle settings different between form factors" topic? [11:08] i.e. default launcher favourites, default background and such? [11:09] and whether changing a setting "propagates" to different ffactors? [11:09] 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.

) and have the code bind to the right one [11:10] Saviq: hmm... are QSettings not to be used? [11:11] mzanetti, aren't QSettings being deprecated? [11:11] Saviq: that would be news to me [11:11] Saviq: they were, but they didn't write any replacement, so they undeprecated it :D [11:11] lol [11:12] oh boy... and I know the reason for all this :D [11:12] mzanetti, and anyway - we use gsettings in Ubuntu extensively, so gsettings-qt is the first place to look at [11:12] mzanetti, like we have for the background, for example [11:13] 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] 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] mzanetti, we're not "switching away from everything G*" [11:14] mzanetti, not where we're using it extensively on the desktop (like for gsettings) [11:14] mzanetti, and where there isn't a real alternative [11:14] hmm... I don't know enough about GSettings to judge that [11:15] just feels weird to completely write Qt apps but then use gsettings instead of QSettings. Thinking about portability of apps for example [11:15] not a real issue with unity, I agree [11:15] Saviq: ok, I will make sure unity8 launcher uses gsettings. I will check out gsettings-qt [11:16] Saviq: is it in main/universe? [11:16] Wellark: we already use it in unity iirc [11:16] anyone know if it's possible to block signals in qml? [11:16] dednick: define "block" signals [11:16] tsdgeos: Saviq: https://code.launchpad.net/~gerboland/unity-mir/fix-FTBFS-mir-951/+merge/179665 [11:17] mzanetti: change in property value causing signal. equiv of QObject::blockSignals [11:17] Saviq: do you have any other technical requirements for the launcher backend? [11:17] 14:06 < Saviq> mzanetti, com.canonical.Unity.Launcher favorites [11:18] Saviq: so, reuse the schema from unity7? [11:18] Wellark, yes [11:18] and paths [11:18] Wellark, wherever it makes sense, we should use the same [11:18] Saviq: do you have a spec for me or is it the old "dig the source, luke" [11:18] Wellark, I have nothing, can't say there is nothing, though [11:18] dednick: what's the issue with QObject::blockSignals [11:19] mzanetti: ? i'm in qml... [11:19] greyback_: shall i "auto-merge" ? [11:19] didrocks, are the unity gsettings schemas documented somewhere? [11:19] dednick: ah... qml. lemme check [11:19] tsdgeos: please [11:20] done [11:20] Wellark, they are effectively documented in the schema itself [11:20] tsdgeos, greyback_I can trigger platform-api build? [11:21] Wellark, http://bazaar.launchpad.net/~unity-team/unity/trunk/view/head:/com.canonical.Unity.gschema.xml [11:21] 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 === MacSlow is now known as MacSlow|lunch [11:22] Saviq: I don't think they are TBH :/ [11:22] mzanetti: ah. ok, thanks. [11:22] didrocks, the .xml is probably enough, really [11:22] Saviq: ok, thanks! [11:22] greyback_, hmm, the FTBFS was on lp:platform-api, though [11:22] dednick: if there isn't a enabled property there, you can set/unset the target property [11:22] Saviq: seems the schema is installed by libunity-core-6.0-7 [11:22] Saviq: odd, I just checked here and it was fine [11:22] Wellark, yes [11:23] greyback_, https://code.launchpad.net/~phablet-team/+archive/mir/+sourcepub/3419610/+listing-archive-extra [11:24] 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] Wellark, it already depends on unity-core [11:25] Saviq: or will unity8 have it's own unity-core [11:25] Saviq: unity-core does not bring in any unity7 binaries? [11:25] Wellark, no, it's just a utility library for "unity shells" [11:26] Wellark, whether it's unity7, unity-2d or unity8 [11:26] Wellark, but there are plans to split the schemas out anyway, I believe [11:27] Saviq: ok, sweet. I was worried if we run into trouble with pure unity8 systems or unity7/unity8 hybrids [11:27] but it's taken care off [11:36] mzanetti, we use gsettings for system settings, not app settings [11:36] mzanetti, and we are talking about writting a gsettings backend for qgsettings, maybe [11:36] seb128: ah ok [11:36] mzanetti, gsettings has some advantage, those keys are shared being component, not a db specific to an app [11:37] mzanetti, they also need to have system/vendor override and lockdown support [11:37] mzanetti, gsettings gives us all that today [11:37] seb128: sweet :) [11:37] ah, I see. thanks for clarifying [11:37] yw [11:37] seb128, Saviq: how complete is gsettings-qt? [11:37] does it give access to everything we need? [11:37] Wellark, complete enough, with Qt and QML bindings [11:38] Wellark, define "complete", it's working and being used in system settings and phone-app [11:38] Wellark, it has c++ and qml apis [11:38] complete as API parity with the GObject API [11:38] not yet [11:38] but you don't need most of things [11:38] ok. [11:39] Wellark, yeah, so in launcher-backend you'd probably use the c++ api [11:40] Saviq: yeah, AFAIK all I need is a way to write a list of values and read them back [11:40] Wellark, yup, that's what it'll give you [11:40] and get notification if somebody else messes with the list (webapps adding launcher entries, etc) [11:41] gsettings supports multiple writers, right? [11:41] you have read/write/notification on changes [11:55] Saviq, mzanetti: last I heard was that "someone" wanted to write a gsettings backend for qsettings [11:55] for apps [11:56] unity and other desktop components need more flexibility than qsettings, so they use gsettings directly (through a qt wrapper) === tvoss is now known as tvoss|quick_lunc === alan_g is now known as alan_g|lunch === _salem is now known as salem_ [12:20] Saviq: what package is providing the gicon qml loader? [12:20] Wellark, ui toolkit plugin [12:22]