| === _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 | ||
| mzanetti | veebers: hey | 07:24 |
|---|---|---|
| mzanetti | 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:30 |
| MacSlow | Do we have working .cmake files for Gio in some branch? | 07:33 |
| Saviq | mzanetti, done | 07:36 |
| Saviq | MacSlow, unity-notifications maybe? | 07:36 |
| Saviq | MacSlow, or not, as you want it in there, right? | 07:37 |
| MacSlow | Saviq, that's what I'm writing it for currently | 07:37 |
| MacSlow | Saviq, correct | 07:37 |
| MacSlow | Saviq, I'm writing one atm... but have trouble getting it to work | 07:37 |
| mzanetti | thanks | 07:38 |
| tsdgeos | hmmmm | 07:50 |
| tsdgeos | i'm beginning to think something is broken in dee or dee-qt | 07:51 |
| tsdgeos | 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:52 |
| * tsdgeos adds some debugging to dee-qt | 07:53 | |
| * tsdgeos isn't happy with dee-qt debugs | 08:07 | |
| tsdgeos | http://paste.ubuntu.com/6009437/ | 08:07 |
| tsdgeos | why you say you remove 11 but remove 0? | 08:07 |
| MacSlow | Saviq, made compiling and linking against gio work now | 08:17 |
| Saviq | MacSlow, k thanks | 08:17 |
| Saviq | tsdgeos, uh oh | 08:18 |
| tsdgeos | Saviq: ok, i think i know what's causing that | 08:18 |
| tsdgeos | not sure that's our root problem though | 08:18 |
| tsdgeos | that's being caused because when dee says "removed" it's actually "aboutToRemove" | 08:19 |
| tsdgeos | and there's no "reallyRemoved" | 08:19 |
| tsdgeos | so we're always one step behind | 08:19 |
| Saviq | ah | 08:19 |
| tsdgeos | that upsets my debugging | 08:19 |
| tsdgeos | not sure if it upset consumers too | 08:19 |
| Saviq | 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 |
| tsdgeos | since you say "remove row 0" so the consumer probably expects that the row is gone but is still not gone | 08:20 |
| * tsdgeos wonders how hard would be for dee to provide a reallyRemovedSignal | 08:21 | |
| veebers | mzanetti: hey, what's the haps? | 08:21 |
| Saviq | tsdgeos, probably an mhr3 question | 08:22 |
| Saviq | pstolowski, or maybe you can point tsdgeos somewhere ↑↑? | 08:23 |
| pstolowski | Saviq, tsdgeos: I'm not familar with dee internals, check with mhr3 pls | 08:27 |
| Saviq | pstolowski, thanks | 08:27 |
| tsdgeos | well adding the signal should not be hard | 08:28 |
| tsdgeos | i've the code here | 08:28 |
| tsdgeos | the thing is if makes sense :D | 08:28 |
| tsdgeos | 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 |
| tsdgeos | probably it is | 08:30 |
| tsdgeos | that'd actually help me a lot debugging this thing | 08:30 |
| tsdgeos | let's invoke a mhr3 | 08:30 |
| tsdgeos | lol | 08:31 |
| tsdgeos | it worked :D | 08:31 |
| Saviq | rotfl | 08:31 |
| mhr3 | your wish is my command | 08:31 |
| tsdgeos | mhr3: how hard would it be to add a row-really-removed signal to dee? | 08:31 |
| tsdgeos | i'm finding my debugging (and probably the qt models) get | 08:32 |
| tsdgeos | confused because removed is "going to remove" | 08:32 |
| tsdgeos | but we translate that in dee-qt to "has been removed" | 08:32 |
| MacSlow | 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 |
| mhr3 | tsdgeos, a sec, got a standup now | 08:32 |
| tsdgeos | and from then on all sort of weird things happen when i try to make sure tthe models are in sync | 08:32 |
| pstolowski | Saviq: do you know when winstack dbus api is going to land on the phone? | 08:46 |
| === Emmy is now known as EMMY | ||
| dednick | Saviq: ping | 08:50 |
| dednick | larsu: ping | 08:57 |
| === EMMY is now known as Emmy | ||
| tsdgeos | mhr3_: ping-when-you-have-time | 09:14 |
| mzanetti | Cimi: lol... I wanted to build a package of unity8 and the testClock failed because it was 11:13 | 09:18 |
| mzanetti | Cimi: there must be something wrong in the check | 09:18 |
| mzanetti | Cimi: right... because the test checks for "11:13" but the greeter says "11:13 AM" | 09:19 |
| mzanetti | lol... what are the odds | 09:19 |
| mhr3_ | tsdgeos, ready | 09:20 |
| tsdgeos | mhr3: how hard would it be to add a row-really-removed signal to dee? | 09:21 |
| tsdgeos | that signals when the removal frmo the model has happened? | 09:21 |
| mhr3_ | tsdgeos, i'd rather change qtdee to properly translate the events to the qt world | 09:22 |
| tsdgeos | mhr3_: well, but it can't | 09:22 |
| tsdgeos | that's why i need the new signal :D | 09:22 |
| mhr3_ | everything is possible | 09:23 |
| mhr3_ | tsdgeos, so why is it failing | 09:23 |
| mhr3_ | do you try to read the actual data inside the callback? | 09:23 |
| tsdgeos | mhr3_: adidas? | 09:23 |
| tsdgeos | 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 |
| tsdgeos | if you tell me how to do that with the signals dee has | 09:24 |
| tsdgeos | i'm happy to | 09:24 |
| MacSlow | Saviq, linking issue solved... if you check your latest email you'll see some progress on the extended snap-decision front | 09:24 |
| tsdgeos | same for insertion btw | 09:25 |
| tsdgeos | but i think insertion is less problematic | 09:25 |
| mhr3_ | 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 |
| mhr3_ | my question is what is that something | 09:25 |
| tsdgeos | i don't call anything | 09:26 |
| mzanetti | data(), no? | 09:26 |
| tsdgeos | stuff is connected to my signals | 09:26 |
| tsdgeos | and that stuff is reacting to those signals | 09:26 |
| tsdgeos | and if we lie in the signals | 09:26 |
| tsdgeos | they get unhappy | 09:26 |
| mhr3_ | but the signals themselves don't lie | 09:28 |
| mhr3_ | but there's difference in call semantics between dee and qt | 09:28 |
| Cimi | mzanetti, you want to fix it or let me do? | 09:29 |
| mzanetti | Cimi: already fixed it. | 09:29 |
| mhr3_ | tsdgeos, can you provide an example of where do the signals lie | 09:29 |
| tsdgeos | not the dee ones | 09:30 |
| tsdgeos | the dee-qt ones | 09:30 |
| tsdgeos | 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 |
| mzanetti | Cimi: https://code.launchpad.net/~mzanetti/unity8/allow-testing-at-11.13/+merge/181231 | 09:30 |
| mhr3_ | tsdgeos, can you be specific, what's actually wrong that makes the code fall over | 09:31 |
| tsdgeos | well i told you | 09:31 |
| tsdgeos | i need to emit a signal before remove starts | 09:31 |
| tsdgeos | and one after removal ends | 09:31 |
| tsdgeos | i don't know how to do the one after removal ends | 09:32 |
| tsdgeos | so right now the code is just emitting while removal has not finished | 09:32 |
| tsdgeos | unless we decide dee-qt should mirror all the data instead of calling dee_model_get_value | 09:33 |
| tsdgeos | then i can do that just fine | 09:33 |
| tsdgeos | but i don't think it's a good idea to copy all the data over | 09:33 |
| mhr3_ | ultimately it's a problem of a single signal vs two, it's not exactly trivial to go from one to two | 09:34 |
| Saviq | dednick, pong | 09:37 |
| Saviq | MacSlow, cool, thanks | 09:37 |
| tsdgeos | mhr3_: ok, i guess that's a no to adding the "really-removed-signal" from your side | 09:38 |
| tsdgeos | i'll see what i can do in dee-qt then | 09:38 |
| mhr3_ | tsdgeos, no, i'd like a cleaner solution | 09:39 |
| mhr3_ | tsdgeos, wondering what that is now | 09:39 |
| tsdgeos | there's nothing cleaner than emmiting a signal in your side | 09:39 |
| tsdgeos | which from looking at the code | 09:39 |
| dednick | Saviq: howdy. have another indicator switchover branch. Network this time. https://code.launchpad.net/~nick-dedekind/unity8/unitymenumodel.network/+merge/181147 | 09:39 |
| tsdgeos | looks like 10 lines | 09:39 |
| tsdgeos | at most | 09:39 |
| dednick | Saviq: think i got the diff right this time. | 09:39 |
| Saviq | dednick, so that's temporary while we don't have the extended snap decisions, right? you just brought the Network plugin back? | 09:41 |
| dednick | Saviq: well, some of the qml will stay (the accesspoint menu items for example), but yes, the agent stuff will be removed later. | 09:41 |
| === tvoss_ is now known as tvoss|lunch | ||
| Saviq | dednick, yup, thanks | 09:44 |
| mhr3_ | tsdgeos, but it's doubling the number of signals, and those are not cheap in gworld | 09:47 |
| nic-doffay | Saviq, back to the models if you have a second? https://pastebin.canonical.com/96140/ | 09:54 |
| nic-doffay | That's not displaying anything, although the model prints out fine. | 09:55 |
| nic-doffay | (The model of the ListView that is) | 09:55 |
| nic-doffay | Saviq, btw even when I use a rectangle there aren't any rows being made. | 09:59 |
| mhr3_ | nic-doffay, the OptionSelector delagate looks wrong, shouldn't you set its model first? | 09:59 |
| nic-doffay | mhr3_, I was setting it internally for now just to test. | 10:00 |
| mhr3_ | nic-doffay, and shouldn't the items be "modelData.name"? | 10:00 |
| Saviq | nic-doffay, OptionSelector needs *something* to display | 10:00 |
| === rachelliu_ is now known as rachelliu | ||
| Saviq | mhr3_, no, modelData is only used for simple models | 10:01 |
| nic-doffay | Saviq, the optionSelector isn't created. Even a simple rectangle isn't made. | 10:01 |
| Saviq | mhr3_, for models with roles, straight roles can be used | 10:01 |
| nic-doffay | Saviq, once I get past that issue the rest should be easy. | 10:01 |
| mhr3_ | ah, thx | 10:01 |
| Saviq | nic-doffay, your ListView needs a height | 10:01 |
| Saviq | mhr3_, or model.roleName | 10:01 |
| Saviq | nic-doffay, that's first | 10:01 |
| Saviq | nic-doffay, dimensions in general | 10:02 |
| nic-doffay | Saviq, it does, I just omitted the code. | 10:02 |
| Saviq | nic-doffay, again, ListViews don't have any implicit height | 10:02 |
| nic-doffay | Saviq, I'm setting the anchors. | 10:02 |
| Saviq | nic-doffay, you should not omit code if we are to see something | 10:02 |
| Saviq | nic-doffay, does onCountChanged: console.log(count) print anything? | 10:02 |
| nic-doffay | Saviq, here's the unomitted code: https://pastebin.canonical.com/96141/ | 10:03 |
| nic-doffay | I'll check that now. | 10:03 |
| Saviq | nic-doffay, if you replace model: scope.filters with model: 10, does it create 10 delegates? | 10:03 |
| nic-doffay | Saviq, yeah. | 10:03 |
| nic-doffay | Count is 0 btw. | 10:03 |
| nic-doffay | if using scope.filters | 10:03 |
| tsdgeos | 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 |
| Saviq | nic-doffay, sounds like scope.filters is empty | 10:04 |
| Saviq | nic-doffay, you could check by adding some debugging in filters.cpp in rowCount() | 10:04 |
| mhr3_ | tsdgeos, yea, that's pretty horrible :/ | 10:06 |
| nic-doffay | Saviq, I'll take a look, ta | 10:07 |
| Saviq | nic-doffay, but if onCountChanged only prints 0, too, that's basically the same thing - the model is empty | 10:07 |
| nic-doffay | Saviq, cool I'm doing more digging. | 10:08 |
| mhr3_ | tsdgeos, so things are actually calling the data() method when removeEnd is emitted? | 10:08 |
| mhr3_ | and that's what's causing the problem ultimately? | 10:08 |
| tsdgeos | yes | 10:10 |
| tsdgeos | data() and count() and stuff | 10:10 |
| tsdgeos | model is supposed to be consistent at all times | 10:11 |
| tsdgeos | hmm i think i can cheat in data() probably and make as if that row had been already deleted | 10:17 |
| * tsdgeos tries a different ugly solution to see if that one works | 10:18 | |
| mhr3_ | tsdgeos, exactly what i was trying right now | 10:20 |
| mhr3_ | tsdgeos, http://paste.ubuntu.com/6009762/ | 10:21 |
| === hikiko is now known as hikiko|lunch | ||
| Saviq | mzanetti, Cimi re: "testing @ 11:13"... UGH! | 10:21 |
| Cimi | Saviq, :D | 10:21 |
| mzanetti | Saviq: hehe... we actually knew about this issue and had a check against it. | 10:22 |
| mzanetti | Saviq: but that check had an issue :D | 10:22 |
| Saviq | mzanetti, Y2K, I tell you :P | 10:22 |
| mhr3_ | tsdgeos, can you try that patch? | 10:23 |
| tsdgeos | yes | 10:23 |
| mhr3_ | tsdgeos, it's still horrible, but there's less of the horrible code | 10:23 |
| mhr3_ | :) | 10:23 |
| Saviq | dednick, so, to test the network switchover, chewie goes away, I install indicator-network and it should all be fine? | 10:34 |
| Saviq | dednick, do we not remove the .indicator file from unity8? | 10:35 |
| dednick | Saviq: you'll probably still have a duplicate | 10:35 |
| dednick | Saviq: because if we release this first, we will have no network indicator. | 10:35 |
| Saviq | dednick, but if we merge that and fix the seed, we can remove the .indicator? | 10:36 |
| dednick | Saviq: i thought it better to just do the small removal of the file later. | 10:36 |
| Saviq | dednick, nah, let's do a proper switchover - we have time until late afternoon | 10:36 |
| dednick | Saviq: ok then. i'll remove the chewie code | 10:37 |
| mhr3_ | pstolowski, isn't there a missing qmlRegisterType<Filters>? | 10:38 |
| mhr3_ | in the unity plugin? | 10:39 |
| Saviq | mhr3_, yes there is | 10:39 |
| tsdgeos | 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 |
| mhr3_ | tsdgeos, hm, i was about to do that as an optimization, odd that it doesn't work | 10:39 |
| pstolowski | mhr3_: hmm, checking | 10:40 |
| mhr3_ | pstolowski, see what saviq said ^ | 10:40 |
| tsdgeos | mhr3_: i mean i know my patch works, yours i don't know, i assume yours probably works too | 10:40 |
| Saviq | pstolowski, mhr3_, we saw that yesterday with nic-doffay | 10:40 |
| mhr3_ | tsdgeos, ah, ok | 10:40 |
| tsdgeos | that's what i meant with "not your patch", not that it didn't work, but that i wasn't trying it | 10:40 |
| Saviq | pstolowski, mhr3_, he'll add it in the enable-filters-ui branch | 10:41 |
| mhr3_ | ok, thx | 10:41 |
| mhr3_ | saviq, we need dee-2.0 that maps nicer to qt :) | 10:43 |
| Saviq | mhr3_, go for it! | 10:43 |
| mhr3_ | still got a week before feature freeze, right? :P | 10:43 |
| mhr3_ | otoh that's how long ci takes to setup | 10:43 |
| pstolowski | Saviq: he'll add what? qmlRegisterType<Filters> ? | 10:45 |
| Saviq | pstolowski, yes | 10:45 |
| pstolowski | Saviq: ok, thanks | 10:45 |
| Saviq | pstolowski, there were some CMake leftovers after removing combined options, too | 10:46 |
| Saviq | pstolowski, no idea how it went through with CMake if the files were not there... | 10:46 |
| pstolowski | Saviq: hmm | 10:46 |
| mhr3_ | cmake doesn't need the sources, it's magic | 10:46 |
| Saviq | mhr3_, exactly! | 10:47 |
| Saviq | dednick, ok, seems to work! can we prepare ogra for the switch? -chewie +indicator-network, right? | 10:47 |
| dednick | Saviq: yep | 10:48 |
| Saviq | dednick, only regression is the signal strength icons | 10:48 |
| dednick | Saviq: yeah, i'm working on the fix, but thostr_ said it is ok for now. | 10:48 |
| Saviq | dednick, ok, .indicator file gone? | 10:49 |
| dednick | Saviq: yes, it's gone. | 10:50 |
| === tvoss|lunch is now known as tvoss_ | ||
| Saviq | mzanetti, https://code.launchpad.net/~mzanetti/unity8/launcher-folding-tweaks/+merge/181208/comments/410241 | 11:00 |
| === MacSlow is now known as MacSlow|lunch | ||
| tsdgeos | mhr3_: so can you review/approve https://code.launchpad.net/~aacid/dee-qt/behave_better/+merge/181258 ? | 11:04 |
| mzanetti | Saviq: seems like the SDK guys are fine with exposing all that popover theming stuff. | 11:06 |
| Saviq | mzanetti, see! ;) | 11:06 |
| mzanetti | Saviq: timp will try to find the time to review/merge it today | 11:06 |
| Saviq | mzanetti, cool | 11:06 |
| tsdgeos | 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 |
| tsdgeos | mhr3_: can you confirm? (you need https://code.launchpad.net/~aacid/dee-qt/behave_better/+merge/181258 too) | 11:16 |
| mhr3_ | tsdgeos, at least it explains why i couldn't see anything wrong with that branch :) | 11:17 |
| tsdgeos | who's going to review https://code.launchpad.net/~aacid/unity8/fix_qlimitproxymodel/+merge/181071 ? Saviq? mzanetti? mhr3_? | 11:17 |
| Saviq | mhr3_, care to do ↑? | 11:17 |
| mhr3_ | saviqsure | 11:17 |
| mhr3_ | eh | 11:17 |
| Saviq | ;) | 11:18 |
| mhr3_ | saviq you're breaking my irc client | 11:18 |
| mhr3_ | it thinks there's two of you | 11:18 |
| mhr3_ | with the same nick | 11:18 |
| mhr3_ | and we thought writing shells is hard... irc clients that's the really tough piece of software | 11:19 |
| Saviq | mhr3_, oh noes, you found out about my secret spy-on-people IRC account... | 11:23 |
| === alan_g is now known as alan_g|afk | ||
| === hikiko|lunch is now known as hikiko | ||
| Saviq | tsdgeos, "qlimitproxymodelqml.cpp: bad whitespace in line 154" | 11:39 |
| === cyphermox_ is now known as cyphermox | ||
| mhr3_ | hmm, wondering if these fixes could fix the weirdness with the renderers visibility | 11:43 |
| === alan_g|afk is now known as alan_g|lunch | ||
| tsdgeos | Saviq: damn | 12:26 |
| om26er | is there a way to launch an app from commandline that is not behind the shell? (without the desktop file) | 12:31 |
| === _salem is now known as salem_ | ||
| === MacSlow|lunch is now known as MacSlow | ||
| greyback | om26er: no, the desktop file is a must | 12:41 |
| om26er | greyback, is that going to change in the future ? | 12:42 |
| om26er | 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:42 |
| greyback | 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 |
| greyback | om26er: maybe use an existing desktop file, as a workaround | 12:43 |
| om26er | greyback, ok, we can try that | 12:44 |
| tsdgeos | mzanetti: whitespace fixed | 12:45 |
| tsdgeos | mzanetti: wops | 12:45 |
| tsdgeos | mhr3_: whitespace fixed | 12:46 |
| greyback | there is way to keep nexus10 from timing out and kicking me out of my ssh session. Anyone know the command? | 12:47 |
| === alan_g|lunch is now known as alan_g | ||
| nic-doffay | 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:54 |
| Saviq | tsdgeos, "damn" whitespace? | 12:56 |
| tsdgeos | i'm not here :D | 12:56 |
| * tsdgeos runs | 12:56 | |
| Saviq | tsdgeos, no, was just asking if that's what you were referring to ;) | 12:56 |
| Saviq | tsdgeos, I'm getting caught by it from time to time, but it's "damn" me then, not "damn" whitespace ;) | 12:56 |
| tsdgeos | Saviq: damn whitespace yes | 12:57 |
| tsdgeos | and me for not running the tests | 12:58 |
| Saviq | nic-doffay, not really, other than different scope backend on the two machines? | 12:58 |
| tsdgeos | obviously | 12:58 |
| nic-doffay | 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:00 |
| Saviq | nic-doffay, if that's really related, that would suggest "scope" isn't an object, but it is most probably | 13:01 |
| nic-doffay | Saviq, any way to get rid of the message? There's enough spam on output for the dash as it is. | 13:02 |
| Saviq | nic-doffay, well... you need to fix whatever is causing the warning ;) | 13:02 |
| Saviq | nic-doffay, and see what actually *is* | 13:02 |
| Saviq | nic-doffay, it might be a simple "model: scope ? scope.filters : null" away | 13:03 |
| nic-doffay | Saviq, I've tried that. | 13:03 |
| Saviq | nic-doffay, then you need to verify that both "scope" and "scope.filters" are really what you want them to be | 13:03 |
| Saviq | nic-doffay, but I actually expect the warning coming from somewhere else | 13:03 |
| nic-doffay | Saviq, I'll try verify both. However there's still the issue about the varying scope backends. | 13:04 |
| nic-doffay | Any idea how to get around that? | 13:04 |
| Saviq | 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 |
| Saviq | nic-doffay, just dig, dig, dig | 13:04 |
| Saviq | nic-doffay, sorry, I don't have all the answers at hand | 13:04 |
| tsdgeos | woooooooooooooooooooooooooooooooooooo | 13:06 |
| tsdgeos | i have stuff in my nexus4 screen | 13:06 |
| tsdgeos | took 12 days but at least :D | 13:06 |
| tsdgeos | greyback: ↑↑↑ | 13:06 |
| greyback | tsdgeos: yay!! | 13:07 |
| pstolowski | nic-doffay: sorry, I had a metting | 13:09 |
| nic-doffay | pstolowski, no prob. | 13:10 |
| nic-doffay | So, yeah I'm stumped about the filters. | 13:10 |
| nic-doffay | Can you think of anything which would mean the same model isn't loaded on my PC? | 13:11 |
| mzanetti | tsdgeos: \o/ | 13:12 |
| tedg | dednick, I noticed the indicator-network branch landed! Are you adjusting the seeds or do you want me to? | 13:13 |
| sil2100 | hm | 13:16 |
| sil2100 | bregma, andyrock: regarding the compiz/0.9.10 branch | 13:17 |
| pstolowski | 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:17 |
| andyrock | sil2100, yes? | 13:18 |
| sil2100 | bregma, andyrock: I was browsing through history of that branch, and my question: | 13:18 |
| nic-doffay | pstolowski, where is the filter count gotten from? | 13:18 |
| nic-doffay | What sets it initially? | 13:18 |
| sil2100 | 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 |
| bregma | sil2100, we avoided a lot of those 'bug fixes' for reasons of stability, but now it's time to move on | 13:19 |
| sil2100 | 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:19 |
| andyrock | sil2100, do you have a list? | 13:20 |
| andyrock | maybe compiz trunk was not affected | 13:20 |
| sil2100 | Or forward-ported fits better | 13:20 |
| andyrock | by those bugs | 13:20 |
| pstolowski | 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:20 |
| bregma | all changes were supposed to go into wither both branches or just 0.9.10 | 13:21 |
| bregma | either* | 13:21 |
| sil2100 | hm, ok hm | 13:22 |
| mhr3_ | tsdgeos, top approved the branch... will you be working on the platform thing to properly handle uri activation? | 13:22 |
| tsdgeos | 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 |
| andyrock | sil2100, if you have a list I can check one by one | 13:23 |
| Saviq | tsdgeos, and didn't really get to it yet, either! | 13:24 |
| sil2100 | andyrock: it's hard to get the list, but I guess I see it's more or less ok here | 13:24 |
| bregma | it's always possible we missed enforcing that policy for some bugs | 13:24 |
| mhr3_ | tsdgeos, so now you know what he'll ask :) | 13:24 |
| dednick | tedg: i believe it's being taken care of | 13:25 |
| dednick | tedg: or rather has been already | 13:26 |
| tedg | dednick, Great! | 13:27 |
| kgunn | tsdgeos: greyback ....can one of you test the "pending" touch image for mir asap...and then provide feedback to ricmm & rsalveti | 13:27 |
| kgunn | http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/pending/ | 13:27 |
| kgunn | just need to see if that fixes the "blank" screen at boot from mir | 13:28 |
| rsalveti | I'm also checking that as we speak to make sure it has the right bits | 13:28 |
| tsdgeos | kgunn: you're late ;-) | 13:28 |
| tsdgeos | [15:06:21] <tsdgeos> woooooooooooooooooooooooooooooooooooo | 13:28 |
| tsdgeos | [15:06:27] <tsdgeos> i have stuff in my nexus4 screen | 13:28 |
| tsdgeos | [15:06:45] <tsdgeos> took 12 days but at least :D | 13:28 |
| tsdgeos | [15:06:47] <tsdgeos> greyback: ↑↑↑ | 13:28 |
| greyback | kgunn: that nexus4? If so, tsdgeos confirms it works | 13:28 |
| kgunn | tsdgeos: i love being late :) | 13:28 |
| === pstolowski is now known as pstolowski|lunch | ||
| rsalveti | awesome | 13:28 |
| rsalveti | :-) | 13:29 |
| Saviq | tsdgeos, rsalveti kgunn \o/ | 13:29 |
| kgunn | yep...thanks rsalveti | 13:29 |
| greyback | rsalveti: nice one | 13:29 |
| kgunn | ....so now how to pull in mir ?....or do we need to sync with ricmm on that ? | 13:29 |
| rsalveti | kgunn: ricmm should be your guy for that indeed | 13:30 |
| sil2100 | andyrock, bregma, didrocks: ah, let's try the new compiz then | 13:32 |
| sil2100 | Doing the switch | 13:32 |
| didrocks | sil2100: ok, but you are not rerunning the stack, right? | 13:32 |
| andyrock | :D | 13:32 |
| didrocks | otherwise, we will miss next tick | 13:32 |
| sil2100 | No no no no ;) | 13:32 |
| didrocks | ok ;) | 13:32 |
| sil2100 | Just preparing for the next tick - be advised that unity stack might fail miserably! | 13:33 |
| * bregma does a cautious little dance | 13:33 | |
| sil2100 | 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 |
| didrocks | sil2100: maybe just ignore it? | 13:36 |
| didrocks | sil2100: and put the last commit + a manual content? | 13:36 |
| sil2100 | 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 |
| sil2100 | didrocks: we decided with Mirv on a *probably* safe revision to start from | 13:38 |
| didrocks | ok | 13:38 |
| sil2100 | ;) | 13:38 |
| sil2100 | We can always revert things if it's wrong! | 13:39 |
| * sil2100 likes to think that way to feel better | 13:39 | |
| sil2100 | didrocks: https://code.launchpad.net/~sil2100/cupstream2distro-config/enable_compiz/+merge/181306 <- can you do the honors? | 13:42 |
| sil2100 | Remember, we can *always* revert! | 13:42 |
| didrocks | done | 13:42 |
| sil2100 | And manual publishing acts as the barier for releasing something that's bad or wrong | 13:42 |
| sil2100 | Thanks, redeploying and pushing unity changes | 13:42 |
| didrocks | yeah, I hope that we won't have any other firedrilling today :p | 13:43 |
| sil2100 | What doesn't kill us makes us stronger, that's what they say at least | 13:43 |
| sil2100 | ;p | 13:43 |
| === Guest79256 is now known as mfisch | ||
| === pstolowski|lunch is now known as pstolowski | ||
| mterry_ | 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:21 |
| Saviq | mterry_, yeah, it is weird, can you please verify that you do see it on your device? I'll try again | 14:22 |
| mterry_ | Saviq, sure. I also left a comment in the demo branch | 14:27 |
| Saviq | mterry_, https://code.launchpad.net/~mterry/unity8/demo/+merge/177923/comments/410372 btw | 14:30 |
| mterry_ | Saviq, and that is with the deb installed? | 14:31 |
| mterry_ | Maybe something broke after the latest merge from trunk | 14:32 |
| mterry_ | Am building myself | 14:32 |
| Saviq | mterry_, the unity8 deb? is that providing the address? | 14:33 |
| mterry_ | Saviq, you'll mostly need unity8-private | 14:33 |
| Saviq | mterry_, ok, let me try again, I assume unity8 needs to be running for that? | 14:33 |
| mterry_ | 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 |
| Saviq | mterry_, ah, so it's tricky like that, didn't know how AccountsService works, brb with the result | 14:34 |
| mterry_ | 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 |
| Saviq | mterry_, ok, will try again | 14:35 |
| mterry_ | phone app seems to take input too | 14:36 |
| mterry_ | 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 |
| Saviq | mterry_, ok | 14:37 |
| vesar | Saviq, hey man do you have any idea what this Hud work item means? [cimi] Streamline HUD invocation transitions: TODO | 14:45 |
| tsdgeos | 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 |
| tsdgeos | maybe is that? | 14:48 |
| Saviq | vesar, tsdgeos it's Oren's indeed, so talking to him would be best :) | 14:48 |
| vesar | Saviq, tsdgeos: ok thanks. I'll have a chat with him then. | 14:49 |
| === alan_g is now known as alan_g|tea | ||
| === alan_g|tea is now known as alan_g | ||
| Saviq | mterry_, https://code.launchpad.net/~mterry/unity8/demo/+merge/177923/comments/410397 | 15:04 |
| mterry_ | Saviq, :-/ Oh, I hadn't noticed that my demo .deb finished, will look myself | 15:06 |
| mterry_ | 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:12 |
| tsdgeos | tedg: you there? | 15:13 |
| tedg | tsdgeos, Yup | 15:13 |
| tsdgeos | 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:14 |
| tedg | tsdgeos, It would, but I put in an upstart job, so upstart should be guaranteeing it running. | 15:17 |
| tsdgeos | ok | 15:17 |
| greyback | Saviq: couple of days later, can undo this change: https://code.launchpad.net/~gerboland/unity-mir/revert34/+merge/180338 | 15:19 |
| Saviq | greyback, happroved | 15:19 |
| greyback | Saviq: thanks | 15:20 |
| tsdgeos | Saviq: who do i speak with about lp:platform-api and where to put the code that calls url-dispatcher? | 15:22 |
| Saviq | tsdgeos, ricmm | 15:22 |
| Saviq | tsdgeos, I started this talk with him on Monday, but didn't really get anywhere / got distracted | 15:23 |
| didrocks | tsdgeos: Saviq: do you know about QtDbus and how I can fake sending some signals to a running process? | 15:24 |
| tsdgeos | didrocks: with the qdbus command line? or? | 15:24 |
| Saviq | didrocks, for testing probably best to write a test helper and run under dbus-test-runner | 15:24 |
| didrocks | I tried to send with gdbus, but I think it's similaire | 15:24 |
| didrocks | Saviq: I'm just trying to do some manual tests right now | 15:24 |
| didrocks | basically, I have a service with an old API | 15:25 |
| didrocks | I wrote the client against the new dbus API | 15:25 |
| didrocks | so starting the client starts the old service | 15:25 |
| didrocks | I kill the service | 15:25 |
| didrocks | and want to send the new signals by hand | 15:25 |
| tsdgeos | didrocks: you should be able to use gdbus too | 15:25 |
| didrocks | I can see my signals being delivered exactly the same way than the old service | 15:25 |
| didrocks | but the client doesn't pick that up | 15:25 |
| didrocks | I fear that QtDbus stays on the old well-known name | 15:26 |
| didrocks | basically: | 15:26 |
| didrocks | signal sender=:1.244 -> dest=(null destination) serial=5 path=/Service; interface=com.canonical.SystemImage; member=UpdateAvailableStatus | 15:26 |
| didrocks | boolean false | 15:26 |
| didrocks | ^ send by the service | 15:26 |
| didrocks | signal sender=:1.245 -> dest=(null destination) serial=2 path=/Service; interface=com.canonical.SystemImage; member=UpdateAvailableStatus | 15:26 |
| didrocks | boolean true | 15:26 |
| didrocks | ^ send by me | 15:27 |
| didrocks | (and yes, false/true doesn't change anything) | 15:27 |
| tsdgeos | you may need to use qdbuswatcher to reconnect? | 15:27 |
| tsdgeos | qdbusservicewatcher | 15:27 |
| didrocks | tsdgeos: ah, qtdbus doesn't do it automatically? | 15:27 |
| tsdgeos | i guess not | 15:29 |
| tsdgeos | don't recall if it should work tbh | 15:29 |
| tsdgeos | didrocks: basically you are connecting to a service, then the service is going down and up in a different process and you're not getting it's signals, right? | 15:30 |
| didrocks | tsdgeos: I can try simulate that, to see if it's really the case (or just due to me sending the signal manually) | 15:31 |
| didrocks | one sec | 15:32 |
| didrocks | tsdgeos: no, that case work | 15:33 |
| didrocks | like sendMethod -> signal received; kill daemon, sendMethod -> signal received from new daemon | 15:33 |
| didrocks | but in those cases, contrary to always doing it by hand, there is sendMethod done | 15:35 |
| didrocks | so maybe qtdbus reconnects to any new well-known name | 15:35 |
| * tsdgeos is not following | 15:38 | |
| didrocks | tsdgeos: basically this works: | 15:39 |
| didrocks | client sendMethod() -> daemon wake up and send back a signal -> client receive the signal ; I kill the daemon; client resend sendMethod() -> a new daemon woke up and send back a signal -> the client receives the signal | 15:39 |
| didrocks | this doesn't work: | 15:40 |
| didrocks | client sendMethod() -> daemon wake up and send back a signal -> client receive the signal ; I kill the daemon; I send via gdbus the same signal with the same parameters -> client doesn't receive the signal | 15:40 |
| didrocks | tsdgeos: makes more sense? ^ | 15:40 |
| tsdgeos | ah ok | 15:41 |
| tsdgeos | is that expected to work? | 15:41 |
| didrocks | not sure TBH ;) | 15:41 |
| didrocks | was trying to mock the new signal APIs that way | 15:41 |
| didrocks | (just for some manual tests) | 15:41 |
| Saviq | didrocks, so you want to fake the client doing sendMethod()? | 15:42 |
| Saviq | didrocks, it probably depends on whether signals are unicast or broad/multicast? | 15:42 |
| Saviq | didrocks, I think the problem is that the signal might be sent before the client reconnects | 15:43 |
| Saviq | s/is/might be/ | 15:43 |
| Saviq | didrocks, so the client misses the signal | 15:43 |
| didrocks | Saviq: I want to fake the daemon sending the signal | 15:43 |
| didrocks | but yeah, I think the client doesn't reconnect to the new name | 15:44 |
| tsdgeos | didrocks: probably you need to send the "hi world this name belongs to me now" | 15:44 |
| tsdgeos | that gdbus is not doing while the real daemon does it | 15:44 |
| didrocks | tsdgeos: I think you're right | 15:44 |
| didrocks | not sure how to force gdbus to do it though ;) | 15:45 |
| === dednick is now known as dednick|lunch | ||
| tsdgeos | didrocks: my suggestion, use a dbus monitor and see what the daemon does when spawning itself | 15:46 |
| tsdgeos | then replicate that | 15:46 |
| seb128 | didrocks, seems like it would be easier to just write a small python script service | 15:46 |
| mterry_ | Saviq, OK, I think I fixed the demo issue. Seemed like startup of AccountsService was racy (first time usually wouldn't work, other times would always work). So I needed to add an explicit startService() call. Try again | 15:47 |
| didrocks | seb128: yeah, seems so | 15:47 |
| mterry_ | Saviq, though... you were seeing a dbus-send error that I wasn't | 15:47 |
| didrocks | seb128: or having the backend guys providing the mock as we were supposed :p | 15:47 |
| didrocks | anyway, thanks tsdgeos, Saviq ;) | 15:47 |
| Saviq | mterry_, will do | 15:47 |
| seb128 | didrocks, try asking slangasek if he can gets barry out of his morning meetings so he can do the mock work done :p | 15:48 |
| slangasek | ? | 15:48 |
| seb128 | slangasek, we need to get system-settings's update panel done, didrocks is on holidays in 2 days, but work is (still) blocked on barry to provide service side changes | 15:56 |
| seb128 | slangasek, barry said he can't do them this morning because he has meetings, e.g we keep being delayed | 15:56 |
| seb128 | slangasek, is there anything you can do so barry can focus on getting his part done so didrocks has a chance to get the settings side done before his holidays? | 15:57 |
| slangasek | seb128: the meeting is over now | 15:59 |
| seb128 | slangasek, from what he said he sounded like all morning would be meetings | 15:59 |
| slangasek | certainly not anything to do with me, if so | 15:59 |
| seb128 | but if meeting time is over, great | 15:59 |
| slangasek | 1.5h total | 15:59 |
| seb128 | slangasek, thanks ;-) | 16:00 |
| mzanetti | Saviq: this seems to still happen every now and then: https://jenkins.qa.ubuntu.com/job/unity-phablet-qmluitests-saucy/1213/testReport/junit/%28root%29/qmltestrunner/Drag_and_Drop__test_dragndrop/ | 16:07 |
| * tsdgeos waves for the day | 16:10 | |
| Saviq | mzanetti, I didn't see that before | 16:12 |
| Saviq | mzanetti, I mean after SDK reverted the easing | 16:12 |
| mzanetti | Saviq: hmm... locally I can reproduce this failing test like once every 20 runs | 16:12 |
| Saviq | mzanetti, yeah, but the easing shouldn't be a problem any more? | 16:13 |
| === jasoncwarner__ is now known as jasoncwarner | ||
| mzanetti | Saviq: ok... friends arrived... will check tomorrow | 16:16 |
| mzanetti | o/ | 16:16 |
| Saviq | mzanetti, o./ | 16:16 |
| === dednick|lunch is now known as dednick | ||
| Saviq | mterry_, if demo-edges is "true", means I won't get it, does it? can I reset? | 16:54 |
| mterry_ | Saviq, that means you should see it | 17:05 |
| Saviq | mterry_, yeah, not there on the desktop somehow... | 17:05 |
| Saviq | mterry_, got it on phone now | 17:05 |
| mterry_ | Saviq, you can reset it to true (or false) with the dbus-send line in the MR description | 17:05 |
| mterry_ | Saviq, oh good | 17:05 |
| === alan_g is now known as alan_g|EOD | ||
| mterry_ | Saviq, you killall'd accounts-daemon? | 17:05 |
| mterry_ | Saviq, are you using -f? | 17:06 |
| Saviq | mterry_, no, no -f, just ./run | 17:06 |
| Saviq | mterry_, but maybe it does pick up the fake service? | 17:06 |
| mterry_ | Saviq, shouldn't... without the -f | 17:07 |
| Saviq | mterry_, k, otp, will try again after | 17:08 |
| mterry_ | good that it works on the phone anyway | 17:08 |
| mterry_ | OK, walking to starbucks, will be back online in a bit | 17:08 |
| * greyback eod | 17:16 | |
| mterry | Saviq, did you ever get my onDisplayPowerChanged branch to work for you? | 19:37 |
| mterry | Saviq, demo branch updated too, check my recent comment | 19:42 |
| Saviq | mterry, didn't try the power one yet | 19:47 |
| mterry | Saviq, I only mention it because it has pieces I would want to solve the CPU-eating-during-screen-blank for the demo branch. I talk about it a bit in my comment | 19:50 |
| Saviq | mterry, yeah, I thought as much | 19:51 |
| Saviq | mterry, yeah, got the events now | 19:53 |
| mterry | Saviq, weird | 19:53 |
| Saviq | mterry, not sure what was happening before | 19:53 |
| Saviq | mterry, ah, found one thing that we might want to think about taking care of later | 19:54 |
| Saviq | mterry, if you press the power button, it should still lock over the phone app | 19:54 |
| Saviq | mterry, powerd probably needs some tweaking for that | 19:54 |
| Saviq | mterry, or well, shell will be listening to the button anyway | 19:54 |
| mterry | Saviq, I don't believe that's a problem. You'd have to press the power button while proximity is in effect, and talking to sforshee, that won't do anything | 19:56 |
| mterry | (i.e. if the machine didn't auto-suspend because someone had an active-lock, the power button won't override that) | 19:56 |
| mterry | Saviq, oh you mean if the phone app is simply up? | 19:56 |
| Saviq | mterry, yeah | 19:56 |
| Saviq | mterry, if you just leave it be on a call, but don't cover the proximity sensor | 19:57 |
| Saviq | mterry, and press power button | 19:57 |
| mterry | Saviq, right, we should look at actual proximity data then. i.e. our current check should be "proximity turned on *AND* proximate" instead of just "proximity turned on" | 19:57 |
| Saviq | mterry, it doesn't lock | 19:57 |
| Saviq | mterry, uup | 19:57 |
| Saviq | mterry, but that's fine, for later | 19:57 |
| mterry | Saviq, I wonder how to get proximate datat | 19:58 |
| mterry | platform-api I believe has that stuff.... | 19:58 |
| Saviq | mterry, we'll come up with something ;) | 19:58 |
| Saviq | kgunn, re: edge gesture over SEARCH | 19:59 |
| Saviq | kgunn, we have a WI in https://blueprints.launchpad.net/ubuntu/+spec/client-1303-unity-ui-panel for that | 19:59 |
| Saviq | kgunn, might need to put it to a milestone, though | 20:00 |
| kgunn | Saviq: ta | 20:00 |
| Saviq | mterry, nitpick: indentation is wrong for enum Status | 20:03 |
| mterry | huh, wonder how that happend. will fix | 20:03 |
| Saviq | mterry, in both real and mock, too | 20:03 |
| mterry | Fixed | 20:04 |
| Saviq | mterry, I think the input issue was because I wasn't killing the phone app between restarting unity8 | 20:08 |
| mterry | Saviq, oh does it get stuck in a weird focus state? | 20:08 |
| Saviq | mterry, so window / input management gets annoyed | 20:08 |
| Saviq | mterry, yeah, looks like it, can't reproduce otherwise | 20:09 |
| Saviq | mterry, I'll file a bug about the "lock during a call" thing | 20:09 |
| mterry | Saviq, thanks, yeah. Assign to me I'll get to it post FF | 20:10 |
| Saviq | mterry, we don't have FF ;) | 20:10 |
| mterry | Well... I thought we were still trying, right? | 20:10 |
| mterry | Saviq, plus pre-FF is busier for other distro business | 20:11 |
| Saviq | mterry, I know | 20:11 |
| Saviq | j/k | 20:11 |
| mterry | :) | 20:11 |
| mterry | Saviq, I miss the idea of rolling releases, with nary an FF in sight | 20:11 |
| Saviq | mterry, bug #1215120 | 20:12 |
| ubot5 | bug 1215120 in Unity 8 "It should be possible to lock the phone during a call" [Undecided,Triaged] https://launchpad.net/bugs/1215120 | 20:12 |
| Saviq | mterry, proximity happroved | 20:13 |
| mterry | Saviq, awesome | 20:13 |
| Saviq | mterry, so let's wait for that to land for the demo one | 20:13 |
| Saviq | mterry, I still need a proper code review of it anyway | 20:14 |
| mterry | Saviq, I can start now, by merging | 20:14 |
| Saviq | mterry, yeah, or thta | 20:14 |
| mterry | Saviq, why doesn't the CPU go into suspend in your case? Does the animation block suspend? | 20:15 |
| mterry | (in the demo case) | 20:15 |
| mterry | Actually, maybe your ssh session was blocking suspend... Let me test by looking at logs | 20:16 |
| Saviq | mterry, it's not that kind of suspend | 20:17 |
| Saviq | mterry, the phone just goes into low power mode, calling it "suspend" is probably wrong | 20:17 |
| mterry | Saviq, so this low power mode would be blocked by the animation running and consuming all the CPU? | 20:18 |
| Saviq | mterry, we are SIGSTOPping apps | 20:18 |
| mterry | I see. But we dont' SIGSTOP the shell and its animations | 20:18 |
| Saviq | mterry, but not the shell | 20:18 |
| mterry | pfft, k | 20:18 |
| Saviq | mterry, yeah, so shell needs to behave and stop redrawing | 20:18 |
| Saviq | mterry, well, we could actually think about SIGSTOPping shell as well, I don't know whether someone considered it yet | 20:19 |
| mterry | Saviq, for me, the animation goes super-sped up on my desktop (with ./run -f). Is there an oddity with the timing when using the mock plugins? | 20:19 |
| mterry | Saviq, shell sigstops the others, eh? So we'd have to move the SIGSTOP logic elsewhere. But not a bad idea. Keeps us from having to add logic like this all over the shell in future (though hopefully we don't have many constant animations | 20:20 |
| Saviq | mterry, yeah, shell has the app manager - we could think about powerd stopping shell when in low power mode | 20:20 |
| Saviq | mterry, if only I got the edge demo on desktop somehow :/ | 20:21 |
| Saviq | mterry, dbus-send works fine | 20:21 |
| Saviq | mterry, I mean it returns true fine | 20:22 |
| mterry | Saviq, oh, did you change the demo user? | 20:22 |
| mterry | Saviq, I bet that's why | 20:22 |
| Saviq | mterry, hum? | 20:22 |
| mterry | Saviq, you should change tests/plugins/LightDM/demo/* to change "phablet" to "saviq" or some such | 20:22 |
| mterry | Saviq, so we look up the right user in your desktop AccountsService | 20:22 |
| Saviq | mterry, in tests? | 20:22 |
| Saviq | mterry, shouldn't it work with real AccountsService? | 20:22 |
| Saviq | mterry, i.e. | 20:23 |
| mterry | Saviq, yeah. The demo LightDM plugin is used by the greeter right now (until we separate) | 20:23 |
| Saviq | ❭ dbus-send --system --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.DBus.Properties.Get string:com.canonical.unity.Accoun | 20:23 |
| Saviq | tsService string:demo-edges | 20:23 |
| Saviq | method return sender=:1.383 -> dest=:1.489 reply_serial=2 | 20:23 |
| Saviq | variant boolean true | 20:23 |
| Saviq | mterry, aah of course | 20:23 |
| mterry | Saviq, the greeter tells AccountsService which user to look up | 20:23 |
| mterry | And it thinks you are phablet right now | 20:23 |
| mterry | Saviq, alternatively, you could change your system username to phablet ;) | 20:23 |
| mterry | Or add a user for phablet... | 20:24 |
| mterry | But then 'saviq' couldn't change 'phablet's data | 20:24 |
| Saviq | mterry, +1 | 20:25 |
| Saviq | mterry, can't get it with -f now... | 20:27 |
| mterry | Saviq, you won't, I added a mock AccountsService plugin that always returns false for it. So as not to mess with the tests | 20:27 |
| Saviq | mterry, ok, so can't tell you why it goes to warp speed | 20:27 |
| Saviq | mterry, shouldn't, that's what I know :) | 20:28 |
| mterry | Saviq, when I test with -f, I usually just comment out the bit in Shell.qml that looks up in AccountsService and set it to true | 20:28 |
| mterry | Saviq, when I do that, it does warp speed | 20:28 |
| mterry | Saviq, do you see it when you run just normal ./run? | 20:28 |
| Saviq | mterry, no, seems to behave fine | 20:28 |
| mterry | I use 'duration' values... | 20:29 |
| mterry | Saviq, OK, good. So it must just be some weird mock thing | 20:29 |
| Saviq | mterry, yeah, duration should be fine | 20:29 |
| Saviq | mterry, -f looks fine, too | 20:30 |
| Saviq | oups | 20:30 |
| mterry | back... I don't get my IRC problems. I thought it was my Internet provider, but now I'm having same problems in a cafe | 20:33 |
| mterry | Saviq, OK, uploaded a change that should turn off demo animation when screen is off | 20:49 |
| Saviq | mterry, cool | 20:49 |
| mterry | Saviq, it involves the merged branch, so until that lands, the diff will be more complicated than it is in reality | 20:49 |
| Saviq | mterry, yup | 20:50 |
| mterry | Saviq, hrm, the jenkins qmltest failure seems real for the demo branch. Will look into it | 20:51 |
| Saviq | mterry, indeed | 20:52 |
| mterry | this branch has been very stumbly so far | 20:52 |
| Saviq | mterry, I wonder, too, if that won't bite us in autopilot tests | 20:52 |
| Saviq | mterry, at some point at least | 20:52 |
| mterry | Saviq, if the demo won't? That's why I had the mock plugin that disabled the demo | 20:53 |
| Saviq | greyback, made the Mir items into bugs, btw https://bugs.launchpad.net/touch-preview-images/+bugs?field.tag=mir-landing-blockers | 20:53 |
| greyback | Saviq: thanks | 20:53 |
| Saviq | mterry, right, we always use a custom lightdm backend in autopilot | 20:53 |
| greyback | Saviq: always nice to get a big list of bugs before bed time | 20:54 |
| Saviq | mterry, so yeah, we'll know when it bites us (when we split greeter for real) | 20:54 |
| Saviq | greyback, only two/three of them are yours, and it's not like you didn't know! ;) | 20:54 |
| greyback | :) | 20:54 |
| Saviq | greyback, shouldn't have shown up, either! :P | 20:54 |
| mterry | Saviq, well, this branch also has a mock AccountsService that always returns false for the demo-edges value | 20:55 |
| Saviq | greyback, you know I'm just lurking around here just to get the pleasure ;) | 20:55 |
| greyback | Saviq: yeah well, need to fix the issue with unity on mir, and got an idea | 20:55 |
| Saviq | mterry, yup, will look at it tomorrow for sure | 20:55 |
| Saviq | greyback, :) | 20:55 |
| greyback | Saviq: part of me suspects that's true | 20:55 |
| Saviq | greyback, at some point I started to note down stuff I thought about before being able to sleep ;) | 20:56 |
| Saviq | greyback, but it seems my conscience is better now - no more writing down for some time now ;D | 20:56 |
| greyback | :D | 20:56 |
| dednick | zzzz | 21:20 |
| === salem_ is now known as _salem | ||
| === mhall119_ is now known as mhall119 | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!