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.
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?
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.
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 ).
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.
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... :?
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...
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.
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.
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
if themis is halfway clean written then we should add it to the haiku-tree to get it further developed, i think.
it is mit-licensed and a native beos app; it would be the perfect net+-substitute...
if themis is halfway clean written then we should add it to the haiku-tree to get it further developed, i think.
it is mit-licensed and a native beos app; it would be the perfect net+-substitute...
If the developers were available, they'd be just as able to contribute code to it outside the Haiku repo...
Skoe, if you're serious about making a native webbrowser for R5/Haiku,
then i strongly suggest working with the BeZilla team to get embedding working properly. http://www.livejournal.com/community/bezilla/
An HTML engine is a serious chunk of code.
For at least the next few years, the BeOS/Haiku community simply cannot compete with Mozilla's community in terms of development, userbase, etc.
It'll also allow more time to be devoted to the actual GUI.
Back around May and June of this year, I was giving a serious look into what would be involved in having a native web browser for BeOS. I would first like to say that the BeZilla team has done an amazing job. The Firefox / Mozilla source tree is IMO uglier than any horror movie I've ever seen, so getting anything like that to work is short of miraculous. I can live with the bugs in the official 1.5 release from a little while ago because I know how hard it is. Many efforts at embedding the Gecko rendering engine have been made over the years, but none of them ever worked the way they should have.
My opinion is to go the OS X / Syllable route and port KHTML. There is AFAICT less overhead than with the XPCOM technology that Mozilla is based on. To be blunt, a good browser is hard. Period. It is a project on the size of Haiku itself.
If there is anyone out there who does not have much experience with coding for BeOS, but has plenty of experience working with Qt, that person should seriously look into working on porting the browser. Doing the port would be helpful in learning the API and be an immense boon to the community. I just wish there were takers. As tight-fisted as I am with my money (for lack of it), I certainly would pay good money even for a good commercial version.
Ok, before I got heavily involved with Mozilla I wanted to work on KHTML, and just as Darkwyrm says, it's elegant.
Unfortunatly build-system configuration is something I hate, so I joined Mozilla and learnt how to get things done there. As the interest for Webcore seems to increase it might be time to try and wake up a project that has been slumbering: Nirvana. I've already talked to some people about it recently and it would be good if a joint effort could be made.
Also I don't know if Darkwyrm was talking about embedding Gecko under BeOS or in general, but the main reason embedding under BeOS doesn't work is in the widget-code for BeOS. It starts the message-looper for handling Mozilla messages in a nsAppShell->Run. In embedding that function is never called. A long time ago I actually had a half-running embedding app upp, although it didn't render correctly. I havn't had time to work on that as priority has been on Firefox and Seamonkey. I don't see any major problems in the way of getting embedding working except some time and effort.
I bet if IE was available for BeOS people would use it :D
I think not. The idea of a truely native webbrowser for Haiku seems good to me, but the problem would be to code a proper render. Not impossible but it requires something different. Leave Gecko and KHTML and all those behind, and go another way. Look at the really small OS'es, like AmigaOS4 and other such modern OS'es with extremely small system resource usage. Get inspiration from them, rather than the large bloated systems used by the majority. Look at FoxIt PDFreader, to see how a PDF-reader is done properly. A browser should have pretty much the same size, extensions not accounted for.
fanton wrote:
Offtopic:
What the hell is with all K's and Be's or B's in KDesktop or BeOS? Like KHTML.
Well, it's just like all the apples on Apple and all the MS'es on Windows and so on. Call it lack of creativity :wink:
Why yet another browser project that will never finish? I know it's very intriguing to write a browser, but we should keep in mind that there are not enough developers for such a project. We should concentrate on things that really improve the user-experience.
And I think that people *do* use the best application. Firefox is cool because it's easy to use and configure. If it were a little bit faster I would love it. At university we use Linux and we have five or six browsers and I got crazy when I had to find Konqueror's option to disable auto-saving password. Well, I gave up because I could not find it within five seconds. In Firefox I just open the preferences dialog and immediately see where to find these settings. Also, after a clean install I only change the default website, disable password and form completion, and maybe (at university) set the cache size down. That's it! Look at the settings in IE. It takes half an hour to configure IE after a Windows reinstall just to make it comfortable to use. Why? Because I have to re-read all possible settings to remember which of them I normally change.
If KHTML is faster then we should make it our native HTML framework and create a browser around it. But make the browser as easy or even easier to use than Firefox.
Please don't spend the time on writing a new engine. We need serious software. Otherwise nobody will use it because it does not display all pages correctly or because it's incomplete.
But we also need native QT and GTK ports. And Haiku must be finished. Then, we need drivers (Intel integrated graphics cards, for example). An office suite (yT is already porting OpenOffice which isn't BeOS-ish enough, later we need at least Abiword + gnumeric + some presenter). We also need Java (when will the port be finished?). Please take a look at our wiki: http://www.haiku-os.org/wiki/index.php?title=Software_Wishlist
Here you will find enough projects. For example, you could work on the Haiku media player to do the things listed on the wiki page. I would love to have TrueCrypt ported to Haiku some day (after the high-priority tasks are finished). An NTFS driver would be cool. There are so many things that would improve our productivity and the user experience much more than a new browser project. BeOS had too many of those just-for-fun projects that vanished as quickly as Be Inc.
I would add to your list the following:
- an audio editoraudacity?
- a 3d modelling/rendering - blender (very GOOD!!!)
Instead of gimp i would try improving GimpShop which is Gimp that looks like Photoshop (it's still beta i think).
p7zip is a 7zip port available in linux only as a shell command. Can do all that 7zip does but no gui. Can extract tar, gzip, bzip2, zip, rpm? (and a couple more) and of course 7z. This could replace all other commands like tar -xvf ... or gunzip... A native Haiku gui frontend for p7zip would be nice for example :D
openoffice.org 2 is very good! i never used abiword. but openoffice has all i ever need. i never ever ever had the feeling a feature was missing. even has a database engine (a la access). but needs java i think.
I would add to your list the following:
- an audio editoraudacity?
- a 3d modelling/rendering - blender (very GOOD!!!)
Instead of gimp i would try improving GimpShop which is Gimp that looks like Photoshop (it's still beta i think).
p7zip is a 7zip port available in linux only as a shell command. Can do all that 7zip does but no gui. Can extract tar, gzip, bzip2, zip, rpm? (and a couple more) and of course 7z. This could replace all other commands like tar -xvf ... or gunzip... A native Haiku gui frontend for p7zip would be nice for example :D
openoffice.org 2 is very good! i never used abiword. but openoffice has all i ever need. i never ever ever had the feeling a feature was missing. even has a database engine (a la access). but needs java i think.
Audacity is HORRIBLE
The Old "SampleStudio" source code is opensource, however, Xentronix are being quite forceful on the trademarks policy. Its a native BeOS app, a quick renaming would make it a decent audio editor. Audacity is not a decent audio editor.
No point in using p7zip for anything but 7zip, as removing other commands === destroy shell scripts, destroy portable software, destroy build systems, etc, etc.
No, it's not. It's FANTASTIC! (That remark is about as intelligent as yours. You are too fast to shoot down ideas...)
MYOB wrote:
The Old "SampleStudio" source code is opensource, however, Xentronix are being quite forceful on the trademarks policy. Its a native BeOS app, a quick renaming would make it a decent audio editor. Audacity is not a decent audio editor.
Define decent audio editor and indecent. Instead of just spreading BS. Audacity handles many different audio formats, loads instantly and has an intuitive and simple, but efficient UI.
So apart from your hatred against any non-BeOS native application, what is it that is SO wrong about Audacity?
MYOB wrote:
No point in using p7zip for anything but 7zip, as removing other commands === destroy shell scripts, destroy portable software, destroy build systems, etc, etc.
I agree with you on that one. However, I don't think we will need support for 7zip very much. Bzip2 is more important.
.....
And now for something completely different(C) Monty Python
When the amigans can handle a sort-of port of GTK then we can do the same. I really like their approach about a GTK->MUI translation layer, where the GTK-widgets are implemented by native widgets, with the GTK-code working as a sort of wrapper around the native widgetset. It gives applications a native look and feel which IMO is very important.
looking at how you people answer, i think each one of you has an unique perspective of what is useful to him/her. i don't mind audacity. myob hates it. Mr.Jones loves it i think other people don't care or use something diffrent.
rather than creating a new browser i think you people should fill wkornew's list using some form of voting, or polls, or talking trough on forums.
i'm neither against nor for creating a new browser based on gecko or khtml. but why make a new browser when firefox will do?
No, it's not. It's FANTASTIC! (That remark is about as intelligent as yours. You are too fast to shoot down ideas...)
MYOB wrote:
The Old "SampleStudio" source code is opensource, however, Xentronix are being quite forceful on the trademarks policy. Its a native BeOS app, a quick renaming would make it a decent audio editor. Audacity is not a decent audio editor.
Define decent audio editor and indecent. Instead of just spreading BS. Audacity handles many different audio formats, loads instantly and has an intuitive and simple, but efficient UI.
So apart from your hatred against any non-BeOS native application, what is it that is SO wrong about Audacity?
MYOB wrote:
No point in using p7zip for anything but 7zip, as removing other commands === destroy shell scripts, destroy portable software, destroy build systems, etc, etc.
I agree with you on that one. However, I don't think we will need support for 7zip very much. Bzip2 is more important.
.....
And now for something completely different(C) Monty Python
When the amigans can handle a sort-of port of GTK then we can do the same. I really like their approach about a GTK->MUI translation layer, where the GTK-widgets are implemented by native widgets, with the GTK-code working as a sort of wrapper around the native widgetset. It gives applications a native look and feel which IMO is very important.
Audacities UI is directly out of a 1994-era childs drawing, its utterly disgusting and completely unusuable
Audio formats are the responsibility of the media kit, NOT an application.
wxWidgets is one thing thats "So" wrong about Audacity, its UI is the next thing thats wrong with, not using B* classes for media work is another, and so on. WRT media, non native apps just suck on BeOS.
bzip2 is already supported in BeOS and in Haiku. However, its not a suitable 'default format' as it doesn't do BeOS filesystem attributes, only zip does.
The way GTK+/GTK2 works makes it -extremely hard- to implement GTK widgets as anything other than drawing controls onto a portable canvas. GTK 2.8 makes this even harder. Don't expect that Amiga approach to be sustainable in the long run.
i'm neither against nor for creating a new browser based on gecko or khtml. but why make a new browser when firefox will do?
Simply because there is only so much that mozilla.org will allow the BeZilla team to commit to CVS.
For instance, if they wanted to add replicant functionality or some other BeOS-specific functionality to the gui, they'd be SOL.
Also, there are times when updates to the mozilla code for other platforms breaks or generally fouls up the BeOS port. Thus requiring the BeZilla team to spend unplanned time and effort to fix those bugs, instead of continuing progress.
IMVHO the initial investment of time and effort to get 1. a HTML rendering engine embeddable
2. a basic native browser utilizing #1
would eventually make up for itself in the flexibility granted to the developers working on the actual browser.
There'd be no need for all of the dancing through hoops and leaping across pits to get a patch that took 3minutes to code checked in.
Not to sound condescending (or to take shots at the BeZilla team), but there are quite a few reasons I can think of for BeOS to have its own browser. Speed, for example. Firefox is acceptable but nowhere near as fast as anything built for BeOS from the ground up. I imagine that if Net+ had the same features as Firefox does, it would still be faster. OS integration would be immensely easier, too.
Another reason is overhead. Firefox has its cross-platform goodness because the entire UI is written in whatever language/API it's called (IDL, I think) and that adds to overhead. IMO, it's akin to going through a big bureaucracy to get anything done. While the underlying technology the entire browser is based on would still be there, cutting down on the cross-platform code would increase speed and reduce overhead.
Like mmadia mentioned, features also come to mind. Wouldn't it be nice to have a browser which has built-in ad-blocking features? AFAIK there isn't a browser out there with that.
I have mentioned this before to the Bezilla team, but what stops you from forking Firefox?
I had the same thought. Why not fork it? K-Meleon (for Windows) is a fork of Mozilla, and much quicker than Firefox and Mozilla.
Of course the fork can't use original icons and themes, nor the name, but who cares? BeOS like icons would be better, and if we should use non-BeOS like icons, it ought to be the Tango Project. But alas, they are not that BeOS-like. They look more like a blend of KDE and Gnome (and we don't want that).
I'm not even sure about using the Gecko engine, but it's easier than writing an engine from scratch, and a wiser choice than KHTML.
I look at it from the perspective of attracting users. Most of us here, people who are interested and involved with the Haiku community, will probably start using Haiku while R1 is even in the Beta stage. We may even attract some old BeOS users who have since moved on to an actively updated OS. At some point, however, it only makes sense that we should hope attract fresh users: people who perhaps have never even heard of or used BeOS.
To old/current BeOS users, and those of us involved in the community, a native web browser is cool project and a neat idea. And, there are even some advantages: slight performance gain and consistent OS wide look and feel. Such a project, as many have pointed out, is a monumental undertaking; it is the same order of magnitude as Haiku itself. But, even if such a project did come to fruition, and achieved complete standards compliance with javascript and some plugin support, I have a feeling lots of new users would end up using firefox, just cause there's a good chance they were using it on whatever platform they are migrating from.
A native browser is NOT going to attract new users. In fact, it is likely to be completely ignored by many of them, even if its just as good or better than the BeZilla port. Computers and connections are fast enough these days to make the performance difference a moot point. People will choose to use what they are used to, rather than nit-picking over microseconds. Such a project would suck a lot of resources from the community and I don't think its worth it. Furthermore, I highly doubt such a project even would get to be as good or better than Firefox.
All that said, we are talking about open source. People contribute because they are interested and inspired by what they are doing. There are things other than a web browser that I think would be more useful to Haiku, but its not like we can just say "cancel the browswer project and put those developers on xxx project". If people in the community want to code a browser, thats what they're going to do. Personally, however, if such a project ever gets off the ground, I will choose to make my contributions elsewhere. My interest lies in seeing Haiku become a robust platform that can someday be a serious competitor in the OS world.
But, even if such a project did come to fruition, and achieved complete standards compliance with javascript and some plugin support, I have a feeling lots of new users would end up using firefox, just cause there's a good chance they were using it on whatever platform they are migrating from.
I for one am mostly interested in Firefox and Thunderbird at this point - but that's because I use them and like them in my Windows environment.
When I use other people's machines - I suggest that they try them, and use them as opposed to Outlook Express and IE. It's a relatively easy sell for Windows users - because the switch is fairly effortless and they can always switch back if they don't like it.
Asking people to try a new OS isn't nearly as easy, but once you get them hooked on Firefox, Thunderbird, and OpenOffice (yeah, i know) -- then they have very little reason NOT to try an alternative OS as long as it supports these "big three" (my opinion). They know what to expect from the apps because they should have the same functionality from platform to platform.
Cross-platform software is a bridge, not just a "hack". It helps users to be comfortable in different OS environments... Once they've made the switch, then SURE, they'll try out a native browser and appreciate it's elegance and speed, but it's less likely that they'll ever reach that point without a cross-platform choice to use as a bridge.
Cross-platform software is a bridge, not just a "hack". It helps users to be comfortable in different OS environments... Once they've made the switch, then SURE, they'll try out a native browser and appreciate it's elegance and speed, but it's less likely that they'll ever reach that point without a cross-platform choice to use as a bridge.
Agreed. Certainly I hope the BeZilla team keeps up its good work for this reason, regardless of what other projects may crop up. As for OpenOffice.org, hopefully yT will be helpful and contribute some of their work back to the community so that that will be possible along with R2 (since it won't be possible at all while we're still using 2.95, right?).
Agreed. Certainly I hope the BeZilla team keeps up its good work for this reason, regardless of what other projects may crop up. As for OpenOffice.org, hopefully yT will be helpful and contribute some of their work back to the community so that that will be possible along with R2 (since it won't be possible at all while we're still using 2.95, right?).
I'm probably completely mistaken here but I'm not sure the compiler version is the limitation... newer versions of GCC can be used on BeOS/Haiku - it just doesn't generate binary-compatible C++ object code.
Oh, ok. Makes sense; OOo is a very big complex piece of software. There are probably lots of other problems that prevent it from running at the moment.
hello, i'm new to the forum and i'd like to present my project/ideas. I'm a big fan of BeOS from years but i've always tried to use it as often as possible but something has always forced me to return using Windows: more "matured" software, updated drivers, and so on. Now that BeOS is no more i've hope to see something (good) happening with Haiku: a good desktop OS. I see also Zeta as a way to push commercial software (maybe also games, drivers and so on) into our system but i can sadly notice that the core software (browser, email client, etc) is too slow developed. low level things (work on haiku kernel, servers, drivers, etc) are active but what people see and use, the software are stuck.
My idea is to have a good system to use, and a good system is a well integrated enviroment with this and that software that is fast, logically integrated from an application to another, and so on. BeOS is all this and i want that this can continue and improve.
It would be nice to create something from scratch but the lack of developers is something to not hide and to think about. My idea is to use existing resources from other "worlds", adapt to our system and build around it a BeOS interface. Successfull examples of this logic are the use of GCC, CUPS, SANE.
Talking about browsers, we have Firefox and is a great piece of software, but it's slow and generally not integrated and developed to fit perfectly into the OS. I don't want to say is bad, but is a third party software. Probably it can be improved by the bezilla team but i feel we need also something more native.
So i've said to myself "I want to contribute" and i've started to analyze how to create a new browser. I've come to this strong points to follow:
- the interface must be simple, uniform and powerful, starting to the Net Positive one and taking ideas from other browsers.- the browser can be used integrated in another application (reusability)- the interface must be customizable by plug-ins that add new functionalities (the target is something like Firefox but skinnability is something to make in the OS, not the browser in our case)- MIME types must logically be used in the browser. you download an mp3 and you can listen in the browser itself if you want. you have a quicktime file and you see in the frame of the web page.- the rendering engine must be pluggable to the browser. The interface is always the same but the user can use and/or develop a plug-in to view pages. The rendering plug-in must respect a certain browser API to work. We could have a KHTML rendering engine, a Gecko one or, not so ironically, a commercial Opera one. This idea is similar to the last Netscape that can use the Mozilla or IE engine, but the Haiku one will be opensource- the default/first rendering plug-in must be easy to mantain and develop. To have this we need to use an opensource engine already functional. I will append a note to this point below.- integration with BeOS must be accomplished. Things like drag-drop of links, send of mails, etc.- Last but not least, the APIs have to be clean and easy to use, specially for integration of the browsering in other applications.
Here is the simplified diagram of the browser structure:
Actually i'm studying how to compile the KHTML code with as less as possible modifications of the original code. My preference to this library is because i think that it could be easier to maintain a C++ source more than WebCore (that is also in Objective-C). Gecko in the other way is huge and need much more experience to handle it, so maybe a Gecko renderer will be created later. Returning on KHTML, I'd like to create a wrapper of the QT calls made in the sources, not a full QT port, so if future patches of the engine can be integrated without comparing all the code and so on.
While working on this i'll write the browser API (things like "load page of the file x") fitting the page frame in a initial browser interface. After that i'll work on networking for loading pages over internet and their chaching/history. After this i'll upgrade more the interface and build the 2 managers (the renderer and plug-in ones).
I've not much experience in OS programming so i cant much help developing Haiku kernel or the servers, but i'd be pleased to use my knowledge for making new software for this system. I hope people can help me on KHTML to speed up the process, if we can encapsulate well the thing we can be half the way :wink: Contact me and we can organize better the work. After Christmas i'll have 2 weeks to work freely on it :)
What do you think of the project? Any suggestions? I'll post another thread to have ideas from you (for the interface)
Bye
Elvencode, drop me a note at gyoder at stny dot rr dot com. Ever since the last WalterCon, I've been meaning to work on getting KHTML to build by implementing the minimum amount of Qt that it uses. We should coordinate on it and divide up the work.
No change was required to build libpcre.a. To build kjs, aka
libJavaScriptCore.so, small changes were required.
Some #ifdef __BEOS__ #include <missing headers> #endif here and there,
and a BeOS thread specific implementation of
Interpreter class locking feature in internal.cpp and it *seems* to
works.
I've not yet run the newest JavaScript tests on it, just the very
simple test.js file that was already there in the 96 version.
That's something that should be done, obvioulsy.
I've also a small issue with an assert in Collector::allocate() which
fail in kjstest bin app because they allocate a Global object *before*
they instanciate the Interpreter object (who need this global object),
so the Interpreter lock count is zero at this time.
I commented out this (new in 125 version) assert for the moment.
Two more pieces of info that may be useful for your enterprise:
"WebCore can render D/X/HTML code using a thin QT=>Native wrapper. YellowTab has ported all the Konqueror code in WebCore, and a part of the QT wrapper code. The left over pieces shouldn't be an amazing amount of work to finish, just needs some time."
hello, i'm new to the forum and i'd like to present my project/ideas. I'm a big fan of BeOS from years but i've always tried to use it as often as possible but something has always forced me to return using Windows....
hi, i've been doing that too. the reason is zeta doesn't have the tools i need. most applications are small and useless. in zeta there is no opensource nor commerical software but only to unupdated leftover from beos.
i think porting opensource software to haiku and finishing haiku is high priority.
Comments
Haiku Web Browser
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
Haiku Web Browser
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?
Haiku Web Browser
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.
Haiku Web Browser
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.
Haiku Web Browser
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.
Haiku Web Browser
I will need to investigate further!
Haiku Web Browser
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.)
Haiku Web Browser
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
Haiku Web Browser
There will be possibilities for embedding with Gecko too. Be sure of it.
Haiku Web Browser
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... :?
Haiku Web Browser
Sounds like it'd just be easy to write from scratch, with KJS etc?
Haiku Web Browser
Nope.
Unless by easy you mean employing a team of people full-time for a couple of years...
Haiku Web Browser
http://themis.sourceforge.net/faq.php?id=12
It's not dead, but nobody is working on it... :?
Haiku Web Browser
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...
Haiku Web Browser
Considering I'd be shocked also, you can have one of mine... dodgy blue chav-esque Nike okay?
Haiku Web Browser
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.
Haiku Web Browser
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
Haiku Web Browser
I do agree, Microsoft is a pain in the Neck :-P. A 100% Microsoft-Compliant Web Browser is impossible, IMHO.
Haiku Web Browser
I didn't mean ActiveX, etc - I meant their 1997 era, almost globally accepted but not W3C ratified extensions to HTML.
Haiku Web Browser
if themis is halfway clean written then we should add it to the haiku-tree to get it further developed, i think.
it is mit-licensed and a native beos app; it would be the perfect net+-substitute...
Haiku Web Browser
If the developers were available, they'd be just as able to contribute code to it outside the Haiku repo...
Haiku Web Browser
ah.. ok.
i just thoght it could get more attention this way... and net+ was also part of the system itself...
Haiku Web Browser
Skoe, if you're serious about making a native webbrowser for R5/Haiku,
then i strongly suggest working with the BeZilla team to get embedding working properly.
http://www.livejournal.com/community/bezilla/
An HTML engine is a serious chunk of code.
For at least the next few years, the BeOS/Haiku community simply cannot compete with Mozilla's community in terms of development, userbase, etc.
It'll also allow more time to be devoted to the actual GUI.
Haiku Web Browser
And reading up on XULRunner might be a good start:
http://developer.mozilla.org/en/docs/XULRunner
My experience
Back around May and June of this year, I was giving a serious look into what would be involved in having a native web browser for BeOS. I would first like to say that the BeZilla team has done an amazing job. The Firefox / Mozilla source tree is IMO uglier than any horror movie I've ever seen, so getting anything like that to work is short of miraculous. I can live with the bugs in the official 1.5 release from a little while ago because I know how hard it is. Many efforts at embedding the Gecko rendering engine have been made over the years, but none of them ever worked the way they should have.
My opinion is to go the OS X / Syllable route and port KHTML. There is AFAICT less overhead than with the XPCOM technology that Mozilla is based on. To be blunt, a good browser is hard. Period. It is a project on the size of Haiku itself.
If there is anyone out there who does not have much experience with coding for BeOS, but has plenty of experience working with Qt, that person should seriously look into working on porting the browser. Doing the port would be helpful in learning the API and be an immense boon to the community. I just wish there were takers. As tight-fisted as I am with my money (for lack of it), I certainly would pay good money even for a good commercial version.
Haiku Web Browser
Ok, before I got heavily involved with Mozilla I wanted to work on KHTML, and just as Darkwyrm says, it's elegant.
Unfortunatly build-system configuration is something I hate, so I joined Mozilla and learnt how to get things done there. As the interest for Webcore seems to increase it might be time to try and wake up a project that has been slumbering: Nirvana. I've already talked to some people about it recently and it would be good if a joint effort could be made.
Here is the google-group: http://groups.google.com/group/nirvana-browser?lnk=li
Here is the Berlios page: http://developer.berlios.de/projects/nirvana/
Also I don't know if Darkwyrm was talking about embedding Gecko under BeOS or in general, but the main reason embedding under BeOS doesn't work is in the widget-code for BeOS. It starts the message-looper for handling Mozilla messages in a nsAppShell->Run. In embedding that function is never called. A long time ago I actually had a half-running embedding app upp, although it didn't render correctly. I havn't had time to work on that as priority has been on Firefox and Seamonkey. I don't see any major problems in the way of getting embedding working except some time and effort.
Haiku Web Browser
Hi,
I think people would use Firefox anyway. It's not really about the best program/os ever but what people like.
I bet if IE was available for BeOS people would use it :D
Offtopic:
What the hell is with all K's and Be's or B's in KDesktop or BeOS? Like KHTML.
Haiku Web Browser
I think not. The idea of a truely native webbrowser for Haiku seems good to me, but the problem would be to code a proper render. Not impossible but it requires something different. Leave Gecko and KHTML and all those behind, and go another way. Look at the really small OS'es, like AmigaOS4 and other such modern OS'es with extremely small system resource usage. Get inspiration from them, rather than the large bloated systems used by the majority. Look at FoxIt PDFreader, to see how a PDF-reader is done properly. A browser should have pretty much the same size, extensions not accounted for.
Well, it's just like all the apples on Apple and all the MS'es on Windows and so on. Call it lack of creativity :wink:
Haiku Web Browser
Please don't feel offended.
Why yet another browser project that will never finish? I know it's very intriguing to write a browser, but we should keep in mind that there are not enough developers for such a project. We should concentrate on things that really improve the user-experience.
And I think that people *do* use the best application. Firefox is cool because it's easy to use and configure. If it were a little bit faster I would love it. At university we use Linux and we have five or six browsers and I got crazy when I had to find Konqueror's option to disable auto-saving password. Well, I gave up because I could not find it within five seconds. In Firefox I just open the preferences dialog and immediately see where to find these settings. Also, after a clean install I only change the default website, disable password and form completion, and maybe (at university) set the cache size down. That's it! Look at the settings in IE. It takes half an hour to configure IE after a Windows reinstall just to make it comfortable to use. Why? Because I have to re-read all possible settings to remember which of them I normally change.
If KHTML is faster then we should make it our native HTML framework and create a browser around it. But make the browser as easy or even easier to use than Firefox.
Please don't spend the time on writing a new engine. We need serious software. Otherwise nobody will use it because it does not display all pages correctly or because it's incomplete.
But we also need native QT and GTK ports. And Haiku must be finished. Then, we need drivers (Intel integrated graphics cards, for example). An office suite (yT is already porting OpenOffice which isn't BeOS-ish enough, later we need at least Abiword + gnumeric + some presenter). We also need Java (when will the port be finished?). Please take a look at our wiki:
http://www.haiku-os.org/wiki/index.php?title=Software_Wishlist
Here you will find enough projects. For example, you could work on the Haiku media player to do the things listed on the wiki page. I would love to have TrueCrypt ported to Haiku some day (after the high-priority tasks are finished). An NTFS driver would be cool. There are so many things that would improve our productivity and the user experience much more than a new browser project. BeOS had too many of those just-for-fun projects that vanished as quickly as Be Inc.
Haiku Web Browser
OFFTOPIC, again (last time!):
@wkornew
I would add to your list the following:
- an audio editor audacity?
- a 3d modelling/rendering - blender (very GOOD!!!)
Instead of gimp i would try improving GimpShop which is Gimp that looks like Photoshop (it's still beta i think).
p7zip is a 7zip port available in linux only as a shell command. Can do all that 7zip does but no gui. Can extract tar, gzip, bzip2, zip, rpm? (and a couple more) and of course 7z. This could replace all other commands like tar -xvf ... or gunzip... A native Haiku gui frontend for p7zip would be nice for example :D
openoffice.org 2 is very good! i never used abiword. but openoffice has all i ever need. i never ever ever had the feeling a feature was missing. even has a database engine (a la access). but needs java i think.
Haiku Web Browser
Audacity is HORRIBLE
The Old "SampleStudio" source code is opensource, however, Xentronix are being quite forceful on the trademarks policy. Its a native BeOS app, a quick renaming would make it a decent audio editor. Audacity is not a decent audio editor.
No point in using p7zip for anything but 7zip, as removing other commands === destroy shell scripts, destroy portable software, destroy build systems, etc, etc.
Haiku Web Browser
No, it's not. It's FANTASTIC! (That remark is about as intelligent as yours. You are too fast to shoot down ideas...)
Define decent audio editor and indecent. Instead of just spreading BS. Audacity handles many different audio formats, loads instantly and has an intuitive and simple, but efficient UI.
So apart from your hatred against any non-BeOS native application, what is it that is SO wrong about Audacity?
I agree with you on that one. However, I don't think we will need support for 7zip very much. Bzip2 is more important.
.....
And now for something completely different (C) Monty Python
When the amigans can handle a sort-of port of GTK then we can do the same. I really like their approach about a GTK->MUI translation layer, where the GTK-widgets are implemented by native widgets, with the GTK-code working as a sort of wrapper around the native widgetset. It gives applications a native look and feel which IMO is very important.
See for yourself:
http://www.amigasoft.net/misc/gtk/gtk2.jpg
http://sourceforge.net/project/screenshots.php?group_id=141931
And read more here:
http://www.amiga.org/modules/news/article.php?storyid=6535
---
Mr.Jones - the one and only ( I think :P )
Edited: Removed a screwed up url-tag
Haiku Web Browser
looking at how you people answer, i think each one of you has an unique perspective of what is useful to him/her. i don't mind audacity. myob hates it. Mr.Jones loves it i think other people don't care or use something diffrent.
rather than creating a new browser i think you people should fill wkornew's list using some form of voting, or polls, or talking trough on forums.
i'm neither against nor for creating a new browser based on gecko or khtml. but why make a new browser when firefox will do?
Haiku Web Browser
Audacities UI is directly out of a 1994-era childs drawing, its utterly disgusting and completely unusuable
Audio formats are the responsibility of the media kit, NOT an application.
wxWidgets is one thing thats "So" wrong about Audacity, its UI is the next thing thats wrong with, not using B* classes for media work is another, and so on. WRT media, non native apps just suck on BeOS.
bzip2 is already supported in BeOS and in Haiku. However, its not a suitable 'default format' as it doesn't do BeOS filesystem attributes, only zip does.
The way GTK+/GTK2 works makes it -extremely hard- to implement GTK widgets as anything other than drawing controls onto a portable canvas. GTK 2.8 makes this even harder. Don't expect that Amiga approach to be sustainable in the long run.
Haiku Web Browser
Not to be rude, but could we get back on topic. This was almost starting to be interesting. Start that up in a thread of it's own.
Haiku Web Browser
fanton said:
Simply because there is only so much that mozilla.org will allow the BeZilla team to commit to CVS.
For instance, if they wanted to add replicant functionality or some other BeOS-specific functionality to the gui, they'd be SOL.
Also, there are times when updates to the mozilla code for other platforms breaks or generally fouls up the BeOS port. Thus requiring the BeZilla team to spend unplanned time and effort to fix those bugs, instead of continuing progress.
IMVHO the initial investment of time and effort to get
1. a HTML rendering engine embeddable
2. a basic native browser utilizing #1
would eventually make up for itself in the flexibility granted to the developers working on the actual browser.
There'd be no need for all of the dancing through hoops and leaping across pits to get a patch that took 3minutes to code checked in.
take a look at http://www.livejournal.com/community/bezilla/ and check out how long the average bug exists before a patch is committed to the repository.
finally, there's numerous patches that can't be fixed due to dependencies outside of BeZilla's access.
Quite a few reasons....
Not to sound condescending (or to take shots at the BeZilla team), but there are quite a few reasons I can think of for BeOS to have its own browser. Speed, for example. Firefox is acceptable but nowhere near as fast as anything built for BeOS from the ground up. I imagine that if Net+ had the same features as Firefox does, it would still be faster. OS integration would be immensely easier, too.
Another reason is overhead. Firefox has its cross-platform goodness because the entire UI is written in whatever language/API it's called (IDL, I think) and that adds to overhead. IMO, it's akin to going through a big bureaucracy to get anything done. While the underlying technology the entire browser is based on would still be there, cutting down on the cross-platform code would increase speed and reduce overhead.
Like mmadia mentioned, features also come to mind. Wouldn't it be nice to have a browser which has built-in ad-blocking features? AFAIK there isn't a browser out there with that.
Fork it
I have mentioned this before to the Bezilla team, but what stops you from forking Firefox?
Re: Fork it
I had the same thought. Why not fork it? K-Meleon (for Windows) is a fork of Mozilla, and much quicker than Firefox and Mozilla.
Of course the fork can't use original icons and themes, nor the name, but who cares? BeOS like icons would be better, and if we should use non-BeOS like icons, it ought to be the Tango Project. But alas, they are not that BeOS-like. They look more like a blend of KDE and Gnome (and we don't want that).
I'm not even sure about using the Gecko engine, but it's easier than writing an engine from scratch, and a wiser choice than KHTML.
Haiku Web Browser
I look at it from the perspective of attracting users. Most of us here, people who are interested and involved with the Haiku community, will probably start using Haiku while R1 is even in the Beta stage. We may even attract some old BeOS users who have since moved on to an actively updated OS. At some point, however, it only makes sense that we should hope attract fresh users: people who perhaps have never even heard of or used BeOS.
To old/current BeOS users, and those of us involved in the community, a native web browser is cool project and a neat idea. And, there are even some advantages: slight performance gain and consistent OS wide look and feel. Such a project, as many have pointed out, is a monumental undertaking; it is the same order of magnitude as Haiku itself. But, even if such a project did come to fruition, and achieved complete standards compliance with javascript and some plugin support, I have a feeling lots of new users would end up using firefox, just cause there's a good chance they were using it on whatever platform they are migrating from.
A native browser is NOT going to attract new users. In fact, it is likely to be completely ignored by many of them, even if its just as good or better than the BeZilla port. Computers and connections are fast enough these days to make the performance difference a moot point. People will choose to use what they are used to, rather than nit-picking over microseconds. Such a project would suck a lot of resources from the community and I don't think its worth it. Furthermore, I highly doubt such a project even would get to be as good or better than Firefox.
All that said, we are talking about open source. People contribute because they are interested and inspired by what they are doing. There are things other than a web browser that I think would be more useful to Haiku, but its not like we can just say "cancel the browswer project and put those developers on xxx project". If people in the community want to code a browser, thats what they're going to do. Personally, however, if such a project ever gets off the ground, I will choose to make my contributions elsewhere. My interest lies in seeing Haiku become a robust platform that can someday be a serious competitor in the OS world.
Haiku Web Browser
I for one am mostly interested in Firefox and Thunderbird at this point - but that's because I use them and like them in my Windows environment.
When I use other people's machines - I suggest that they try them, and use them as opposed to Outlook Express and IE. It's a relatively easy sell for Windows users - because the switch is fairly effortless and they can always switch back if they don't like it.
Asking people to try a new OS isn't nearly as easy, but once you get them hooked on Firefox, Thunderbird, and OpenOffice (yeah, i know) -- then they have very little reason NOT to try an alternative OS as long as it supports these "big three" (my opinion). They know what to expect from the apps because they should have the same functionality from platform to platform.
Cross-platform software is a bridge, not just a "hack". It helps users to be comfortable in different OS environments... Once they've made the switch, then SURE, they'll try out a native browser and appreciate it's elegance and speed, but it's less likely that they'll ever reach that point without a cross-platform choice to use as a bridge.
Haiku Web Browser
Agreed. Certainly I hope the BeZilla team keeps up its good work for this reason, regardless of what other projects may crop up. As for OpenOffice.org, hopefully yT will be helpful and contribute some of their work back to the community so that that will be possible along with R2 (since it won't be possible at all while we're still using 2.95, right?).
Haiku Web Browser
I'm probably completely mistaken here but I'm not sure the compiler version is the limitation... newer versions of GCC can be used on BeOS/Haiku - it just doesn't generate binary-compatible C++ object code.
Haiku Web Browser
Oh, ok. Makes sense; OOo is a very big complex piece of software. There are probably lots of other problems that prevent it from running at the moment.
Haiku Web Browser
hello, i'm new to the forum and i'd like to present my project/ideas. I'm a big fan of BeOS from years but i've always tried to use it as often as possible but something has always forced me to return using Windows: more "matured" software, updated drivers, and so on. Now that BeOS is no more i've hope to see something (good) happening with Haiku: a good desktop OS. I see also Zeta as a way to push commercial software (maybe also games, drivers and so on) into our system but i can sadly notice that the core software (browser, email client, etc) is too slow developed. low level things (work on haiku kernel, servers, drivers, etc) are active but what people see and use, the software are stuck.
My idea is to have a good system to use, and a good system is a well integrated enviroment with this and that software that is fast, logically integrated from an application to another, and so on. BeOS is all this and i want that this can continue and improve.
It would be nice to create something from scratch but the lack of developers is something to not hide and to think about. My idea is to use existing resources from other "worlds", adapt to our system and build around it a BeOS interface. Successfull examples of this logic are the use of GCC, CUPS, SANE.
Talking about browsers, we have Firefox and is a great piece of software, but it's slow and generally not integrated and developed to fit perfectly into the OS. I don't want to say is bad, but is a third party software. Probably it can be improved by the bezilla team but i feel we need also something more native.
So i've said to myself "I want to contribute" and i've started to analyze how to create a new browser. I've come to this strong points to follow:
- the interface must be simple, uniform and powerful, starting to the Net Positive one and taking ideas from other browsers.
- the browser can be used integrated in another application (reusability)
- the interface must be customizable by plug-ins that add new functionalities (the target is something like Firefox but skinnability is something to make in the OS, not the browser in our case)
- MIME types must logically be used in the browser. you download an mp3 and you can listen in the browser itself if you want. you have a quicktime file and you see in the frame of the web page.
- the rendering engine must be pluggable to the browser. The interface is always the same but the user can use and/or develop a plug-in to view pages. The rendering plug-in must respect a certain browser API to work. We could have a KHTML rendering engine, a Gecko one or, not so ironically, a commercial Opera one. This idea is similar to the last Netscape that can use the Mozilla or IE engine, but the Haiku one will be opensource
- the default/first rendering plug-in must be easy to mantain and develop. To have this we need to use an opensource engine already functional. I will append a note to this point below.
- integration with BeOS must be accomplished. Things like drag-drop of links, send of mails, etc.
- Last but not least, the APIs have to be clean and easy to use, specially for integration of the browsering in other applications.
Here is the simplified diagram of the browser structure:
Actually i'm studying how to compile the KHTML code with as less as possible modifications of the original code. My preference to this library is because i think that it could be easier to maintain a C++ source more than WebCore (that is also in Objective-C). Gecko in the other way is huge and need much more experience to handle it, so maybe a Gecko renderer will be created later. Returning on KHTML, I'd like to create a wrapper of the QT calls made in the sources, not a full QT port, so if future patches of the engine can be integrated without comparing all the code and so on.
While working on this i'll write the browser API (things like "load page of the file x") fitting the page frame in a initial browser interface. After that i'll work on networking for loading pages over internet and their chaching/history. After this i'll upgrade more the interface and build the 2 managers (the renderer and plug-in ones).
I've not much experience in OS programming so i cant much help developing Haiku kernel or the servers, but i'd be pleased to use my knowledge for making new software for this system. I hope people can help me on KHTML to speed up the process, if we can encapsulate well the thing we can be half the way :wink: Contact me and we can organize better the work. After Christmas i'll have 2 weeks to work freely on it :)
What do you think of the project? Any suggestions? I'll post another thread to have ideas from you (for the interface)
Bye
Nice!
I'd say go for it. :)
Haiku Web Browser
Elvencode, drop me a note at gyoder at stny dot rr dot com. Ever since the last WalterCon, I've been meaning to work on getting KHTML to build by implementing the minimum amount of Qt that it uses. We should coordinate on it and divide up the work.
Haiku Web Browser
WebCore is partially written in ObjectiveC.
There's a GTK version of WebCore by Nokia, though i don't recall how far they progressed.
an email from Phillippe Houdoin (2004-apr)
Check out these links too,
http://nirvana.synrc.com/ (might be dead)
http://groups.google.com/group/nirvana-browser?lnk=li
Haiku Web Browser
Elvencode,
Two more pieces of info that may be useful for your enterprise:
"WebCore can render D/X/HTML code using a thin QT=>Native wrapper. YellowTab has ported all the Konqueror code in WebCore, and a part of the QT wrapper code. The left over pieces shouldn't be an amazing amount of work to finish, just needs some time."
See: http://www.yellowtab.com/news/article.php?id=45
"ABrowse is a web browser for the AtheOS/Syllable operating system. Like Apple's Safari web browser, it uses a port of the KHTML layout engine."
See: http://sourceforge.net/projects/syllable-net
Koki
Haiku Web Browser
hi, i've been doing that too. the reason is zeta doesn't have the tools i need. most applications are small and useless. in zeta there is no opensource nor commerical software but only to unupdated leftover from beos.
i think porting opensource software to haiku and finishing haiku is high priority.