ahayzen | balloons, will do | 00:00 |
---|---|---|
ahayzen | balloons, will probably add them tomorrow if Victor doesn't :) | 00:00 |
balloons | sounds great. you guys have been doing great work | 00:00 |
balloons | and the test writing has been fine | 00:00 |
balloons | good stuff! | 00:00 |
balloons | *fine = fun | 00:00 |
balloons | lo | 00:00 |
ahayzen | haha | 00:01 |
ahayzen | balloons, should this be able to land now, if we approve it again? Jenkins was playing up before https://code.launchpad.net/~vthompson/music-app/fixes-1259962/+merge/198601 | 00:02 |
balloons | ahayzen, yes most likely | 00:02 |
ahayzen | balloons, haha Victor just did it literally then lol | 00:02 |
ahayzen | balloons, thanks for ur help, we'll try and stay green :) | 00:03 |
balloons | ahayzen, you are most welcome | 00:04 |
ahayzen | balloons, oh one very last thing the bug for infographics should i add the needs-autopilot-test or just report as bug first before we decide if to do it or not? | 00:05 |
ahayzen | balloons, FYI the bug with autopilot testcase https://bugs.launchpad.net/music-app/+bug/1261587 | 00:13 |
ubot2` | Launchpad bug 1261587 in Ubuntu Music App " Autopilot Testcase Needed: When the library has an empty state" [Undecided,New] | 00:13 |
balloons | ahayzen, you can still put it in there, but don't mark the status as active | 00:15 |
ahayzen | balloons, ok and tht MP didn't land :/ | 00:15 |
=== chriadam|away is now known as chriadam | ||
dholbach | good morning | 08:00 |
=== mpt_ is now known as mpt | ||
=== dholbach_ is now known as dholbach | ||
JamesTait | Good morning all; happy Maple Syrup Day! :-D | 09:14 |
=== chriadam is now known as chriadam|away | ||
owl | hi | 09:33 |
oSoMoN | nerochiaro, hey, would you mind approving https://code.launchpad.net/~osomon/gallery-app/fix-ftbfs-cmake-moc/+merge/199198 ? | 09:42 |
=== zequence_ is now known as zequence | ||
nerochiaro | oSoMoN: looking | 10:05 |
nerochiaro | oSoMoN: ok, makes sense. approved | 10:06 |
nerochiaro | oSoMoN: weird that it built fine on desktop | 10:06 |
oSoMoN | nerochiaro, yeah, it shouldn’t have built in the first place | 10:08 |
oSoMoN | nerochiaro, thanks for approving, the next MR up for review is https://code.launchpad.net/~osomon/gallery-app/wait-for-confirm-dialogue/+merge/199076 | 10:08 |
oSoMoN | nerochiaro, I’ve added a bunch of mostly minor comments to your MR | 10:37 |
nerochiaro | oSoMoN: i'm looking into them | 10:38 |
=== xnox_ is now known as xnox | ||
nerochiaro | oSoMoN: regarding the comment about my TODO for the transitions going in and out of open pictures: I had a second look and I think the current behavior is acceptable. My next work item after this MR is merged is making sure the list comes back to the previous position, so I can have another look at the transitions when I do that. But I think for now I'll just remove the TODO from the code, address the rest of your | 10:56 |
nerochiaro | comments so we can go ahead and merge this MR. Sounds like a plan ? | 10:56 |
oSoMoN | nerochiaro, sounds like a plan, I’ll do another quick round of functional testing after you address all my comments, and we should be good to go | 10:57 |
nerochiaro | oSoMoN: and I think I'll actually change the name of lastOpenedPicture to currentMediaInViewer. much clearer | 11:02 |
oSoMoN | nerochiaro, sounds good | 11:02 |
oSoMoN | nerochiaro, I’ve triggered a new CI run on your MR, now that my fix for the build on trusty has been merged | 11:21 |
nerochiaro | oSoMoN: thanks | 11:21 |
nerochiaro | greyback: do you remember if there is already a bug report somewhere about providing from unity8 a standard way for AP tests to request closing an app "cleanly" (i.e. as the user would do using the shell) ? | 11:31 |
greyback | nerochiaro: no bug report I'm aware of | 11:31 |
nerochiaro | greyback: if I file one, to which package should it be addressed to ? | 11:32 |
greyback | nerochiaro: unity8 I think. Didn't we think it best if unity8 had a support package for AP to add common utils like this? | 11:33 |
nerochiaro | greyback: yes | 11:35 |
nerochiaro | greyback: there's already a package called unity8-autopilot though | 11:36 |
greyback | nerochiaro: true, that includes AP tests for u8 | 11:36 |
greyback | there are probably handy things in that which other projects would appreciate if shared | 11:36 |
nerochiaro | greyback: so should i report a bug on unity8-autopilot to add this king of emulator ? | 11:39 |
greyback | nerochiaro: yeah | 11:40 |
nerochiaro | greyback: https://bugs.launchpad.net/unity8/+bug/1261720 | 11:59 |
ubot2` | Launchpad bug 1261720 in Unity 8 "add to unity8-autopilot emulator for closing apps" [Undecided,New] | 11:59 |
nerochiaro | greyback: unity8-autopilot is built out of unity8 it seems | 11:59 |
greyback | nerochiaro: yes it is | 12:00 |
nerochiaro | oSoMoN: pushed all changes you requested, I think | 12:00 |
oSoMoN | nerochiaro, ok, will test in a bit | 12:04 |
=== gatox is now known as gatox_dr | ||
oSoMoN | nerochiaro, it seems you didn’t remove the TODOs from your code | 13:07 |
nerochiaro | oSoMoN: oh, ok, doing it now | 13:10 |
nerochiaro | oSoMoN: pushed | 13:11 |
nerochiaro | oSoMoN: heading out for a bit of food | 13:11 |
oSoMoN | same here | 13:12 |
zsombi | tmoenicke: ping | 14:04 |
tmoenicke | zsombi: pong | 14:06 |
timp | zsombi: can you add the proposed new functions to https://docs.google.com/a/canonical.com/document/d/1Ng3fJxg-LaUgQU3ITNIg0cOB0Ii00XuX3a8PAs7lpns/edit# ? | 14:10 |
zsombi | tmoenicke: do you know the height of the OSK by heart? | 14:11 |
zsombi | timp: yes, I will | 14:12 |
timp | okay :) thanks | 14:12 |
zsombi | timp: uhm... how you thought? where ? :D | 14:13 |
zsombi | tmoenicke: any hunch? 30 GU or less? | 14:14 |
timp | zsombi: I don't understand the question | 14:14 |
timp | zsombi: in proposal 2? (or proposal 2A). I think we can mark proposal 3 as not chosen | 14:14 |
zsombi | timp: there's no "real" API proposal there, just examples thrown here'n'there... | 14:14 |
zsombi | timp: ahh... and the P2 is not up to date at all... | 14:15 |
tmoenicke | zsombi: iirc 468 w/out predictive text | 14:16 |
timp | zsombi: indeed. iconSource, pagePreloaded are nonsense now | 14:16 |
tmoenicke | zsombi: but you should be able to read it from the rectangle | 14:16 |
timp | zsombi: I'll edit that part | 14:16 |
zsombi | tmoenicke: yes, I should, just was trying to test it without OSK support... | 14:17 |
zsombi | timp: ok | 14:17 |
zsombi | tmoenicke: so 468 pixels, right? | 14:17 |
zsombi | tmoenicke: what's the pixel/GU ration of the Nexus? | 14:18 |
timp | zsombi: I'm done | 14:19 |
zsombi | timp: me2 :) | 14:20 |
zsombi | timp: do you happen 2 know the GRID_UNIT_PX of Nexus? | 14:20 |
timp | zsombi: I removed the old questions and the gallery section which is also ages old | 14:20 |
timp | zsombi: galaxy nexus? | 14:20 |
timp | zsombi: can I look it up on the device? | 14:20 |
tmoenicke | zsombi: iirc the GN has 18px/gu | 14:21 |
zsombi | ah, it's 18 | 14:21 |
timp | phablet@ubuntu-phablet:~$ export | grep GRID | 14:21 |
timp | declare -x GRID_UNIT_PX="18" | 14:21 |
zsombi | tmoenicke: got it also, thx | 14:21 |
nerochiaro | oSoMoN: well spotted, there was a missing dependency. i fixed it now, pushed all changes you requested | 14:21 |
zsombi | tmoenicke: at some point next year, we should agree on the DatePicker to be added to the OSK layout | 14:22 |
oSoMoN | nerochiaro, thanks, I’m testing on my device now | 14:22 |
oSoMoN | nerochiaro, in the meantime, could you please review https://code.launchpad.net/~osomon/gallery-app/wait-for-confirm-dialogue/+merge/199076 ? | 14:23 |
tmoenicke | cool | 14:23 |
timp | zsombi: it should be possible to use the ConditionalLayouts for our UITK gallery, right? | 14:23 |
nerochiaro | oSoMoN: do you mind if i take care of it after standup ? need to check something before it's too late in the day and sdk people go home | 14:23 |
timp | zsombi: currently it is a bit of a hack. not a bad hack, but still | 14:24 |
oSoMoN | nerochiaro, sure, as long as it goes in today | 14:24 |
nerochiaro | oSoMoN: ok | 14:24 |
zsombi | timp: yes, it should be | 14:24 |
zsombi | timp: the last one of teh DatePickers: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/pickerpanel/+merge/199250 | 14:26 |
timp | zsombi: jenkins still doesn't like the previous one | 14:28 |
timp | zsombi: I added the new MR to my list | 14:29 |
zsombi | timp: the datepicker fails again on docs... but where? it does pass on my local machine... | 14:29 |
zsombi | timp: the error is not really descriptive | 14:30 |
timp | last time it seemed to fail on generating the docs :s | 14:30 |
zsombi | timp: that's all I see: SRC=documentation ./documentation/docs.sh /tmp/buildd/ubuntu-ui-toolkit-0.1.46+14.04.20131129/documentation; make[1]: *** [docs] Error 1 | 14:33 |
zsombi | timp: and only on armhf | 14:34 |
=== gatox_dr is now known as gatox | ||
timp | kalikiana_: ^ didn't we see something like that before? and did you have a look at the cause then? (I vaguely remember something like that) | 14:37 |
dholbach | dpm, mhall119: do you know where http://developer.ubuntu.com/resources/tutorials/getting-started/creating-click-packages-with-cpp-extensions/ went? | 14:46 |
dholbach | hum, nevermind, it was linked from the test site | 14:47 |
dholbach | hrm | 14:47 |
mhall119 | dholbach: from the developer.u.c test site? | 14:53 |
dholbach | yeah | 14:54 |
dholbach | I found the blog post to the app showdown from last time which I referred somebody to | 14:54 |
popey | beuno: is there a problem with the store? I clicked an app in the dash and get a spinner... http://popey.com/~alan/phablet/device-2013-12-17-145531.png | 14:56 |
popey | hmm, seems okay now | 14:57 |
beuno | popey, network glitch? | 15:00 |
popey | possibly | 15:05 |
dpm | hi kenvandine, if we'd like to invoke the camera app from the reminders app to take a picture to attach it to a note and upload it to Evernote, is this something we can do with the content picker? I.e. passing images around. How would it actually work? | 15:14 |
kalikiana_ | timp: I think it may be a race condition, that's why the previous fix didn't actually fix it… I have a possible fix in one branch; I'll isolate it and show you; but since it's a race hard to say if that fixes it… you see the problem | 15:14 |
kenvandine | dpm, i don't think that's a use case we have a way of dealing with now | 15:17 |
timp | kalikiana_: argh. | 15:17 |
=== oSoMoN_ is now known as oSoMoN | ||
timp | kalikiana_: yep, that can be a big hassle. :( | 15:18 |
kenvandine | dpm, i think what we need for this is a way to open camera app and tell it to store the picture in the reminders app | 15:18 |
mzanetti | kenvandine: that still wouldn't go back to the reminders after a picture has been taken | 15:20 |
kenvandine | it would need to | 15:20 |
mzanetti | kenvandine: I think we'd need to convert the camera app to a "picker" | 15:20 |
kenvandine | maybe | 15:20 |
mzanetti | dpm: so yeah... given that it's just about writing Camer {} in qml I'd say we do that ourselves for now | 15:21 |
kenvandine | so the camera app being special hurts us here | 15:21 |
timp | kalikiana_: anyway, thanks for looking into these annoying failures :) | 15:21 |
timp | kalikiana_: you've been working quite a lot on those | 15:21 |
kalikiana_ | timp: somebody has to, right? :-D | 15:24 |
kalikiana_ | here you go https://code.launchpad.net/~kalikiana/ubuntu-ui-toolkit/splitBuildInstall2/+merge/199306 | 15:24 |
timp | kalikiana_: yes, *somebody* has to. That's why I am especially happy that you did it ;) | 15:26 |
dpm | mzanetti, that sounds good to me. kenvandine, I'm not sure I can follow what you mean by the camera app being special, could you clarify? | 15:27 |
kenvandine | well camera-app stores the images in the gallery-app | 15:28 |
kenvandine | it doesn't own it's content | 15:28 |
kenvandine | which is "weird" in our design | 15:28 |
kenvandine | all content is owned by a single app | 15:28 |
dpm | aha, gotcha | 15:28 |
timp | kalikiana_: thanks. I add it to my review list, I need to read up on debian packaging to fully understand what's happening. | 15:28 |
kalikiana_ | timp: I still don't know why it's only armhf… my theory is it might be parallelizing so stricter order would help | 15:31 |
dpm | thanks kenvandine | 15:31 |
mzanetti | kenvandine: one more question. should I be able already to use the gallery content picker somehow? | 15:36 |
kenvandine | yup | 15:37 |
kenvandine | using the content-hub api | 15:37 |
* mzanetti googles for docs | 15:37 | |
kenvandine | https://code.launchpad.net/~ken-vandine/+junk/hub-importer | 15:37 |
kenvandine | has an example | 15:38 |
mzanetti | cool. thanks. | 15:39 |
kenvandine | http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Content/ | 15:40 |
kenvandine | mzanetti, ^^ | 15:40 |
mzanetti | yep. found that | 15:40 |
=== Ursinha-afk is now known as Ursinha | ||
=== teknico_ is now known as teknico | ||
=== gatox is now known as gatox_lunch | ||
hakermania | How can GNOME 3 and Unity has so similar layout and GNOME 3 be so much faster ? | 17:10 |
hakermania | Even with the Unity blur and the logging of the applications off, GNOME 3 remains 7 to 10 times faster. | 17:11 |
EDY | hi developers | 17:20 |
=== EDY is now known as Guest52113 | ||
Guest52113 | any developer girl here? | 17:21 |
popey | Guest52113: we tend not to distinguish between male and female developers round these parts | 17:28 |
popey | why? | 17:28 |
=== gatox_lunch is now known as gatox | ||
balloons | nik90, ping | 19:51 |
nik90 | balloons: pong | 21:03 |
balloons | nik90, :-) So I wanted to chat about alarms and your merge proposal | 21:04 |
balloons | nik90, so first things first. What's up with alarms? Who were you speaking with about getting the visualization to show up? | 21:05 |
nik90 | balloons: I sent some messages over to charles kerr who was incharge of the notifications. But I did not get any reply. | 21:06 |
nik90 | And I haven't pursued it again recently | 21:07 |
nik90 | so technically no one is on the alarms issue | 21:07 |
balloons | nik90, ok, so I started to chase charles a bit but wasn't sure if I had the right person | 21:08 |
balloons | nik90, however, afaik does charles need to make a change on the platform side or do you simply need information? | 21:09 |
nik90 | balloons: he is actually responsible for indicator-datetime service which runs in the background all the time. It is supposed to trigger the notifications when an alarm is triggerd | 21:10 |
charles | nik90, balloons, there's an email discussion today started by dpm about alarms that's discussing the current status, I can forward some of that along to you | 21:10 |
nik90 | charles: yeah sure. I want to get the alarms notifications works asap. It would help identify if there are any issues on the clock app side | 21:11 |
balloons | charles, thank you that would be helpful. In a nutshell is there work for you to do yet? | 21:13 |
charles | balloons: yes, there's indicator-datetime and alarm api work for this scheduled for right after the Christmas break | 21:16 |
charles | it's discussed a little in the third mail I just sent to you | 21:16 |
charles | there's also a link to the draft API there, too | 21:16 |
balloons | charles, excellent, I got the mails ;-) Thank you much | 21:17 |
balloons | I'll update the bug with those details so we have the status recorded.. | 21:17 |
balloons | now nik90 onto your merge proposal ;-) | 21:18 |
balloons | charles, do keep us up to date on the bug report if you would, I know you will | 21:18 |
nik90 | charles: I thought that the indicator-datetime part was complete since it is marked as Fix commited on the bug report | 21:18 |
nik90 | Or is this not yet landed on the phone yet? | 21:18 |
nik90 | balloons: sure :) | 21:19 |
nik90 | balloons: I read your comment on the MP | 21:19 |
charles | nik90: well, there is some code in indicator-datetime right now that connects directly to EDS and should theoretically pull up snap decisions | 21:20 |
balloons | nik90, I'm running again on the latest build and not able to reproduce it | 21:20 |
nik90 | balloons: but here is the thing. The error message seems to indicate test_timer.py file which was not modified in the MP. Could this be a MIR issue or something? | 21:20 |
charles | I'm not sure how much confidence to put into the existing datetime code; one thing that will happen with the API discussed in those emails is a better testing framework to do unit tests against the EDS code | 21:21 |
balloons | nik90, it's possible I ran something else.. anything is possible. I'm not seeing any issues now | 21:21 |
nik90 | charles: okay. Yeah I kept an active look on the datetime trunk and thought same | 21:21 |
nik90 | balloons: :) | 21:21 |
nik90 | balloons: so merge? | 21:21 |
charles | :) | 21:21 |
balloons | a couple more runs and yes, I'll approve | 21:21 |
=== Noskcaj10 is now known as Noskcaj | ||
nik90 | charles: I manually got the latest trunk build and tested alarms on phone but it didnt trigger any snap notifications | 21:22 |
balloons | well maybe I have questions to, heh.. | 21:22 |
nik90 | charles: so I am assuming that it needs some debugging | 21:22 |
nik90 | balloons: hehe. let me know and I will answer them :-D | 21:22 |
balloons | why do you have a timeout loop on self.main_view.get_world_cities_list().count != 0? you are using a wait_select so it shouldn't be needed anymore. | 21:22 |
nik90 | balloons: line number pls? | 21:23 |
balloons | ? | 21:23 |
nik90 | found it | 21:23 |
nik90 | balloons: let me look at the code and let you know. 1 second | 21:24 |
nik90 | 1 minute | 21:24 |
balloons | in test_create_lap, can we confirm the stopwatch moves (aka, things increment) even if you want to sleep | 21:24 |
balloons | nik90, I'll just keep posting in here so we iterate faster | 21:24 |
balloons | and finally, you should abstract out the code to create a lap, and call it instead of calling self.test_create_lap() inside test_delete_lap | 21:25 |
balloons | the tests look like the pass just fine now.. So I would say we're good, just need info and tweaks | 21:25 |
nik90 | balloons: what do you mean by abstract out the code to create a lap? | 21:27 |
nik90 | do you mean it shouldn't contain tests and only focus on creating a lap? | 21:27 |
balloons | nik90, so instead of calling the actual test function, call a function that can be used by both tests to create a lao | 21:27 |
balloons | yes.. not a good idea to call a test as part of a test.. | 21:28 |
nik90 | okay that can be done. I will define a new function in test_stopwatch.py file itself | 21:28 |
balloons | yep. that should work fine | 21:30 |
nik90 | balloons: okay I now remember why a timeout loop is required. | 21:34 |
nik90 | this test is to specifically retrieve the results returned from the oonline API | 21:34 |
nik90 | however if you open the clock app and press add city, you will notice that the list is already populated with local results | 21:34 |
nik90 | hence it is necessary to wait few seconds after performing a search to allow for the online results to populate the list | 21:35 |
nik90 | otherwise it just grabs the first local city accidentally instead of the actual online one | 21:35 |
balloons | nik90, do you expect the list to increase in size? | 21:35 |
nik90 | giving a false positive | 21:35 |
balloons | also, we need to work on not retrieving the online result but :-) | 21:36 |
nik90 | balloons: as in more cities being added to the list? | 21:36 |
balloons | yes.. atm, the code would continue no matter what | 21:36 |
nik90 | balloons: yes, the local city list is temporary. We need to get the final result from the design team | 21:36 |
nik90 | but it is a low priority one since online search is available | 21:36 |
balloons | ohh.. while it's !=0.. weird.. it's just wait 10 seconds | 21:36 |
balloons | So if it was 0 it would fail... that's basically just a 10 second sleep | 21:37 |
nik90 | actually yeah :P | 21:37 |
balloons | so if you want online results, grab the original count, then wait for it to increment | 21:38 |
nik90 | no the original count won't increment | 21:38 |
nik90 | the original list would be completely replaced with the online results | 21:39 |
balloons | ohh? | 21:39 |
nik90 | so the original count doesnt matter | 21:39 |
nik90 | the listview can only have one source | 21:39 |
nik90 | so when an online search is made, it replaces the local list with the online one | 21:39 |
nik90 | and hence you see only online search results made by the user | 21:39 |
balloons | well, I'll defer to you since I'm not failure with the objects | 21:39 |
balloons | the point is, it's not doing what you think it is :-) | 21:40 |
nik90 | yeah I am strongly suspecting so | 21:41 |
nik90 | I think I need to think about this more | 21:42 |
nik90 | okay I will see if this can be tested any other way tonight. | 21:43 |
nik90 | Regarding the second question you had about the stopwatch lap | 21:43 |
nik90 | I am using sleep to allow it to sleep 2 seconds and then press the lap button | 21:44 |
nik90 | to ensure that the lap consists of some time | 21:44 |
balloons | nik90, right I'm ok with that. I'd also like to see us check that some time elapses.. or am I missing something | 21:46 |
balloons | i see you check that a lap is created.. perhaps it's enough and I'm offbase | 21:46 |
nik90 | well I could add a check to see if the stopwatch text changes after it has been started | 21:46 |
balloons | ohh right.. the point is, even with a 2 second sleep you can't be sure the stopwatch has moved | 21:47 |
balloons | bingo :-) | 21:47 |
nik90 | but that is already done in the the test_start_stop_reset_stopwatch() test | 21:47 |
nik90 | so why test it again in another test concerning laps? | 21:47 |
balloons | can you have a 0 second lap? | 21:47 |
balloons | in theory it could happen | 21:47 |
balloons | under the current test if 2 seconds isn't enough time for the clicks to process etc | 21:48 |
nik90 | true | 21:48 |
nik90 | alrite I will add a assert statement there | 21:48 |
balloons | it's a possible point of failure due to timing.. | 21:48 |
nik90 | to check if the stopwatch label changes | 21:48 |
balloons | not probable I suppose, but possible | 21:48 |
balloons | yes, that's it | 21:48 |
balloons | gotta watch out for those things.. ok that's all my commentary :-) | 21:48 |
nik90 | regarding your online server mockup | 21:49 |
nik90 | I do not know how to mock that | 21:49 |
nik90 | but here is the thing | 21:49 |
nik90 | the interaction between choosingn a local city and choosing a online city is the same | 21:49 |
nik90 | the only difference between one is fetched online | 21:49 |
balloons | right. I am OK with having the test in there for now. If it flakes out in the dashboard we'll revisit. | 21:50 |
nik90 | okay | 21:50 |
balloons | Perhaps the others would disagree with me :-) | 21:50 |
nik90 | :-) | 21:50 |
balloons | we'll solicit feedback before merging if needed.. it;s easy to disable it | 21:51 |
nik90 | true | 21:51 |
nik90 | I will also talk to thomi about this and keep u updated | 21:51 |
nik90 | meanwhile I will fix the other 2 points u mentioned | 21:51 |
balloons | I put everything in the mp as a summary | 21:52 |
balloons | thanks nik90 ! | 21:52 |
nik90 | np | 21:54 |
nik90 | balloons: u still there? | 22:27 |
nik90 | ballons: I dont think the online search can be tested. As I mentioned earlier the listview containing local results is cleared and overridden with online results. So if you look at the model.count it goes from 91(local) -> 0(after clearing) -> 5 or whatever number of online results. | 22:29 |
nik90 | balloons: But the thing is it is not possible to distinguish between the 91 (local) and 5 (online) results since they populate the same listmodel | 22:29 |
nik90 | balloons: so I am not really sure what I should be doing here to fix it :) | 22:30 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!