Analytics

Friday, April 29, 2011

Collection of WebKit ports

WebKit is a very successfull project. It is that in many ways. The code produced seems to very fast, the code is nice to work on, the people are great, the partys involved collaborate with each other in the interest of the project. The project is also very successfull in the mobile/smartphone space. All the major smartphone platforms but Windows7 are using WebKit. This all looks great, a big success but there is one thing that stands out.

From all the smartphone platforms no one has fully upstreamed their port. There might be many reasons for that and I think the most commonly heard reason is the time needed to get it upstreamed. It is specially difficult in a field that is moving as fast as the mobile industry. And then again there is absolutely no legal obligation to work upstream.

For most of today I collected the ports I am aware of, put them into one git repository, maybe find the point where they were branched, rebase their changes. The goal is to make it more easy to find interesting things and move them back to upstream. One can find the combined git tree with the tags here. I started with WebOS, moved to iOS, then to Bada and stopped at Android as I would have to pick the sourcecode for each android release for each phone from each vendor. I think I will just be happy with the Android git tree for now. At this point I would like to share some of my observations in the order I did the import.

Palm


Palm's release process is manual. In the last two releases they call the file .tgz but forgot to gzip it, in 2.0.0 the tarball name was in camel case. The thing that is very nice about Palm is that they provide their base and their changes (patch) separately. From looking at the 2.1.0 release it looks that for the Desktop version they want to implement Complex Font rendering. Earlier versions (maybe it is still the case) lack the support for animated GIF.

iOS


Apple's release process seems to be very structured. The source can be downloaded here. What I think is to note is that the release tarball contains some implementations of WebCore only as .o file and Apple has stopped releasing the WebKit sourcecode beginning with iOS 4.3.0.

Bada


This port is probably not known by many. The release process seems to be manual as well, the name of directories changed a lot between the releases, they come with a WML Script engine and they do ship something they should not ship.

I really hope that this combined tree is useful for porters that want to see the tricks used in the various ports and don't want to spend the time looking for each port separately.

5 comments:

Ademar said...

Any reason why my previous comment was deleted? o_O

zecke said...

Hi,
no idea. I got your comment by email, I didn't trash it, and it was not in the moderation queue. I can send you the text by email and you add it again?

Ademar said...

I also got it via e-mail, so here it goes again. :-)

"From all the smartphone platforms no one has fully upstreamed their port"

You forgot about Nokia/Symbian (assuming Symbian is a smartphone platform) ;-)

The QtWebKit development process is 100% open and tracked directly in WebKit's bugzilla. The stable version, which is used by phones, is handled in a separate branch in gitorious, but the release policy states that a patch has to be upstreamed first before it's accepted in the stable branch.

So it's as open as one can be and with an "upstream first" policy.

You can check the details on the wiki, including links to the meta-bugs and the git repository: http://trac.webkit.org/wiki/QtWebKit

As a side note, nice work on rebasing the other ports. :-)

zecke said...

symbian: To my understanding the current browser is still based on a very old WebKit release and not based on QtWebKit. This is why I didn't count it here.

QtWebKit: In the beginning we made the mistake of using an external git repository (on staikos.net) too much for the first release. Through some pain and Simon's efforts one ended up with the upstream first (which is occassionally broken) policy.


rebase: This is something I still need to do for Android and iOS, for Palm... palm was doing the job. But in both cases it will be difficult as people might have cherry-picked a lot, or just not merged the changelog. I am mostly interested in Android right now.

Ademar said...

To be honest I don't know which qtwebkit is used by the current browser, but the new one (already announced, about to be released) is based on QtWebKit-2.1, which is handled in the open as I described.