Difference between revisions of "Webkit backend for Hulahop"

From Sugar Labs
Jump to navigation Jump to search
Line 27: Line 27:
 
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 minimal modifications of Hulahop's APIs where they expose PyXPCOM or xulrunner internals, thereby further abstracting Hulahop.
+
I will be attempting to write a [http://webkit.org/ Webkit] backend for Hulahop. This will require minimal modifications of Hulahop's APIs where they expose PyXPCOM or xulrunner internals (mostly just a few renames).
  
 
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.
 
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.
+
[http://code.google.com/p/pywebkitgtk/ PyWebkitGTK] 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..
  
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, so 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.
+
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. Secondly, XUL extensions only work on Gecko, not on 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. 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.
 
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.
Line 48: Line 48:
  
 
* '''How about XUL extensions?'''
 
* '''How about XUL extensions?'''
Hulahop can load some Firefox extensions right now, and this ability would be lost for the Webkit version. However, it's not that big a problem because 1) many XUL extensions target the Firefox chrome, which does not exist in Browse and 2) [http://userscripts.org/ userscripts] (GreaseMonkey) are lighter-weight extensions that work in many browsers (GreaseMonkey for Firefox, GreaseKit for Safari, Opera, Chrome, etc.). Although userscripts do not have the same access to browser and native APIs as XUL extensions, they are still very capable. [http://softwareas.com/for-browser-extensions-grease-is-the-word Some] even envision userscripts getting APIs to supplement some of the capabilities they are lacking.
+
Hulahop can load some Firefox extensions right now, and this ability would be lost for the Webkit version. However, it's not that big a problem because 1) many XUL extensions target the Firefox chrome, which does not exist in Browse and 2) [http://userscripts.org/ userscripts] (GreaseMonkey) are lighter-weight extensions that work in many browsers (GreaseMonkey for Firefox, GreaseKit for Safari, Opera, Chrome, etc.). Although userscripts do not have the same access to browser and native APIs as XUL extensions, they are still very capable. [http://softwareas.com/for-browser-extensions-grease-is-the-word Some] even envision userscripts getting APIs to supplement some of the capabilities they are currently lacking.
  
 
* '''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.'''
Line 54: Line 54:
 
Milestones:
 
Milestones:
 
# Replacement WebView class instantiates and displays google.com successfully
 
# Replacement WebView class instantiates and displays 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], with adjustments if necessary
# Browse modified to use the the Hulahop API with the modifications can load google.com
+
# Browse modified to use the the Hulahop API with can load google.com
 
# Browse can browse history and make/load bookmarks
 
# Browse can browse history and make/load bookmarks
 
# Browse can save/restore to/from the Journal
 
# Browse can save/restore to/from the Journal

Revision as of 09:42, 2 April 2009

[backup proposal]

About you

  • What is your name?

Lucian Branescu Mihaila

  • What is your email address?

lucian dot branescu at gmail dot com

  • What is your Sugar Labs wiki username?

lucian

  • What is your IRC nickname?

lucian. backups are lucian1900 and sindbad1900

  • What is your primary language? (We have mentors who speak multiple languages and can match you with one of them if you'd prefer.)

English and Romanian, either is fine.

  • Where are you located, and what hours do you tend to work? (We also try to match mentors by general time zone if possible.)

Mostly in the UK, perhaps a short while in Romania during the summer break. I don't have a 'coding time' in my schedule, anything goes. I also often stay up late at night.

  • Have you participated in an open-source project before? If so, please send us URLs to your profile pages for those projects, or some other demonstration of the work that you have done in open-source. If not, why do you want to work on an open-source project this summer?

I've started a small project on freshmeat called statusPidgin that fetched text from various sources and made it a status message in Pidgin. It's now abandoned, but you can find the source on softpedia
I have also released one of my school projects as open source (a small web imap/pop3 client), but I doubt it's still hosted anywhere. You can get it from my dropbox. I haven't contributed in a significant way to open source projects before, beside bug reports and small patches.
I am a user of open source (linux, KDE, gcc, python, firefox, webkit) and am absolutely delighted by the concept. I am convinced it is the most efficient way of developing software, and perhaps not only software.
I am especially interested in the Sugar project, as I have myself experienced the closed-mindedness that schools instill in their students by teaching them using closed source software. I have been fortunate enough to get some exposure to linux and kde early enough and I would like to help others by showing them the alternatives.

About your project

  • What is the name of your project?

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?

I will be attempting to write a Webkit backend for Hulahop. This will require minimal modifications of Hulahop's APIs where they expose PyXPCOM or xulrunner internals (mostly just a few renames).

Hulahop has a rather nice, simple, python API for integrating browsers in PyGTK applications. It embeds XULrunner with a small chrome and provides simple enough interaction between Python and the DOM inside the chrome. It is built on PyXPCOM, which allows interaction between Python and XPCOM components.

PyWebkitGTK 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..

I intend to provide an alternative WebView implementation for Hulahop that embeds Webkit. Hulahop's API does have places where PyXPCOM bleeds through, so 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. Secondly, XUL extensions only work on Gecko, not on Webkit.
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 experimentation was already done on the XO. I have made some of my own tests that confirm most of these results, both on OS X natively and 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. The same trend is observed on the 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.

  • Why not use existing solutions?
  1. Browse-WebKit is mostly incomplete.
  2. 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 SocialCalc would have to recycle Browse source, which is less than optimal.

  • How about XUL extensions?

Hulahop can load some Firefox extensions right now, and this ability would be lost for the Webkit version. However, it's not that big a problem because 1) many XUL extensions target the Firefox chrome, which does not exist in Browse and 2) userscripts (GreaseMonkey) are lighter-weight extensions that work in many browsers (GreaseMonkey for Firefox, GreaseKit for Safari, Opera, Chrome, etc.). Although userscripts do not have the same access to browser and native APIs as XUL extensions, they are still very capable. Some even envision userscripts getting APIs to supplement some of the capabilities they are currently lacking.

  • 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. Milestones:

  1. Replacement WebView class instantiates and displays google.com successfully
  2. hulahop-webkit works with this snippet, with adjustments if necessary
  3. Browse modified to use the the Hulahop API with can load google.com
  4. Browse can browse history and make/load bookmarks
  5. Browse can save/restore to/from the Journal
  • 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.

Python is my favourite programming language and JavaScript is a close enough second. I have some experience with python and I've built various things, from small utilities to websites with it. My most interesting project was helping to port a scientific application from c++ and Qt3 to Python and Qt4. It involved writing some Pyrex as well. It was lovely to see just how much the code shrunk, while keeping the application itself just as speedy.

I have used JavaScript and HTML to build a small web game, Mousebuster (not online, get it from my dropbox). Although at first I did not like javascript at all, I quickly realised it's immense advantage: huge existing install base.

I also had some contact with C# and Java and have been thoroughly disappointed by their general lack of expressiveness. I did one small schoolwork in C#, that dealt with a database of students. Recently, I did another small schoolwork in Java, dealing with a cricket club. After finishing each, I was amazed at how much of my code was just boilerplate or fighting the type system, code that I wouldn't have had to write in a more dynamic language.

I also used various linux distros for several years, until last year. I got a macbook as a gift and broadcom drivers are still a mess, but that'll get fixed at some point. I found unix in general so intriguing that I set up a small home server with a 300mhz CPU. I put debian on it and used it for various purposes, from web hosting, file serving, distcc node to a router for my home.

Since I was using a lot of open source at home, I tried to push it in school as well. I managed to make students and teachers aware of GCC as a replacement for Borland C/C++, Mono and SharpDevelop as a replacement for the not-quite-free Visual Studio. With the help of a friend, I even managed to convince the head of school to install Ubuntu in one of the labs.

You and the community

  • If your project is successfully completed, what will its impact be on the Sugar Labs community? Give 3 answers, each 1-3 paragraphs in length. The first one should be yours. The other two should be answers from members of the Sugar Labs community, at least one of whom should be a Sugar Labs GSoC mentor. Provide email contact information for non-GSoC mentors.
  • Sugar Labs will be working to set up a small (5-30 unit) Sugar pilot near each student project that is accepted to GSoC so that you can immediately see how your work affects children in a deployment. We will make arrangements to either supply or find all the equipment needed. Do you have any ideas on where you would like your deployment to be, who you would like to be involved, and how we can help you and the community in your area begin it?

I'm not familiar with schools near where I live, as I am an international student. [Any suggestions?]

  • What will you do if you get stuck on your project and your mentor isn't around?

Google, check sugarlabs/olpc forums/mailing lists/wikis. Ask on #sugar/mailing list. Ask other mentors and GSoC students or developers of related open source software.

  • How do you propose you will be keeping the community informed of your progress and any problems or questions you might have over the course of the project?

In the worst case scenario, just emails to my mentor and commits. IRC has proven itself time and again and I intend to proudly announce any advances made. I intend to set up a blog and use that as well. Identi.ca or Twitter may also prove useful.

Miscellaneous

My development environment with the small hack.
  • We want to make sure that you can set up a development environment before the summer starts. Please send us a link to a screenshot of your Sugar development environment with the following modification: when you hover over the XO-person icon in the middle of Home view, the drop-down text should have your email in place of "Restart." See the image on the right for an example. It's normal to need assistance with this, so please visit our IRC channel, #sugar on irc.freenode.net, and ask for help.

Picture to the right.

  • What is your t-shirt size? (Yes, we know Google asks for this already; humor us.)

XL

  • Describe a great learning experience you had as a child.

The most important thing I ever learned was to never be certain of anything and to always be prepared for the worst.

  • Is there anything else we should have asked you or anything else that we should know that might make us like you or your project more?

Web technologies are remarkably flexible and it would be great to encourage students to play around with them.