[13:59] <dpm> https://plus.google.com/hangouts/_/76cpi8to3h6t7hacjkk6pv0d0s
[14:00] <dpm> For anyone wanting to join the hangout ^
[14:03] <dpm> To participate in the hangout, please join https://plus.google.com/hangouts/_/76cpi8to3h6t7hacjkk6pv0d0s
[14:04] <dpm> The notes: http://pad.ubuntu.com/uds-1311-appdev-1311-porting-apps-materials
[14:04] <Elleo> yep, all working
[14:04] <karni> Hi dpm. Yes we can hear you.
[14:05] <karni> np
[14:07] <dpm> kyleN, http://pad.ubuntu.com/uds-1311-appdev-1311-porting-apps-materials
[14:07] <karni> Should we even be talking about Blackberry ;)?
[14:08] <karni> kyleN: yes, use the link http://pad.ubuntu.com/uds-1311-appdev-1311-porting-apps-materials
[14:09] <karni> I mean, we should probably focus 100% on the existing platforms, rather than BB(Rim) which died.
[14:12] <Elleo> karni: those BB developers, like MeeGo developers will be looking for somewhere to go though
[14:12] <Elleo> and a platform that allows them to work with technologies they're already familiar with might be a pretty attractive target
[14:12] <karni> Elleo: right. I realized we're talking about porting *to* Ubuntu, not from. you're right.
[14:13] <karni> Elleo: yeah, I got that wrong.
[14:13] <Elleo> ah, okay :)
[14:13] <karni> :)
[14:18] <Elleo> dpm: plus MeeGo
[14:19] <Elleo> dpm: I've been vaguely considering writing a tool for automating as much translation as possible between MeeGo, Sailfish and Ubuntu Touch QML components
[14:21] <lucaotta> Elleo: that's going to work only if the semantics of properties/objects are the same
[14:22] <Elleo> dpm: basically just a quick script that translates between fairly common components, there's a lot of similar things between Ubuntu Touch and MeeGo but with slightly different property names, object names, etc.
[14:22] <Elleo> I haven't done much besides sketching out a few ideas, but I've been porting a bunch of MeeGo apps over the past couple of weeks and have found a fair number of commonalities
[14:23] <Elleo> it'd basically just do as much of the grunt work as possible, and highlight possible translations for things that can't be fully automated
[14:25] <Elleo> yeah, on kyleN's point, MeeGo has a fair number of apps at the moment (enough to make a usable day-to-day phone platform), and porting is relatively easily (Qt4 -> Qt5 and Nokia QML to Ubuntu QML)
[14:32] <Elleo> kyleN: nope, I haven't written it yet, all the porting I've done so far has been by hand
[14:32] <Elleo> dpm: sure
[14:32] <dpm> Elleo, would you be interested in developing this script further, and if it works well we could use it as a tool we can recommend on developer.ubuntu.com?
[14:32] <dpm> ah, cool, thanks :)
[14:32] <Elleo> :)
[14:32] <dpm> Elleo, what's your Launchpad id?
[14:33] <Elleo> dpm: michael-sheldon
[14:33] <dpm> Elleo, cool, if you're ok with it, let me add a work item in the blueprint for you
[14:33] <dholbach> Elleo, awesome
[14:33] <Elleo> dpm: sure :)
[14:34] <Elleo> kyleN: yep, I'll have a go at writing it myself, (time allowing)
[14:34] <dholbach> maybe a first step could be to have sort of a "dictionary", to know what needs to be translated from meego to what in ubuntu touch
[14:34] <Elleo> dholbach: yeah
[14:34] <dholbach> Elleo, great :)
[14:35] <Elleo> dpm: yeah, I'd be primarily targeting MeeGo first
[14:35] <Elleo> the eventual goal would be to have it multi-directional
[14:35] <Elleo> with MeeGo, Ubuntu and Sailfish input and Ubuntu and Sailfish output
[14:36] <Elleo> kyleN: yeah, Sailfish is basically a continuation of MeeGo
[14:36] <Elleo> it's mostly developed by ex-Nokia employees who were MeeGo developers
[14:36] <karni> QUESTION: I was wondering if you guys could talk a little/how much do we know about possibility of porting Android/iOS apps to Ubuntu. I'm not familiar with the topic, and it seems its included on the agenda, so it'd be great if we touched on that :)
[14:36] <Elleo> yeah, Sailfish has its own components
[14:39] <karni> I'm only aware of Myriad. Considering Dalvik will be replaced (already testing undergoing in KitKat), they'll also have a lot on their hands.
[14:39] <karni> hehe
[14:39] <karni> Yes
[14:40] <karni> Yes, and we are not promoting Java. That is correct.
[14:40]  * karni nods
[14:41] <karni> Yes. I was just looking at "general guidelines" on the pad and was wondering what we plan to include on that subject.
[14:41] <karni> Ah, gotcha dpm
[14:43]  * karni nod
[14:44] <karni> Thanks kyleN, dpm, now I understand what we were aiming for with those 'general guideline' notes
[14:44] <karni> kyleN: heheh
[14:48] <karni> kyleN: dpm: It would be good to have a central point for dropping porting material to. Do we already have one? If not, perhaps we could decide who or where to drop whatever porting material/hints we come up with.
[14:52] <karni> dpm: FYI what you suggested will probably partially be part of app dev school http://pad.ubuntu.com/uds-1311-appdev-1311-app-dev-schools-materials
[14:54] <dholbach> yeah, it might be hard to already expect attendees in appdev schools to already know how to write Android/iOS apps
[15:02] <popey> dpm: you starting this one?
[15:02] <dpm> popey, yep!
[15:02] <popey> sweet!
[15:03] <dpm> popey, https://plus.google.com/hangouts/_/7acpj0kbue9qr3ib5b7uack0e8
[15:04] <popey> ^^ if anyone else wants to join us
[15:06] <dpm> http://summit.ubuntu.com/uds-1311/meeting/22067/appdev-1311-coreapps-saucy-review/
[15:06] <popey> http://pad.ubuntu.com/uds-1311-appdev-1311-coreapps-saucy-review
[15:07] <iBelieve> I didn't mean to wave three times :) the webpage was messed up :(
[15:07] <dpm> For anyone wanting to join the hangout: https://plus.google.com/hangouts/_/7acpj0kbue9qr3ib5b7uack0e8
[15:07] <iBelieve> I join if I could, but I can't since I'm under 18 :(
[15:07] <nik90> :(
[15:12]  * dpm hugs iBelieve
[15:13] <dpm> iBelieve, feel free to add notes to the pad (I think you already have) or feedback on IRC
[15:16] <iBelieve> dpm:thanks, will do.
[15:19] <iBelieve> I need to go, but I'll try to come back for the core apps planning session in the next hour
[15:33] <asomething> Exactly. Seed it with know great devs, and let them develop their own criteria for letting new people in
[15:33] <nik90> asomething: you should join the hangout..would love to hear your feedback
[15:35] <asomething> well, i could help as well =)
[15:36] <dpm> cool, thanks!
[15:36] <ahayzen1> we had a few times where people would approve themselves, but usually we would just ping dpm, popey, mhall to check the review
[15:38] <dpm> asomething, does this work item look ok to you? -> [asomething] Create an ubuntu-core-app-dev (or similar) team to review/triage across core apps, including guidelines
[15:38] <ahayzen1> a few times we have had it where we need design to review a merge before it can be approved as well, just as a note
[15:39] <asomething> dpm, I might say something like "investigate creating" as opposed to "create" Don't think I have the power to do that on my own
[15:44] <dpm> asomething, I think you should be able to edit the pad, but in any case, I've just changed it to [asomething] Investigate creating an ubuntu-core-app-dev (or similar) team to review/triage across core apps, including guidelines
[15:46] <asomething> The code from http://reqorts.qa.ubuntu.com/reports/sponsoring/ could be used to make an overall view of core app merge proposals if that would be helpful
[15:48]  * dpm looks
[15:50] <dpm> that's pretty awesome, could we easily set it up for core apps asomething?
[15:50] <asomething> dpm, I'll take a look at modifying it
[15:51] <asomething> it's the distro sides sponsoring queue
[15:51] <WebbyIT> Just left the university, this was an interesting talk :/
[15:55] <dpm> https://wiki.ubuntu.com/Touch/CoreApps/DevelopmentGuide
[16:01] <popey> https://plus.google.com/hangouts/_/7acpjkn9kgb6j6vi40l2t2n03g?authuser=0&hl=en
[16:01] <popey> ^^^ hangout url for this session
[16:10] <balloons> seems to be live now :-)
[16:12] <vthompson> Mark also talked about implementing desktop-like dialogs/pop-ups for running on the desktop, IIRC. How do we plan on doing this?
[16:18] <iBelieve> popey: will any new or existing apps be added to the core apps? Such as a tasks app or an audio recorder?
[16:23] <balloons> iBelieve, I don't believe any new core apps are being added apart from what has been announced, aka evernote, etc
[16:23] <asomething> weather could have an extended or hourly forecast when in tablet
[16:23] <iBelieve> balloons:thanks
[16:24] <balloons> vthompson, did they answer your question? :-p
[16:24] <nik90> balloons: not yet
[16:24] <sergiusens> popey, filemanager already does the right thing
[16:24] <sergiusens> popey, has a nice folder list on the left and file list on the right
[16:24] <vthompson> balloons, no--I doubt it's something we can answer now though
[16:25] <popey> sweet!
[16:25] <sergiusens> might need more features though; like the ones you mentioned
[16:26] <popey> sergiusens: does terminal do the right thing?
[16:27] <balloons> week view in weather
[16:27] <sergiusens> popey, it's set as a sidestage app
[16:28] <vthompson> popey, I assume terminal is fine since the UI in tablet mode won't change... but maybe they could add extra tabs?
[16:28] <asomething> notes could use a grid view in a larger display
[16:29] <popey> http://pad.ubuntu.com/uds-1311-appdev-1311-coreapps-trusty-planning
[16:32] <vthompson> popey, music-app could use a well designed tablet mode. First pass we could just place the main app side-by-side with the Now Playing queue... but there has to be a better design
[16:33] <ahayzen> \o/
[16:33] <ahayzen> vthompson, i'm back :)
[16:34] <vthompson> ahayzen, perfect timing as well
[16:34] <ahayzen> yh lol..i load the page...'the music app'
[16:35] <ahayzen> popey, is there anyone we could just ask for their recommendation about specific designs if we don't have a dedicated designer assigned to us?
[16:35] <vthompson> popey, you should add Evernote as well
[16:35] <sergiusens> popey, have you tried the click? https://jenkins.qa.ubuntu.com/job/docviewer-app-click/
[16:37] <sergiusens> it includes the binary plugin
[16:37] <vthompson> popey, doesn't the design team hold regular hangouts now? Couldn't we hijack some time at one of those?
[16:37] <ahayzen> popey, understood, thanks
[16:37] <ahayzen> vthompson, the design clinic?
[16:37] <vthompson> ahayzen, yea that
[16:40] <vthompson> popey, nik90, I like the idea of fishing for community designs
[16:40] <nik90> vthompson: +1..Putting a work task for it
[16:41] <ahayzen> same +1
[16:41] <popey> https://ubuntu.mybalsamiq.com/projects/ubuntuphonecoreapps/grid;jsessionid=A2453A091AD4857F26D9DDD8CED046DD-n3
[16:43] <WebbyIT> I seriously hate Italian network connection :/
[16:44] <vthompson> popey, how do I log into mybalsamiq? User/pass doesn't seem to be Ubuntu SSO...
[16:45] <ahayzen> vthompson, looks like dpm manages it? https://ubuntu.mybalsamiq.com/forgotpassword
[16:46] <popey> https://wiki.ubuntu.com/Touch/CoreApps/Design
[16:46] <ahayzen> popey, from the wiki 'Next, send an email to David Planella (david.planella AT canonical DOT com) and Michael Hall (michael.hall AT canonical DOT com) to ask to be added to MyBalsamiq (this is the system we use for creating mock-ups.'
[16:47] <vthompson> popey, ahayzen, excellent. Thanks!
[16:50]  * sergiusens doesn't mind someone else doing stuff :-)
[16:53] <balloons> sergiusens, lol
[16:54] <vthompson> nik90, your help would be very welcomed
[16:54] <ahayzen> nik90, would love ur help :)
[16:54] <nik90> vthompson: :D
[16:55] <nik90> vthompson: would love to join you guys
[16:56] <ahayzen> vthompson, wht do u think?
[16:57] <vthompson> popey, I'd like to start doing some wireframes--maybe in mybalsamiq. We could see which designs float to the top
[16:57] <ahayzen> vthompson, i feel throw it out to community but i'm fine either way
[16:57] <balloons> nik90, :-p
[16:58] <vthompson> popey, ahayzen, nik90, if we could find a decent way to put together designs we could call for the community to contribute wireframes
[16:58] <ahayzen> vthompson, agreed
[16:58] <nik90> +1
[16:59] <vthompson> nik90, great idea about utilizing the wiki
[17:00] <popey> any final comments?
[17:01] <nik90> thnx guys for your ideas
[17:01] <popey> Thanks!
[17:01] <nik90> Lets make the 14.04 cycle awesome
[17:01] <ahayzen> thanks guys
[17:01] <nik90> btw for really awesome designs check out https://www.pinterest.com/ubuntudesigners/appspiration/
[17:01] <nik90> this was shared during the design session
[17:02] <dpm> vthompson, ahayzen, just drop me an e-mail with the address you'd like to use for Balsamiq and I'll add you
[17:02] <ahayzen> dpm, thanks
[17:02] <vthompson> dpm, doing so now. :)
[17:02] <dpm> awesome :)
[17:03] <ahayzen> dpm, sent :)
[17:05] <dpm> cool
[17:44] <rottinrob> popey....did I miss our meeting
[17:44] <popey> hey rottinrob - no it's at 19:05 UTC which is ~20 mins time
[17:45] <popey> no
[17:45] <popey> 1 hour 20 mins time
[17:45] <popey> stupid clocks
[17:45]  * popey will send a mail to the team ☻
[17:45] <rottinrob> oh great...I have a time translating these time zones...lol
[17:47] <popey> ditto!
[17:51] <mandel_> ok, so if my utc foo is good, I should be running a session in this run in about 15 min...
[17:53] <mandel_> gatox, ask!
[17:53] <gatox> QUESTION: testing
[17:53] <mandel_> gatox, I hate xchat
[17:54] <gatox> QUESTION: testing
[17:54] <mandel_> yes \o/
[18:01] <mandel_> oSoMoN, hello!
[18:01] <oSoMoN> hi mandel_
[18:02] <mandel_> oSoMoN, any idea on how to get to the hangout, I'm utter useless with this kind of things
[18:02] <oSoMoN> mandel_, if you’re the session owner, someone from the organization should ping you with the link to the hangout
[18:03] <mandel_> oSoMoN, awesome
[18:05] <oSoMoN> mandel_, got the link?
[18:05] <mandel_> oSoMoN,
[18:05] <mandel_> no
[18:05] <oSoMoN> dpm, hey, do you know who’s in charge of creating the hangout for the next session?
[18:05] <oSoMoN> (the one starting now)
[18:06] <dpm> oSoMoN, popey
[18:06] <oSoMoN> popey, ping
[18:06] <mandel_> dpm, gracias!
[18:06] <popey> oh
[18:06] <mandel_> popey, give us hang out
[18:06]  * popey is on another session
[18:06] <mandel_> :)
[18:06] <popey> bah
[18:06] <popey> ok, will drop out and create one
[18:06] <mandel_> popey, sweet, thx!
[18:07] <KaleoF> h
[18:07] <KaleoF> a
[18:07] <KaleoF> n
[18:07] <KaleoF> g
[18:07] <KaleoF> o
[18:07] <KaleoF> u
[18:07] <KaleoF> t
[18:07] <aquarius> session not started yet/
[18:07] <aquarius> ?
[18:07] <popey> https://plus.google.com/hangouts/_/7acpjpo4jb8poer9r3fhb6s3do?authuser=0&hl=en
[18:07] <oSoMoN> aquarius, about to start
[18:07] <aquarius> cool
[18:07] <popey> join that
[18:07]  * aquarius is keen on watching this one :)
[18:07] <KaleoF> aquarius is keen.
[18:07] <popey> who is joining?
[18:08] <aquarius> I am indeed. The download service is really important to a bunch of app ideas I have :)
[18:08] <ralsina_> hi aquarius! Long time :-)
[18:08] <aquarius> yo ralsina_!
[18:09] <popey> tvoss_: https://plus.google.com/hangouts/_/7acpjpo4jb8poer9r3fhb6s3do?authuser=0&hl=en
[18:12] <micah2_> yup, we see you!
[18:12] <netcurli> stream is live
[18:13] <aquarius> tvoss_ arrives!
[18:13] <tvoss_> aquarius, o/
[18:17] <aquarius> "if you take a look at the wiki..." and stop. :)
[18:18] <dbarth> tvoss_: i assume you wake up the remote party then, right?
[18:18] <aquarius> tvoss_, I disagree: I think that my app should be able to call DownloadManager.ShowMeAllPreviousDownloads(). I don't think I want my app to get a magic signal on wakeup saying "a download arrived!" because I might not be ready t receive it
[18:19] <dbarth> aquarius: well, that's the API contract for the location service i guess
[18:19] <tvoss_> aquarius, sure ... that's another part of the story, but both should be possible
[18:19] <dbarth> ie, you asked for it, so you get a reply
[18:19] <tvoss_> aquarius, yup, it depends on the service, too
[18:19] <aquarius> *nod*
[18:19] <dbarth> aquarius: hi btw ;)
[18:19] <aquarius> hi dbarth!
[18:19] <dbarth> have some nice apps in mind?
[18:20] <aquarius> my model for the download service is for, say, a podcast player. I say "download this podcast so I can play it later". To do that, I should have to just do downloadManager.downloadAURL(the_url, my_id_for_it)
[18:20] <tvoss_> dbarth, we don't wake up the app for ordinary location updates, only if the app wants geofencing, and there is a "significant" location change
[18:20] <dbarth> ah
[18:20] <aquarius> at that point, I might get put to sleep or get killed; later, I want to check, or be signalled, that the download is complete.
[18:21] <Elleo> aquarius: ideally I'd have thought you should be able to specify the destination as well, not just ask for something to be downloaded and then later told where it is
[18:21] <aquarius> but if the download completes while I'm asleep, then I should not miss stuff :)
[18:21] <Elleo> aquarius: that way you can pass it to the media player service while it's still downloading
[18:22] <aquarius> Elleo, yes and no. I like the idea that the downloadmanager can pick names, so that there are never any name collides and you don't have to specify "overwrite or abort" as a parameter... but I also want to be able to read a partially completed download, for exactly the reason you suggest ;)
[18:22] <Elleo> yeah, being able to ask for the location while it's downloading would work yoo
[18:22] <Elleo> too*
[18:22] <aquarius> Elleo, I can pass a partially completed download to some other service as long as I get told its name at the start rather than at the end :)
[18:23] <Elleo> yeah
[18:23] <aquarius> I have a list of things I think are important ;-)
[18:24] <aquarius> mandel_, tvoss_ do you want to see my list of things I think are important? :)
[18:24] <mandel_> aquarius, yes!
[18:25] <aquarius> Things I think are important in my app: QML support; progress updates for downloads; list previously downloaded things, including in previous sessions; get path of downloaded thing, which must be somewhere inside my sandbox; pass arbitrary URLs; get name of downloaded thing before it's finished downloading.
[18:25] <aquarius> Things I think are important either in my app or in some centralised service UI (perhaps a "download indicator"?): cancel ongoing download; pause ongoing download; open downloaded thing in some app that declares for it (i.e., download indicator is a content hub provider)
[18:26] <aquarius> Request for QML API: Create new downloads with a method, *not* by dynamically creating a whole QML object, because that's incredibly irritating. BUT list of current downloads and list of all downloads should be available as a ListModel from DownloadManager to make it easy for me to deal with it in QML.
[18:26] <aquarius> I agree with KaleoF here -- signals are good, if you are alive, but if you are not alive you need to have some way to query the state explicitly as well as signals on changes.
[18:27] <tvoss_> aquarius, +1
[18:27] <aquarius> agreed totally that my app should not be atomatically woken up when my download completes!
[18:27] <aquarius> *automatically
[18:27] <Elleo> aquarius: perhaps in the case of things like passing downloading things to the media service it should be possible to pass a reference to a download manager id that the media player can subscribe to (so it can show buffering progress)?
[18:28] <aquarius> Elleo, that I'd certainly like to see, but I can imagine that being a phase 2 thing :)
[18:28] <Elleo> yeah
[18:28] <netcurli> yea
[18:28] <aquarius> Elleo, that sort of tight integration would be great though
[18:28] <dbarth> is that where the client API lives as well: https://code.launchpad.net/~ubuntuone-hackers/ubuntu-download-manager/trunk ?
[18:28] <dbarth> is there a lib already or just the dbus service?
[18:28] <aquarius> mandel_, see list above of things I care about :)
[18:29] <mandel_> proposal => https://docs.google.com/a/canonical.com/document/d/1fqeIXENmZsY2ziO9_pq3Xt6xVtLVa4xmb009dJxzaQo/edit#
[18:29] <netcurli> I like the idea of a notification
[18:29] <dbarth> cool, thanks
[18:29] <aquarius> no, no, no automatic notification
[18:30] <aquarius> or at least let me opt in to them
[18:30] <aquarius> the download manager doesn't know *what* it's downloading, so it can't meaningfully notify me
[18:30] <aquarius> I want the notification to say "Your latest podcast from the Ubuntu UK team is downloaded", not "file http://whatever/uupc.12.mp3 is downloaded"
[18:31] <aquarius> only the app can meaningfully notify.
[18:31] <netcurli> yea, ideally you could specify what the notification looks like
[18:31] <netcurli> or if there should be one
[18:31] <Elleo> aquarius: the app could give the download manager a message to display on completion
[18:31] <Elleo> then the app doesn't need to be woken up to notify if it's in the background
[18:31] <aquarius> true, I suppose, I just don't like handing off bits of my UI to other people to deal with ;)
[18:32] <aquarius> but yes, I could call downloadManager.downloadURL(url, my_id_for_it, message_to_display_on_complete) or similar
[18:32] <bfiller> tvoss_: multiple clients that want access to downloads in progress
[18:33] <bfiller> tvoss_: i.e. a download manager app
[18:33] <tvoss_> bfiller, but they can use getDownloadRequest with the id they would have to know anyway
[18:34] <aquarius> tvoss_, two different approaches. I can either set up the signal listener once on the DM and then have a big switch statement inside it, or I can attach a signal listener to every DownloadRequest when I get it
[18:34] <alex-abreu> bfiller, tvoss_ oSoMoN excet that atm there is no "model" (even w/ a restricted view) of the current downloads available
[18:34] <aquarius> tvoss_, the difference between them is really just personal preference, I think; I'm not sure one is necessarily better than the other
[18:34] <dbarth> i guess the *manager pattern is where actions are, and the request object is a more inert structure in that case
[18:34] <aquarius> I'd love to have current downloads and previous downloads available as a ListModel in QML :)
[18:35] <KaleoF> aquarius: can you summarise your  needs in the pad? :)
[18:35] <tvoss_> aquarius, might be my strict ood mind then
[18:35] <KaleoF> aquarius: +1
[18:35] <alex-abreu> aquarius, indeed
[18:35] <dbarth> passing the request object to the action functions may look better in that case
[18:35] <aquarius> KaleoF, I can, but my needs are not necessarily everyone else's needs ;)
[18:35] <oSoMoN> aquarius, in the initial API proposal, I’m stating that the DownloadManager object has a list model interface
[18:36] <aquarius> I have added my list to the pad :)
[18:36] <aquarius> oSoMoN, yaaay
[18:36] <aquarius> a magic DownloadManagerProgressBar component would be nice, but it's not critical
[18:37] <aquarius> and if you make a central one you have to care about letting me theme it for my app
[18:37] <Elleo> should the general public be able to view the pad? I just get errors telling me I'm not authorised to see it
[18:37] <aquarius> might be easier to just publish an *example* of one somewhere sensible
[18:37] <aquarius> rather than a real component in the SDK that you have to support.
[18:37] <aquarius> Elleo, I can see the pad...
[18:37] <KaleoF> good point
[18:38] <Elleo> aquarius: you're an ex-canonical employee though, you might have left over permissions?
[18:38] <aquarius> Elleo, I should hope not :) Can you see other pads?
[18:38] <netcurli> I can see the pad as well
[18:38] <Elleo> aquarius: nope, seems not
[18:39] <Elleo> perhaps there's something wrong with my account then; guess I'll just have to file a bug later
[18:39] <aquarius> Elleo, try bringing up the pad alone in its own window; it doesn't like it if you're not signed in right and you're in an iframe
[18:39] <aquarius> KaleoF, feel free to move around or delete my things; they are just my thoughts, not a list of work items ;)
[18:39] <aquarius> mandel_, KaleoF, I don't necessarily think we need a central indicator. If there isn't one, then I have to do all the stuff that it can do inside my app, but I can live with that for version 1 at least
[18:40] <Elleo> aquarius: same error
[18:40] <aquarius> Elleo, hrm, dunno then, soz
[18:40] <Elleo> no worries
[18:40] <bfiller> mandel_: you just need to requery the download service when you are brought back alive, check for the status of your download
[18:41] <aquarius> bfiller, perfect, that's what I want :) I get signalled if I'm alive to be signalled, but I can also check by hand if I want
[18:41] <bfiller> aquarius: right, should be pretty striaghtforward I think
[18:42] <ralsina_> android forgets downloads on restart at least
[18:43] <aquarius> KaleoF, yeah, other platforms don't provide a central download manager. Meego did, but it was weird and not all that good and required you to talk raw dbus to it ;)
[18:43] <aquarius> it's hard to check what other people are doing when you're better than they are ;)
[18:44] <aquarius> I have added a note to the pad about garbage collection
[18:44] <Elleo> mandel_: what about recoverable errors? i.e. a download is 40% complete, network drops out, do you still delete the file?
[18:45] <Elleo> mandel_: because surely in those circumstances it's better to provide the capacity to resume the file
[18:45] <netcurli> is there a way to delete files via qml?
[18:45] <aquarius> KaleoF, you probably do want *some* garbage collection just in case the app itself deletes one of the files that the download manager downloaded for it. the DM's record should be updated at some point, otherwise you try to open the file *from the download manager* and it's not there any more
[18:46] <aquarius> netcurli, nope. So the DM needs to provide a deleteThisFileThatIDownloadedForYou method :)
[18:47] <Elleo> mandel_: excellent, that's perfect
[18:47] <aquarius> From my perspective as an app dev, I want to say "download this URL!" and then later get told "it is downloaded!" and I don't have to care at all about whether there was network all the time or whatever; that's the benefit that the DownloadManager brings to me :)
[18:48] <aquarius> OK, I have to step out, gang. Thank you for listening to my thoughts!
[18:48] <Elleo> mandel_: can the download manager override an app's requests for downloading over 3g? e.g. is it possible for the user to set a global setting saying "Never download anything bigger than 10mb over 3G", regardless of what the app wants?
[18:48] <aquarius> happy to carry on discussing this another time
[18:49] <Elleo> mandel_: or have it refuse to do 3g downloads if roaming
[18:49] <cjwatson> Elleo: it's easier to see what the pad is complaining about if you start it in a new window; but it is restricted to certain teams in Launchpad due to widespread abuse at previous conferences, not just Canonical though (e.g. ubuntu-etherpad gets you it)
[18:50] <Elleo> cjwatson: ah, okay
[18:50] <cjwatson> Elleo: (we had people coming onto UDS pads and deliberately blanking their contents, pasting racist abuse, etc.)
[18:50] <cjwatson> it was all very unpleasant
[18:55] <Elleo> mandel_: I'd like to switch gpodder (podcast client) to using the download manager
[18:55] <netcurli> yes
[18:56] <netcurli> podcast client is a good use case
[18:59] <Elleo> mandel_: there's catchpodder and gpodder (I'm the guy working on gpodder for UT)
[18:59] <netcurli> I am the dev of catchpodder
[18:59] <netcurli> ;)
[18:59] <Elleo> perfect :)
[19:00] <mandel_> Elleo, netcurli you two are mine ;)
[19:00] <popey> \o/
[19:01] <popey> next session starting shortly
[19:01] <mandel_> Elleo, netcurli do you want to chat about this in a diff channel?
[19:01] <mandel_> Elleo, netcurli mainly get your use cases etc..
[19:02] <mandel_> Elleo, netcurli I'll be in #ubuntu-download-manager ;)
[19:02] <KaleoF> aquarius: I transferred your needs to the API gdoc
[19:02] <Elleo> mandel_: okay
[19:03] <popey> https://plus.google.com/hangouts/_/7ecpicj893vo9g6r5fivpihc28 for the next session hangout
[19:08] <micah2_> you are live
[19:10] <popey> http://pad.ubuntu.com/uds-1311-appdev-1311-reminders-app-planning
[19:12] <popey> https://blueprints.launchpad.net/ubuntu-phone-commons/+spec/reminders-app-development
[19:16] <micah2_> popey is not the main video stream
[19:17] <popey> https://code.launchpad.net/reminders-app
[19:20]  * karni launches reminders-app and sees the default "Hello... / Tap me!" QML template. I mean, is this code anything else than a qtc template?
[19:21] <karni> Rotton - do you perhaps have headphones?
[19:21] <popey> https://docs.google.com/a/canonical.com/file/d/0B9aUQbgVanPGeHhfU0NVTXh5QTg/edit
[19:21] <karni> *Rottin
[19:23] <karni> Ok. lp:reminders-app is just a qtc template. Which branch is something more? the trunk is owned by rottinrob?
[19:24] <karni> I mean, it's named "trunk" ;) Not that it is a trunk in lp terms.
[19:26] <jkeyes0> karni: I think dpm owns the trunk. I've rottinrob and I have branches out there that we've requested to merge in
[19:27] <jkeyes0> it's still REALLY early days, though. not much of anything to it yet. establishing UI layout for now, then once the API plugin is ready, we can get it talking to Evernote
[19:28] <karni> jkeyes0: I understand. Was just cought by surprize when I saw lp:reminders-app. Just had a look at Rob's work.
[19:37] <dholbach> https://bugs.launchpad.net/reminders-app
[19:38] <karni> Though I don't work on reminders, I agree with dholbach, file bugs++
[19:38]  * dholbach hugs karni
[19:38] <karni> ^-^
[19:39] <karni> Provide great status/overview, and easy to link with bzr commit --fixes lp:xxx
[19:39] <dholbach> popey, dpm mentioned something about a blog post... did you guys talk about that already?
[19:40] <popey> http://popey.com/~alan/phablet/gallery.php
[19:40] <karni> popey: wohooo \o/
[19:41] <dholbach> this is my first time talking to real-life core app developers - this is exciting! :-)
[19:42] <nik90> dholbach: :_-)
[19:43] <nik90> I meant :-)
[19:45] <karni> Jordan, you have a familiar face. I'm almost sure I know you from somewhere (Michał Karnicki here). Possible?
[19:46] <jkeyes0> karni: I make videos on YouTube pretty regularly
[19:47] <karni> jkeyes0: That's it!! :D I know you :D (not in person, though ;< hehehe)
[19:47] <karni> jkeyes0: I like your videos!
[19:47] <jkeyes0> Thanks!
[19:47] <popey> \o/
[19:47] <karni> Thank you all!
[19:48] <popey> thanks guys!
[19:49] <dholbach> my browser is acting up
[19:59] <dpm> jkeyes0, karni, the owner of lp:reminders-app is the reminders-app-dev team. The current code right now is essentially generic code to get the app bootstrapped. We need the first branches landing to make it more functional as soon as possible, so that people can start building upon it. In that regard, the merge proposal from Jordan is a step in that direction, which is quite cool
[20:01] <karni> dpm: Gotcha, great :)
[20:01] <karni> dpm: I just found the template in trunk confusing, thought maybe I'm not launching it properly ;D
[20:02] <dpm> karni, yeah, it's because we need the branches to land to trunk to make it functional
[20:02] <karni> dpm: Yes, that's usually the way it works =D
[20:03] <dpm> :)
[20:03] <karni> dpm: Catch you tomorrow!
[20:03] <dpm> karni, see you!