[00:00] <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:01] <ahayzen> haha
[00:02] <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:03] <ahayzen> balloons, thanks for ur help, we'll try and stay green :)
[00:04] <balloons> ahayzen, you are most welcome
[00:05] <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:13] <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:15] <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 :/
[08:00] <dholbach> good morning
[09:14] <JamesTait> Good morning all; happy Maple Syrup Day! :-D
[09:33] <owl> hi
[09:42] <oSoMoN> nerochiaro, hey, would you mind approving https://code.launchpad.net/~osomon/gallery-app/fix-ftbfs-cmake-moc/+merge/199198 ?
[10:05] <nerochiaro> oSoMoN: looking
[10:06] <nerochiaro> oSoMoN: ok, makes sense. approved
[10:06] <nerochiaro> oSoMoN: weird that it built fine on desktop
[10:08] <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:37] <oSoMoN> nerochiaro, I’ve added a bunch of mostly minor comments to your MR
[10:38] <nerochiaro> oSoMoN: i'm looking into them
[10:56] <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:57] <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
[11:02] <nerochiaro> oSoMoN: and I think I'll actually change the name of lastOpenedPicture to currentMediaInViewer. much clearer
[11:02] <oSoMoN> nerochiaro, sounds good
[11:21] <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:31] <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:32] <nerochiaro> greyback: if I file one, to which package should it be addressed to ?
[11:33] <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:35] <nerochiaro> greyback: yes
[11:36] <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:39] <nerochiaro> greyback: so should i report a bug on unity8-autopilot to add this king of emulator ?
[11:40] <greyback> nerochiaro: yeah
[11:59] <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
[12:00] <greyback> nerochiaro: yes it is
[12:00] <nerochiaro> oSoMoN: pushed all changes you requested, I think
[12:04] <oSoMoN> nerochiaro, ok, will test in a bit
[13:07] <oSoMoN> nerochiaro, it seems you didn’t remove the TODOs from your code
[13:10] <nerochiaro> oSoMoN: oh, ok, doing it now
[13:11] <nerochiaro> oSoMoN: pushed
[13:11] <nerochiaro> oSoMoN: heading out for a bit of food
[13:12] <oSoMoN> same here
[14:04] <zsombi> tmoenicke: ping
[14:06] <tmoenicke> zsombi: pong
[14:10] <timp> zsombi: can you add the proposed new functions to https://docs.google.com/a/canonical.com/document/d/1Ng3fJxg-LaUgQU3ITNIg0cOB0Ii00XuX3a8PAs7lpns/edit# ?
[14:11] <zsombi> tmoenicke: do you know the height of the OSK by heart?
[14:12] <zsombi> timp: yes, I will
[14:12] <timp> okay :) thanks
[14:13] <zsombi> timp: uhm... how you thought? where ? :D
[14:14] <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:15] <zsombi> timp: ahh... and the P2 is not up to date at all...
[14:16] <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:17] <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:18] <zsombi> tmoenicke: what's the pixel/GU ration of the Nexus?
[14:19] <timp> zsombi: I'm done
[14:20] <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:21] <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:22] <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:23] <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:24] <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:26] <zsombi> timp: the last one of teh DatePickers: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/pickerpanel/+merge/199250
[14:28] <timp> zsombi: jenkins still doesn't like the previous one
[14:29] <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:30] <zsombi> timp: the error is not really descriptive
[14:30] <timp> last time it seemed to fail on generating the docs :s
[14:33] <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:34] <zsombi> timp: and only on armhf
[14:37] <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:46] <dholbach> dpm, mhall119: do you know where http://developer.ubuntu.com/resources/tutorials/getting-started/creating-click-packages-with-cpp-extensions/ went?
[14:47] <dholbach> hum, nevermind, it was linked from the test site
[14:47] <dholbach> hrm
[14:53] <mhall119> dholbach: from the developer.u.c test site?
[14:54] <dholbach> yeah
[14:54] <dholbach> I found the blog post to the app showdown from last time which I referred somebody to
[14:56] <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:57] <popey> hmm, seems okay now
[15:00] <beuno> popey, network glitch?
[15:05] <popey> possibly
[15:14] <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:17] <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:18] <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:20] <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:21] <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:24] <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:26] <timp> kalikiana_: yes, *somebody* has to. That's why I am especially happy that you did it ;)
[15:27] <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:28] <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:31] <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:36] <mzanetti> kenvandine: one more question. should I be able already to use the gallery content picker somehow?
[15:37] <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:38] <kenvandine> has an example
[15:39] <mzanetti> cool. thanks.
[15:40] <kenvandine> http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Content/
[15:40] <kenvandine> mzanetti, ^^
[15:40] <mzanetti> yep. found that
[17:10] <hakermania> How can GNOME 3 and Unity has so similar layout and GNOME 3 be so much faster ?
[17:11] <hakermania> Even with the Unity blur and the logging of the applications off, GNOME 3 remains 7 to 10 times faster.
[17:20] <EDY> hi developers
[17:21] <Guest52113> any developer girl here?
[17:28] <popey> Guest52113: we tend not to distinguish between male and female developers round these parts
[17:28] <popey> why?
[19:51] <balloons> nik90, ping
[21:03] <nik90> balloons: pong
[21:04] <balloons> nik90, :-) So I wanted to chat about alarms and your merge proposal
[21:05] <balloons> nik90, so first things first. What's up with alarms? Who were you speaking with about getting the visualization to show up?
[21:06] <nik90> balloons: I sent some messages over to charles kerr who was incharge of the notifications. But I did not get any reply.
[21:07] <nik90> And I haven't pursued it again recently
[21:07] <nik90> so technically no one is on the alarms issue
[21:08] <balloons> nik90, ok, so I started to chase charles a bit but wasn't sure if I had the right person
[21:09] <balloons> nik90, however, afaik does charles need to make a change on the platform side or do you simply need information?
[21:10] <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:11] <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:13] <balloons> charles, thank you that would be helpful. In a nutshell is there work for you to do yet?
[21:16] <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:17] <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:18] <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:19] <nik90> balloons: sure :)
[21:19] <nik90> balloons: I read your comment on the MP
[21:20] <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:21] <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:22] <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:23] <nik90> balloons: line number pls?
[21:23] <balloons> ?
[21:23] <nik90> found it
[21:24] <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:25] <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:27] <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:28] <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:30] <balloons> yep. that should work fine
[21:34] <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:35] <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:36] <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:37] <balloons> So if it was 0 it would fail... that's basically just a 10 second sleep
[21:37] <nik90> actually yeah :P
[21:38] <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:39] <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:40] <balloons> the point is, it's not doing what you think it is :-)
[21:41] <nik90> yeah I am strongly suspecting so
[21:42] <nik90> I think I need to think about this more
[21:43] <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:44] <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:46] <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:47] <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:48] <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:49] <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:50] <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:51] <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:52] <balloons> I put everything in the mp as a summary
[21:52] <balloons> thanks nik90 !
[21:54] <nik90> np
[22:27] <nik90> balloons: u still there?
[22:29] <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:30] <nik90> balloons: so I am not really sure what I should be doing here to fix it :)