A Browsing Adventure Tale. Apr 01, 2004 04:44 UTC, by Chris Simmons, Senior Journalist From the page-turner department... Matt Madia sent me a beautifully crafted letter for the community which talks about his involvement in bringing the Mozilla browser to BeOS. I can't do justice to his letter with words alone, so I will just say, read on... Web browsing. Perhaps the most universal task among computer users. Thanks to the BeZilla team and other enthusiastic members of our community, BeOS has decent browsing abilty thanks to the ports of Mozilla and Mozilla Firefox, both of which use the leading standards-compliant Gecko html rendering engine. Unfortunately no amount of progress will allow Mozilla to use BeOS specific features such as translators, drag 'n drop, replicants, attributes, media codecs and so on. There is quite a speed penalty as well. The amount of code used to provide Mozilla's user interface is relatively heavy due to its cross platform design. Fortunately there are alternatives. We can either code our own web browser from the ground up or we can take an existing html rendering engine such as Mozilla's Gecko engine and embed it into our own native web browsing application. Although building our own browser, such as what Project Themis is doing, would give us blistering performance, it carries its own set of obstacles. Aside from the mammoth task of building our own fully functional rendering engine from the ground up, we are faced with the fact that we have a limited number of developers and a small userbase. There are presently not enough people able to find bugs in our rendering engine and even less developers to fix them. By implementing an existing rendering engine into our own browser, a lot of coding time would be saved. In addition, it would enable developers and users to utilize that engine in other browsers on other operating systems, which aids in reporting and fixing bugs. Realistically we have two choices for a rendering engine. Use the Gecko engine, developed by the Mozilla team and used in the browsers Mozilla, Firefox, Netscape's Navigator, Galeon, Kmeleon, and others. Use KHTML, developed by the KDE team and utilized by KDE's Konqueror, Apple's Safari, SkyOS's SkyKruzer, and Atheos/Syllable's Abrowser. The task of embedding Gecko has been a topic of much conversation during the last few years and was re-started with the Net++ project which unfortunately never saw completion. I ambitiously attempted to continue Procton's Gecko embedding widget for BeOS, but sadly it did not go as well as I had hoped. The BeOSJournal forum has my most recent postings detailing the unresolved problems. I have tried the #mozilla IRC channel, newsgroups, and other contacts searching for a solution but have so far come up empty. The files related to my work are available online, but unless something revolutionary happens, I consider my work on Gecko discontinued. In the meantime though, I have noticed much buzz around the KHTML engine and have been doing a little investigation. KHTML seemingly offers many advantages over Gecko as cited by Apple's Safari team in a letter back to the KHTML's developers of the KDE team following a year of research on their choices. A.) Choosing Gecko over KHTML: Larger community of developers and users. More standards compliant. Majority of port is complete, as it uses Mozilla / Firefox sources. (Nightly CVS.) Next logical step in BeZilla evolution. B.) Choosing KHTML over Gecko: Relatively small amount of code (140,000 lines) which will also be reflected in low start up times. Ease of development within that code. Designed to be multi-threaded vs single-threaded Gecko. Foundations for a full Qt port, which may eventually allow us to port KOffice and other KDE software. Without a doubt much work will be needed to get this working, porting Apple's WebCore (Apple's version of KHTML) also depends on porting the KJS engine also known as JavaScriptCore, which in turn depends on PCRE regular expressions library. Luckily Philippe Houdoin reports the last two components to be easy to port. He also states, "where Apple had written in Objective C and C++ a QT wrapping layer called KWQ, one should do something similar but using BeOS C++ API to wrap QT classes used by KHTML code" This is where you, YES YOU!, enter the story. It's even a choose-your-own-adventure type of story. If you chose 'A', it will involve learning about Gecko's inner workings to figure out what causes my error, as everyone I've shown the code to is stumped. If you chose 'B', we can start fresh on KHTML. This will entail creating templates and guides on how to write BeAPI code based on WebCore's Objective C and Qt's code. Monkey men, such as myself, will then take that information and convert as much code as possible. This will quite possibly be a large task but we should be rewarded with a supremely fast, mature browsing solution. Or you can chose 'C', morphing into a monkey man to help us out with our mammoth project in any way you can. Once either engine is ported successfully, it will only be a matter of time before a native GUI browser will be able to make use of it. Whatever path you choose, the risks and sacrifices may be great but the reward of participating in what many would see as a valuable BeOS project can not be ignored. Respectfully, Matt Madia, Karina Goddard.