[haiku-development] Who wants to help develop a Haiku native web browser?

  • From: Ryan Leavengood <leavengood@xxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 24 Feb 2009 15:55:49 -0500

A lot of exciting things are happening in the world of web browsers
these days. Google's Chrome has shaken things up a bit while Firefox,
Safari and Opera all continue to improve (more or less) and we now
have at least three very fast open source Javascript engines
(JavascriptCore Extreme, V8 and TraceMonkey.) IE is even starting to
suck less.

I consider a solid web browser as my primary need on any operating
system. Haiku has our Firefox port, but it is not up to the standards
many of us want, including those who ported it, who are under
constraints imposed by the Mozilla project. While Firefox 3 offers
some improvements, I find it is starting to feel bloated, slow and
buggy and is not the Firefox browser I fell in love with. Therefore I
am not even sure it is worth porting.

As many of you may recall, I ported WebKit to Haiku more than a year
ago. With the help of Andrea Anzani and Stephan Assmus we got it to
render some pages, but a lot of functionality was still missing.
Everyone stopped working on it and that code has languished for the
last year as WebKit has changed and improved in countless ways.

Haiku has also continued to be improved and now we even have a native
GCC4 tool chain, so there is no longer a need to cross compile when
working on ports like WebKit.

What this means to me is that it is time the WebKit port is brought
up-to-date and finally committed into the official WebKit repository.
I also think we should write a native web browser to use this WebKit
port. But both of these are big projects and I am crazy to think I
could do it alone. Plus several people have shown interest in helping
out on this, but I have repeatedly told them "please wait until I can
do x,y,z." Well I have realized I am slowing things down too much and
need to let other people help.

So, I ask: who wants to help on this? I mean REALLY, who has the time,
motivation and tenacity to work on this?

To give an idea, here is what I think needs to get done:

1. The latest WebKit code needs to be "re-ported" to compile again for
Haiku. This doesn't mean that everything works, but that the build
system is set up right again. A LOT has changed in a year (especially
in JavaScriptCore) so this might take a little while. My idea for this
was to just start with a fresh checkout of WebKit, and then bring over
whatever is needed from my original port.

*IMPORTANT* For those who don't know, my ported code can be checked
out anonymously from here:

http://ryanleavengood.com/svn/repo/WebKit/trunk/

It has been there ever since I wrote it, so it isn't like I was trying
to hide it from anyone. Still no one worked on it once Andrea stopped
in January 2008. It will probably still even compile.

2. A decision needs to be made whether we continue to use Jam as the
build tool for the WebKit port, or try to use one of the existing
WebKit build systems. Within the last year a new autotools based build
has been added, which might be a better choice, mainly because other
people would maintain it. Jam is nice because it can easily snap into
a Haiku build directory. But then have to maintain that when things
are moved around plus not all WebKit developers on Haiku will
necessarily also be Haiku developers with the full tree checked out.
At the same time I am not 100% sure whether the autotools build system
in WebKit can work on Haiku. This should be determined first. For
number 1 above it might be easiest just to update the jam build system
I created for WebKit and then figure out whether autotools would work
too.

3. Once the above is done a lot of the missing pieces in the WebKit
port should be filled in. The thread model needs to be improved and
various things like Affine transform code need to be added.

4. Probably while the above is being done a browser shell should be
started. Maybe some of the existing BeOS open source browsers could
serve as a starting point, though I at least am open to starting from
scratch. And before anyone mentions it, I too like Chrome but the
Chromium code that Chrome is built on is A LOT OF CODE and would
probably be just as hard to port as WebKit. So for now I think we
should make use of some pieces of it (like the "omnibar" code), but
save a full port for later, if ever. I would not be opposed to copying
the Chrome interface though...

5. At some point a decently working WebKit port and browser shell
should be available and people can start testing. Then it is the usual
add features/bugs, test, release, rinse and repeat.

Once the grunt work (1-3) is over though, this should be quite fun and
I would hope new developers would be able to come aboard just as
easily as they do on Haiku.

So, after hearing all that, who wants to help? :)

Let me know,
Ryan

Other related posts: