| davidcalle_afk | elimisteve: no estimates since people hold out until the last day to polish their work, but if you look at https://uappexplorer.com/apps?type=scope you can see roughly what's been entered already | 08:25 |
|---|---|---|
| === davidcalle_afk is now known as davidcalle | ||
| elimisteve | thanks davidcalle | 09:05 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| nik90 | appdevs, Can anyone what's the benefit of using textSize (introduced in UC1.3) over fontSize? | 10:35 |
| timp | nik90: string comparisons are expensive | 10:41 |
| nik90 | timp, ah ok, so now they are enums that just set the value directly thereby avoiding string comparisons | 10:42 |
| timp | yes, and internally there was a binding to the fontSize which made it even worse | 10:44 |
| nik90 | timp, wow you guys are squeezing every little to improve performance. Looking forward to see zbenjamin's C++ conversion branches land in rc-proposed images very soon. | 10:46 |
| timp | we had to move the Label to a cpp implementation for this. Label also gets the proper default color from the theme now. | 10:46 |
| ahayzen | \o/ | 10:46 |
| nik90 | \o | 10:47 |
| timp | me too :) zbenjamin is doing a lot of good work with the c++ conversions | 10:48 |
| === JMulholland_ is now known as JMulholland | ||
| zbenjamin | nik90: don't expect too much in terms of performance though. I did only a few basic components so far :) Its all prerequisites for the bigger ones | 12:03 |
| mcphail | nik90: do I remember correctly that it was you who worked on the bug in the clock app, where the alarm would register for the wrong day if set after midnight? thanks for fixing that. Have you seen the same behaviour in indicator panel? Would it be an easy fix? | 12:06 |
| nik90 | zbenjamin, ack. | 12:07 |
| nik90 | McIntireEvan, yes I worked on that bug. Are you noticing it with the indicator-panel as well? | 12:07 |
| nik90 | mcphail, ^^ | 12:07 |
| nik90 | used the wrong nick | 12:07 |
| mcphail | yes - if I check my alarms ar 0130h before bed, the first alarm is still marked as "0730 tomorrow" | 12:07 |
| nik90 | mcphail, I am afraid the indicator-datetime is an entirely different project and interfaces directly with EDS while clock does it with the SDK. | 12:08 |
| nik90 | Can you report a bug? I can request charles to look into it. | 12:08 |
| mcphail | nik90: aah. that's a pity. I'll just file a bug, then | 12:09 |
| nik90 | https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+filebug | 12:09 |
| mcphail | ta | 12:09 |
| === _salem is now known as salem_ | ||
| mcphail | nik90: https://bugs.launchpad.net/ubuntu/+source/indicator-datetime/+bug/1549783 | 12:30 |
| ubot5` | Launchpad bug 1549783 in indicator-datetime (Ubuntu) "Indicator shows "Tomorrow" for an alarm happening today when checked after midnight" [Undecided,New] | 12:30 |
| nik90 | mcphail, thnx a lot. I just managed to reproduce it by manually changing the system time and checking. Will expand on the bug description to make it easier to reproduce. | 12:33 |
| mcphail | nik90: Thanks! | 12:34 |
| jockerfox | Hi, exist an italian forum for ubuntu sdk develeper ? | 14:08 |
| nik90 | timp, Hey, after upgrading to UC 1.3, it seems I cannot find the page header buttons in QML Unit Tests. | 16:53 |
| nik90 | I looked at the UITK Tests source, for eg at http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/tests/unit/tst_components/tst_header_colors.qml | 16:54 |
| nik90 | testCase.header = findChild(mainView, "MainView_Header"); | 16:54 |
| nik90 | findChild(testCase.header, actionName + "_header_button"); | 16:54 |
| nik90 | but for me the second find child doesn't find the trailing action buttons which previously passed with UC 1.2. | 16:54 |
| nik90 | any ideas? | 16:54 |
| timp | nik90: when you use PageHeader, the old MainView_Header is hidden | 16:55 |
| timp | nik90: the PageHeader is a new Item. You can simply refer to that item (page.header, or you give it the objectName that you like and you select using that) | 16:56 |
| nik90 | timp, does the old MainView_Header hide even if I use PageHeader in just one of the mainPage.qml from where I launch other child pages? | 16:57 |
| nik90 | I expected PageHeader to be used only in mainPage.qml, while the child pages pushed from mainPage.qml use the old page header | 16:57 |
| timp | nik90: it depends on the Page that is active at the moment. If that page has Page.header set, the MainView header is hidden. When you activate another page (for example push it on a pagestack), and that page has no Page.header, then the AppHeader becomes visible again | 16:58 |
| timp | nik90: if you use AdaptivePageLayout, the AppHeader is always hidden | 16:58 |
| timp | nik90: Yeah, what you expected sounds right | 17:00 |
| nik90 | timp, in the clock app, I used PageHeader only in mainPage.qml to hide the header for good. However in the child pages like (AlarmLabel and EditAlarmPage) we retain the old header. But in autopilot vis, I don't see it anymore. Also the old tests fail as a result of not being able to use MainView_Header | 17:00 |
| nik90 | I will try setting a object id to the pageHeader I set and see If I can access that. | 17:00 |
| timp | nik90: the header with objectName: "MainView_Header" is still there in MainView.qml | 17:01 |
| timp | let me check something, maybe the objectNames for the buttons changed | 17:01 |
| nik90 | I couldn't find MainView_Header. I searched for the node using autopilot3 vis. | 17:02 |
| timp | hmm | 17:02 |
| timp | nik90: objectName: action.objectName + "_button" | 17:02 |
| timp | nik90: ah, so the testCase.header = findChild(mainView, "MainView_Header") already fails? | 17:03 |
| timp | nik90: I wonder if that fails when it is executed at a moment when the mainview header is not visible | 17:03 |
| nik90 | hmm no that line passes..although I dont see it in vis. | 17:03 |
| nik90 | it just fails at not being able to find the save header button | 17:03 |
| nik90 | I will try action.objectName + "_button" | 17:04 |
| nik90 | timp, that worked! | 17:04 |
| timp | ok, so we changed that :s | 17:05 |
| timp | I remember there were some problems with tests, but I don't remember the details | 17:05 |
| nik90 | :) | 17:06 |
| nik90 | ahayzen, balloons: ping | 18:13 |
| ahayzen | nik90, pong | 18:13 |
| balloons | nik90! | 18:13 |
| nik90 | Hi :) | 18:13 |
| ahayzen | o/ | 18:13 |
| nik90 | I need some autopilot help :) | 18:13 |
| balloons | nik90, what are you working on? | 18:14 |
| ahayzen | uhoh | 18:14 |
| * ahayzen hides :-) | 18:14 | |
| nik90 | So the backstory is that we switched clock app to UC 1.3 and the new ListItemLayouts which provides three labels title, subtitle and summary. | 18:14 |
| nik90 | How do I grab these via autopilot | 18:14 |
| ahayzen | nik90, the same way as before? | 18:14 |
| nik90 | in the qml code, I can only set the objectName of ListItemLayout | 18:14 |
| ahayzen | hmm let me check what i did | 18:14 |
| ahayzen | i seem to remember things working, or maybe AP got skipped :') | 18:15 |
| balloons | nik90, do you absolutely need to use autopilot for what you are writing? | 18:15 |
| nik90 | however I cannot access the properties by listitemlayoutitemobjectname.title.text | 18:15 |
| nik90 | balloons, well we implemented the new clock app design whhich is blocked by failing tests :/ | 18:15 |
| nik90 | so I just started fixing some of them | 18:15 |
| balloons | nik90, well I have some news on that front too | 18:15 |
| balloons | I've been going through all the apps; but yes the clock tests have some issues | 18:16 |
| ahayzen | oh i think i remember... | 18:16 |
| ahayzen | nik90, http://bazaar.launchpad.net/~music-app-dev/music-app/trunk/view/head:/app/ui/Songs.qml#L101 | 18:17 |
| balloons | I guess I'm asking if any of the current tests can be deemed as either 1) Too hard to maintain 2) Can be mostly implemented at a lower level | 18:17 |
| balloons | according to you that is | 18:17 |
| ahayzen | nik90, basically just set the title.objectName to something :-) | 18:17 |
| nik90 | balloons, I am going to check if trunk has all AP tests passing. If that is the case, then this new design implementation should have its tests passing as well without too much effort. | 18:17 |
| nik90 | I remember seeing ahayzen branch fixing a failing test for clock app. | 18:18 |
| ahayzen | nik90, i had a branch that fixed some things, just not all ... then it got top approved so jenkins swallowed it up | 18:18 |
| nik90 | ahayzen, wait, does top-approving ignore the test results? | 18:18 |
| ahayzen | nik90, yup | 18:19 |
| balloons | my notes are; Tests suffer from timing issues, missing objects, missing location helpers and the random keyboard doesn't appear bug | 18:19 |
| balloons | so that's clock | 18:19 |
| ahayzen | nik90, it was the 'workaround' to speed up development :') | 18:19 |
| nik90 | I wasn't aware of that. | 18:19 |
| ahayzen | :-) | 18:19 |
| nik90 | balloons, are there AP test writers who can volunteer to help with that? | 18:19 |
| nik90 | I am trying to improve the situation instead of leaving it as it is. | 18:20 |
| ahayzen | nik90, maybe we can get some of the GCI people on it | 18:20 |
| balloons | yes, I am with you | 18:20 |
| balloons | but I guess I should share somethig with both of you | 18:20 |
| balloons | ahayzen saw a sneak preview of what I'm going to share, but it's pretty much ready now | 18:21 |
| balloons | https://docs.google.com/document/d/1ApGwM9iI9qArbu4fMMdDs4Irb9fULfSVIjm79E-UBpQ/edit# | 18:21 |
| * nik90 reads | 18:22 | |
| ahayzen | i think we just need to migrate more to QUnit/QTest/whatever you call it | 18:22 |
| ahayzen | but you still need autopilot for somethings | 18:22 |
| ahayzen | and ideally i'd like there to be zero manual tests :-) | 18:22 |
| balloons | Also note the workflow at the bottom. We've been suggested to stop running AP tests on commit, and as you can see the new workflow runs it only during release | 18:22 |
| ahayzen | ...not more... | 18:22 |
| ahayzen | ..but that comes from someone who worked for a company doing manual tests for years :') | 18:23 |
| balloons | well historically manual testing has defined ubuntu.. I suppose this is a bit of realism creeping into the idealism we've had until now | 18:24 |
| ahayzen | balloons, who does the "run manual tests" before the branch lands? | 18:24 |
| nik90 | balloons, I have been pushing for ages about allowing core-app devs use QML Tests for both feature-tests and unit-tests, however it was rejected by the SDK devs. | 18:24 |
| ahayzen | balloons, is that by another member of the team? or will QA be testing every branch from the community now? | 18:24 |
| nik90 | thereby we have had new SDK releases without running the clock app qml tests thereby leading to breakage at some point. | 18:25 |
| nik90 | Is this new flow accepted by all the concerned people (SDK, QA, Core-apps devs) ? | 18:25 |
| balloons | I literally just spoke with QA about it, but yea, that's the idea | 18:26 |
| balloons | on the SDK side, perhaps we can help by adding jobs they can easily run | 18:26 |
| balloons | or a script? I'm not sure, but we do want to make it easy. | 18:27 |
| balloons | I hadn't thought about the SDK side of things, so it's a good point nik90 | 18:28 |
| balloons | I am concerned however that it seems the cmake builds vary and not all are running unit tests even on build, so tweaking jenkins to force the issue is on the list | 18:28 |
| balloons | I know you spent time working on running qmltests on the device, which kind of didn't work out. However, we could potentially do the ole on the desktop run | 18:29 |
| nik90 | I think jenkins was running the clock app qml tests at some point. | 18:29 |
| nik90 | true | 18:29 |
| nik90 | runnign on the desktop is a small compromise | 18:29 |
| nik90 | until we find a way to run it on the device. | 18:30 |
| balloons | right. More or less the idea is during the release process all the high level user testing is done, and it's done on a real device. Both automated and manual testing | 18:30 |
| ahayzen | i nearly had a script running it on device | 18:30 |
| balloons | for the merges; sure, let's just get low levels tests run, wherever we can do it | 18:30 |
| nik90 | balloons, I believe QA already does manual-testing before releasing a click to the store. | 18:30 |
| balloons | yep, definitely | 18:30 |
| balloons | what I'd like to see is making sure all the manual tests which are scattered around get committed into the repos | 18:31 |
| balloons | so it's very straightforward | 18:31 |
| nik90 | balloons, btw how has "Pilot" helped? | 18:31 |
| nik90 | because "Pilot" was all about getting manual-tests into the hands of the community testers. | 18:31 |
| nik90 | That would solve the "find all regressions" before release problem..hell even the QA team would benefit from such an approach. | 18:32 |
| balloons | yes indeed. I would say it's been utilized more for specific OTA feature testing, like the bluetooth stuff. We haven't taken it any further than the initial run with the community core apps | 18:32 |
| balloons | I'm certainly for it, but it requires coordination on QA's and core app devs side as well | 18:32 |
| balloons | this issue has kind of risen above it. All the jenkins and automated testing stuff has sort of pushed it down the list in priority | 18:33 |
| balloons | jenkins now at least is running stable, fingers crossed | 18:33 |
| ahayzen | balloons, one thing i noticed for Pilot is people hit 'Fail' and not 'Skip' sometimes...and then i cannot tell whether the comment came from a pass/skip/fail | 18:33 |
| balloons | yea, we have to roll a new version that forces a comment on fail | 18:34 |
| balloons | the code got done, but we've not synced from upstream | 18:34 |
| ahayzen | balloons, look at this https://ubuntu-community-testing.staging.ubuntu.com/reports/overview/2015.com.ubuntu.music/music-library/music-appears-sd-card | 18:34 |
| balloons | lol, I like it | 18:34 |
| ahayzen | balloons, 2 skips ... but 3 comments saying "No sd card slot" | 18:34 |
| ahayzen | so that suggests at least one person selected pass/fail | 18:34 |
| ahayzen | when they should have selected skip | 18:34 |
| balloons | right. | 18:36 |
| balloons | So overall, what do you guys think? | 18:36 |
| ahayzen | i think we should migrate as many tests as possible to Unit... then the rest to manual/autopilot | 18:37 |
| balloons | For instance, some of the changes are a bit more straightforward. Reminders/notes for example has proven very hard to maintain because of all the mocking. The AP testsuite for it moving forward will limit this to only what can be done without having to have an evernote account attached to make it maintainable | 18:37 |
| ahayzen | balloons, what about then running AP only when the branch is top approved? | 18:37 |
| ahayzen | and apps where it is tricky, could just remove their instances of AP, only having manual/unit | 18:38 |
| ahayzen | and we should move all manual tests so that they are in the branch | 18:38 |
| balloons | ahayzen, according to QA we should run it only at release, so that's what we'll do. Obviously this means apps need to make sure they have lower level test coverage | 18:38 |
| ahayzen | hmmm | 18:38 |
| nik90 | Without an army of volunteers to help out with writing/maintain AP tests, having a fully automated test-suite is idealistic and very difficult to achieve as observed. I'd migrating to QML Tests for most lower level test coverage and leaving the rest to manual testing (via Pilot) seems the way to go. | 18:38 |
| balloons | and you are correct ahayzen. So I mentioned notes, but I'm not sure what for example what Music | 18:39 |
| balloons | 's suite should look like | 18:39 |
| ahayzen | balloons, i'd like to move alot of ours to Unit tests | 18:40 |
| ahayzen | but some things could be tricky as alot of components depends on other things...but that is just down to poor way the code is constructed :-/ | 18:40 |
| ahayzen | (refactor-round-2 anyone? ;-) ) | 18:40 |
| balloons | ok, good. Calculator is another straighforward example. They have a nice suite of both unit and autopilot tests. And the AP tests run and don't cause issues. However, they are re-testing stuff the unit tests cover, so no reason to have many of them | 18:40 |
| balloons | ohh also nik90, cmakepluginparser is broken, but the replacement is much simpler | 18:42 |
| ahayzen | balloons, is there an example layout of how unit test structure should look like for jenkins to figure it out ? | 18:42 |
| ahayzen | or is that WIP | 18:42 |
| balloons | not yet. As I said, lol, I literally just finished doing the research and writing that up and sharing it. So today I was going to start working on the easy apps | 18:43 |
| balloons | Ohh, this is some raw info too: https://docs.google.com/spreadsheets/d/1LqKolytVmzsebEZQHUyByTCnoFmpPE9eNYQJAyvfIVA/edit#gid=0 | 18:43 |
| ahayzen | :-) | 18:44 |
| balloons | so for the unit tests, it's simply a matter of making sure jenkins always runs them. That's all we really care about | 18:44 |
| balloons | for sanity sake, I guess tests/unit is the desirable location | 18:45 |
| ahayzen | yeah | 18:45 |
| ahayzen | balloons, what about mocking though? | 18:45 |
| balloons | mocking; as in integration tests or ? | 18:45 |
| balloons | We'll worry about integration tests after everything else on the list is done imho | 18:45 |
| ahayzen | mocking for unit tests | 18:46 |
| ahayzen | eg to test our Player {} component we would need music which is tracked by ms2 | 18:46 |
| balloons | ohh and before we get too much lost in the weeds, nik90, did we actually answer your question, or just complicate things? | 18:47 |
| ahayzen | balloons, in a WIP branch i had, i had a bash script http://bazaar.launchpad.net/~ahayzen/music-app/qml-unit-test-filenames/view/head:/tests/unit/setup_run_on_device.sh :-) | 18:47 |
| ahayzen | haha | 18:47 |
| nik90 | balloons, got it..dont' focus too much on AP tests for now.. | 18:47 |
| nik90 | that said I fixed 2 AP to PASS | 18:47 |
| nik90 | 2/5 not bad :P | 18:47 |
| ahayzen | :-) | 18:47 |
| balloons | well nik90, specifically since it's blocking you, I'd like some input on what tests should stay and what needs removed | 18:48 |
| ahayzen | yeah i remember being able to get 2 passing, the others required location ? | 18:48 |
| ahayzen | balloons, only the ones related to location need to be removed :-) ... music passes IIRC :-) | 18:48 |
| nik90 | ahayzen, I doubt any of the tests require location consider we have 3 alarm tests, and 2 worldclock tests. | 18:48 |
| balloons | ack ahayzen, that was my thought. nik90 already pushed things to the lower level tests last year | 18:48 |
| nik90 | I got the 2 world clock tests working just now | 18:48 |
| balloons | for some reason the alarm ones is it do | 18:49 |
| nik90 | alarm tests are failing due to "UCUbuntuShape.isAnimating failed: false != dbus.Boolean(true, variant_levl=1) | 18:49 |
| nik90 | hmm strange | 18:49 |
| ahayzen | nik90, hmm i thought weather and clock were both failing due to the location dialog....oh maybe it different | 18:49 |
| ahayzen | nik90, have you checked the screenshot? | 18:49 |
| nik90 | balloons, ahayzen I think you are referring to asking for location permission from the user. | 18:49 |
| ahayzen | nik90, yeah that | 18:50 |
| ahayzen | that is what was blocking the weather app tests, and i thought the clock as i was trying to fix both | 18:50 |
| balloons | nik90, so I guess if you think all 5 are still solid and should be maintained, that's what we'll do. If you feel any will just cause more headaches, let's make sure we have low level coverage as much as possible and a manual test for it | 18:50 |
| nik90 | which I believe was blocked because trust-store didnt have proper support for AP tests or something..but that too was fixed sometime later. | 18:50 |
| ahayzen | balloons, "that was my thought" ... to the use of a bash script ? | 18:50 |
| balloons | ahayzen, I was referring to your suggestion about removing tests that run into the location issue | 18:51 |
| ahayzen | ah :-) | 18:51 |
| ahayzen | balloons, what do you think about the bash script ? | 18:51 |
| ahayzen | :-) | 18:51 |
| balloons | re: the script, is this unit tests? | 18:51 |
| ahayzen | balloons, yup that is for running the unit tests | 18:51 |
| balloons | and if I run them locally and not on the device? | 18:52 |
| ahayzen | balloons, use the other script :-) http://bazaar.launchpad.net/~ahayzen/music-app/qml-unit-test-filenames/view/head:/tests/unit/setup_run_locally.sh | 18:52 |
| balloons | ahayzen, nik90 I'm all ears if you have a preference for how you'd like jenkins to run unit tests, as well as how the apps should have them laid out | 18:53 |
| ahayzen | balloons, because, for example, that test was checking that different filenames work with the app, as we have been having multiple issues with #'s or funny characters in filename breaking the encoding | 18:53 |
| balloons | ahayzen, right, great regression test | 18:53 |
| ahayzen | so obviously it needs to make and move the files into ~/Music | 18:53 |
| ahayzen | hence the script | 18:53 |
| balloons | should every app just provide a script that jenkins runs? | 18:54 |
| ahayzen | balloons, i think if we had two or one dynamic script that can do any presetup and then run the tests would be best | 18:54 |
| balloons | should I just try and execute qmltestrunner myself in the folder? | 18:54 |
| ahayzen | something like what i was trying todo | 18:54 |
| ahayzen | balloons, or maybe.... have a init.sh and cleanup.sh that you run before/after | 18:54 |
| balloons | well, heh, that should still all be one script for jenkins sanity sake | 18:55 |
| nik90 | I usually go into the builddir and run "ctest --output-on-failure" which runs *all* qml testsuites and outputs the results. | 18:55 |
| balloons | right, I was leaning towards the ctest idea -- but ahayzen has a point about doing setup things | 18:55 |
| nik90 | http://bazaar.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/trunk/view/head:/README.unittest | 18:55 |
| ahayzen | i was just running $ ubuntu-app-test qmltestrunner -silent -eventdelay 500 | 18:55 |
| ahayzen | IIRC | 18:55 |
| nik90 | wait, ubuntu-app-test? | 18:56 |
| ahayzen | yeah | 18:56 |
| nik90 | not seen that until now | 18:56 |
| nik90 | interesting | 18:56 |
| ahayzen | so you can run qmltestrunner on device | 18:56 |
| balloons | ctest is nice because you can control the output level | 18:56 |
| ahayzen | it like runs your app inside that | 18:56 |
| nik90 | ah ok | 18:56 |
| ahayzen | otherwise qmltestrunner can't run on device due to permissions and stuff | 18:57 |
| ahayzen | so it gives it an 'app' to run in | 18:57 |
| nik90 | balloons, I say with your experience decide if jenkins will find it easier to run scripts or ctest. | 18:57 |
| nik90 | and all app devs stick to it. | 18:57 |
| ahayzen | nik90, can the ctest have mocking in it though? | 18:57 |
| balloons | well the answer is if we require a script, it doesn't matter | 18:57 |
| balloons | that does mean you are forced to follow a rule about how your source tree is setup. Which we don't yet have (only rule is having a cmake file) | 18:58 |
| nik90 | ahayzen, I haven't tried moving files...however we mock clock app alarms so that the user's alarms are not affected in the desktop. | 18:58 |
| balloons | but presumably we could add it to cmake, so | 18:58 |
| ahayzen | nik90, problem is, we have mediascanner2 to deal with, which is a nightmare to mock | 18:58 |
| ahayzen | it is easiest to move the files into ~/Music :-) | 18:58 |
| nik90 | ah..then a script would be make it easier | 18:59 |
| nik90 | ah script give more power/flexibility on setting up things for the test. | 18:59 |
| balloons | yea, I'm concerned for things like docviewer having the same issue | 18:59 |
| ahayzen | i think a script gives the most options | 18:59 |
| ahayzen | whether that script just then runs ctest, then doesn't matter | 18:59 |
| nik90 | yup | 19:01 |
| balloons | ok, do we think we can sanely include that in cmake and not have developers take it out? | 19:01 |
| ahayzen | so for clock the script could simply just do $ ctest --output-on-failure | 19:01 |
| ahayzen | but for more complex ones, we can then do mocking etc | 19:01 |
| ahayzen | balloons, i'm not a cmake ninja, so idk what can be done in it | 19:03 |
| nik90 | not sure either | 19:04 |
| nik90 | zbenjamin, ^^ | 19:04 |
| nik90 | zbenjamin, do you happen to know if we can make cmake execute a script in jenkins? | 19:04 |
| ahayzen | balloons, i sense we need to try a few use cases, end to end.. to figure out the best structure :-) | 19:04 |
| balloons | yes, we'll have to try and see what everyone prefers | 19:05 |
| nik90 | ahayzen, just noticed that music-app and clock share almost the same source tree structure (except for the backend folder) | 19:05 |
| ahayzen | hehe | 19:05 |
| ahayzen | i would say that is not a mistake ;-) i may have hijacked some of the structure :-) | 19:06 |
| nik90 | you guys added http://bazaar.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/trunk/view/head:/README.unittest as well? :P | 19:06 |
| ahayzen | nik90, the google code-in people did :-) | 19:06 |
| nik90 | I meant http://bazaar.launchpad.net/~music-app-dev/music-app/trunk/view/head:/README-Mergeproposal.md | 19:06 |
| nik90 | my bad | 19:06 |
| balloons | we made some attempts to standardize readme's and make contribution easier by including them | 19:07 |
| nik90 | either way good to set a common structure amongst core-apps to help easily debug/contribute. | 19:07 |
| ahayzen | nik90, balloons made a task at the google code-in to sort out all the readmes for the core-apps :-) | 19:07 |
| nik90 | oh | 19:07 |
| nik90 | awesome! | 19:07 |
| ahayzen | so that's why we all have similar readmes, even in markdown :-) | 19:08 |
| balloons | DanChapman, care to chime in on how you are running unit tests for dekko? | 20:08 |
| m_jimmer | nik90: http://pastebin.com/2mxRknxE << example | 20:30 |
| balloons | nik90, all done messing with clock? | 21:10 |
| nik90 | balloons, I fixed those 2/5 AP tests and merged the new design implementation. I am now working on adding the new bottom edge stuff that design requested. | 21:11 |
| nik90 | hopefully we can get a store release next week. | 21:11 |
| balloons | nik90, ok. So I can remove the cmakepluginparser and add the ability for the tests to run again from an SDK build? | 21:11 |
| balloons | basically fix the test setup / launch dode | 21:12 |
| nik90 | balloons, sure, go ahead | 21:12 |
| balloons | k | 21:12 |
| nik90 | any change I am doing will not touch that part of the code | 21:12 |
| balloons | I'm just curious how you managed to launch the tests | 21:12 |
| balloons | as I can't on my desktop without these changes | 21:12 |
| nik90 | balloons, I just followed the instruction in README.autopilot and .unittest | 21:13 |
| nik90 | I am running in my spare 16.04 laptop | 21:13 |
| balloons | hmm, ok. Well, I trust I won't be breaking anything | 21:13 |
| nik90 | you're the testing expert..I trust it will be fine. | 21:14 |
| balloons | nik90, ok I think everything is going to be fixed. | 22:17 |
| nik90 | yay | 22:17 |
| balloons | Not too bad. Removed more code than anything else :-) | 22:17 |
| nik90 | balloons, me too ;) https://code.launchpad.net/~nik90/ubuntu-clock-app/new-bottom-edge/+merge/287236 | 22:24 |
| nik90 | balloons, let me know when to top-approve. | 22:26 |
| ahoneybun | mhall119, I have a few errors on installing the SDK on Kubuntu 15.10 with the backports | 22:43 |
| ahoneybun | you said to let someone know if there was any issues | 22:43 |
| balloons | nik90, land it I guess. You changed the bottom edge anyway, so we'll look into why it's coming up not ready after you land | 22:52 |
| nik90 | balloons, ack. | 22:53 |
| nik90 | balloons, on testing your MP, I cannot run the tests anymore on 16.04 desktop | 22:56 |
| balloons | nik90, I tried both ways.. using the builddir and using the sdk build | 22:56 |
| nik90 | I get, ERROR: unittest.loader.ModuleImportFailure.ubuntu_clock_app.tests.test_alarm | 22:56 |
| nik90 | ImportError: No module name ubuntuuitoolkit | 22:56 |
| nik90 | actually 1 sec | 22:57 |
| balloons | and you have the uitk installed right, lol? | 22:57 |
| nik90 | it works! | 22:57 |
| balloons | kk | 22:57 |
| nik90 | I accidentally used autopilot | 22:57 |
| nik90 | instead of autopilot3 | 22:57 |
| balloons | ahhh | 23:02 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!