ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

It's been a little while since we talked about this, and while I think some may
have bits and pieces of the information, I wanted to get everyone on the same
page. Mostly, this is captured in the bp[0]. Please note, I'm reporting
highlights for various individuals/teams.

What's done:
 * oxide builds[1] an i386, amd64 and armhf
 * oxide packaging is completed and in PPA[2]
 * oxide verified to work on desktop and touch, with limitations (see below)
 * oxide build now uses cmake instead of qmake, drastically reducing -j4 cross
   compilation time (ie, ~70 minutes as opposed to 12 hours for local builds)
 * navigation API is completed
 * oxide supports accelerate compositing
 * many oxide refreshes from chromium content API pulls. Most were nearly
   painless with at least one requiring more effort due to upstream moving
   headers around. This clearly demonstrates we made the right choice using
   Oxide wrt future maintenance
 * webbrowser-app updated to use oxide (preliminary, via branches)
 * webapp-container updated to use oxide (preliminary, via branches)

What's in progress:
 * investigating how to deal with lack of Qt 5.2 in the archive
 * implement input methods for oxide on touch (in branch, but needs work)
 * apparmor policy updates for using oxide in webapp-container and UbuntuWebView
 * CI team enabling oxide CI

What's up next (not comprehensive):
 * benchmarks comparing QtWebKit and Oxide on armhf
 * implement/fix various bugs to make webbrowser-app (and webapp-container)
   usable when using oxide[3]
 * upload to Ubuntu
 * update UbuntuWebView to use Oxide
 * update cordova to use Oxide

There is still a lot to do, but I believe we are in good shape. We were slowed
down quite a bit by needing to use PPA builds which have a 12 hour turnaround
for armhf, but this is now solved with the recent cmake cross-building updates.
Various snags with armhf builds related to assumptions in the build regarding
presuming ARM builds are android with nion, etc also slowed us down last month,
but these are all worked out for past few weeks. armhf benchmarks were first
blocked on working armhf builds but are now blocked implementing the input
methods for touch, which requires Qt 5.2 (other bug fixes require 5.s as well).
5.2 landing is blocked on the frameworks discussions being resolved enough for a
5.2 upload, so we don't think we will have oxide in the archive for at least a
couple weeks at the earliest. We are hoping we can use the qt5-edgers PPA[4] to
at least unblock the work itself even if the landing is blocked until 5.2 hits
the archive.

Oxide is definitely in a state where people can hack on it[1][5] (though the
wiki hasn't been updated on how to use cmake yet-- Chris is adding that soon).
It would be great to have phonedations/platform API start looking at integrating
oxide[6] and if needed, helping with the 5.2 builds so we can keep moving
forward (and ideally getting familiar with the arm specific de-android patches
so we can share the load for keeping oxide working on Ubuntu). Once the input
method implementation is merged and we can do benchmarks, it's conceivable we'll
need some help from phonedations resolving issues there.

[0]https://launchpad.net/ubuntu/+spec/client-1308-oxide
[1]https://wiki.ubuntu.com/Oxide/BuildInstructions
[2]https://launchpad.net/~phablet-team/+archive/ppa/+packages
[3]https://bugs.launchpad.net/webbrowser-app/?field.tag=oxide
[4]https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-beta2
[5]https://wiki.ubuntu.com/Oxide/BzrWorkflow
[6]https://bugs.launchpad.net/oxide/+bug/1249387

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature