[00:57] <elopio> boiko: oh, it has succeeded the last 5 times. It seems better now, I hadn't notice that.
[00:58] <elopio> I'll take a look at dialer app instead.
[07:51] <mzanetti> t1mp: hey, I just noticed that tagger doesn't start any more. Looking at the logs it looks very strange...
[07:51] <mzanetti> t1mp: did something change in the Page element?
[07:55] <mzanetti> dpm: so... I'd say we should merge our branches... that'll make it easier to get through CI
[07:55] <dpm> mzanetti, yeah, actually I've been doing that all along
[07:55] <dpm> my branch contains all of your changes
[07:55] <dpm> as I realized separately they would not pass Jenkins tests
[07:55] <mzanetti> yeah... sure... but as you've set it as a prereq its still threated as 2 different ones
[07:56] <dpm> mzanetti, yeah, I need to re-send a MP that removes the pre-dep
[07:56] <dpm> pre-req
[07:56] <dpm> but I was trying to understand what's needed for AP
[07:56] <mzanetti> dpm: should we merge it into a team branch, so baloons can add commits to make autopilot work
[07:57] <dpm>  mzanetti, wfm
[07:57] <mzanetti> dpm: I think if we're going to use production we only need to update the token in the jenkins setup and that's it
[07:58] <mzanetti> given that account-plugin-evernote is still the same name ,but switched over to production
[07:58] <dpm> mzanetti, I'm not too sure. I see that the tests use their own token :/
[07:58] <mzanetti> and the app uses production too without the -s
[07:58] <dpm> hardcoded
[07:58] <mzanetti> yeah... so that needs to be updated
[07:58] <dpm> http://bazaar.launchpad.net/~reminders-app-dev/reminders-app/trunk/view/head:/tests/autopilot/reminders/evernote.py#L23
[07:59] <mzanetti> yeah, that's it... a new one with the production server needs to be created and put in there...
[07:59] <mzanetti> I'd say that's it
[07:59] <dpm> mzanetti, not sure. Why do we need to hardcode a token instead of generating it? It will make the tests fail whenever the shardId changes
[08:00] <mzanetti> dpm: well... that's a question for balloons and/or elopio
[08:00] <dpm> right, right, but it's a question I can't ignore
[08:01] <mzanetti> no?
[08:01] <mzanetti> I mean... they sure have a reason to hardcode it... most likely because its too cumbersome to generate one for each test run
[08:02] <mzanetti> so... unless we want to rethink the way we're doing the tests at all, I'd say they just need to be updated. in this case the token
[08:04] <dpm> in that case we should use another API key. We're already publishing the consumer secret and name in one place, and Evernote have asked us to change that once we go into production. I wouldn't want to hardcode it somewhere else, especially if the shardId specified in that token (and perhaps other parameters in the token) is something that can change on the Evernote servers
[08:05] <dpm> anyway, we'll discuss it with balloons and elopio when they're up. I'd like it to be trivial to adapt the tests, but I'm afraid it will not be
[08:05] <dpm> in the meantime, I'll push the team branch
[08:10] <mzanetti> t1mp: this is the error: http://paste.ubuntu.com/7740832 and this is the code: http://bazaar.launchpad.net/~mzanetti/tagger/trunk/view/head:/app/qml/main.qml
[08:10] <mzanetti> doesn't make much sense to me...
[08:11] <JoeyChan> Hi,         for this bug https://bugs.launchpad.net/ubuntu-rssreader-app/+bug/1298978
[08:11] <JoeyChan> any schedule  upgrade to Qt 5.3.1 ?
[08:23] <mzanetti> dpm: oops. just found an uncommited changed
[08:24] <dpm> mzanetti, nm, you can push it to lp:~reminders-app-dev/reminders-app/switch-to-production now
[08:25] <mzanetti> yep, will do
[08:25] <dpm> cool
[08:30] <mzanetti> dpm: who would have thought it requires a 1000 line diff to switch to production :D
[08:30] <mzanetti> -1 for the sandbox
[08:30] <dpm> mzanetti, indeed, I had planned this to be 2 days. It's been almost 2 weeks
[08:31] <dpm> mzanetti, btw, the branch as it is does not build. I'm guessing it's because of the missing commit you were mentioning?
[08:31] <mzanetti> no... shouldn't be
[08:31] <mzanetti> lemme check
[08:32] <dpm> mzanetti, that's what I'm getting: http://pastebin.ubuntu.com/7740922/
[08:32] <mzanetti> dpm: fixed
[08:33] <mzanetti> ah... pushed to wrong branch
[08:33] <mzanetti> now
[08:33] <dpm> yep, building now, thanks
[08:33] <mzanetti> dpm: btw... line 341 in the diff did the trick with the hostname
[08:35] <dpm> mzanetti, yeah, I had asked mardy about that
[08:35] <mzanetti> oh... did you fix it too?
[08:35] <mzanetti> I thought it looks different than what I recalled :D
[08:35] <mzanetti> hehe
[08:35] <mzanetti> right... mine was EvernoteConnection.hostname = accountService.authData["parameters"]["HostName"]
[08:35] <dpm> mzanetti, yeah, yours was slightly different, both worked. But I took Alberto's suggestion, as he's the master of UOA :)
[08:36] <mzanetti> actually I'm surprised that works
[08:36] <mzanetti> given that authData is a jsonObj
[08:36] <mzanetti> anyways
[08:36] <mzanetti> I think we're good now
[08:37] <dpm> yep, will sync with balloons to adapt the tests and robru to do the archive upload for account-plugin-evernote
[08:56] <kalikiana> t1mp: https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/120-HeaderState/+merge/224813
[09:03] <t1mp> kalikiana: weird. So if the initial state is "normal" instead of "", then it does set the initial value from the state?
[09:04] <kalikiana> t1mp: yes, anything other than ""
[09:05] <kalikiana> t1mp: would it be feasible to get the 'head' from the Page the state was defined in?
[09:06] <kalikiana> mostly as a way to avoid filling in head: mypage.head everywhere
[09:07] <t1mp> I don't see a way
[09:08] <t1mp> the page is not even the parent of the states
[09:08] <kalikiana> oh?
[09:08] <kalikiana> but the State uses its parent
[09:08] <kalikiana> ah sorry, it uses the head's parent
[09:08] <t1mp> ?
[09:10] <kalikiana> t1mp: that's why you need to set head to an existing page's head, no?
[09:10] <kalikiana> as opposed to just setting eg. actions on the PageHeadState
[09:11] <t1mp> kalikiana: the PageHeadState sets the actions of the Page.head, that's why I need the Page.head there
[09:13] <t1mp> kalikiana: I agree that the API is not super-pretty.. so if you know of a better way to do it tell me :)
[09:13] <kalikiana> t1mp: but the state is inside the same Page
[09:13] <t1mp> hmm.. getting weird jenkins failures here https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/NewColors/+merge/225230
[09:13] <t1mp> kalikiana: what does it matter that the state is in the page?
[09:14] <t1mp> kalikiana: the state doesn't know about the page
[09:14] <kalikiana> t1mp: it makes it redundant to pass the page or page.head there for each state
[09:14] <kalikiana> when it's the obvious choice
[09:15] <t1mp> kalikiana: for us, yes. But State is not as smart as we are ;)
[09:15] <kalikiana> what's the parent of State then?
[09:17] <t1mp> kalikiana: http://qt-project.org/doc/qt-5/qml-qtquick-state.html
[09:17] <t1mp> kalikiana: State is not an Item
[09:22] <kalikiana> hrm. okay
[09:23] <kalikiana> I suppose defining head is the best option then
[09:23] <t1mp> I don't know a better option
[09:23] <t1mp> but it is not very nice.. so if you have any ideas....
[09:26] <t1mp> kalikiana: setting the property values back in State { name: "" } is probably something that also needs to be done when using standard States, right?
[09:27] <t1mp> not specific for the PageHeadState
[09:27] <kalikiana> t1mp: a crazy idea would be to not use State/ states… so PageHeadState could have a parent… but that would duplicate the states API…
[09:28] <kalikiana> say it were headerState for the sake of the argument
[09:29] <kalikiana> t1mp: yes, there's 2 rules, avoid "", and change the name of the state if you change its target
[09:30] <t1mp> kalikiana: what do you mean change the State's target?
[09:33] <kalikiana> t1mp: sorry I mean PropertyChanges.target
[09:35] <t1mp> I still don't get it, can you show an example?
[09:35] <t1mp> btw, in https://docs.google.com/a/canonical.com/document/d/1wUUKtPmRmwbUELC1BUB9l0VOAwS_zAPRSCqMopUxR1c/edit# we discussed a bunch of alternatives for this HeaderState before, but in the end they all turned out to be much more complicated than what I have now
[09:35] <t1mp> we = zsombi and I
[09:36] <t1mp> kalikiana: I had prototypes to automatically detect the Page.head from the state, but it seemed not doable in a straightforward way
[09:40] <dholbach> rpadovani, HAPPY BIRTHDAY!!!
[09:41] <kalikiana> t1mp: dude, target is a property :-)
[09:41] <kalikiana> changing that property
[09:41] <kalikiana> won't work as you like unless you change the state by name
[09:42] <kalikiana> t1mp: "straightforward" meaning what? would it be a complete solution or would it fail in some cases?
[09:42] <liuxg_> I want to make use of the existing wifi setting in my qml app, how can I import the libs. I did it like: import Ubuntu.SystemSettings.Wifi 1.0. However, it complains that "module "Ubuntu.SystemSettings.Wifi" is not installed". How  can I set the import path correctly? thanks
[09:43] <kalikiana> t1mp: I assume you did discuss it well so I'm not trying to unroll all the rationales. But to understand why it's like this
[09:50] <t1mp> kalikiana: with "straightforward" I mean there was no solution in qml. Perhaps there is a solution if we would re-implement Items and more in cpp ;)
[09:50] <t1mp> kalikiana: I was going to type "impossible", but of course it is not impossible, so I said not straightforward :)
[09:50] <kalikiana> ha. okay
[09:50] <kalikiana> let's leave it at that then
[09:51] <t1mp> kalikiana: but you have a fresh look on it, so maybe you do see a solution that we didn't think of?
[09:51]  * t1mp gonna eat sth, brb
[09:55] <kalikiana> looking at the State API I fear that's the real problem, as long as we're using that and not going for a state-like separate API
[09:55] <kalikiana> it's like the QtObject issue where there's no children default property
[10:12] <t1mp> kalikiana: yeah, State only updates properties, but doesn't know any context
[10:13] <nik90_> t1mp, kalikiana: I need one of you to check my MP https://code.launchpad.net/~nik90/ubuntu-clock-app/add-modify-alarm-support/+merge/224791. It uses the SDK Alarms API to edit a saved alarm. But sometimes it causes the clock app to crash while saving the alarm. Just need someone to review and see if I am doing anything wrong. (if you have some time to spare)
[10:14] <t1mp> kalikiana: ^ do you know anything about the alarms?
[10:27] <dholbach> lool, beuno, popey: https://lists.launchpad.net/ubuntu-appstore-developers/msg00869.html - your input would be appreciated
[10:35] <popey> dholbach: k
[10:49] <kalikiana> nik90_: I can take a look
[10:49] <nik90_> kalikiana: thnx
[10:52] <dpm> mzanetti, it wasn't in the original requirements, but while testing Reminders, I've noticed that we also download PDF attachments. I'm wondering if we can do anything to show those. The best thing would be to use content hub and make them available to our (inexistent) doc viewer. But since we cannot do that for obvious reasons, do you think we could do something like use a JS PDF viewer to show a preview? We've got other more important things to do,
[10:52] <dpm>  so I'm not proposing it for RTM, but I'd like to hear your thoughts
[10:53] <mzanetti> dpm: yeah, there's lots more...
[10:54] <mzanetti> dpm: I started to add support for audio files
[10:54] <mzanetti> dpm: but video files are still lacking
[10:54] <mzanetti> dpm: IIRC you can upload a mp3 file and it'll show up as audio in the viewer
[10:54] <dpm> oh wow, I hadn't realised you'd started on those
[10:54] <mzanetti> but yeah... really not finished
[10:55] <mzanetti> I figured pictures would be most pressing and just did some proof of concept for others to see if the architecture allows it
[10:55] <dpm> indeed
[10:58] <kalikiana> nik90_: did you have any trace from that crash?
[10:58] <nik90_> kalikiana: I am not sure how to get the trace..In the console output all I get is The program has unexpectedly finished.'
[10:59] <kalikiana> gdb :-)
[11:00] <nik90_> kalikiana: yeah let me try reproducing the crash
[11:02] <nik90_> kalikiana: http://paste.ubuntu.com/7741424/
[11:04] <t1mp> kalikiana: I pushed an update to https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/120-HeaderState/+merge/224813
[11:05] <t1mp> kalikiana: is there anything else you like to be changed tere?
[11:05] <t1mp> *there
[11:08] <nik90_> t1mp: in your example in that MP, I noticed you defined the search action twice. http://paste.ubuntu.com/7741446/
[11:08] <nik90_> t1mp: is that necessary?
[11:08] <nik90_> t1mp: in the "added file 'modules/Ubuntu/Components/PageHeadState.qml"
[11:09] <t1mp> nik90_: no, that is a mistake. I removed it now, thanks :)
[11:09] <nik90_> t1mp: np
[11:10] <nik90_> t1mp: one more thing, you defined state: "default". Is this required? Doesn't qml automatically load the default state?
[11:10] <nik90_> t1mp: and does "default" and "" point to the same state?
[11:11] <t1mp> kalikiana: ^ your solution to make it simple brings up new questions ;)
[11:12] <t1mp> nik90_: errr.. wait a second.
[11:12] <t1mp> nik90_: the first state should be named "default", not ""
[11:12] <nik90_> ;)
[11:14] <t1mp> nik90_: it seems like the property changes are only applied when the state changes, so when I name the first state "" (which is the default initial state), its properties are not applied, and I would have to set head.actions for the Page as well as in the state
[11:14] <t1mp> nik90_: thats what I had in r1125 of this branch
[11:14] <nik90_> t1mp: well you wouldn't have to define state " " explicitly since it points to the default property values
[11:15] <nik90_> t1mp: this way you would only require the PageHeadState for the search mode while the default mode is implied automatically when you define the head.actions in the page
[11:16] <kalikiana> t1mp: isn't the comment obsolete now? "// needed otherwise actions will not be"
[11:16] <kalikiana> it's not actually a work-around anymore
[11:16] <kalikiana> it does set the action(s)
[11:16] <t1mp> kalikiana: yeah. See my last revision :)
[11:17] <kalikiana> ah
[11:17] <t1mp> kalikiana: mumble
[11:18] <nik90_> t1mp: so quick question. I would need to use the PageHeadState *only* when having multiple header modes? or also when having just a default mode?
[11:19] <t1mp> nik90_: only for multiple header modes
[11:19] <nik90_> ack
[11:20] <t1mp> nik90_: normally you can simply set the Page.head properties.. but if you want to change those depending on the state, I recommend PageHeadState
[11:20] <t1mp> nik90_: you don't even need PageHeadState; a normal State will do, but then you have to define all the properties that you want to set separately.. PageHeadState is only for convenience
[11:21] <nik90_> t1mp: ah ok
[11:24] <nik90_> kalikiana: does the trace tell your anything? It seems to be at QV4::QObjectWrapper::wrap(QV4::ExecutionEngine*, QObject*) () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5 but that doesnt tell me if this is a SDK crash or EDS crash
[11:25] <kalikiana> I see a ton of these: Do not put Page/Tabs/PageStack inside another Page because that causes confusion which is the active page that sets the title and actions
[11:25] <kalikiana> hmm
[11:26] <kalikiana> I wonder where there's a variant involved here fromVariant
[11:26] <nik90_> kalikiana: that's due to the bottom edge. But it is the same code used in the contacts, dialer app
[11:26] <nik90_> kalikiana: so that's couldn't cause the crash
[11:27] <kalikiana> probably not, but I can't ignore seeing tons of errors ;-)
[11:28] <nik90_> kalikiana: :)...I am using http://bazaar.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/utopic-3.0/view/head:/app/components/PageWithBottomEdge.qml which is the component I got from renato
[11:28] <nik90_> kalikiana: in the designs we got, the bottom edge houses a page. Since the bottom edge itself is in a page, it results in Page inside a Page. Hence the warnings
[11:29] <t1mp> maybe we should remove those warnings
[11:29] <kalikiana> hmm I think that sounds like something we discussed in the last sprint
[11:29] <t1mp> there used to be apps that have Page inside Page, and they assumed that the inner one (I think) was active
[11:41] <kalikiana> nik90_: hrm not really getting ideas on the crash
[11:42] <nik90_> kalikiana: I will try reproducing some more crashes and see if the trace output is any different.
[11:42] <nik90_> kalikiana: I got these crashes while deleting the alarm and swiping the bottom edge
[11:43] <nik90_> kalikiana: may be the crash with regards to saving an alarm might show something
[11:47] <nik90_> kalikiana: found a better output
[11:47] <nik90_> kalikiana: http://paste.ubuntu.com/7741599/
[11:47] <nik90_> kalikiana: this is around the UCAlarmModel clear() function
[13:25] <dpm> popey, could you trigger a jenkins run for https://code.launchpad.net/~reminders-app-dev/reminders-app/switch-to-production/+merge/225436 ? for some reason the changes from 4 hours ago hasn't triggered a new run
[13:26] <popey> dpm: done
[13:26] <dpm> great, thanks
[13:30] <mzanetti> dpm: did you just move the meeting?
[13:33] <dpm> mzanetti, yeah, it seems balloons and elopio are not yet around
[13:33] <mzanetti> ah ok... yeah, would be good to have them around :D
[13:33] <dpm> :)
[13:33] <mzanetti> not sure If I can participate at 5 though
[13:33] <mzanetti> but you know all my opinions on it already... so I'm sure you can take care of it
[13:34] <dholbach> mhall119, is https://bugs.launchpad.net/ubuntudeveloperportal/+bug/1334275 at the right LP project?
[13:34] <dpm> mzanetti, sure, I put you as optional, as you've got enough on your plate, and you and I have already discussed the options
[14:07] <renato__> popey, pkunal-parmar , great news I go the same freeze on desktop :D I will be able to debug that :D
[14:07] <pkunal-parmar> :)
[14:07] <pkunal-parmar> let me know if i can help
[14:07] <popey> "great" news!
[14:25] <rschroll> Morning, all.  Anyone interested in hacking on the epub reader Beru, see the list of bugs here: https://github.com/rschroll/beru/issues?labels=hackdays-1407
[14:26] <rschroll> Let me know if you have questions, concerns, or patches!
[14:27] <mihir> popey: balloons Jenkins passed this MR , https://code.launchpad.net/~nskaggs/ubuntu-calendar-app/fix-1335512/+merge/225373
[14:29] <balloons> wonderful..
[14:29] <rschroll> SDK question: How do you tell if a device is reorientable?  I want to add an option to lock the orientation, but only when that's meaningful.
[14:36] <t1mp> kalikiana: any first thoughts on this MR? https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/panelHeight/+merge/225493
[14:36] <t1mp> kalikiana: I still have to run some tests and check apps to make sure I don't break anything
[14:44] <mhall119> http://developer.ubuntu.com/2014/07/100000-app-downloads/
[14:46] <ogra_> mhall119, insane ... you are making that up, right ?
[14:48] <renato__> popey, https://code.launchpad.net/~pkunal-parmar/ubuntu-calendar-app/CalManagement/+merge/213355/comments/542463
[14:50] <popey> thanks renato__
[14:50] <mhall119> ogra_: it's crazy right? But beuno swears the numbers are accurate
[14:50] <ogra_> ah, so it is him making them up ... :)
[14:51] <beuno> I get paid based on them/
[14:51]  * ogra_ thought so :) 
[14:52] <renato__> popey, one more patch: https://code.launchpad.net/~pkunal-parmar/ubuntu-calendar-app/CalManagement/+merge/213355/comments/542465
[14:52] <mhall119> beuno: you could have at least kept it at a plausible level :-P
[14:52] <renato__> popey, this is just changing the usability, is not related with the freeze
[14:57] <popey> ok
[15:01] <nik90_> zbenjamin: hey, regarding the updated packages which fixes the desktop file issue, when do you plan on pushing them as an update? Or have they already landed?
[15:02] <zbenjamin> nik90_: we have them in landing but still fight with a gdb problem :/
[15:03] <nik90_> zbenjamin: ah ok. hey do you still have the link to the updated packages?
[15:03] <nik90_> zbenjamin: someone is doing the cmake stuff for the clock app and I want to give them the latest packages to test it against.
[15:06] <nik90_> zbenjamin: ^^
[15:08] <zbenjamin> hm i think so
[15:09] <zbenjamin> https://launchpad.net/~ubuntu-sdk-team/+archive/experimental/+sourcepub/4254550/+listing-archive-extra
[15:24] <kalikiana> t1mp: this looks redundant
[15:24] <kalikiana>  property real position: panel.opened ? 0 : size
[15:24] <kalikiana> 38	+ onSizeChanged: position = panel.opened ? 0 : size
[15:24] <t1mp> kalikiana: redundant?
[15:25] <kalikiana> the property already should have the value, no?
[15:25] <t1mp> kalikiana: no it is not, the first line only sets the initial value
[15:25] <t1mp> kalikiana: there are bindings in the states that change it. They set the new values, but don't update position when size changes later
[15:25] <t1mp> s/bindings/PropertyChanges
[15:27] <t1mp> kalikiana: so I think it is correct what I did
[15:27] <t1mp> kalikiana: but I still need to run some tests, so don't happrove yet :)
[15:27]  * t1mp off now, bbl
[15:41] <rschroll> QML question: I have a dialog that has blank space at the top and the bottom.  Any idea why?  https://github.com/rschroll/beru/issues/44
[15:43] <nik90_> rschroll: the top space is generally where the dialog title is placed.
[15:43] <nik90_> rschroll: do you have the qml code link to your dialog?
[15:43] <nik90_> rschroll: the issue shouldn't be present either way
[15:44] <rschroll> nik90_: https://github.com/rschroll/beru/blob/master/ui/BookPage.qml#L263
[15:45] <rschroll> I'm not setting a dialog title, because it should be pretty obvious what this is about.
[15:48] <nik90_> rschroll: have you tried setting the anchors of the option selectors you use? Or does the dialog use a column automatically?
[15:49] <mhall119> DanChapman: I'm loving dekko's use of the bottom edge
[15:49] <rschroll> nik90_: Haven't tried much of anything.  This used to work, but broke sometime recently.
[15:49] <rschroll> My understanding is that dialogs should handle positioning for you...
[15:50] <rschroll> What anchors would you suggest?
[15:50] <nik90_> rschroll: true, I suppose you could ask a SDK dev if anything changed recently
[15:50] <mhall119> Kaleo: is there a -doc package for the Ubuntu UI Toolkit?
[15:51] <nik90_> rschroll: I was thinking may be specify the anchors.top for the option selector to ensure it starts at the top.
[15:51] <rschroll> I'll give it a try...
[15:53] <DanChapman> mhall119: thanks, yes it turned out quite nice :-) one neat little trick to try when replying to a message, highlight an area of the actual message then pull up the composer ;-)
[15:55] <mhall119> DanChapman: doesn't seem to do anything
[15:55] <rschroll> nik90_: That seems to take the option selector out of the flow.  I end up with them stacked in z.
[15:55] <rschroll> Plus a log of errors from Dialog.qml:175:9
[15:56] <DanChapman> mhall119: it doesn't have only the highlighted message text in the composer?
[15:57] <DanChapman> and not the whole message
[15:57] <nik90_> rschroll: hmm
[15:57] <mhall119> DanChapman: it has no text either way
[15:57] <nik90_> rschroll: I will have to create a sample app with a dialog similar to what you use to check what's going wrong
[15:58] <rschroll> nik90_: I can make a test case, if that would help
[15:58] <nik90_> rschroll: test case?
[15:58] <rschroll> I wanted to know if it's a known problem
[15:58] <mhall119> DanChapman: I'm on devel, not devel-proposed, if that might make a difference
[15:59] <rschroll> a simple qml file that (hopefully) displays the problem
[15:59] <mhall119> but I updated dekko this morning
[15:59] <nik90_> rschroll: ah yeah that would help..I don't think the issue is known
[16:02] <nik90_> t1mp: is zsombi on a vacation? I haven't seen him on irc for a while
[16:03] <DanChapman> mhall119: i'm running image #105 and its working fine so you don't seee it working like the two images here http://people.ubuntu.com/~dpniel/dekko/images/?
[16:04] <mhall119> DanChapman: nope, like I said I get an empty message field no matter if I highlight something or not
[16:07] <DanChapman> mhall119: hmmm interesting, i'll upgrade to devel and see what's going on. You should at least be getting the default signature in the message field
[16:10] <mhall119> DanChapman: ah ha!  I went back and setup my Sender Identity, and now it works
[16:11] <mhall119> so, it's something caused by not having that info
[16:12] <mhall119> DanChapman: are you able to change Trojita's network info to "Bandwidth saving mode" when the phone is on 3g? Do we have something that gives you that kind of data?
[16:14] <DanChapman> mhall119: Maybe something went wrong setting up the defaults in U1db. I'll look into that as the composer expects at least the default signature to be there, which really it should work with no signature, i'll fix that.
[16:15] <mhall119> DanChapman: maybe it's because I had an early version installed?
[16:15] <DanChapman> mhall119: i was going to ask you that very question, it's easy enough to configure in Trojita but is there an import component or a c++ api that I can access that info from.
[16:16] <mhall119> DanChapman: maybe something from upstream Qt...
[16:16] <mhall119> t1mp: Kaleo: do either of you know of an API that can tell us if the phone is on wifi or 3g?
[16:17] <rschroll> nik90_ and anyone else interested: Test case here: https://gist.github.com/rschroll/50b75537dd4f814a827b
[16:33] <davmor2> popey: dekko I can send mail, also in the setup pages, the password warning send the next title Red too
[16:33] <davmor2> can't send mail even
[16:34]  * popey points davmor2 at DanChapman
[16:35] <mterry> Any SDK knowledgeable-folks around?  I have a Dialog object that I want to not be covered by the OSK.  It doesn't seem like setting "MainView.anchorToKeyboard: true" is automatically fixing that for me.  Is there another way to control layout of the dialog?
[16:35] <davmor2> mail saved as Drafts doesn't show up in Drafts on the list of folders either
[16:38] <davmor2> DanChapman: Prepare for an influx of bugs thanks to popey asking me to test dekko ;)
[16:38] <popey> \o/
[16:38] <DanChapman> davmor2: Trojita itself doesn't yet have a way to save drafts to the IMAP 'Drafts' but uses local copies. I have a it on a list of things to fix
[16:39] <DanChapman> thanks popey :-)
[16:39] <popey> :D
[16:39] <davmor2> DanChapman: that's good to know
[16:39] <popey> he breaks stuff better than I can
[16:40] <DanChapman> davmor2 what's up with sending mail?
[16:40] <davmor2> DanChapman: When you start typing in a password you get the red Warning that is fine but it seem to turn the next text field title red too
[16:40] <DanChapman> davmor2: IMAP or SMTP?
[16:41] <davmor2> DanChapman: SMTP
[16:42] <davmor2> DanChapman: I have Use STARTTLS, my mail domain, port 25, Authenticate, username and pass filled in
[16:44] <davmor2> DanChapman: and when I hit Send I get http://davmor2.co.uk/~davmor2/screenshots-phone/device-2014-07-03-174335.png
[16:48] <DanChapman> davmor2: right ok could you have a look at ~/.config/com.ubuntu.developer.dpniel.dekko and see if msa.method=SMTP and the port and starttls are correct. I have a feeling this is deeper in the msa factories
[16:52] <davmor2> DanChapman: everything looks correct that has an msa.
[16:57] <davmor2> DanChapman: on a plus side the imap is pretty danr snappy and works fine :)
[16:57] <davmor2> darn even
[17:07] <DanChapman> davmor2: Thanks for looking, It looks like it's creating the submission factory fine then, but it's pulling out at some point during the creation of the message parts. Needs further digging on that one. But yes the IMAP side, as you say is rather snappy :-)
[17:09] <DanChapman> davmor2: do you know the specific smtp server you use? I'd like to try and reproduce it or is it a service like gmail or something
[17:10] <davmor2> DanChapman: it's my own :)
[17:14] <elopio> dpm, hey
[17:14] <elopio> the token that we have in the tests is not for the application. Is for the sandbox test user.
[17:14] <dpm> hola elopio
[17:15] <elopio> dpm: hola
[17:16] <dpm> elopio, yes, I realised that. We were talking with balloons about replacing that token with one for a production test user
[17:16] <dpm> or rather, generating a token for a production test user
[17:17] <dpm> we were wondering why we're hardcoding instead of using UOA to generate it
[17:17] <balloons> elopio, see above.. this is one of the things I was going to chat with you about, so may as well do it here with dpm
[17:18] <elopio> dpm: for the sandbox, hardcoding is the way to go. Then we will have a user that doesn't go through the authorization process that's web and we don't yet have a way to introspect it.
[17:19] <elopio> we should probably do all the heavy automated testing on the sandbox anyway.
[17:20] <balloons> elopio, I'm assuming you did the setup and authorization already for the token you have hardcoded in there corect?
[17:20] <elopio> balloons: yes. You go to the sandbox website, create an account and generate a token.
[17:20] <elopio> that token will be preauthorized for all apps.
[17:21] <balloons> elopio, and actually come to think of it, we can't do that for production, can we?
[17:21] <elopio> balloons: no, we can't.
[17:21] <elopio> for production after we add the account to online accounts, we have to open the ui
[17:21] <elopio> and click a button.
[17:21] <elopio> then, the user will be able to connect.
[17:21] <balloons> yep yep.. I had thought there was some magic, lol, but nope ;-)
[17:22] <elopio> that's doable on the desktop. On the phone not yet, but Alex is working on the oxide-selenium
[17:22] <balloons> so dpm, I guess for test launching we need to use -s
[17:22] <dpm> balloons, elopio, I need to step out for a few minutes, bbiab and will read the scrollback
[17:23] <balloons> elopio, we can commit to https://code.launchpad.net/~reminders-app-dev/reminders-app/switch-to-production/+merge/225436, which is the conversion to production. Given everything, I say we stick with the sandbox, as-is, and tweak the tests to launch reminders in sandbox mode. We can do this using the -s arg. I assume then the tests will pass.
[17:23] <elopio> balloons, dpm: as testing against production involves system settings, online accounts and selenium, I thought a better place for it would be the UX project.
[17:23] <elopio> and for MP, we should test using the sandbox.
[17:24] <balloons> k, I'll make the tweaks. Thanks elopio
[17:24] <elopio> balloons: yes, that sounds fine.
[17:25] <elopio> while we don't have a oxide-selenium, we need to manual test with production. But just a quick exploratory test, as most will be automated tested on the sandbox.
[17:25] <popey> DanChapman: lets move that here, eh nik90_ ?
[17:25] <elopio> well, in the future, that is.
[17:26] <popey> DanChapman: if you could help with crafting a cmake file for https://code.launchpad.net/~ubuntu-clock-dev/ubuntu-clock-app/utopic-3.0 that would be awesome.
[17:26] <DanChapman> popey sure :-)
[17:27]  * DanChapman goes to look
[17:36] <balloons> popey, et la, rss reader should be unblocked in trunk now. I put in a workaround for the test issue
[17:38] <popey> nice one!
[17:38] <rschroll> QML question: How do you set the window and application titles?  (The window title is set to be the same as the Page title by default, but I want them different.)
[17:39] <t1mp> mhall119: sorry, I have no idea if there's an API for that
[17:39] <t1mp> nik90_: yes, zsombi is away for a while
[17:40] <t1mp> ahayzen: it is not done yet (I still have to test some apps to ensure I didn't break anything), but here is an MR that should fix your bug https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/panelHeight/+merge/225493
[17:40] <t1mp> ahayzen: feel free to test it and comment on the MR :)
[17:51] <mhall119> t1mp: it looks like there's a qt-networkmanager library, but it's not installed and I don't know if apparmor would allow access to it
[17:58] <dpm> elopio, balloons, I'd prefer to use production rather than sandbox, but if you think the best way to go for now is sandbox, then fine with me too. However, I'd like to understand a couple of things: 1) elopio, you seem to imply that the process for authenticating in production is different than sandbox, but afaik, it's exactly the same: you could equally receive a token for production and hardcode it 2) Why does the process of logging in need to be
[17:58] <dpm> introspected? I.e. does the fact that UOA authentication via UI (i.e. web page) cannot be introspected mean we can't continue with the process?
[17:58] <elopio> dpm: on the sand box you can get a preauthorized token.
[17:58] <balloons> dpm, I think what you are missing is for the sandbox we can avoid having to authorize
[17:59] <elopio> on production you won't. So in order to use a production token, you will have to ack on an evernote web page that requests authorization.
[17:59] <dpm> elopio, what's a preauthorized token exactly? That's probably the part I'm missing, yes
[17:59] <dpm> oh, I see
[17:59] <dpm> so you won't have to click on the web page to enable the account
[18:00] <balloons> dpm, right. We generate a token and then just use it.. evernote won't make us authenticate
[18:00] <dpm> I was getting confused with our additional UOA authorization, where you also have to click on the u-s-s accounts UI a second time to authorize the app
[18:00] <elopio> dpm: http://dev.evernote.com/doc/articles/authentication.php#devtoken
[18:00] <balloons> I thought elopio had solved this somehow with mardy, but it's not the case. So things make perfect sense
[18:01] <elopio> dpm: but anyway, the sandbox is there to be tested. It's evernote's job to make sure that what you will find in production is as close as possible to what is in the sandbox.
[18:01] <balloons> it was the original problem way back in the day.. I got around it by authenticating, then copying the cookie and session data across for each test run :-)
[18:01] <elopio> so, we should run many many tests in the sandbox. On production just a subset.
[18:01] <balloons> that was fun hehe
[18:02] <elopio> we need a separate suite of tests to check that with the online accounts plugin, you can get an authorized token.
[18:02] <dpm> elopio, well, while I agree, it's us who people will come to when the app or the tests fail because of changes in production. But I do get the point and I agree with the way to go.
[18:02] <elopio> for that, we will need to introspect the web page.
[18:03] <dpm> ack
[18:03] <balloons> I think it's important to think of this as the first step.. but yes, we will want and need to run things on both
[18:03] <elopio> and then, we need a suite that tests the oa plugin, the reminders app and the integration with production.
[18:03] <elopio> I was proposing to put that in the UX tests project, not on the reminders branch.
[18:05] <dpm> balloons, elopio, so do I understand it correctly that the only things we need to do to land that branch and thus to migrate to production are: a) launch the app from the tests with '--sandbox' b) add a dependency to the autopilot .deb package to account-plugin-evernote-sandbox to ensure Jenkins installs the sandbox auth plugin ?
[18:06] <balloons> dpm, I'm working on that as we speak.. and yes, that should be it in theory
[18:06] <dpm> awesome
[18:07] <dpm> thanks balloons, elopio
[18:08] <elopio> dpm, balloons: what about the errors on the tests? Are we still having them?
[18:10] <balloons> elopio, I believe the current failures exist because we are pointing reminders at production, while using our sandbox account
[18:10] <balloons> reminders opens up, but doesn't connect to the server
[18:33] <mhall119> rpadovani: happy birthday :)
[18:49] <elopio> mardy: I have a couple of branches for review. Can you please take a look?
[18:49] <elopio> https://code.launchpad.net/~elopio/ubuntu-system-settings-online-accounts
[19:28] <rschroll> Design question: How are full-screen pages supposed to work with the back button being in the new header design?  The design docs still show the footer.
[19:30] <mhall119> rschroll: youcan still use the header component in a full-screen app
[19:31] <mhall119> or you can always add your own component for back button
[19:32] <rschroll> mhall: Is there something that makes the header automatically hide and show?  Or do I have to program that myself?
[19:37] <rschroll> mhall119 ^^
[19:42] <dpm_> popey, if you happen to be around, would you mind triggering Jenkins for https://code.launchpad.net/~reminders-app-dev/reminders-app/switch-to-production/+merge/225436 ? For some reason this morning commits were not triggering Jenkins. Perhaps because it's a team branch. If you're not around, then tomorrow, no worries :)
[19:43] <dpm_> or perhaps balloons has got Jenkins powers for that? ^
[19:47] <balloons> bien sur mon ami
[19:48] <dpm_> très bien :)
[19:53] <balloons> dpm, Je pas certain succès
[19:54] <balloons> Ce ne fonctionne pas sur la desktop
[19:56] <dpm_> damn
[19:57] <dpm_> balloons, what's the issue? Test failure, or the app not working on the desktop?
[19:57] <balloons> dpm_, the tests haven't worked yet for me
[19:58] <dpm_> argh
[19:58] <balloons> Error fetching username: "Not connected."
[19:58] <balloons> reminders itself isn't making a connection to the server
[19:58] <balloons> it unlocks after we create the account, but doesn't see it.. the log reads like qml: No account available! Please setup an account in the system settings
[19:58] <dpm_> balloons, that's what I got on trusty desktop too, but I thought it was because something needed backporting
[19:59] <balloons> hmm.. well I suppose we have to blame the diff at first
[19:59] <dpm_> perhaps is because something that's expected from the unity8 session is not there?
[20:00] <balloons> dpm_, oO.. you changed the provider id
[20:00]  * balloons notes reading the diff is a good idea
[20:00] <dpm_> aha!
[20:00] <dpm_> well spotted
[20:01] <dpm_> yeah, I needed to do that to be able to install both pluging alongside
[20:01] <dpm_> *plugins
[20:01] <balloons> yea, makes total sense
[20:03]  * balloons re-runs
[20:03]  * dpm_ crosses fingers
[20:03] <balloons> success
[20:03] <dpm_> \o/
[20:04] <balloons> the new one is running
[20:05] <balloons> ok, so assuming this is good. We are landing this and updating the store right?
[20:05]  * balloons runs full testsuite now
[20:07] <dpm_> balloons, we might have to wait with updating the store until tomorrow, as we'll need to update the account-plugin-evernote package in the archive first
[20:07] <dpm_> I'm coordinating with robru to do this as soon as the branch lands
[20:08] <dpm_> or if we can land it soon, perhaps we can do the archive upload today, but I'm about to leave soon
[20:08] <balloons> i think it's ready
[20:08] <balloons> if you are happy, I'm happy
[20:08] <balloons> I should run it on the device now though..
[20:09] <rschroll> mhall119: Can you clarify: Is there built-in support for full-screen behavior with the new header, or would I have to show and hide the header manually?
[20:09] <dpm_> balloons, +1
[20:10] <dpm_> I'm not just happy, I'm extremely happy
[20:10] <rschroll> Note that the page is not flickable, so the header won't vanish and reappear with scrolling
[20:11]  * balloons just realized what time it is for dpm :-)
[20:11] <balloons> the day went quick..
[20:11] <dpm_> indeed :)
[20:11] <dpm_> but we're making progress :)
[20:12] <balloons> ohh yea. I solved the rssreader blockage, got calendar landed and this too ;-) best way to leave for a long weekend
[20:12] <dpm_> balloons, nice work
[20:13] <balloons> always a team effort.. it's just SO nice when it all lines up
[20:14]  * dpm_ hugs balloons and elopio
[20:14] <balloons> dpm_, feel free to top approve
[20:14] <balloons> I'm just building and running on the device, but if something weird is happening there I wouldn't hold this merge for it anyway
[20:15] <dpm_> balloons, sounds good to me, top approved. Jenkins was being a bit funny with running jobs on this branch (perhaps because it was a team branch), so it might need some poking to auto-land?
[20:15] <balloons> dpm_, sure I can launch the autoland job
[20:15] <balloons> jenkins says success :-)
[20:16] <dpm_> *\o/*
[20:17] <balloons> k, autolanding job is launched.. we should be merged in a few mins
[20:17] <dpm_> awesome, I'll see if I can get the archive upload lined up
[20:19] <popey> dpm_: still need jobs triggering
[20:20] <popey> ?
[20:23] <mhall119> rschroll: if you're not using a flickable to auto-hide the header, then yes you'd have to manage it in your own code.  At that point it might be worthwhile just making your own back button that fits better into your app
[20:23] <dpm_> popey, no, thanks, we've been iterating through it with balloons, and it's all good
[20:23] <popey> good good
[20:23] <balloons> yep yep.. we's gonna have a new shiny on reminders!
[20:25] <popey> yee haw
[20:31] <rschroll> mhall119: Thanks for the info.  Is there any reason not to continue using the old toolbar in this case?
[20:34] <dpm_> and merged :)
[20:36] <mhall119> rschroll: the only reasons not to are if (1) you want to use the new header features or (2) you want to use the bottom edge for something else
[20:37] <rschroll> mhall119: Is it possible to toggle the new header on a per-page basis?
[20:40] <rschroll> nik90_: I've submitted two bugs about the dialog sizing issues: #1337555 and #1337556.  Let me know if I should ping anyone about them.
[21:02] <mhall119> rschroll: you'd have to use an on*Changed property callback to change the property on the MainView, but it should be possible (not sure how nice that is from a UX perspective though)
[21:19] <rschroll> mhall119: thanks.  I'll give it a try.  And if it doesn't work, I'll just steal the toolbar code wholesale and use that for my bottom-edge behavior in the fullscreen page.
[21:23] <ahayzen> t1mp, thanks for the quick branch :D
[21:31] <mhall119> rschroll: just keep the license in mind if you copy code
[21:46] <rschroll> mhall119: Don't worry -- I'm being a good boy: https://github.com/rschroll/beru/blob/master/COPYING :)
[22:40] <gerlowskija> Has anyone seen this error when running the calendar-app autopilot tests: "ImportError cannot import name pickers"? (full error: http://paste.ubuntu.com/7744319/).
[22:40] <gerlowskija> I can run other the autopilot tests for other apps without problems (I tried clock-app and dropping-letters).