Firefox is nice.
We can still approve a lot of aspects of Firefox under BeOS. Given more time we could make it or SeaMonkey very BeOS like. So maybe all we need are more SeaMonkey/Firefox devs. 
Firefox is nice. Its rendering engine is nice. But the questions is what is better, faster, more standards-compliant and lightweight. While some of those are subjective of course, others objectivly point to KHTML. Overall, KHTML isnât mixed into firefox, it is a more browser-independant engine and there wonât be the influence of external (firefox) elements on the creation of HkHtmlView or the Haiku Browser (Quest is my idea name-wise). The engine is external, but I think (just as others do) that we should create our own browser.
so in conclusion Ă¢ââÂÂĂÂĂ go khtml.
fanton wrote:
i do not want PERFECT SOFTWARE, i want MY SOFTWARE!!! stupidness is good. stupidness means youre learning. i want the freedom to choose my own crappy software...
Itâs âstupidityâ.
Youâre free to use Firefox and all the other Mozilla tools if you want. Youâre free to run OpenOffice in an X11 environment if you want to. Port Mac-on-Linux and run Pages for all I care. Iâm just saying that I intensely dislike Firefox on Be, itâs like a 100â concrete slab in the middle of a forest.
Reading your posts on that other thread, I begin to wonder why youâre interested in Haiku to begin with.
-Paws
Exactly right noicetonepause.
fanton, Install âcrappy softwareâ if you will, but donât force other users to. The end-user is more important than a power-user becuase ultimatly, the power-user can do whatever they want. They could install complex textmode apps or âcrappyâ bloatware. It doesnât make a difference in the scheme of things - nothing prevents someone from making and installing âcrappy softwareâ, but I think that most people attracted to Haiku would be less resceptive to that.
noisetonepause wrote:
fanton wrote:i do not want PERFECT SOFTWARE, i want MY SOFTWARE!!! stupidness is good. stupidness means youre learning. i want the freedom to choose my own crappy software...Itâs âstupidityâ.
Youâre free to use Firefox and all the other Mozilla tools if you want. Youâre free to run OpenOffice in an X11 environment if you want to. Port Mac-on-Linux and run Pages for all I care. Iâm just saying that I intensely dislike Firefox on Be, itâs like a 100â concrete slab in the middle of a forest.
Reading your posts on that other thread, I begin to wonder why youâre interested in Haiku to begin with.
-Paws
LOL. youre way over the line mr. you can just shove off people just because you disagreeâŚill prefer to stick around thank you very much.
well I do like haiku, I just donât like the Be spirit. i very much like the people behind haikuâŚ
The fanaticism in this thread is starting to get weirdâŚ
Agreed :?
To be frank, I see (in this thread and in a lot of other threads) people trying to push things onto other people.
Firefox is already available on BeOS. If you want Firefox and are happy using Firefox, and will continue to use Firefox in the event of a native browser being developed, well, why would you contribute to this discussion?
In any event, to help get this back on track, thereâs some questions we can ask to streamline this a bit:
- 1. Is there going to be a native browser developed? (Expressions of interest from potential developers could probably solve this one.) Assuming yes:
- Will you create a new engine or use an existing one?
-
What does Haiku want in an engine? (Brainstorm, ie speed and standards. Rate from 1 to $x, add the group score. Keep the top $n, chuck the rest)
-
What engines are currently available (probably a bit dependant on license)? (Make a list, no discussion.)
-
What are the differences between the engines? (every engine on that list, no discussion.)
-
Which of those engines best fits the criteria listed in the initial brainstorm?
-
You have your engine.
- 2.1 [New Engine] Are there any existing projects that you could take a look at?
I didnât go down the "create new engine" branch, because BBCode is bad enough. If I missed anything in the "native browser app" branch, add it in.
Quote:
Darn straight. The list approach is clinical, very clinical. It throws out the need to be passionate, the need to defend a piece of software. Everybody votes. You can even vote on the $n number of features to keep out of the $x produced. In the end, code is written.
The fanaticism in this thread is starting to get weird...
Weâve all seen projects spiral into talk and not much elseâŚ
SLAP! Wakey, wakey, hands off snakey. Time to look at number one on that list. If thereâs no solid EOI, you might as well leave the topic alone for a while.
fanton wrote:
well I do like haiku, I just don't like the Be spirit. i very much like the people behind haiku..
Then what is it that you like about it Ă¢ââ the ui? Haiku without the Be spirit is essentially just a customized distro of unix. Nearly every (if not every) function of Haiku/BeOS is duplicatable with other solutions on other *nix platforms. If you donât like the spirit of the project then why not stick with a theme for your favorite WM? I just donât see the point. You cannot deny what Haiku is, has been, and want to be.
togs, the pricipal problem with your proposal is those terrible qualifies that we, as human beings with subjective language, are bound to. What does Haiku want?
Ok Ă¢ââ I cannot post my whole post, it cuts me off every time I try to edit at âWhat does Haiku wantâ. I click submit and it submits, but cuts it off!
so here is the rest of the above post. . . .
What meets those standards? What is fastest, how do you score it? How do you define âavailableâ? Define differences. Define similarities. What is âbest fitsâ. Clinical works for 1+1, clinical works for d/dx of (2x+2)^(-.5), but clinical certainly does not work for subjective decisions. Pro/Con lists are great, the trouble is that everyoneâs is different. Hence the usefullness of a Forum (discussion board) especially for a project of collaboration such as this.
Telepathy would make this so much easier eh?
Telepathy would indeed. 
Not being a developer, I couldnât define the differences in the way you ask, or in the way that I meant. As a user, the differences would be easy to discount (rendering speed, for example) because we all have different machines with different specs.
This discussion (and the decisions that come from it) needs to be had by those writing (or planning to) the actual code. Once that discussion has taken place, a spec is written, and some goals have been created, then maybe a discussion could take place here.
As it is now I see nothing but outright put-downs, rabid fanaticism, continual repetition, some wildly inaccurate statements and in the future a locked thread. This is not a discussion. This started out a discussion, but is becoming meaningless rather quickly.
If somebody turns up tomorrow with an 0.1 running on KHTML, then thatâs progress, and because of that progress, KHTML could well win by default.
Talk is cheap. Progress is priceless.
EDIT: Spelling.
Hi, im doing some research. The [square brackets] are my own comments about my findings.
Here is what KHTML supports
- HTML 4.01 [most important]
- CSS 1
- CSS 2.1 (with the exception of paged media)
- CSS 3 selectors and partially other selected features [not fully CSS3 compliantâŚbut not required yet]
- PNG, MNG, JPEG, GIF graphic formats
- DOM 1, 2 and partially 3
- ECMA-262/JavaScript 1.5 [NO IDEA!]
- Partial Scalable Vector Graphics support [very important]
Gecko
4.0
XML 1.0 [GOOD!!!]
XHTML 1.1 [GOOOD!!! as HTML will become oficially obsolete]
MathML [useful]
XForms (via an official extension)
SVG [FULLY?? THATS GOOD]
CSS Level 1 (partial support for CSS 2 and 3) [partial support for 2? NOT GOOD]
DOM Level 1 and 2 (partial support for DOM 3)
RDF
JavaScript 1.6
Gecko offers much more functionality. And I predict (maybe wrongly) that if the Firefox trend continues more and more developers will help out Mozilla. And eventually Gecko will surpass KHTML in ceratin areas. Its just a wild guessâŚ
Ok, it seems Netscape and AOL also use Gecko. So its perhaps more widespread.
from wikipedia:
âOne of the big initiatives in 1.9 will be an overhaul of the graphics infrastructure. Instead of using the platformsâ API, Cairo will be used for all graphics outputs. This will result in improved 2D graphics capabilities and, via Glitz, acceleration using 3D graphics hardware. It will also mean that there will be a single rendering pipeline for HTML/CSS, canvas and SVG, so that SVG effects can be applied to HTML content. Because of Cairo, it will also be possible to output the graphics as formats like PNG and PDF, e.g. âSave this page as a PDFâ.â [no idea how useful this is.]
a blogs
it seems most comparisons beween khtml and gecko end around 2003 ;D weirdâŚand it also seems that more browsers use gecko nowâŚexcept safari, ie and operaâŚ
theres this comparison between safari and camino. form what iâve read camino seems faster. Mac users can tell me that. if so then khtml doesnt make it that fast. khtml is probalby very easy to read.
also it seems gecko is a pig, hard to read, and is not fully css2 compliant. but it does have xml, xhtml, and javascript
gecko is full of featurs and more widely supported.
heres a comparison on wikipedia
NOTE that some people say wikipedia is crappy beacuse its not made by experts but by people like you and meâŚi beg to differ beacuse its made by lots of peopleâŚeach will correct the other oneâs mistakesâŚi think wikipedia is a very very good encyclopedia.
LOLâŚkhtml has never been ported to windowsâŚsucksâŚi know you ppl dont caare. i doâŚim not goign to use 5 browsers for 5 osesâŚbut i have firefox so ;D i duncherâŚ
html comparison
REMEMBER!!! a browser is a big diffrence from a kit/server. a browser should be able to support things like rss, xhtml, adobe/macromedia stuff, javascript, and all the cool stuff people use, AND SVG (this is my personal favourite. this is the free alternative to flash/shockwave)âŚand other super advanced features, plugins/extensions, tabs, etc, etcâŚa server will only output html pages or xml or blablablaâŚ
now back to the comparisonâŚi have no personal coding experience with eitherâŚi favour gecko because despite its problems (it seems to be less conforming to standars but more portable) it has been ported everywhere and has more featuresâŚpersonal favourite features are MathML (nobody likes it but me, very useful)âŚXML, and XHTMLâŚAND SVG!!! css is more for the developers than for meâŚi like building the plainest webpages for my own slef;p
XML comparison
and XHTML
the comparison for XML is incompleteâŚbut I think Gecko is more XHTML and XML compliant than khtml
CSS comparison (very indepth)
my personal choice is i donât know and i donât know. if you ppl whant to make an html/xml/css/xhtml/svg server, i say go with khtml?..
it looks like khtml does not have xml or xhtml supportâŚi think it does but not full xml/xhtml supportâŚim confusedâŚ
You know, I am just going to throw this out there.
But while looking into Open Darwin, I was reading about Webkit. Now as most people here know, Webkit (a fork of KHTML) is one half into Webcore. Now as it so happens, they (developers of Open Darwin, not completely those of Apple Computer Inc.) were concerned into porting Webkit to other platfoms. Of course Linux seem to come put since there was a build of Webcore into the GTK+, a project called GTK+Webcore. But isnât Haiku another platform?
Well, personally speaking it would be quite interesting to see if Webkit (be it used for a browser or something else completely) could be ported to another platform like Haiku⌠Considering that there is a likely to be differences towards Mac OS X, Open Darwin and Haiku, would porting WebKit (along with KJS, since it happenes that they didnât release JavaScriptCore, and anything else that would be needed) involve doing?
(And from what I head when it was releasted, this is not the straightest thing to complie⌠seems to be componiates missing. Canât really speak for the Nightlies now, that could have changed since then)
That Slashdot link, while a little old now, was a very nice read. Good find.
Has anyone found any more recent comparisons? A lot of the stuff I found is centered around Apple using KHTML as the engine for Safari, around '03, I think.
fanton,
Lists are good. 
Gecko has partial svg support. KHTML has full SVG support now I believe.
KHTML has better support for CSS then Gecko. But, gecko has xhtml. I tend to believe the oppisite as far as devleopment. Apple has recently taken an increased interest in the developement of WebCore and therefore of KHTML. Netscape, AOL, and Mozilla are âcloseâ and use the same technologies. The real indicator is if good browsers use it (things that AOL and Netscape arenât). Two excellent browsers: Firefox (gecko) and Safari (KHTML). So again, a tossup.
The popularity of one engine over another is misleading because of Firefox. People are often quick to bandwagon. "more widely supported" cannot be established but Gecko has more features yes. So again Ă¢ââ the distinctions between the two are very clouded. Interpretation of importance and features and then choosing a direction makes the whole process difficult. I think detailed discussion of what is important should precede what meets our definition of importance. How can we find something without knowing what to look for?
The following paragraph is a tangent
I havenât heard any fanaticism by anyone (and donât believe I am spewing any) or outright putdowns. Repetition is a normal characteristic of discussion and debate where people attempt to re-phrase and tweak their communications to reach others. Especially with a non-physical (audio-visual or in-person) discussion, communicating with a wide palette is key. âMeaninglessâ is relative, those who wish to continue should and those who find this thread of discussion meaningless should abandon it Ă¢ââ the digital realm holds no one hostage. The virtue of the web is that there is always more space to continue a discussion on a new thread, a new website, a chat protocol, or via e-mail, the web offers boundless communication.
You can discuss the merits of Gecko and KHTML until the cows come home, but the fact remains unless someoneâs prepared to put the work into making them a reality on Haiku, itâs all moot anyway.
Dirty Harry wrote:
You can discuss the merits of Gecko and KHTML until the cows come home, but the fact remains unless someone's prepared to put the work into making them a reality on Haiku, it's all moot anyway.
Again Ă¢ââ we need to know what we want first. There is no point in looking for something without knowing what it is. If someone magically ported IEâs (closed) back-end tomorrow it would be "progress" but not in any productive direction. If you donât know what you get want, you just get stuck with what is laying around.
ar1000 wrote:
Dirty Harry wrote:You can discuss the merits of Gecko and KHTML until the cows come home, but the fact remains unless someone's prepared to put the work into making them a reality on Haiku, it's all moot anyway.Again Ă¢ââ we need to know what we want first. There is no point in looking for something without knowing what it is. If someone magically ported IEâs (closed) back-end tomorrow it would be "progress" but not in any productive direction. If you donât know what you get want, you just get stuck with what is laying around.
What Iâm saying is that if a developer feels like she/heâs up to the task of porting KHTML and wants to do it, she/he will. You can want what you like and make a decision, but unless youâre going to do the work, then that decision isnât going to do a whole lot of good. A committee isnât going to produce KHTML for Haiku, a motivated individual will; if youâre that motivated individual, I wish you the best as it would be a great asset to the platform.
Whatâs talked about here may assist that person in making a decision about what to do. Itâs a bit like digging through a haystack for the needle, though. :?
I havenât had much time to find recent links comparing KHTML to Gecko. Perhaps tomorrow.
Cheers,
togs
Dirty Harry wrote:
ar1000 wrote:Dirty Harry wrote:You can discuss the merits of Gecko and KHTML until the cows come home, but the fact remains unless someone's prepared to put the work into making them a reality on Haiku, it's all moot anyway.Again Ă¢ââ we need to know what we want first. There is no point in looking for something without knowing what it is. If someone magically ported IEâs (closed) back-end tomorrow it would be "progress" but not in any productive direction. If you donât know what you get want, you just get stuck with what is laying around.
What Iâm saying is that if a developer feels like she/heâs up to the task of porting KHTML and wants to do it, she/he will. You can want what you like and make a decision, but unless youâre going to do the work, then that decision isnât going to do a whole lot of good. A committee isnât going to produce KHTML for Haiku, a motivated individual will; if youâre that motivated individual, I wish you the best as it would be a great asset to the platform.
And yet, if Microsoft was motivated to produce IE for Haiku and thats not what the project decided on, it would be a waste.