=== _salem is now known as salem_ === salem_ is now known as _salem === mfisch` is now known as mfisch === mfisch is now known as Guest79256 === jono is now known as Guest36288 [07:24] veebers: hey [07:30] Saviq: when you have some time, please check the last comment here to see if you agree: https://code.launchpad.net/~kaijanmaki/unity8/launcher-backend/+merge/179663 [07:33] Do we have working .cmake files for Gio in some branch? [07:36] mzanetti, done [07:36] MacSlow, unity-notifications maybe? [07:37] MacSlow, or not, as you want it in there, right? [07:37] Saviq, that's what I'm writing it for currently [07:37] Saviq, correct [07:37] Saviq, I'm writing one atm... but have trouble getting it to work [07:38] thanks [07:50] hmmmm [07:51] i'm beginning to think something is broken in dee or dee-qt [07:52] i have a QLimitFilterModel whose first element is "Fitxers i carpetes" get a sourceRowsAboutToBeRemoved 11 11 and then the first element is not "Fitxers i carpetes" but "Google Drive" :S [07:53] * tsdgeos adds some debugging to dee-qt [08:07] * tsdgeos isn't happy with dee-qt debugs [08:07] http://paste.ubuntu.com/6009437/ [08:07] why you say you remove 11 but remove 0? [08:17] Saviq, made compiling and linking against gio work now [08:17] MacSlow, k thanks [08:18] tsdgeos, uh oh [08:18] Saviq: ok, i think i know what's causing that [08:18] not sure that's our root problem though [08:19] that's being caused because when dee says "removed" it's actually "aboutToRemove" [08:19] and there's no "reallyRemoved" [08:19] so we're always one step behind [08:19] ah [08:19] that upsets my debugging [08:19] not sure if it upset consumers too [08:20] tsdgeos, when you decide to do it, you might want to salvage some tests from https://code.launchpad.net/~unity-team/dee-qt/deevarianttext-and-tests/+merge/153530 [08:20] since you say "remove row 0" so the consumer probably expects that the row is gone but is still not gone [08:21] * tsdgeos wonders how hard would be for dee to provide a reallyRemovedSignal [08:21] mzanetti: hey, what's the haps? [08:22] tsdgeos, probably an mhr3 question [08:23] pstolowski, or maybe you can point tsdgeos somewhere ↑↑? [08:27] Saviq, tsdgeos: I'm not familar with dee internals, check with mhr3 pls [08:27] pstolowski, thanks [08:28] well adding the signal should not be hard [08:28] i've the code here [08:28] the thing is if makes sense :D [08:30] because you do a row-removed (iter), then you'd need a row-really-removed(void) since passing the iter there obviously makes no sense, that's what qmodel does, but not sure assuming there will be no more than one begin before the next end is a dee thing [08:30] probably it is [08:30] that'd actually help me a lot debugging this thing [08:30] let's invoke a mhr3 [08:31] lol [08:31] it worked :D [08:31] rotfl [08:31] your wish is my command [08:31] mhr3: how hard would it be to add a row-really-removed signal to dee? [08:32] i'm finding my debugging (and probably the qt models) get [08:32] confused because removed is "going to remove" [08:32] but we translate that in dee-qt to "has been removed" [08:32] Saviq, hm... the symbol resolving of the gio-calls fails at runtime... not sure why.. so I'm back to cmake-trouble-solving [08:32] tsdgeos, a sec, got a standup now [08:32] and from then on all sort of weird things happen when i try to make sure tthe models are in sync [08:46] Saviq: do you know when winstack dbus api is going to land on the phone? === Emmy is now known as EMMY [08:50] Saviq: ping [08:57] larsu: ping === EMMY is now known as Emmy [09:14] mhr3_: ping-when-you-have-time [09:18] Cimi: lol... I wanted to build a package of unity8 and the testClock failed because it was 11:13 [09:18] Cimi: there must be something wrong in the check [09:19] Cimi: right... because the test checks for "11:13" but the greeter says "11:13 AM" [09:19] lol... what are the odds [09:20] tsdgeos, ready [09:21] mhr3: how hard would it be to add a row-really-removed signal to dee? [09:21] that signals when the removal frmo the model has happened? [09:22] tsdgeos, i'd rather change qtdee to properly translate the events to the qt world [09:22] mhr3_: well, but it can't [09:22] that's why i need the new signal :D [09:23] everything is possible [09:23] tsdgeos, so why is it failing [09:23] do you try to read the actual data inside the callback? [09:23] mhr3_: adidas? [09:24] mhr3_: well qt has a signal that needs to be emitted before the data is removed and one after the data is removed [09:24] if you tell me how to do that with the signals dee has [09:24] i'm happy to [09:24] Saviq, linking issue solved... if you check your latest email you'll see some progress on the extended snap-decision front [09:25] same for insertion btw [09:25] but i think insertion is less problematic [09:25] tsdgeos, ultimately it has to be a problem that when the end signal is emitted you call something and gives you inconsistent state of the model, right? [09:25] my question is what is that something [09:26] i don't call anything [09:26] data(), no? [09:26] stuff is connected to my signals [09:26] and that stuff is reacting to those signals [09:26] and if we lie in the signals [09:26] they get unhappy [09:28] but the signals themselves don't lie [09:28] but there's difference in call semantics between dee and qt [09:29] mzanetti, you want to fix it or let me do? [09:29] Cimi: already fixed it. [09:29] tsdgeos, can you provide an example of where do the signals lie [09:30] not the dee ones [09:30] the dee-qt ones [09:30] because i can't do what i need to do with what dee gives me (or at least i don't see how to do it) [09:30] Cimi: https://code.launchpad.net/~mzanetti/unity8/allow-testing-at-11.13/+merge/181231 [09:31] tsdgeos, can you be specific, what's actually wrong that makes the code fall over [09:31] well i told you [09:31] i need to emit a signal before remove starts [09:31] and one after removal ends [09:32] i don't know how to do the one after removal ends [09:32] so right now the code is just emitting while removal has not finished [09:33] unless we decide dee-qt should mirror all the data instead of calling dee_model_get_value [09:33] then i can do that just fine [09:33] but i don't think it's a good idea to copy all the data over [09:34] ultimately it's a problem of a single signal vs two, it's not exactly trivial to go from one to two [09:37] dednick, pong [09:37] MacSlow, cool, thanks [09:38] mhr3_: ok, i guess that's a no to adding the "really-removed-signal" from your side [09:38] i'll see what i can do in dee-qt then [09:39] tsdgeos, no, i'd like a cleaner solution [09:39] tsdgeos, wondering what that is now [09:39] there's nothing cleaner than emmiting a signal in your side [09:39] which from looking at the code [09:39] Saviq: howdy. have another indicator switchover branch. Network this time. https://code.launchpad.net/~nick-dedekind/unity8/unitymenumodel.network/+merge/181147 [09:39] looks like 10 lines [09:39] at most [09:39] Saviq: think i got the diff right this time. [09:41] dednick, so that's temporary while we don't have the extended snap decisions, right? you just brought the Network plugin back? [09:41] Saviq: well, some of the qml will stay (the accesspoint menu items for example), but yes, the agent stuff will be removed later. === tvoss_ is now known as tvoss|lunch [09:44] dednick, yup, thanks [09:47] tsdgeos, but it's doubling the number of signals, and those are not cheap in gworld [09:54] Saviq, back to the models if you have a second? https://pastebin.canonical.com/96140/ [09:55] That's not displaying anything, although the model prints out fine. [09:55] (The model of the ListView that is) [09:59] Saviq, btw even when I use a rectangle there aren't any rows being made. [09:59] nic-doffay, the OptionSelector delagate looks wrong, shouldn't you set its model first? [10:00] mhr3_, I was setting it internally for now just to test. [10:00] nic-doffay, and shouldn't the items be "modelData.name"? [10:00] nic-doffay, OptionSelector needs *something* to display === rachelliu_ is now known as rachelliu [10:01] mhr3_, no, modelData is only used for simple models [10:01] Saviq, the optionSelector isn't created. Even a simple rectangle isn't made. [10:01] mhr3_, for models with roles, straight roles can be used [10:01] Saviq, once I get past that issue the rest should be easy. [10:01] ah, thx [10:01] nic-doffay, your ListView needs a height [10:01] mhr3_, or model.roleName [10:01] nic-doffay, that's first [10:02] nic-doffay, dimensions in general [10:02] Saviq, it does, I just omitted the code. [10:02] nic-doffay, again, ListViews don't have any implicit height [10:02] Saviq, I'm setting the anchors. [10:02] nic-doffay, you should not omit code if we are to see something [10:02] nic-doffay, does onCountChanged: console.log(count) print anything? [10:03] Saviq, here's the unomitted code: https://pastebin.canonical.com/96141/ [10:03] I'll check that now. [10:03] nic-doffay, if you replace model: scope.filters with model: 10, does it create 10 delegates? [10:03] Saviq, yeah. [10:03] Count is 0 btw. [10:03] if using scope.filters [10:04] mhr3_: Saviq: so http://paste.ubuntu.com/6009700/ fixes the problems for me, but to be honest that code (even removing the debugs) gives me an ultra cringe, and of course abuses the fact that almost noone uses beginInsertRows to access the "old" model data [10:04] nic-doffay, sounds like scope.filters is empty [10:04] nic-doffay, you could check by adding some debugging in filters.cpp in rowCount() [10:06] tsdgeos, yea, that's pretty horrible :/ [10:07] Saviq, I'll take a look, ta [10:07] nic-doffay, but if onCountChanged only prints 0, too, that's basically the same thing - the model is empty [10:08] Saviq, cool I'm doing more digging. [10:08] tsdgeos, so things are actually calling the data() method when removeEnd is emitted? [10:08] and that's what's causing the problem ultimately? [10:10] yes [10:10] data() and count() and stuff [10:11] model is supposed to be consistent at all times [10:17] hmm i think i can cheat in data() probably and make as if that row had been already deleted [10:18] * tsdgeos tries a different ugly solution to see if that one works [10:20] tsdgeos, exactly what i was trying right now [10:21] tsdgeos, http://paste.ubuntu.com/6009762/ === hikiko is now known as hikiko|lunch [10:21] mzanetti, Cimi re: "testing @ 11:13"... UGH! [10:21] Saviq, :D [10:22] Saviq: hehe... we actually knew about this issue and had a check against it. [10:22] Saviq: but that check had an issue :D [10:22] mzanetti, Y2K, I tell you :P [10:23] tsdgeos, can you try that patch? [10:23] yes [10:23] tsdgeos, it's still horrible, but there's less of the horrible code [10:23] :) [10:34] dednick, so, to test the network switchover, chewie goes away, I install indicator-network and it should all be fine? [10:35] dednick, do we not remove the .indicator file from unity8? [10:35] Saviq: you'll probably still have a duplicate [10:35] Saviq: because if we release this first, we will have no network indicator. [10:36] dednick, but if we merge that and fix the seed, we can remove the .indicator? [10:36] Saviq: i thought it better to just do the small removal of the file later. [10:36] dednick, nah, let's do a proper switchover - we have time until late afternoon [10:37] Saviq: ok then. i'll remove the chewie code [10:38] pstolowski, isn't there a missing qmlRegisterType? [10:39] in the unity plugin? [10:39] mhr3_, yes there is [10:39] mhr3_: that also "works" (well actually not your patch but the one I wrote that stores the position as int instead of as iter) [10:39] tsdgeos, hm, i was about to do that as an optimization, odd that it doesn't work [10:40] mhr3_: hmm, checking [10:40] pstolowski, see what saviq said ^ [10:40] mhr3_: i mean i know my patch works, yours i don't know, i assume yours probably works too [10:40] pstolowski, mhr3_, we saw that yesterday with nic-doffay [10:40] tsdgeos, ah, ok [10:40] that's what i meant with "not your patch", not that it didn't work, but that i wasn't trying it [10:41] pstolowski, mhr3_, he'll add it in the enable-filters-ui branch [10:41] ok, thx [10:43] saviq, we need dee-2.0 that maps nicer to qt :) [10:43] mhr3_, go for it! [10:43] still got a week before feature freeze, right? :P [10:43] otoh that's how long ci takes to setup [10:45] Saviq: he'll add what? qmlRegisterType ? [10:45] pstolowski, yes [10:45] Saviq: ok, thanks [10:46] pstolowski, there were some CMake leftovers after removing combined options, too [10:46] pstolowski, no idea how it went through with CMake if the files were not there... [10:46] Saviq: hmm [10:46] cmake doesn't need the sources, it's magic [10:47] mhr3_, exactly! [10:47] dednick, ok, seems to work! can we prepare ogra for the switch? -chewie +indicator-network, right? [10:48] Saviq: yep [10:48] dednick, only regression is the signal strength icons [10:48] Saviq: yeah, i'm working on the fix, but thostr_ said it is ok for now. [10:49] dednick, ok, .indicator file gone? [10:50] Saviq: yes, it's gone. === tvoss|lunch is now known as tvoss_ [11:00] mzanetti, https://code.launchpad.net/~mzanetti/unity8/launcher-folding-tweaks/+merge/181208/comments/410241 === MacSlow is now known as MacSlow|lunch [11:04] mhr3_: so can you review/approve https://code.launchpad.net/~aacid/dee-qt/behave_better/+merge/181258 ? [11:06] Saviq: seems like the SDK guys are fine with exposing all that popover theming stuff. [11:06] mzanetti, see! ;) [11:06] Saviq: timp will try to find the time to review/merge it today [11:06] mzanetti, cool [11:16] mhr3_: so now when using https://code.launchpad.net/~aacid/unity8/fix_qlimitproxymodel/+merge/181071 the problems you had with dash plugins filtering should be gone [11:16] mhr3_: can you confirm? (you need https://code.launchpad.net/~aacid/dee-qt/behave_better/+merge/181258 too) [11:17] tsdgeos, at least it explains why i couldn't see anything wrong with that branch :) [11:17] who's going to review https://code.launchpad.net/~aacid/unity8/fix_qlimitproxymodel/+merge/181071 ? Saviq? mzanetti? mhr3_? [11:17] mhr3_, care to do ↑? [11:17] saviqsure [11:17] eh [11:18] ;) [11:18] saviq you're breaking my irc client [11:18] it thinks there's two of you [11:18] with the same nick [11:19] and we thought writing shells is hard... irc clients that's the really tough piece of software [11:23] mhr3_, oh noes, you found out about my secret spy-on-people IRC account... === alan_g is now known as alan_g|afk === hikiko|lunch is now known as hikiko [11:39] tsdgeos, "qlimitproxymodelqml.cpp: bad whitespace in line 154" === cyphermox_ is now known as cyphermox [11:43] hmm, wondering if these fixes could fix the weirdness with the renderers visibility === alan_g|afk is now known as alan_g|lunch [12:26] Saviq: damn [12:31] is there a way to launch an app from commandline that is not behind the shell? (without the desktop file) === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow [12:41] om26er: no, the desktop file is a must [12:42] greyback, is that going to change in the future ? [12:42] the UbuntuUIToolkit have autopilot tests which rely on bla.qml files but they don't have a desktop file for them so they end up not showing on screen when there tests are run, hence failure [12:43] om26er: eventually yes. We'll always enforce a connection between an app and its desktop file, but hopefully it'll be quite transparent [12:43] om26er: maybe use an existing desktop file, as a workaround [12:44] greyback, ok, we can try that [12:45] mzanetti: whitespace fixed [12:45] mzanetti: wops [12:46] mhr3_: whitespace fixed [12:47] there is way to keep nexus10 from timing out and kicking me out of my ssh session. Anyone know the command? === alan_g|lunch is now known as alan_g [12:54] Saviq, pstolowski ran my branch with the same code and the model is being displayed properly. I still see nothing. Any idea why this would differ on two different machines? [12:56] tsdgeos, "damn" whitespace? [12:56] i'm not here :D [12:56] * tsdgeos runs [12:56] tsdgeos, no, was just asking if that's what you were referring to ;) [12:56] tsdgeos, I'm getting caught by it from time to time, but it's "damn" me then, not "damn" whitespace ;) [12:57] Saviq: damn whitespace yes [12:58] and me for not running the tests [12:58] nic-doffay, not really, other than different scope backend on the two machines? [12:58] obviously [13:00] Saviq, there is something that might be related on the line when I bind the scope.filters to the model I get this expression: TypeError: Result of expression is not an object [13:01] nic-doffay, if that's really related, that would suggest "scope" isn't an object, but it is most probably [13:02] Saviq, any way to get rid of the message? There's enough spam on output for the dash as it is. [13:02] nic-doffay, well... you need to fix whatever is causing the warning ;) [13:02] nic-doffay, and see what actually *is* [13:03] nic-doffay, it might be a simple "model: scope ? scope.filters : null" away [13:03] Saviq, I've tried that. [13:03] nic-doffay, then you need to verify that both "scope" and "scope.filters" are really what you want them to be [13:03] nic-doffay, but I actually expect the warning coming from somewhere else [13:04] Saviq, I'll try verify both. However there's still the issue about the varying scope backends. [13:04] Any idea how to get around that? [13:04] nic-doffay, first of all you need to verify that is actually the case, other than that - see if you have the same versions of libunity and libunity-core on both machines [13:04] nic-doffay, just dig, dig, dig [13:04] nic-doffay, sorry, I don't have all the answers at hand [13:06] woooooooooooooooooooooooooooooooooooo [13:06] i have stuff in my nexus4 screen [13:06] took 12 days but at least :D [13:06] greyback: ↑↑↑ [13:07] tsdgeos: yay!! [13:09] nic-doffay: sorry, I had a metting [13:10] pstolowski, no prob. [13:10] So, yeah I'm stumped about the filters. [13:11] Can you think of anything which would mean the same model isn't loaded on my PC? [13:12] tsdgeos: \o/ [13:13] dednick, I noticed the indicator-network branch landed! Are you adjusting the seeds or do you want me to? [13:16] hm [13:17] bregma, andyrock: regarding the compiz/0.9.10 branch [13:17] nic-doffay: perhaps there is some kind of timing issue and thus a random behavior... but since filters model handles additions and signals row insertion, this shouldn't matter... [13:18] sil2100, yes? [13:18] bregma, andyrock: I was browsing through history of that branch, and my question: [13:18] pstolowski, where is the filter count gotten from? [13:18] What sets it initially? [13:19] andyrock: the current compiz released to saucy has a lot of 'bugs' fixed, which can be seen from the changelog - but the compiz/0.9.10 branch doesn't seem to have the commits from those fixes in it [13:19] sil2100, we avoided a lot of those 'bug fixes' for reasons of stability, but now it's time to move on [13:19] andyrock: since it looks as if we were daily releasing further from the 0.9.9 branch and not all of the patches were ported back to 0.9.10 [13:20] sil2100, do you have a list? [13:20] maybe compiz trunk was not affected [13:20] Or forward-ported fits better [13:20] by those bugs [13:20] nic-doffay: the Filters model class that you're facing in QML wraps UnityCore filters model; it's the number of rows of underlying dee model [13:21] all changes were supposed to go into wither both branches or just 0.9.10 [13:21] either* [13:22] hm, ok hm [13:22] tsdgeos, top approved the branch... will you be working on the platform thing to properly handle uri activation? [13:23] mhr3_: Saviq was asssigned/doing that, i have a review to do for greyback and then i'll ask Saviq what he wants me to do :D [13:23] sil2100, if you have a list I can check one by one [13:24] tsdgeos, and didn't really get to it yet, either! [13:24] andyrock: it's hard to get the list, but I guess I see it's more or less ok here [13:24] it's always possible we missed enforcing that policy for some bugs [13:24] tsdgeos, so now you know what he'll ask :) [13:25] tedg: i believe it's being taken care of [13:26] tedg: or rather has been already [13:27] dednick, Great! [13:27] tsdgeos: greyback ....can one of you test the "pending" touch image for mir asap...and then provide feedback to ricmm & rsalveti [13:27] http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/ [13:28] just need to see if that fixes the "blank" screen at boot from mir [13:28] I'm also checking that as we speak to make sure it has the right bits [13:28] kgunn: you're late ;-) [13:28] [15:06:21] woooooooooooooooooooooooooooooooooooo [13:28] [15:06:27] i have stuff in my nexus4 screen [13:28] [15:06:45] took 12 days but at least :D [13:28] [15:06:47] greyback: ↑↑↑ [13:28] kgunn: that nexus4? If so, tsdgeos confirms it works [13:28] tsdgeos: i love being late :) === pstolowski is now known as pstolowski|lunch [13:28] awesome [13:29] :-) [13:29] tsdgeos, rsalveti kgunn \o/ [13:29] yep...thanks rsalveti [13:29] rsalveti: nice one [13:29] ....so now how to pull in mir ?....or do we need to sync with ricmm on that ? [13:30] kgunn: ricmm should be your guy for that indeed [13:32] andyrock, bregma, didrocks: ah, let's try the new compiz then [13:32] Doing the switch [13:32] sil2100: ok, but you are not rerunning the stack, right? [13:32] :D [13:32] otherwise, we will miss next tick [13:32] No no no no ;) [13:32] ok ;) [13:33] Just preparing for the next tick - be advised that unity stack might fail miserably! [13:33] * bregma does a cautious little dance [13:36] didrocks: it's hard to find the right rev-id to give in lp:compiz/0.9.10 for daily-release to start generating the changelog from [13:36] sil2100: maybe just ignore it? [13:36] sil2100: and put the last commit + a manual content? [13:38] didrocks: we could, but then there would be a lot of manual adding, as there are many bug-fixing commits that need mentioning so that the bugs get closed [13:38] didrocks: we decided with Mirv on a *probably* safe revision to start from [13:38] ok [13:38] ;) [13:39] We can always revert things if it's wrong! [13:39] * sil2100 likes to think that way to feel better [13:42] didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/enable_compiz/+merge/181306 <- can you do the honors? [13:42] Remember, we can *always* revert! [13:42] done [13:42] And manual publishing acts as the barier for releasing something that's bad or wrong [13:42] Thanks, redeploying and pushing unity changes [13:43] yeah, I hope that we won't have any other firedrilling today :p [13:43] What doesn't kill us makes us stronger, that's what they say at least [13:43] ;p === Guest79256 is now known as mfisch === pstolowski|lunch is now known as pstolowski [14:21] Saviq, you don't see onDisplayPowerStateChange being called? Odd... I'm sure I tested and it worked fine. I also didn't see the input issue... The only way I could think we'd do that is if we defocus apps due to a displaypower signal, but then you'd be seeing the greeter too [14:22] mterry_, yeah, it is weird, can you please verify that you do see it on your device? I'll try again [14:27] Saviq, sure. I also left a comment in the demo branch [14:30] mterry_, https://code.launchpad.net/~mterry/unity8/demo/+merge/177923/comments/410372 btw [14:31] Saviq, and that is with the deb installed? [14:32] Maybe something broke after the latest merge from trunk [14:32] Am building myself [14:33] mterry_, the unity8 deb? is that providing the address? [14:33] Saviq, you'll mostly need unity8-private [14:33] mterry_, ok, let me try again, I assume unity8 needs to be running for that? [14:34] Saviq, not for the dbus-send line, but you will want to killall accounts-daemon after installing, so it picks up new field [14:34] mterry_, ah, so it's tricky like that, didn't know how AccountsService works, brb with the result [14:35] Saviq, also, about the proximity branch, it seems to work fine for me. I put a printf in the onDisplayPowerStateChanged func, and I see the print plus the greeter [14:35] mterry_, ok, will try again [14:36] phone app seems to take input too [14:37] Saviq, the first time after killing accounts-daemon, the first dbus-send won't work (it doesn't wait long enough), so just retry [14:37] mterry_, ok [14:45] Saviq, hey man do you have any idea what this Hud work item means? [cimi] Streamline HUD invocation transitions: TODO [14:48] vesar: afair Oren wanted to improve how the HUD was invoked, the idea of the hud button staying around for more time even if you did release your finger, etc. [14:48] maybe is that? [14:48] vesar, tsdgeos it's Oren's indeed, so talking to him would be best :) [14:49] Saviq, tsdgeos: ok thanks. I'll have a chat with him then. === alan_g is now known as alan_g|tea === alan_g|tea is now known as alan_g [15:04] mterry_, https://code.launchpad.net/~mterry/unity8/demo/+merge/177923/comments/410397 [15:06] Saviq, :-/ Oh, I hadn't noticed that my demo .deb finished, will look myself [15:12] Saviq, I'm seeing the no-edge-demo problem, but not your dbus-send problem. Will look into why... Hopefully just a dumb typo when merging from trunk [15:13] tedg: you there? [15:13] tsdgeos, Yup [15:14] tedg: what's your expectaction of use of url-dispatcher, that people use url_dispatch_send from url-dispatcher.h? Does that spawn the daemon if needed? [15:17] tsdgeos, It would, but I put in an upstart job, so upstart should be guaranteeing it running. [15:17] ok [15:19] Saviq: couple of days later, can undo this change: https://code.launchpad.net/~gerboland/unity-mir/revert34/+merge/180338 [15:19] greyback, happroved [15:20] Saviq: thanks [15:22] Saviq: who do i speak with about lp:platform-api and where to put the code that calls url-dispatcher? [15:22] tsdgeos, ricmm [15:23] tsdgeos, I started this talk with him on Monday, but didn't really get anywhere / got distracted [15:24] tsdgeos: Saviq: do you know about QtDbus and how I can fake sending some signals to a running process? [15:24] didrocks: with the qdbus command line? or? [15:24] didrocks, for testing probably best to write a test helper and run under dbus-test-runner [15:24] I tried to send with gdbus, but I think it's similaire [15:24] Saviq: I'm just trying to do some manual tests right now [15:25] basically, I have a service with an old API [15:25] I wrote the client against the new dbus API [15:25] so starting the client starts the old service [15:25] I kill the service [15:25] and want to send the new signals by hand [15:25] didrocks: you should be able to use gdbus too [15:25] I can see my signals being delivered exactly the same way than the old service [15:25]