Changes

Webkit backend for Hulahop

Webkit backend for Hulahop

* Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?

* Describe your project in 10-20 sentences. What are you making? Who are you making it for, and why do they need it? What technologies (programming languages, etc.) will you be using?

I will be attempting to write a [http://webkit.org/ Webkit] backend for Hulahop. This will require modifications of Hulahop's APIs where they expose PyXPCOM or xulrunner internals.

I will be attempting to write a [http://webkit.org/ Webkit] backend for Hulahop. This will require modifications of Hulahop's APIs where they expose PyXPCOM or xulrunner internals, thereby further abstracting Hulahop.

  everything below is to be modified, please ignore for now

  everything below is to be modified, please ignore for now

Hulahop has a nice, simple, python API for integrating browsers in PyGTK applications. It embeds XULrunner with a small [http://kb.mozillazine.org/Chrome_URLs chrome] and provides simple enough interaction between Python and the DOM inside the chrome. It is built on [https://developer.mozilla.org/en/PyXPCOM PyXPCOM], which allows interaction between Python and XPCOM components.

Hulahop has a rather nice, simple, python API for integrating browsers in PyGTK applications. It embeds XULrunner with a small [http://kb.mozillazine.org/Chrome_URLs chrome] and provides simple enough interaction between Python and the DOM inside the chrome. It is built on [https://developer.mozilla.org/en/PyXPCOM PyXPCOM], which allows interaction between Python and XPCOM components.

This project, [http://code.google.com/p/pywebkitgtk/ PyWebkitGTK] that unsurprisingly provides a PyGTK widget with a browser inside. It's API is lower level than Hulahop and more specific to Webkit, so it should be both feasible and beneficial to the community at large to wrap PyWebkitGTK in Hulahop's API, where it makes sense.

This project, [http://code.google.com/p/pywebkitgtk/ PyWebkitGTK] that unsurprisingly provides a PyGTK widget with a browser inside. It's API is lower level than Hulahop and more specific to Webkit, so it should be both feasible and beneficial to the community at large to wrap PyWebkitGTK in Hulahop's API, where it makes sense.

I intend to provide an alternative WebView implementation for Hulahop that embeds Webkit.  Hulahop's API does have places where PyXPCOM bleeds through, but the I will attempt to provide a WebView class with as little dependency on a specific engine as possible.

I intend to provide an alternative WebView implementation for Hulahop that embeds Webkit.  Hulahop's API does have places where PyXPCOM bleeds through, but the I will attempt to provide a WebView class with as little dependency on a specific engine as possible.

This project is not aimed at providing a complete a drop-in replacement for the current (Gecko) version of hulahop. Firstly, activities (like Browse) that use hulahop do not restrict themselves to an engine-independent subset of the API, so they will have to be modified in order to work with hulahop-webkit. Also, there probably isn't enough time during GSoC to do all that work.

This project is not aimed at providing a complete a drop-in replacement for the current (Gecko) version of hulahop. Firstly, activities (like Browse) that use hulahop do not restrict themselves to an engine-independent subset of the API, so they will have to be modified in order to work with hulahop-webkit.

<br />

<br />

The motivation for this project is the fact that there is a lot of empirical data that shows Webkit is significantly faster and uses significantly less memory than Gecko. I have made some of my own tests that confirm most of these results. [links to results go here]. Webkit ends up being anywhere from 1.5 to 9 times faster than Gecko on benchmarks.

The motivation for this project is the fact that there is a lot of empirical data that shows Webkit is significantly faster and uses significantly less memory than Gecko. Some [http://www.j5live.com/2007/08/02/webkit-and-xulrunner-mozilla-side-by-side-on-the-xo/ experimentation] was already done on the XO. I have made some of my own tests that confirm most of these results, both [http://dl.getdropbox.com/u/317039/webkit%20vs%20gecko.txt on OS X natively] and [http://dl.getdropbox.com/u/317039/webkit%20vs%20gecko%20soas.txt on linux in VirtualBox]. Webkit ends up being anywhere from 1.2 to 9 times faster than Gecko on benchmarks.

Besides these synthetic benchmarks, there is also a significant difference in the (decidedly subjective) user experience. While running the more intensive benchmarks, the Webkit demo browser was much more responsive than Gecko, which frequently locked up.  

Besides these synthetic benchmarks, there is also a significant difference in the (decidedly subjective) user experience. While running the more intensive benchmarks, the Webkit demo browser was much more responsive than Gecko, which frequently locked up.

The same trend is observed on the [http://www.chromeexperiments.com/ Chrome Experiments]. There may be some bias on the part of the builders of these experiments that may make the observation invalid, since Chrome uses Webkit. However, these experiments stress the JavaScript engine much more than anything else and Chrome has a different engine (v8) to Webkit.

The same trend is observed on the [http://www.chromeexperiments.com/ Chrome Experiments]. There may be some bias on the part of the builders of these experiments that may make the observation invalid, since Chrome uses Webkit. However, these experiments stress the JavaScript engine much more than anything else and Chrome has a different engine (v8) to Webkit.

This may have to do with better threading and different interactions with the Python and gobject bindings, but considering that both bindings use GTK and have Cairo rendering, it is at least reasonable to conclude that the browser widget in PyWebkitGTK has better user responsiveness than the one in Hulahop-gecko.

# Some other GTK WebKit browser. They would have to be sugarized.

Both of these would only provide WebKit for Browse. Other activities that need a browser GTK widget, like [http://www.socialtext.net/socialcalcxo/index.cgi SocialCalc] would have to recycle Browse source, which is less than optimal.

* What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.

* What is the timeline for development of your project? The Summer of Code work period is 7 weeks long, May 23 - August 10; tell us what you will be working on each week. (As the summer goes on, you and your mentor will adjust your schedule, but it's good to have a plan at the beginning so you have an idea of where you're headed.) Note that you should probably plan to have something "working and 90% done" by the midterm evaluation (July 6-13); the last steps always take longer than you think, and we will consider cancelling projects which are not mostly working by then.

I plan to get a small WebView class working with both webkit and gecko in the first 2-3 weeks. Two weeks at most should be necessary to build a demo browser with controls (and change the WebView class where necessary). The rest could be spent on investigating and refactoring Browse and polishing things up or for emergencies.

I plan to get a small WebView class working with both webkit and gecko in the first 2-3 weeks. Two weeks at most should be necessary to build a demo browser with controls (and change the WebView class where necessary). The rest could be spent on investigating and refactoring Browse and polishing things up or for emergencies.

Milestones:

Milestones:

# Replacement WebView class instantiates and displays successfully

# Replacement WebView class instantiates and displays google.com successfully

# hulahop-webkit WebView loads google.com successfully

# hulahop-webkit works with [http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView this snippet], adjustments as necessary for the reworked Hulahop API.

# hulahop-webkit works with [http://wiki.laptop.org/go/Sugar_Code_Snippets#WebView this snippet] (or similar)

# Browse refactored to use the new Hulahop API can load google.com

# Hulahop browser with controls (back/forward/url/history/etc.) can browse several websites. (perhaps stripped-down Browse)

# Browse can browse history and make/load bookmarks

# Browse   "    can save and restore to/from the Journal

# Refactor Browse to use hulahop-webkit

* Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.

* Convince us, in 5-15 sentences, that you will be able to successfully complete your project in the timeline you have described. This is usually where people describe their past experiences, credentials, prior projects, schoolwork, and that sort of thing, but be creative. Link to prior work or other resources as relevant.