[14:02] <mhall119> hangout link to join: https://plus.google.com/hangouts/_/7acpjj0d3h4nsehsjvkqrs2h8o?authuser=1&hl=en
[14:03] <mhall119> will be a minute late, helping somebody with their schedule
[14:04] <mhall119> alright, going live now
[14:06] <mzanetti> mhall119: here nowe
[14:06] <mzanetti> -e
[14:13] <mhall119> any last minute questions?
[14:25] <Moshe> Yes
[14:29] <Moshe> Why David attends this http://summit.ubuntu.com/uds-1311/meeting/22079/appdev-1311-sdk-apps-performance/
[14:34] <Moshe> Bye
[14:34] <Moshe> see ya
[15:01] <bfiller> mhall119: should I setup the hangout for the next session?
[15:02] <mhall119> bfiller: if you're running it yes
[15:02] <bfiller> mhall119: ack
[15:08] <mhall119> hangout URL: https://plus.google.com/hangouts/_/7ecpji96dlvlrvqdueto0ho8u4?authuser=0&hl=en
[15:08] <dholbach> http://pad.ubuntu.com/uds-1311-appdev-1311-apps-convergence
[15:10] <oSoMoN> link to the hangout?
[15:11] <boiko> oSoMoN: hangout URL: https://plus.google.com/hangouts/_/7ecpji96dlvlrvqdueto0ho8u4?authuser=0&hl=en
[15:11] <oSoMoN> thx boiko
[15:15] <greyback> QUESTION: Is the "Tabs" design considered usable on the desktop?
[15:16] <iBelieve> greyback:I filed this bug, which got marked as wishlist: https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1193981
[15:16] <udsbotu> Launchpad bug 1193981 in Ubuntu UI Toolkit "Display tabs as traditional tabs on the desktop" [Wishlist,Confirmed]
[15:16] <asomething> greyback, I've thought it would be nice if tabs turned into columns if there was enough space (ie on the desktop)
[15:16] <greyback> iBelieve: yep, that's an option
[15:17] <greyback> asomething: that's a very responsive UI layout idea, and yes something we've been experimenting with
[15:18] <pmcgowan> bfiller, there was a commitment from the last sprint to get initial design feedback mid dec
[15:18] <iBelieve> asomething:the problem with that, at least in some apps, is that a specific tab might want to be full-width, and some apps might not want that type of layout. So if that type of layout is added, it should be optional
[15:19] <boiko> asomething: I'm not completelly sure turn tabs into columns is a good idea, usually tabs are used to separate different kinds of content/presentation/context, but maybe on a case-by-case evaluation that can be an option
[15:19] <greyback> QUESTION: desktop apps can take advantage of right-click - do we need a widget for a right-click menu?
[15:20] <iBelieve> greyback:I'd like to see long-press on a touch screen be turned into a right-click on the desktop
[15:20] <iBelieve> greyback:so then a popover component should be good enough
[15:20] <iBelieve> QUESTION: Will a settings page be displayed differently on the desktop, such as in a separate dialog, versus in a tab on tablet/phone?
[15:21] <greyback> iBelieve: tbh I'm not a fan of long press at all. It's quite easy to do accidentally
[15:22] <pmcgowan> we won't have "two sdks", but we will keep it simple for 14.04
[15:22] <bfiller> http://developer.ubuntu.com/api/qml/sdk-1.0/Ubuntu.Layouts/
[15:24] <pmcgowan> there is a devices API, need to check it
[15:24] <greyback> nope, nothing in qtubuntu for that
[15:24] <pmcgowan> there is in qt if I recall right
[15:25] <mhall119> greyback: can you join the hangout?
[15:26] <greyback> mhall119: if you'd like. I've not much to say
[15:26] <mhall119> greyback: you have questions :)
[15:26] <mhall119> iBelieve: you too if you can join
[15:26] <mhall119> https://plus.google.com/hangouts/_/7ecpji96dlvlrvqdueto0ho8u4?authuser=0&hl=en
[15:26] <iBelieve> mhall119:I wish, but I'm not 18 yet, so Google won't let me :(
[15:26] <mhall119> ah, that limit sucks
[15:27] <iBelieve> yeah, it is disappointing
[15:30] <asomething> These should be landing along with Qt 5.2 in trusty http://blog.qt.digia.com/blog/2012/06/06/desktop-components-for-qt-5/
[15:32] <iBelieve> mhall119:I meant an app's own preferences/settings
[15:34] <michelR> in previous vUDS? Katie said that settings will be unified via HUD
[15:36] <iBelieve> when I referred to displaying in a separate window, I was referring to the SDK somehow opening it in a separate window on the desktop. The developer wouldn't be able to open windows.
[15:37] <iBelieve> No desktop app that I know of replaces the app's content view with settings or puts the settings in a tab, so the current way of having everything from an app in one window doesn't make sense on the desktop.
[15:39] <iBelieve> bfiller:an example of an app that doesn't scale well when being resized is the calendar app. It looks really bad when maximized.
[15:40] <boiko> desktop Qt apps are given the chance to limit their sizes if they want to, maybe that's something we can include in the mainview or layout API?
[15:41] <mhall119> iBelieve: if we're going to provide a unified way or defining and displaying settings, we can offer something like a modal dialog on desktop yes
[15:42] <karni> Was a bit in an out. Were pickers and toolbars mentioned? How would they change when a tablet switches to 'desktop' mode with keyboard and mose, or how common bits on the phone & desktop?
[15:44] <iBelieve> QUESTION: Will multi-touch mice/touchpads, like on Macs, be supported? For example, if there is a mouse, but it is multi-touch, then scrollbars would be hidden as on touch.
[15:47] <mhall119> karni: toolbars were, pickers not yet
[15:47] <mhall119> switching from touch to mouse input has also been discussed
[15:48] <iBelieve> mhall119:I heard/saw that, but I don't think anything about multi-touch mouse input was discussed.
[15:51] <mhall119> iBelieve: right, I was answering karni
[15:51] <karni> mhall119: I'll review that, thanks
[15:51] <iBelieve> mhall119:oh, sorry
[16:03] <karni> Thanks all
[16:07] <bfiller> http://pad.ubuntu.com/uds-1311-appdev-1311-apps-systemapps-roadmap
[16:10] <tedg> bfiller, Any plans to increase HUD usage in the core apps?
[16:13] <tedg> bfiller, Cool, thanks!
[16:27] <tedg> bfiller, I thought syncevolution just needed to be setup?  Why can't that land?
[16:32] <tedg> bfiller, My understanding is that it's build for that use-case.  So it's more a matter of setting up a refresh.
[16:32] <tedg> bfiller, I believe that kenvandine knows more about it.
[16:32] <tedg> He likes work items :-)
[16:32] <kenvandine> tedg, not really, ideally we really need UOA support
[16:32] <kenvandine> and a mechanism to make it refresh
[16:32] <tedg> kenvandine, I thought that UOA support was in progress?
[16:33] <kenvandine> not sure what the latest is
[16:33] <kenvandine> tedg, i know upstream is receptive to it
[16:33] <tedg> K
[16:33] <tedg> The Upstart guys are talking about trying to get the time bridge working this cycle.
[16:34] <tedg> So that'd provide the refresh mechanism
[16:36] <tedg> Thanks bfiller, great update!
[16:36] <karni> Thank you bfiller!
[16:37] <bfiller> you're welcome :)
[18:07] <Kaleo> hi
[18:08] <pmcgowan> mhall119, this your HO?
[18:08] <mhall119> pmcgowan: kind of
[18:08] <pmcgowan> I mean setting it up
[18:09] <Kaleo> https://plus.google.com/hangouts/_/72cpjq6gpjgk9fene1cuscahkk?authuser=1&hl=en
[18:09] <mhall119> pmcgowan: I've setup the hanout, going live now
[18:09] <mhall119> it's Kaleo's topic though
[18:09] <pmcgowan> understood
[18:11] <Kaleo> mzanetti, you want to join?
[18:11] <Kaleo> kenvandine, ? :)
[18:12] <dobey> pmcgowan: yeah i think the fan noise is you
[18:12] <kenvandine> Kaleo, i'm in another session
[18:12] <Kaleo> :)
[18:12] <kenvandine> Kaleo, but if you need me, ping me :)
[18:12] <pmcgowan> dobey, yeah
[18:13] <aquarius> consider my +1 for jsonlistmodel.... or +100 :)
[18:13] <kenvandine> +10 for me :)
[18:13] <aquarius> given that, and some way to do authentication, working with remote APIs is trivial
[18:14] <aquarius> it's reasonably easy now, if you implement stuff yourself with XHR, but it'd be nice if that was wrapped up in something.
[18:14] <Kaleo> aquarius, nice
[18:14] <Kaleo> aquarius, join us!
[18:14] <dobey> heh. i have thought a lot about this problem, but never got around to writing the stuff i wanted to write, to do this. and then the current online-accounts stuff got written and i had nothing to do with it
[18:15] <aquarius> the biggest problem here isn't JSONListModel, really, it's authentication. JSONListModel isn't that hard to implement yourself, but it is hard to implement generically so that you can do arbitrary authentication methods (oauth, basic auth, add api key to every request, flickrauth, etc)
[18:15] <aquarius> pmcgowan, I think that that abstraction layer you're talking about *is* JSONListModel
[18:15] <aquarius> I'm not sure anything more complex is required
[18:16] <mzanetti> yeah. the problem is that you need queries
[18:16] <aquarius> Kaleo, I'm trying to cook dinner at the same time, henc not joinnig ;)
[18:16] <aquarius> mzanetti, xmllistmodel handles that well with query and role; jsonlistmodel can do a similar thing, using JSON Pointer.
[18:16] <Kaleo> ok
[18:16] <aquarius> this is what JSON Pointer is *for* :)
[18:16] <dobey> aquarius: you need google glass apparently
[18:16] <aquarius> http://tools.ietf.org/html/rfc6901
[18:16] <dobey> aquarius: then we can watch you cook, and listen to you rant, at the same time
[18:17] <aquarius> jsonpointer RFC
[18:17] <dobey> mhall119: why do we even have online-accounts then? :)
[18:19] <aquarius> mhall119, almost nobody uses basic auth for API access.
[18:19] <dobey> having written a non-standard online-accounts plug-in, i wouldn't recommend other people do it
[18:19] <aquarius> mhall119, it's either api key based, or oauth. Neither are a username/password combinaion.
[18:19] <pmcgowan> I mispoke when I said basic
[18:19] <dobey> it would be nice if it didn't require adding the metadata to use basic auth or oauth though
[18:20] <dobey> you'd be surprised how many services use basic auth
[18:21] <aquarius> I think you guys are confusing two things to do with API auth here: there is "how do I get the credentials" (which is clearly Online Accounts's job) and then "once I have the credentials, how do I use them to make a request for the API endpoint" (which is not necessarily Online Accounts at all; it is oauth signing, or flickr auth signing, or getting a frob, or whatever)
[18:21] <dobey> there are thousands of sites that use basic auth
[18:21] <dobey> aquarius just isn't interested in them because they're not web 10.0
[18:21] <aquarius> dobey, for json-based APIs? I think I'd disagree, but OK -- my point is really that there are many different auth methods
[18:21] <dobey> aquarius: they aren't necessarily using JSON, no. but they exist
[18:22] <aquarius> It's not at all clear to me that "make a request to the endpoint and use the credentials" belongs in Online Accounts at all; that sounds like something my app should do
[18:22] <dobey> mhall119: i mean it would be nice if for standard auth models (basic, pure oauth, etc… ) that one didn't need to provide the service/provider info for online-accounts
[18:22] <dobey> just have an API to say "here is my endpoint, or the realm i need to use" "set it up"
[18:23] <mzanetti> so I guess OnlineAccounts would need to be capable of signing oauth parameters and/or building those queries - depending on which oauth method is used
[18:25] <dobey> aquarius: i think they do belong there. every app that wants to show an image from flickr shouldn't have to duplicate code to talk to flickr
[18:25] <aquarius> dobey, right, but I can't think what a generic API would look like that Online Accounts can provide to apps
[18:25] <pmcgowan> do we need any additional level of abstraction like a DataSource ?
[18:25] <Kaleo> http://techbase.kde.org/Development/Tutorials/Plasma/DataEngines
[18:26] <dobey> aquarius: i sort of can, but i never got around to actually writing it (as i said earlier) :)
[18:26] <mzanetti> Kaleo: that's probably not what we want
[18:26] <Kaleo> http://developer.blackberry.com/native/reference/cascades/bb__data__datasource.html
[18:26] <aquarius> OnlineAccounts.Account.requestThisApiUrlUsingWhateverAuthMethodYouNeedToUse("http://service.com/api/method?whatever"), I suppose/
[18:26] <dobey> aquarius: i mean, we're already doing some of this anyway, in unity. the scopes api does exactly that (though in most cases currently unauthenticated)
[18:26] <Kaleo> http://developer.blackberry.com/native/documentation/cascades/device_platform/data_access/using_data_source.html
[18:27] <aquarius> dobey, right, but the scopes API is very constrained: it provides getAListOfSearchResults and getDataForThisOneSearchResult, and then the rest is scope-specific
[18:27] <aquarius> dobey, apps want to do things other than those :)
[18:27] <dobey> aquarius: right. i'm just saying it's a start, not the end solution
[18:27] <aquarius> like, say, upgrade my account by paying £5 or something. It's hard to see how to map that onto a generic API
[18:28] <dobey> aquarius: for basic things like searching inside the gallery app, for photos on flickr, it'd work great
[18:28] <mzanetti> aquarius: yeah... that's what I think too
[18:28] <aquarius> Kaleo, all the datasource stuff I know about doesn't handle authentication very well :(
[18:28] <dobey> aquarius: it doesn't need to be a totally generic api though
[18:28] <dobey> aquarius: it needs to be generic for doing generic things, and provide a way to do specific things when needed
[18:30] <aquarius> This conversation is, I think, too handwavy. Kaleo, mhall119, I think a useful approach might be to define four or five things that would be good to talk to, and then define what the API would look like that would allow talking to them. So a couple of the things that dobey mentioned which have basic auth, and then Flickr, Yummly.com, and Paypal, for example
[18:33] <aquarius> mhall119, there is potential commonality here with the generic json scope, no? Both need a semi-generic way to define a JSON endpoint, queries into it to get data, and auth...
[18:33] <mhall119> aquarius: to a point yes, but I think apps will need more than scopes
[18:33] <aquarius> I can rough out a few different APIs if you want me to, mhall119
[18:34] <aquarius> happy to do, say, simple flickr, yummly, and something that dobey comes up with?
[18:34] <aquarius> but it will look a lot like What Stuart Wants The API To Look Like
[18:34] <Kaleo> What Stuart Wants The API To Look Like is usually good
[18:35] <aquarius> bilf: there are about fifteen different half-baked implementations of JSONListModel ;)
[18:35] <aquarius> er, bfiller ;)
[18:35] <mzanetti> yeah... exacly bfiller... You never know what you get. in the end you have tree of json objects but you don't know what to do with it
[18:36] <dobey> JSON, XML, or csv are the most common way to get data
[18:36] <aquarius> bfiller, do you have a few good examples of that sort of XML data?
[18:36] <aquarius> something that's not easily parseable with xmllistmodel but *is* regular enough that it could be parsed with a theoretical BillFillerXMLListModel? (i.e., not totally irregular)
[18:37] <pmcgowan> the rss reader also did a lot with this
[18:37] <pmcgowan> xml data
[18:39] <aquarius> bfiller, being unable to parse multi-model XML into a ListModel isn't really an XML parsing problem... it's a function of ListModel itself. The rule for a ListModel is that all the items in the model have to have the same keys -- you are not supposed to have one ListModel which contains both airlines and hotels :)
[18:39] <pmcgowan> sounds like the problem is very data/site specific
[18:39] <aquarius> bfiller, that's not an XML problem -- you can't have one ListModel with both airlines and hotels in it even if you populate it yourself
[18:41] <aquarius> you can get to the parent node, indeed
[18:42] <Kaleo> http://qt-project.org/wiki/Qt_and_Web_Services
[18:43] <aquarius> you'd end up with your ListElements being { type: airline, details: { an airline-specific dict of stuff }}, { type: hotel, details: { an hotel-specific dict of stuff }}
[18:43] <aquarius> bfiller, yeah, I've been going on about auth and controlling the request from XMLListModel for the whole session, don't worrk ;)
[18:43] <aquarius> *worry :)
[18:43] <bfiller> aquarius: haha, good :)
[18:45] <aquarius> No way to create an XML/JSON doc from input data simply in QML, other than by hand ( mydoc = {name: qmlinputfield.text, address: qmlinputfield2.text}, etc)
[18:46] <aquarius> Kaleo, yeah, I just noticed that that work item is totally fixed by your link ;)
[18:46] <Kaleo> :)
[18:46] <Kaleo> aquarius, write a beautiful Stuart API TM
[18:46] <Kaleo> aquarius, that's the next work item for you
[18:46]  * aquarius updates the notes to point at Kaleo's link ;)
[18:48] <mzanetti> yeah... I guess I can look into it if kgunn is fine with it
[18:49] <Kaleo> lol
[18:49]  * aquarius laughs
[18:49] <aquarius> stop trying to just trying to assign stuff to me :)
[18:49] <bfiller> aquarius: good example of problem I was talking about: http://qt-project.org/forums/viewthread/3685
[18:50] <aquarius> bfiller, right. That dude there wants a ListModel which contains both Channel and Program items
[18:50] <aquarius> that's not allowed. ListModels don't work like that.
[18:50] <aquarius> It would be nice if they did, but they don't ;)
[18:51] <bfiller> aquarius: I want the same thing :)
[18:51] <aquarius> I see what you mean about the parent node thnig, though
[18:52] <kyleN> I'll be glad to write something up with a bit of guidance to start with from the technical experts
[18:52] <mzanetti> o/
[18:52] <pmcgowan> kyleN, thanks
[18:53] <bfiller> aquarius: your ListElement example above though is exactly what I want but from XmlListModel. Looks like it's easy with Json to do it
[19:10] <aquarius> bfiller, yeah... ideally you'd do this: http://pastebin.ubuntu.com/6454817/ but it doesn't work, which must be an XmlListModel limitation where it won't ascend to the parent :(
[19:12] <aquarius> bfiller_afk, mzanetti ^