| === jzheng is now known as jzheng_afk | ||
| * tsdgeos is confused because he gets an email saying his mir landing is stuck | 08:10 | |
| * tsdgeos then realizes the email was supposed to be for AlbertA and not for me | 08:11 | |
| tsdgeos | too many Albert* A* people | 08:11 |
|---|---|---|
| tsdgeos | :D | 08:11 |
| Saviq | tsdgeos, hey, plugins/Dash/croppedimagesizerasyncworker.cpp:22:27: fatal error: QtConcurrentRun: No such file or directory | 09:50 |
| Saviq | #include <QtConcurrentRun> ¿? | 09:50 |
| tsdgeos | hmmm | 09:50 |
| tsdgeos | i guess | 09:50 |
| tsdgeos | how does that compile here? | 09:50 |
| tsdgeos | Saviq: which branch? | 09:50 |
| Saviq | tsdgeos, asyncCropped, I imagine | 09:51 |
| Saviq | tsdgeos, https://code.launchpad.net/~unity-team/unity8/rtm-dash-staging/+merge/241513 | 09:51 |
| Saviq | that's what it was trying to build from | 09:51 |
| tsdgeos | ./Dash/croppedimagesizerasyncworker.cpp:22:#include <QtConcurrentRun> | 09:52 |
| Saviq | tsdgeos, yeah, -I wrong? | 09:52 |
| Saviq | qt5_use_module needs Concurrent, I think | 09:53 |
| Saviq | so I failed the merge did I | 09:53 |
| Saviq | hmm or not | 09:54 |
| Saviq | well, I must've, somehow, since your diff includes the find_package, and mine does not | 09:54 |
| tsdgeos | yeah | 09:54 |
| tsdgeos | the find_package is missing from CMakeLsits.txt | 09:54 |
| Saviq | tsdgeos, still, http://paste.ubuntu.com/9211842/ is better | 09:55 |
| Saviq | 'innit | 09:55 |
| tsdgeos | i have no idea what¡s the difference tbh | 09:56 |
| Saviq | tsdgeos, qt5_use_modules actually takes care of checking if the module exists | 09:56 |
| Saviq | http://paste.ubuntu.com/9211866/ | 09:57 |
| Saviq | and it's more readable | 09:57 |
| * Saviq wonders how the find_package got lost | 09:57 | |
| mzanetti | it was added in two branches. maybe that messed up the merge | 09:58 |
| tsdgeos | Saviq: well the find package also makes sure the module exists | 09:58 |
| Saviq | tsdgeos, yes, but in an unrelated place (in the top-level CMakeLists.txt) | 09:58 |
| Saviq | tsdgeos, which means that you add the _INCLUDE that might not exist, and instead of getting a cmake error early, you get ENOFOUND | 09:59 |
| tsdgeos | which is good so all dependencies are checked in the same place ;) | 09:59 |
| Saviq | tsdgeos, I disagree | 09:59 |
| tsdgeos | but if you want me to apply that change i can | 09:59 |
| Saviq | tsdgeos, fook bzr, somehow the CMakeLists.txt change gets lost when I merge the fucker | 10:04 |
| Saviq | well, it's there, but not included in the diff ¿? | 10:04 |
| tsdgeos | ^_^ | 10:05 |
| Saviq | tsdgeos, ah! | 10:05 |
| Saviq | tsdgeos, that's actually an argument for including the dependency change in the same file | 10:05 |
| Saviq | tsdgeos, you added the Concurrent check in CMakeLists.txt in the "get rid of warning" branch | 10:05 |
| Saviq | so it's there in trunk, not in rtm | 10:05 |
| tsdgeos | how is that an argument for that? | 10:06 |
| tsdgeos | it'd say it's an argument for "merges can't be applied directly from trunk to rtm" | 10:06 |
| Saviq | tsdgeos, but but! | 10:07 |
| Saviq | tsdgeos, basically, IMO a CMakeLists.txt file (especially for QML plugins) should be as self-contained as possible | 10:07 |
| Saviq | tsdgeos, with as little assumptions as possible | 10:08 |
| tsdgeos | but none of our files is like that | 10:08 |
| tsdgeos | but sure, i'll change that in the async branch | 10:08 |
| Saviq | I'd say most of them are like that (sure, not completely, but at least | 10:09 |
| Saviq | we should keep that in mind) | 10:09 |
| tsdgeos | Saviq: pushed | 10:11 |
| Saviq | tsdgeos, tx | 10:12 |
| tsdgeos | MacSlow: there? | 10:18 |
| MacSlow | tsdgeos, yup | 10:19 |
| tsdgeos | MacSlow: i do not understand http://bazaar.launchpad.net/~macslow/unity8/swipe-dismiss-snap-decisions/revision/1243 | 10:19 |
| tsdgeos | that needs some change in the backend no? | 10:19 |
| MacSlow | no | 10:21 |
| MacSlow | it does not | 10:21 |
| tsdgeos | MacSlow: why? | 10:22 |
| tsdgeos | Saviq: are you going to review https://code.launchpad.net/~mzanetti/unity8/fix-appdelegate-jumping/+merge/241930 regarding the problem you found or want me to? | 10:22 |
| Saviq | tsdgeos, I'll test it with the silo after rebuilding | 10:22 |
| tsdgeos | Saviq: ok | 10:22 |
| tsdgeos | mzanetti: change | 10:22 |
| tsdgeos | verify(Math.abs(Math.abs(appWindowWithShadow.y) - dragDistance) == threshold); | 10:22 |
| tsdgeos | to a compare? | 10:23 |
| MacSlow | tsdgeos, the close() method was always already part of the libnotify-API we support for ages now | 10:23 |
| tsdgeos | mzanetti: and you have added a parameter now | 10:23 |
| tsdgeos | damn that was for MacSlow | 10:24 |
| tsdgeos | MacSlow: and you have added a new parameter, no? | 10:24 |
| mzanetti | what? | 10:24 |
| mzanetti | ah | 10:24 |
| tsdgeos | Saviq: https://code.launchpad.net/~larsu/unity8/stop-using-statusicon/+merge/234502 has a serious isssue with jenkins, haven't run in days after a commit :S | 10:24 |
| tsdgeos | mzanetti: for you only the verify -> compare | 10:24 |
| larsu | tsdgeos: do you have the powers to nudge jenkins a bit on that | 10:25 |
| tsdgeos | i do i guess | 10:25 |
| tsdgeos | let me try | 10:25 |
| Saviq | tsdgeos, I'll take care of that | 10:25 |
| tsdgeos | Saviq: tx | 10:25 |
| * Saviq wonders why it didn't run "/ | 10:26 | |
| Saviq | :/ | 10:26 |
| MacSlow | tsdgeos, well yes... it's only really used (and needed) for the qmltest | 10:26 |
| MacSlow | tsdgeos, the real backend ignores it | 10:26 |
| tsdgeos | ignore what? | 10:27 |
| MacSlow | tsdgeos, the passed paramter (as used in the qmltest) | 10:28 |
| tsdgeos | MacSlow: but does it already have the paramater and it's just unused? or is not there at all? | 10:28 |
| * Saviq back in 1h or so | 10:29 | |
| MacSlow | tsdgeos, not there at all | 10:31 |
| MacSlow | tsdgeos, it's only used in the qmltest | 10:31 |
| MacSlow | tsdgeos, and close() is most unlikely to be be needing a parameter in the real backend... especially considering it's public API... for the qmltest I'm slightly bending "the rules" a bit, but the amount of code and effort (in the NotificationMocks plugin) this saves is considerable. | 10:34 |
| tsdgeos | MacSlow: i think relying on the JS->C++ binding ignoring the extra parameter to call an invokable function with less parameters is a bit on the too much side to be honest | 10:40 |
| tsdgeos | Saviq: ↑ ? | 10:40 |
| MacSlow | tsdgeos, Saviq: The alternative is a lot of code to be added to the NotificationMocks plugin (and possibly adjustment of existing and working notification qmltests) for just one single method (close()) to work as expected in the qmltests. | 10:45 |
| tsdgeos | the mock doing what it should do | 10:46 |
| tsdgeos | is what mocks are about | 10:46 |
| tsdgeos | you're not supposed to add extra code to your code | 10:46 |
| MacSlow | tsdgeos, Saviq: with my cost-benefit understanding, I'm in favour of the less-impactful solution, which is currently in the swipe-dismiss-snap-decisions unity8-branch. | 10:47 |
| MacSlow | tsdgeos, mzanetti: so no approval until I replicate all of the backend in the NotificationMocks and can the current solution? | 10:50 |
| tsdgeos | MacSlow: i don't fell calling close(moo) and then the C++ method being only close() is good | 10:51 |
| tsdgeos | but if Saviq thinks it's fine i'll approve it | 10:51 |
| MacSlow | tsdgeos, I understand the concern to some extend, but also wanted to avoid blowing up the diff for the sake of one single method being needed. | 10:52 |
| tsdgeos | i'm unconvinced tbh | 11:04 |
| tsdgeos | are we back to qmluitests failing in trunk? | 11:04 |
| mzanetti | MacSlow: yeah, I tend to agree with tsdgeos here | 11:05 |
| MacSlow | tsdgeos, mzanetti: ok... two against one... I guess I lose :) | 11:06 |
| mzanetti | tsdgeos: btw, I pushed the verify -> compare thing | 11:07 |
| tsdgeos | MacSlow: tx | 11:07 |
| MacSlow | tsdgeos, mzanetti: I'll resurrect the older stuff I did for NotificationMocks before | 11:07 |
| tsdgeos | mzanetti: tx | 11:07 |
| tsdgeos | yes we are (qmluitests failing in trunk) | 11:09 |
| tsdgeos | i'll fix some | 11:09 |
| tsdgeos | sdk broke us again :/ | 11:19 |
| === _salem is now known as salem_ | ||
| === Malsasa_ is now known as Malsasa | ||
| tsdgeos | QQmlExpression: Expression file:///home/tsdgeos_work/phablet/unity8/qmluitestsfix/qml/Components/LazyImage.qml:115:19 depends on non-NOTIFYable properties: | 11:29 |
| tsdgeos | QQuickImage_QML_10::source | 11:29 |
| tsdgeos | that looks bad | 11:29 |
| Saviq | uuuugrh | 11:45 |
| * Saviq will work on moving our qmluitests to autopkgtests this week, will block UITK from releasing things that break our tests :P | 11:46 | |
| tsdgeos | Saviq: dednick: https://code.launchpad.net/~aacid/unity8/qmluitestsfix/+merge/242652 | 12:11 |
| tsdgeos | fixes 3 out of the 4 qmltests failingg | 12:12 |
| tsdgeos | the other one is the source property | 12:12 |
| tsdgeos | which can't fix | 12:12 |
| tsdgeos | Saviq: how will it fix it? are all autopkgtests run after sdk landing? | 12:12 |
| Saviq | tsdgeos, autopkgtests are ran for _the package_ and any dependants | 12:12 |
| tsdgeos | nice | 12:13 |
| Saviq | indeed | 12:13 |
| dandrader | mzanetti, in TabletStage, spreadRepeater.itemAt(0) will always be the focused one on the main stage? | 12:16 |
| mzanetti | dandrader: no | 12:17 |
| mzanetti | dandrader: if there is only a side stage app running not. atm the dash can only be main stage but that is to be changed according to designers | 12:18 |
| mzanetti | dandrader: also there might be other cases... | 12:19 |
| dandrader | mzanetti, erm.. couldn't parse your last sentence. | 12:19 |
| mzanetti | bottomline: no, don't rely on itemAt(0) to be neither the focused one, nor always in main stage | 12:19 |
| dandrader | mzanetti, so if the main stage is empty and there's only an app in the side stage then itemAt(0) will be that side-stage guy. but if there's someone focusedon the main stage, he will be at itemAt(0), right? | 12:20 |
| mzanetti | not noecessarily I think | 12:21 |
| === MacSlow is now known as MacSlow|lunch | ||
| mzanetti | dandrader: index in model != z index | 12:21 |
| mzanetti | dandrader: there is priv.mainStageAppId | 12:24 |
| === dandrader is now known as dandrader|afk | ||
| === Malsasa_ is now known as Malsasa | ||
| cwayne-afk | mzanetti: finally got my site back up and running, guess it got 'hacked' by some script kiddies or somethin' | 12:47 |
| mzanetti | ouch | 12:52 |
| === dandrader|afk is now known as dandrader | ||
| dandrader | Saviq, greyback_, we should support upside down in tablets, right (unlike with phones)? | 13:19 |
| dandrader | ie, inverted landcape | 13:19 |
| * greyback_ looks to see if spec said anything | 13:20 | |
| greyback_ | dandrader: I don't see anything in the spec, so I say do whatever is easiest for you | 13:21 |
| === MacSlow|lunch is now known as MacSlow | ||
| greyback_ | allowing all orientations probably makes most sense | 13:21 |
| Saviq | greyback_, dandrader, even on phone it's controversial to disable it | 13:24 |
| greyback_ | it's what the spec says. And I agree, you're less likely to hold phone upside-down to your face to answer a call | 13:24 |
| Saviq | agreed | 13:24 |
| Saviq | but then there's the case of all the sockets | 13:25 |
| Saviq | where you suddenly can't rotate your phone to what's more convenient (when charging or with headset connected etc.) | 13:25 |
| mzanetti | tsdgeos: hmm in here: https://code.launchpad.net/~aacid/unity8/qmluitestsfix/+merge/242652 | 13:25 |
| dandrader | Saviq, greyback_, My idea is to have a device config file or something from where unity8 reads things such as what is the primary orientation and the supported device orientations | 13:26 |
| * greyback_ thinks 3 out of 4 orientations enough to find something comfortable | 13:26 | |
| mzanetti | tsdgeos: doesn't the change in tst_Indicators basically come down to a wait(100), and if it doesn't match to wait(200) | 13:26 |
| mzanetti | ? | 13:26 |
| mzanetti | tsdgeos: what I mean is that if you do "mappedPosition = aux", wouldn't this always be true afterwards? "mappedPosition.x == aux.x" | 13:27 |
| dandrader | just don't know yet what's the best/easiest way to achieve such thing. ideas welcome | 13:27 |
| greyback_ | dandrader: +1 on file setting primary device orientation. -1 on it defining supported orientations, as that's more code-paths to support and unused ones likely to bitrot | 13:27 |
| dandrader | greyback_, do you remember what to we do to reade the device name? | 13:27 |
| Saviq | greyback_, well, that's the thing, if your power connector is on the bottom | 13:27 |
| Saviq | greyback_, and you still want it portrait | 13:28 |
| greyback_ | we've had this argument :) | 13:28 |
| Saviq | greyback_, you only get one | 13:28 |
| Saviq | IMO it should be user-overridable even | 13:28 |
| greyback_ | dandrader: yeah was via the library for adb | 13:28 |
| * greyback_ hunts for code | 13:28 | |
| Saviq | dandrader, libandroid-properties | 13:28 |
| dandrader | greyback_, about your -1. it's no big deal. it's just a Qt.ScreenOrientations var that will be &ed with the apps supported orientations to define the final shell rotation. that logic is there and must work regardless of the actual value of the supported device orientations var | 13:31 |
| dandrader | Saviq, thanks | 13:31 |
| greyback_ | dandrader: if you say so. I'm not gonna block on it, but I'm not fond of the idea | 13:31 |
| === cwayne-afk is now known as cwayne | ||
| greyback_ | dandrader: yeah I musta deleted the code I had using android-properties, but it's pretty straight forward | 13:32 |
| === Malsasa_ is now known as Malsasa | ||
| dandrader | hmmm, I wonder what libandroid-properties will say when running on a desktop... | 13:35 |
| Saviq | mterry, re: shutdown dialog on suspend, lp:~mterry/unity8/cache-greeter-bg fixes it then? | 13:36 |
| mterry | Saviq, it does, but at the cost of memory | 13:36 |
| mterry | Saviq, I tried a naive "make greeter load async" but it had problems, looks like that would need a smart-ish fix | 13:37 |
| Saviq | mterry, but we have ideas (like dropping in a black overlay straight away and having an async image on top)? | 13:37 |
| mterry | Saviq, so I just tried to cache bg. But we apparently explicitly wanted to save that memory in the past | 13:37 |
| Saviq | mterry, yeah, let's find out what the impact really is | 13:37 |
| mterry | Saviq, we could do something like that yeah, and make the greeter load async. I don't recall what exactly the bugs were when I simply added async: true. But I abandoned that path to just cache the bg | 13:38 |
| Saviq | mterry, kk | 13:38 |
| mterry | Saviq, but we should look at async again, I'm sure it's solvable :) | 13:39 |
| mterry | Saviq, the confusing part to me is that CrossFadeImage marks its internal Image objects as async | 13:39 |
| mterry | Saviq, maybe I don't know much about qml image loading, but I would have assumed that would solve the problem for us | 13:40 |
| Saviq | mterry, maybe it's not the images then but creating the greeter itself | 13:40 |
| Saviq | with the infographics and all | 13:40 |
| mterry | Saviq, but when I simply moved the image out, it fixed the problem (and greeter load was instant) | 13:40 |
| Saviq | mterry, right, so that could simply be IO | 13:41 |
| Saviq | mterry, which, apparently, is *really* slow on mobile | 13:41 |
| Saviq | mterry, that we could fix by caching a pre-cropped, pre-scaled image | 13:41 |
| mterry | Saviq, but async, right? Wouldn't the async bits of CrossFadeImage mean that we'd return from greeter.show() immediately and load in background? | 13:41 |
| Saviq | mterry, well, that's assuming your whole phone isn't IO-blocked... | 13:41 |
| mzanetti | Saviq: the impact was ~35MB on a Nexus10 and around 10MB on a Nexus4 | 13:42 |
| mzanetti | that's what I recall from when I moved it to a loader | 13:42 |
| Saviq | mhm | 13:42 |
| Saviq | dandrader, so I can release the silo without your touch postEvent branch even, now that UAL got fixed to not spin our mainloop? | 13:43 |
| dandrader | Saviq, yes. I even pulled out its merge proposal | 13:44 |
| Saviq | dandrader, ah I thought you left it WiP is why I couldn't find it | 13:44 |
| Saviq | dandrader, we don't want that change then? | 13:44 |
| dandrader | Saviq, it's really not needed. I will come back to it later, after the shellRotation work | 13:45 |
| Saviq | dandrader, o | 13:45 |
| Saviq | k | 13:45 |
| Saviq | tsdgeos, FYI I'll wait for your MP to silo things, please prio it | 13:50 |
| mterry | Cimi, any feedback so far on the wizard-plugin stuff? I can make some changes in response to early review comments as you finish the review | 13:58 |
| Cimi | mterry, I am bad in C++ | 13:59 |
| Cimi | mterry, but I can submit the qml things I saw for now | 13:59 |
| mterry | Cimi, sure, would let us work in parallel a bit | 13:59 |
| mterry | Cimi, do you want another reviewer for the c++ stuff or are you just saying you're chewing through it, just slower than the qml stuff? | 14:00 |
| Cimi | mterry, chewing | 14:00 |
| Cimi | but as always I might not be able to spot everything | 14:00 |
| mterry | Cimi, cool :) | 14:00 |
| mterry | Cimi, eh, that's true for every review by anyone :) | 14:00 |
| tsdgeos | Saviq: which one? | 14:01 |
| Saviq | tsdgeos, sorry ;) | 14:02 |
| tsdgeos | Saviq: the one for tests? | 14:02 |
| Saviq | tsdgeos, the qml tests one | 14:02 |
| Saviq | yup | 14:02 |
| tsdgeos | Saviq: it's up already | 14:02 |
| Saviq | tsdgeos, but mzanetti NeedsFixin' it | 14:02 |
| tsdgeos | ah | 14:02 |
| * tsdgeos reads | 14:02 | |
| mzanetti | needsinfo actually, but yeah | 14:02 |
| Cimi | cooking now, catch you in 20 | 14:02 |
| dednick | tsdgeos: comment attached | 14:05 |
| tsdgeos | tx | 14:05 |
| Saviq | paulliu, hey, are you proposing https://code.launchpad.net/~paulliu/unity8/lp1350891_ScrollBackground or still working on it? | 14:06 |
| mzanetti | dednick: hmm... tryCompareFunction does execute the function repeatedly | 14:06 |
| tsdgeos | dednick: mzanetti: you're right i missed updating aux again | 14:06 |
| tsdgeos | dednick: mzanetti: pushed something new | 14:06 |
| mzanetti | tsdgeos: as I constantly tell Mirco he's not allowed to use wait() I'd prefer we follow that too (even though I understand the difference in your use case) :D | 14:07 |
| tsdgeos | dednick: i can move to the dowhile you mentioned, i'm not a fan of do whiles | 14:07 |
| tsdgeos | dednick: i can move to the dowhile you mentioned, i'm not a fan of do whiles | 14:07 |
| tsdgeos | mzanetti: then suggest something that works :D | 14:07 |
| mzanetti | tryCompareFunction, no? | 14:07 |
| tsdgeos | no | 14:07 |
| tsdgeos | how do i check it has stopped moving? | 14:08 |
| dednick | tsdgeos: neither am i, but it was less code lines to give the example;) | 14:08 |
| tsdgeos | with a tryCompareFunction? | 14:08 |
| tsdgeos | at most i can try to guess that's the value | 14:08 |
| tsdgeos | and compare for that | 14:08 |
| paulliu | Saviq: ah. I'll need to ask an image from designers. | 14:08 |
| paulliu | Saviq: to tile it. Not yet done. | 14:08 |
| dednick | tsdgeos: well, i guess if you stall before the trycompre it may work. | 14:08 |
| dednick | erm, actually no | 14:09 |
| mzanetti | tsdgeos: ohh, now I get what you're doing.. the new line you pushed changed it significantly | 14:09 |
| paulliu | Saviq: context switching to another branch now. I'll go to the designer and ask what to do now. | 14:09 |
| mzanetti | yeah, tryCompare won't work in this case | 14:10 |
| tsdgeos | mzanetti: but i'm with you | 14:10 |
| tsdgeos | i should try comparing the final vale | 14:10 |
| tsdgeos | it's always 59.5 | 14:10 |
| mzanetti | if possible, please do so, yes | 14:10 |
| tsdgeos | so i guess i can try to find out what 59.5 is :D | 14:10 |
| mzanetti | :) | 14:10 |
| dednick | lol. why is it moving?! | 14:10 |
| tsdgeos | dednick: well it's just created, they grow from the right | 14:11 |
| dednick | oh. think it's some behaviour in the | 14:11 |
| dednick | panel | 14:11 |
| Saviq | paulliu, ok, one thing I noticed there, you don't need the additional Flickable, just fill GenericScopeView or so | 14:12 |
| paulliu | Saviq: ok. | 14:13 |
| Saviq | paulliu, did you request the new asset? remember we'll need a background that will work for different aspect ratios | 14:14 |
| paulliu | Saviq: ok. BTW, who is the best one I should ping? | 14:15 |
| Saviq | paulliu, the bug's assigned to Esti, so her | 14:17 |
| paulliu | ok | 14:17 |
| Saviq | mzanetti, is bug #1368668 handled by your reversible spread branch maybe? | 14:25 |
| ubot5 | bug 1368668 in unity8 (Ubuntu RTM) "[Apps switcher] Visual feedback of user's finger movement needed throughout the gesture" [Medium,Triaged] https://launchpad.net/bugs/1368668 | 14:25 |
| * mzanetti reads | 14:26 | |
| mzanetti | Saviq: yea... a bit surprised vesar creates duplicates of his own bugs :) | 14:27 |
| Saviq | mzanetti, well I think what he means is the short span where you move your finger and nothing's moving on screen | 14:27 |
| Saviq | mzanetti, that not the case after reversible spread? | 14:27 |
| mzanetti | Saviq: well, it is for 2 gus on the left edge | 14:28 |
| Saviq | mzanetti, no, I meant between toggle and spread | 14:28 |
| mzanetti | Saviq: so if you move the finger all across the screen the leftmost 2gus don't move anything any more | 14:28 |
| * Saviq tries | 14:28 | |
| Saviq | mzanetti, nope, still there | 14:29 |
| mzanetti | then I don't get it | 14:30 |
| mzanetti | wait. | 14:30 |
| Saviq | mzanetti, try moving your from the right edge so that it takes like 5s to span the scree | 14:30 |
| mzanetti | is that about the snapping in the middle? | 14:30 |
| mzanetti | Saviq: ^ | 14:30 |
| Saviq | mzanetti, roughly in the middle, the "next" app stops and both start moving after some 4gus later | 14:30 |
| mzanetti | ffs | 14:30 |
| mzanetti | that's the next one I told them is bad when we first did it :D | 14:31 |
| mzanetti | ok... well then | 14:31 |
| mzanetti | assign it to me | 14:31 |
| Saviq | see, you should be a UX designer ;P | 14:31 |
| mzanetti | yeah | 14:31 |
| mzanetti | totally | 14:31 |
| mzanetti | they should just tell me: we want a right edge spread, to whatever you like :D | 14:32 |
| tsdgeos | mzanetti: dednick: so adding a waitForRendering makes it work on valgrind for me, so pushed that at the end | 14:47 |
| tsdgeos | Saviq: ↑ | 14:47 |
| Saviq | kk | 14:52 |
| mzanetti | tsdgeos: jenkins still complained about a fail in testLazyImage, but I couldn't repro | 14:55 |
| tsdgeos | mzanetti: that's sdj | 14:56 |
| tsdgeos | mzanetti: it's been reported and fix is incoming | 14:56 |
| tsdgeos | mzanetti: i guess your sdk is too old :D | 14:57 |
| mzanetti | ah ok | 14:57 |
| mzanetti | tsdgeos: approved | 14:57 |
| tsdgeos | any idea where all those "Using blocking call!" come from? | 15:05 |
| tsdgeos | ah maybe it's the qtdbus patches? | 15:05 |
| tsdgeos | Mirv: do you know if the patches you added to dbus add a "Using blocking call!" debu? | 15:06 |
| tsdgeos | mterry: i think you're eatly-disable has lots of badtags | 15:10 |
| mterry | tsdgeos, guh I can't get these tags right today | 15:10 |
| tsdgeos | let me re-branch | 15:10 |
| tsdgeos | just to make sure | 15:10 |
| mterry | tsdgeos, I'm running the strip script on it now | 15:10 |
| tsdgeos | ok | 15:10 |
| mterry | tsdgeos, yeah it has some bad tags | 15:10 |
| tsdgeos | cltr+c | 15:10 |
| mterry | tsdgeos, they keep slipping into my remote branches despite being clean locally. I must be doing something wrong when merging | 15:11 |
| mterry | tsdgeos, ok clean | 15:17 |
| === dandrader is now known as dandrader|lunch | ||
| Cimi | mterry, don't we have anything better than using a blank space to check an unset license path? | 16:35 |
| mterry | Cimi, we could use a separate property probably | 16:35 |
| Cimi | mterry, even empty is not good enough? | 16:36 |
| mterry | Cimi, no because empty is a valid return if HERE isn't installed | 16:36 |
| mterry | Cimi, but we need to distinguish between "got empty back" or "haven't heard back yet" | 16:36 |
| Cimi | mmm | 16:36 |
| mterry | Cimi, I agree it's a bit of a hack. A separate property is probably cleaner, but I got a bit lazy there | 16:37 |
| Cimi | mterry, have a coffee :) no rush | 16:38 |
| === dandrader|lunch is now known as dandrader | ||
| mzanetti | Saviq: ping | 17:09 |
| Cimi | mterry, we should move to a new path for wizard has run | 18:00 |
| Cimi | mterry, maybe move the file if the old is detected? | 18:01 |
| mterry | Cimi, we could sure... but I didn't think it was worth the complexity | 18:01 |
| mterry | Cimi, no one touches that file by hand (should go through phablet-config welcome-wizard --enable) | 18:02 |
| Cimi | mterry, we should do it now since we are still beta | 18:02 |
| mterry | we'd have to update phablet-tools as well | 18:02 |
| Cimi | mterry, yeah we can do that... | 18:02 |
| Cimi | mterry, or move the file from upstart or what | 18:02 |
| mterry | Cimi, we're not really. This is for vivid. Rtm has already branched | 18:03 |
| mterry | Cimi, but who cares what the filename is? | 18:03 |
| Cimi | mterry, probably Saviq :P | 18:04 |
| Cimi | I'd put it under a more generic or unity8 path if we decide to move it to unity8 | 18:04 |
| Cimi | it kinda changes app so we could move it, that was my though | 18:04 |
| mterry | Cimi, I agree that it *should* live in a unity8 path or what not -- I even have a comment in the C++ saying that it's only the current path for historical reasons. I just don't think it's worth the complexity of the code change to support migration | 18:07 |
| Cimi | mterry, valid point | 18:08 |
| Cimi | mterry, let's double check with saviq tomorrow, we can always migrate in a branch in the future | 18:08 |
| mterry | Cimi, but I'm willing to be out-voted :) | 18:08 |
| === alan_g is now known as alan_g|EOD | ||
| === salem_ is now known as _salem | ||
| === greyback__ is now known as greyback | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| balloons | mzanetti, I have a present for you if you are about | 22:54 |
| mzanetti | balloons: terminal app? | 23:01 |
| balloons | mzanetti, file manager and terminal are in the store. indeed | 23:01 |
| mzanetti | awesome :) | 23:01 |
| balloons | I can't add my ubuntu one account though, so I can't install :-( | 23:01 |
| mzanetti | hmm... iirc that worked for me... will try tomorrow | 23:02 |
| balloons | indeed.. good stuff. I want to try your windowing with it | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!