=== t1mp_ is now known as t1mp === udsbotu changed the topic of #ubuntu-uds-appdev-2 to: Track: App Development | The photo gallery application | Url: http://summit.ubuntu.com/uds-1303/meeting/21619/appdev-1303-apps-galle [15:01] I'm here! :) [15:09] are the photos purely local? [15:10] is there any design for pulling them from an online service? [15:11] there's an u1 api for photos now :) [15:11] 'k [15:20] read only support for these gallery would be nice, or atleast plugin arch for these [15:20] soryy, joined late [15:20] also the camera and other photo apps use different folders [15:21] emblems ? [15:21] as nautilus does [15:32] the streaming seems stopped [15:32] or is it just for me? [15:32] oh? [15:33] hangout still running [15:33] "1 viewer" [15:33] popey: here I cannot access the youtube streaming anymore [15:33] yeah, same here on my second machine [15:33] boom ended [15:34] yikes hangout died [15:34] it is back [15:34] phew === emily is now known as Guest9073 [15:38] not that I know of [15:38] manual publishing [15:38] never seen u1 there [15:39] picasa, fickr, and other services [15:39] uds-appdev-2: 5 minutes left in this session! [15:39] auto-sync would be nice, but read-only support be a awesome start [15:40] cache auto clean , for online albums [15:40] uds-appdev-2: 4 minutes left in this session! [15:40] ritz: makes sense [15:41] uds-appdev-2: 3 minutes left in this session! [15:42] uds-appdev-2: 2 minutes left in this session! [15:45] uds-appdev-2: This session has ended. === udsbotu changed the topic of #ubuntu-uds-appdev-2 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1303/appdev-2/ - http://ubottu.com/uds-logs/%23ubuntu-uds-appdev-2.log [16:07] hi [16:56] everyone: plenaries are now on ubuntuonair.com [17:05] ok === FunnyLookinHat_ is now known as FunnyLookinHat === udsbotu changed the topic of #ubuntu-uds-appdev-2 to: Track: App Development | Web Browser Application for touch devices | Url: http://summit.ubuntu.com/uds-1303/meeting/21621/appdev-1303-apps-webbrowser/ [18:19] Hi guys [18:19] extra thoughts that aren't on the agenda which I don't know about: playing media from HTML, Flash rendering, command line options, developer tools, user agent string, getting people to care about our browser and how that'll happen, asking ppk to work with it [18:20] benchmarks: sunspider, [18:20] yeaaaa [18:20] firefox's http://arewefastyet.com/ shows many performance tests that they do [18:20] I think chromium project has release-tests they use that we can compare against. [18:21] the acid test isn't about performance, it's about rendering accuracy, but yeah [18:22] I don't want to derail the meeting if you guys have a plan [18:22] sil-unwell: http://summit.ubuntu.com/uds-1303/meeting/21621/appdev-1303-apps-webbrowser/ [18:22] sil-unwell, :) [18:22] so no-one is expected to use this browser on their desktop, say? [18:22] there's an etherpad with the agenda at the bottom [18:23] popey: ya, I am reading the etherpad :) [18:23] ok, cool [18:24] android does the same with youtube or html videos [18:24] android does that too [18:24] right: maybe that's what we want to do (play video in a separate app) but someone needs to think about that, and write it ;-) [18:24] yeah [18:24] html5 video, I mean [18:24] it makes sense for bypassing compositor as well :) [18:24] I think syncing one of the most important things [18:26] sil-unwell: no doubt [18:26] why not join #qtwebkit [18:26] I have some Qt/Webkit experience [18:26] I did large parts of the interaction part of qtwebkit [18:27] as well as the N9 browser [18:27] awesome [18:27] i've tried building an native application with it and it was pretty bad, it definatly has bugs that are not in gtk webkit. But i think it should be fixable. [18:27] olafura: I agree with you on that [18:28] gtk uses webcore for all drawing [18:28] ie. no pinch zooming etc [18:28] Hi, I'm ready to work on QtWebKit for ubuntu [18:28] phone [18:28] also an issue with handling some certificate types [18:29] yeah we fixed most of these issues for the N9 browser [18:29] but not all got upstreamed [18:30] memory doesnt grow linear with number of tabs [18:30] there are a lot of static allocated memory and lots of caches which are shared etc [18:31] it makes no sense optimizing per size.. everyone are already doing that, ie. google and apple and optimizing a lot [18:32] I think you should only keep current tab in memory and storing session information so you can open it back as it was without the memory penality [18:32] better to optimize the graphics system [18:32] a lot is configurable already, like page cache size etc [18:32] They do, at least partially, rewrite the HTML [18:33] they'll do things like add title attributes, or inject JS which rewrites the HTML for you. [18:33] why does this matter? We're not going to proxy everything, right? [18:33] I wouldn't touch resizing images with a ten foot pole, there is too much variability with javascript resizing and stuff like that [18:33] willcooke: http://stuartroebuck.blogspot.co.uk/2010/07/mobile-proxy-cache-content-modification.html [18:33] these proxies are often transparent [18:33] sil-unwell: *we* might not, but if you're using a mobile network *you* might not get a choice [18:34] willcooke: sure thing, but this isn't anything that our browser can do anything about, right? [18:34] erm, well [18:34] if we know to expect it we can be smarter than the average bear [18:34] if websites are stupid about how they display images it's their fault [18:34] we can't undo it. The operators do it for a reason; if we reverse it they'll be super cross ;) [18:34] oSoMoN: just joined, did you guys talk about user agent ? [18:34] nerochiaro: not yet [18:35] I have two things that I think might be related to "must-have features" [18:35] both could be considered implementation details [18:36] 1. we should standardize on a particular renderer and that renderer should be what we are using in our SDK [18:36] Surely you want the history to open in a new tab! [18:36] so probably tabs should come first [18:37] I can help with (Qt)WebKit :) [18:37] adding tabs and history should be quite easy [18:37] ie, webkit makes sense to me. I have a session tomorrow on how to maintain this, but the idea is that our browser and our SDK use the same rendering code, it reduces maintenance costs [18:37] jdstrand: I think we're OK for #1 - we're using the QtWebKit from the SDK [18:37] bfiller__: oSoMoN: are we targeting only mobile sites or also normal sites ? in the latter case, what happens with popups ? [18:37] Why not port chromium? [18:37] Most of the ui is html [18:37] willcooke: ok, I thought I heard that may still be up in the air at the beginning of the talk [18:37] hah good luck :-) [18:38] * qengho hides. [18:38] you need to get the graphis to work with acceleration, and it canot use the platform stuff as it does all it self [18:38] 2. consider using seccomp2 (ala chromium) for code that is processing untrusted content [18:38] also the android port isnt upstreamed [18:38] - cleaning history and cookies in the past minutes, days, etc. [18:38] bfiller__: well, it can *use* cookies OK. How do you clear cookies, for example? [18:38] also: - private browsing [18:38] jdstrand: there is a seccomp sandbox for webkit2 contributed by my coworking (it is in bugzilla) [18:39] kenne: excellent. let's look hard at using it-- it greatly helps the security stance [18:39] jdstrand: just talk to tmpsantos on freenode when he is online [18:40] ok webkit1 is bad, webkit2 is like 1000x better [18:40] with performance for pinching etc [18:40] you just cannot do these things properly with webkit1 without inventing soething like webkit2 [18:40] kenne, +1 ... [18:40] it makes no sense investing in webkit1/qt [18:41] willcooke: there is a big distinction between "the browser can receive cookies and hand them back" (which is built in) and "there is UI for them so you can do things like clear cookies to log into a site" (which is *not* built in) [18:41] jdstrand: https://docs.google.com/document/d/1Fe2ZSEazdqzxBWHDjGF8WuYwsI6-C95Ljmn-QiMyl94/edit?usp=sharing [18:41] oSoMoN: don't really agree with what you just said re history and bookmarks [18:41] oSoMoN: bookmarks serve a different purpose [18:41] sil-unwell: noted [18:42] on bookmarks: we need to think, HARD, about how bookmarks and installable webapps fit together. If I "bookmark a site", am I bookmarking it to my home screen? If I'm bookmarking it to my home screen, isn't that the same as installing it as a web app? Where's the dividing line? [18:42] kenne: ah, excellent :) [18:42] sil-unwell: IMHO, bookmarking != "installing" a webapp [18:42] U1DB QML bindings: not quite usable yet but it's reasonably close. You could start working with it now. [18:42] willcooke: you and I disagree there ;) [18:42] alex-abreu: are you guys using Qt5 and qtwebkitwidgets today? or Qt4 ? [18:42] I think Chromium is way too heavy for this [18:43] sil-unwell: :) [18:43] kenne, qt5 [18:43] btw #qtwebkit is the channel where the qt guys hang out [18:43] codealot, yes [18:43] (sorry, was sending questions to appdev-1 instead of appdev-2) [18:43] sil-unwell: also, some web sites just don't work well at all on mobiles; so tab/cookies/etc sync needs to be very carefully thought about [18:43] alex-abreu: but are you using webkit2 or webkit1? [18:43] 19:29 < lool> dbarth: did you bring up remote apps? [18:43] 19:32 < lool> QUESTION: would it be possible to support the remote apps use case (thinclient) with API similar to webapps? e.g. to integrate apps in the launcher [18:43] kenne, wk2 [18:43] then I dont understand why the pinch and panning is bad [18:44] I had this running on very low end phones and smoothly 60fps [18:44] dbarth would like to integrate remote apps (apps launched from an app server) in the launcher; I was wondering whether this would link in any way to webapps APIs [18:44] kenne, depends on the backing store implementation right? e.g. w/ accelerated compositing etc. [18:45] kenne, and what's backing it [18:45] codealot Chromium should not be any heavier then QtWebkit plus all the application code required to reimplement years of browser work [18:45] tiled backing store [18:45] also, would this mean moving away from firefox as the default on real computers? [18:45] alex-abreu: webkit2/qt always uses the tiled backing store and shares the tiles across process boundaries [18:45] olafura: I do agree with you [18:46] alex-abreu: there is not really any way to avoid accelerated compositing and tiled backing store (nor does it make sense) [18:46] kenne, yeah, but the final composition ... [18:46] yeah the final composition happens in the ui process (coordinated graphics) [18:46] but is latest chromium based on webkit2? [18:46] kenne, ok. ... might be something in the layers between touch detection -> dispatch to browser [18:46] which you might be compositing as well [18:46] kenne, yeah [18:46] no chromium is not at all based on WebKit 2 [18:47] chromium uses something similar (content_layer) [18:47] codealot, no it's webkit1, and they have their own message based splitting of renderers [18:47] may be content shell or CEF [18:47] the pages dont show when fully loaded [18:47] the pages are shown when the initial layout is complete [18:47] Chromium Embedded Framework [18:48] you can probably trigger it to do more iterative layouts which actually makes the loading slower [18:48] but it may show things earlier [18:48] kenne, yeah [18:48] right. This is sacrificing actual speed for perceived speed; force a layout before everything's downloaded, and then reflow later. [18:48] I wonder if rendering is done in tiles (as usually done on mobile devices) [18:48] it shouldnt really be slow, but I have noticed it as well [18:49] it might be issues with networking as well [18:49] everyone else has already addressed this problem (in a variety of positions on the perceived-vs-real-speed spectrum) so it'd be worth looking at everyone else to see how they did it :) [18:50] sil-unwell, indeed [18:50] sil-unwell: but you dont want to layout before it is ready either because you end up with the layout changing and confusing the user [18:50] i wouldn't try to be too aggressive on the perceived loading speed. it's very easy to go overboard and make stuff look horrible and get fits of flickering and such as stuff moves around after things get loaded [18:51] dobey: exactly [18:51] kenne: totally agreed. This is what I meant about how every other browser has chosen their personal compromise around don't-reflow-too-much vs put-stuff-on-the-screen-asap [18:51] and it doesn't help that web developers also do a bunch of crazy things to try and work around things in various browsers, to make their own pages look like they load faster [18:51] which QPA plugin been used in ubuntu phone? [18:52] qtwebkit is using the default setting now, so it should be fine, the different is that it is not showing a white screen between the first load and initial layout [18:52] XCB/XLIB/EGLFS?? [18:52] Arun__: I think it uses a QPA that talks to SurfaceFlinger [18:52] Arun__: at least for now [18:53] Arun__, I am think canonical implemented a new based on SurfaceFlingler [18:53] Arun__: we've written our own, qtubuntu [18:53] unless qpa plugin uses hardware path it will be slow [18:53] Arun__: it's the qpa plugin that talks to surface flinger via ubuntu-platform-api [18:53] Arun__: lp:qtubuntu [18:53] i'd stick to the default for the reflow/layout stuff. if it's going to slow on actual phone hardware that we're targeting, then there's likely some misuse of hardware causing problems somewhere, or there's a bug in webkit [18:53] I'd think it's IO-bound, and we have cycles to burn between chunks. [18:54] willcooke: but similarly, completely ignoring the webapps stuff, if I open the grooveshark html5 app in my phone browser, and then I switch to another app on my phone, the music had better not stop playing or it's useless. [18:54] QUESTION: which is the mailing list for this? [18:55] sil-unwell, yes [18:55] sil-unwell: that's a multi-tasking problem, not a webapps problem [18:55] :) [18:55] bfiller: surface flinger is similar like x11/wayland windowing server?? [18:55] willcooke, in the end it's going to be a webapps problem :) [18:55] willcooke: absolutely, yes. The webapps stuff just exhibits the problem in even more detail :) [18:55] sil-unwell, totally [18:55] I would stick with the iphone one until last minutes [18:55] * willcooke puts his head back in the sand [18:55] Arun__: in some ways similar [18:55] that way you get the mobile sites and can actually fix things [18:56] QUESTION: is there a way for the browser to be used by native touch apps that need to open a browser to login to some service, and then want control back? [18:56] that is how we did the N9 browser [18:56] the user agent was changed last minute [18:56] alecu`: yes, good question. [18:56] bfiller__ How about using Chromium as the base instead of QtWebkit? [18:57] to enlarge alecu`s question, what will the browser do if it gets an x-my-new-scheme://blah URL? [18:57] kenne, are you the Kenneth working for Intel (ex-nokia) ? [18:57] alex-abreu: indeed [18:57] kenne, cool [18:57] QUESTION: getting people to care about our browser and how that'll happen. [18:57] what about plugins? [18:57] sorry time is almost up and I was slightly away: just my five cents. I thing we go with qtwebkit. Its pretty easy to change be the webkit wrapper into use webkit2 [18:57] and the proceed from there [18:57] ok, we'll use webkit then, thanks! [18:57] NPAPI? [18:58] Arun__, :( [18:58] alex-abreu: im often online during the day, so if you have questions, feel free to ask me [18:58] kenne, yeah I saw quite a few of your presentation, will most likely come to you [18:58] custom-uri scheme is there [18:59] custom uri scheme is a W3C standard [18:59] tel:##### URL scheme? [18:59] not only new http schemas, but something similar to android's intents, where a portion of the url is used to select the app. For instance, open urls that start with http://youtube.com in a media player instead of the browser [18:59] fugue88: does that already exist as a standard? [18:59] willcooke: I believe so, I'll look around for it. [18:59] thanks fugue88 [19:00] the hard part is finding out what is a phone number and it varies from country to country and slows down layout :-) and has all kinds of bad side effects [19:00] RFC 3966. [19:00] thanks all! [19:00] thanks all [19:00] :) [19:00] cheers [19:00] good session === udsbotu changed the topic of #ubuntu-uds-appdev-2 to: Track: App Development | Ubuntu SDK Tools | Url: http://summit.ubuntu.com/uds-1303/meeting/21625/appdev-1303-ubuntu-sdk-tools/ [19:00] hey kenne, so you’re a qtwebkit developer? [19:01] kenne, and EFL2 binding guy from what I recall [19:01] what is the mailing list for ubuntu browser development? [19:01] ah, awesome, I see we have a list of people who can help, that’s gonna be very handy [19:01] oSoMoN, yes, that and the webkit port for Tizen [19:02] sorry this is my real nick :) [19:02] willcooke: RFC 3966, in case you didn't see my response. [19:02] Cheers! [19:02] fugue88: awesome!! Thanks [19:02] oSoMoN, can we create a ml ? [19:03] oSoMoN, alex-abreu : I can take a work item to sort out a mailing list [19:03] alex-abreu, I wouldnt call the EFL port a binding, though the EFL API is not mostly self contained on top of a generic webkit2 C port [19:03] willcooke: excellent, thanks [19:04] kenneth_: awesome, I’ve been hanging around on #qtwebkit lately, I’ll ping you later this week (gotta leave for dinner now) === netcurli_ is now known as netcurli [19:04] oSoMoN: I'm probably late, but I suggest to raise the priority of the webdriver. [19:05] oSoMoN, ok, feel free [19:05] elopio, oSoMoN yeah, testing is moahor there [19:05] major [19:05] if you don't start building with that kind of testability in mind, it's going to be a pain. [19:05] alex-abreu: great. [19:05] can we leverage Selenium? [19:06] also, we have some extensive selenium suites that run on firefox. [19:06] if we can run them on the phone too without changing anything, that's a great acceptance test for the phone browser. [19:06] we already have automated tests for the chrome running with autopilot, would it make sense to integrate webdriver in there? [19:06] alex-abreu, what are you testing? like if you are just testing qtwebkit, you could contrtibute additional tests upstream (web engine regression tests, api unit tests etc) [19:06] the stream is on! [19:07] QUESTION: web intents? [19:07] zyga-uds, dead spec [19:08] Could