Has anyone declared their intentions to develop a Haiku-specific web browser? I mean one with the functionality of BeZilla/Firefox, but written in C++/BeAPI to work specifically with the Be API?
Being “native” is not all it’s cracked up to be. The most likely candidate for a native browser would be one based on a cross-platform rendering engine (Gecko (from firefox/mozilla) or KHTML (from Konqueror/Safari)), with a clean BeOS interface written from scratch.
The web was intended to be cross platform, there is no need to have a written-from-scratch renderer - it is a lot of work to support all the web standards and there are some good cross-platform rendering engines about already (as I have mentioned).
The themis project are working on a fully native browser, but with such a small team it is unlikely they will reach the standards compliance and website functionality level of firefox.
Firefox is written in C++ by the way, and of course uses the BeAPI too (otherwise it simply wouldn’t work). The only thing that makes people think Firefox is non-native is that it renders the interface itself the same way that it renders web pages.
Simon
I remember some time ago YellowTab announced that they will have a WebCore port. Webcore is the LGPL KHTML derivative that Safari uses.
Anybody know what happened with that?
They said they ported it, I asked if they where willing to share the code as I’d be far more interested in WebCore, but I’ve never gotten any replies.
So if they have it, they are being very quiet about it.
yT had a phase some years ago where they decided to announce they had lots of things, many of which are yet to appear. At least recently they’ve been keeping a bit more quiet on that front and actually doing something useful instead.
A webcore port would indeed be nice to have, it fits in with the slimmed-down outlook of BeOS better than the HUGE beast that is Gecko, and with Apple using it in their official browser web designers are going to be forced to take it seriously when designing pages.
I’d say the right route for a kick ass browser definitely is to base it on KHTML, like already suggested. Haiku has even greater reasons to choose this rendering engine than Apple had, because KHTML is C++ while Gecko is plain C. Some reasons for Apple’s choice of engine were its clean design, small, efficient and easy to understand code base, and good standards conformity.
I’m not sure whether it’s better to start off with WebCore or plain KHTML+KJS. On one hand, WebCore removes dependencies on Qt and KDE libraries, which is also necessary for Haiku. On the other hand, WebCore is targeting Cocoa and Objective-C. The latter could turn out to be a huge problem because ObjC++ (combining ObjC and C++ in the same file) isn’t yet supported by GCC. This means that even if support was to be added and a new GCC released tomorrow, we’re talking at least version 4.1 of the compiler, and Haiku’s still using GCC 2.95, right?
Both the good and the bad mentioned above (ditch Qt/KDE, add ObjC API) is realized by Apple’s KWQ adapter. Maybe the best thing to do for Haiku would be to write a new adapter to replace deps on KDE/Qt and add a few things here and there specific to the BeOS API? Hopefully this could be done in a way that makes it easy to pull in the newest version of KHTML every now and then, without too much work on the adapter.
I am not a Haiku/BeOS programmer and I don’t know more about WebCore than what I’ve read in various blogs/news sites, but these are my thoughts on the topic. I really hope we’ll see a modern, fast, native web browser on this platform by the time of R1.
I will need to investigate further!
Well, I think we definatly should skip Obj-C if someone would start working on this. My main issue is with setting up something that builds (boy do I dislike configure / make ).
(Btw, Gecko is far from plain C.)
Porting WebCore to BeOS means rewrite something similar to Apple’s KWQ layer but using BeOS API instead of Cocoa’s one.
KJS is easy to port under BeOS, and several developers (me included) already did it.
KHTML heavily rely on a large portion of Qt classes that Apple choose to implements using wrappers around there own Cocoa similar classes. That a good way to do it for BeOS too, but it’ll require to well understand both these Qt classes and Cocoa to understand KWQ before being able to reproduce this design for BeOS classes.
It’s obvious we can’t simply port the Objective C code under BeOS. Not only because our gcc doesn’t support ObjC (yet?) but because it doesn’t make any sense as our OS upper API is C++, not ObjC.
Anyway, with a fine Firefox port already, even if having a cool - hopefully integrated into a future Haiku WebKit or whatever - native browser still sounds like a good idea, I guess the urge is no more that high these days.
BTW, Apple justs opened his open sourced WebKit web site:
http://webkit.opendarwin.org
There will be possibilities for embedding with Gecko too. Be sure of it.
Just one note:
recently Steve Jobs has announced that Apple will probably leave KHTML to develop a new browser engine… This should make Haiku developer rethink their ideas about Gecko and Webcore… It won’t be sure (even if it’ll remain auspicable, because of Konqueror at least) that web developers will take in acoount so much webcore support… :?
Sounds like it’d just be easy to write from scratch, with KJS etc?
skoe wrote:
Nope.
Sounds like it'd just be easy to write from scratch, with KJS etc?
Unless by easy you mean employing a team of people full-time for a couple of years…
Meanwhile wrote:
http://themis.sourceforge.net/faq.php?id=12It’s not dead, but nobody is working on it… :?
If they ever manage to write a rendering engine as standards-and-web-site compliant as mozilla (or even KHTML), I’ll eat my hat. I don’t even have a hat, so I’d even have to buy one before eating it…
tb100 wrote:
Meanwhile wrote:http://themis.sourceforge.net/faq.php?id=12It’s not dead, but nobody is working on it… :?
If they ever manage to write a rendering engine as standards-and-web-site compliant as mozilla (or even KHTML), I’ll eat my hat. I don’t even have a hat, so I’d even have to buy one before eating it…
Considering I’d be shocked also, you can have one of mine… dodgy blue chav-esque Nike okay?
Exactly what “Standards” would be considered enough for you to eat your hat?
The Basics:
xHTML 1.0 (Standard, Strict)/1.1
HTML 4
XML
CSS 1 and 2
Some others:
MathML
XForms
Scripts:
Javascript
Did i miss anything? I have been planning to write a Web Browser (Even a simple one) for a long time now, and it has been lingering on my TODO list for almost as long… It’s now almost time it’s at the top of my list, and i’m going to give it a go.
skoe wrote:
Exactly what "Standards" would be considered enough for you to eat your hat?The Basics:
xHTML 1.0 (Standard, Strict)/1.1
HTML 4
XML
CSS 1 and 2Some others:
MathML
XFormsScripts:
JavascriptDid i miss anything? I have been planning to write a Web Browser (Even a simple one) for a long time now, and it has been lingering on my TODO list for almost as long… It’s now almost time it’s at the top of my list, and i’m going to give it a go.
That’d do OK once you add in the common Microsoft and Netscape extensions to HTML3/4, but look how long its taken the RISCOS people to get NetSurf to supporting -some- of them - and no JavaScript! Although, BeOS should be somewhat easier to programme for at the low-down level, you’ll have similar problems
I do agree, Microsoft is a pain in the Neck :-P. A 100% Microsoft-Compliant Web Browser is impossible, IMHO.
skoe wrote:
I do agree, Microsoft is a pain in the Neck :-P. A 100% Microsoft-Compliant Web Browser is impossible, IMHO.
I didn’t mean ActiveX, etc - I meant their 1997 era, almost globally accepted but not W3C ratified extensions to HTML.