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