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?
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.
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.
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.
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..
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:
2. Will you create a new engine or use an existing one?
2.1 [New Engine] Are there any existing projects that you could take a look at?
Assuming "use an existing one" here.
3. 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)
4. What engines are currently available (probably a bit dependant on license)? (Make a list, no discussion.)
5. What are the differences between the engines? (every engine on that list, no discussion.)
6. Which of those engines best fits the criteria listed in the initial brainstorm?
7. You have your engine.
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:
The fanaticism in this thread is starting to get weird...
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.
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.
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.
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.
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.]
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.
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..
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
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.
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.
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.
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. :)
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.
to be honest, i think mr Dirty Harry said it quite nice.
khtml sounds more beos-ish. and all i need is native svg support (you could replace icons with svg ones eventually using the khtml's svg), xml (system configuration files could become xml), xhtml, and html.
what do we need to port it? how would be go about porting it? we need to adapt it to server_app's function calls?
[edit]
oh ok now i remember.. khtml is using qt. so you have to port qt then to haiku first.
to be honest, i think mr Dirty Harry said it quite nice.
khtml sounds more beos-ish. and all i need is native svg support (you could replace icons with svg ones eventually using the khtml's svg), xml (system configuration files could become xml), xhtml, and html.
what do we need to port it? how would be go about porting it? we need to adapt it to server_app's function calls?
[edit]
oh ok now i remember.. khtml is using qt. so you have to port qt then to haiku first.
so by porting qt to beos would mean you could have gecko too..
That would make sites that don't work with khtml (gmail)...WHAT? khtml does not support gmail...i didnt know this.
I don't understand - are you suggesting using KHTML as an OS Shell? -- for decoding SVG - all you need is an SVG library - not a whole HTML renderer -- and even better, since the AGG is already available to the app_server, it already has built-in SVG support...
And what are you expecting KHTML to solve with it's XML parsing? There are XML libraries for that too...
I think using KHTML as a multi-purpose OS support library is extremely backwards... if you truly want something that is BeOS-style, you'll use all the OS components to process SVG and read XML -- not a ported browser engine.
i really wish theres one library and one only for svg, one for xml, one for blablabal. not 2, 15 or 1543 libraries depeding on where you need it. you could take app_server's svg and move it in the translator, and use that same svg library in khtml (replacing the one already there). or maybe not ;D
KHTML depends on externals for all image processing anyway. The modulard design IMO is a plus becuase it makes it easier to upgrade components that interoperate with other OS functions
i really wish theres one library and one only for svg, one for xml, one for blablabal. not 2, 15 or 1543 libraries depeding on where you need it. you could take app_server's svg and move it in the translator, and use that same svg library in khtml (replacing the one already there). or maybe not ;D
As mentioned by ar1000, almost all software uses libraries for modular functionality... This is essential for reusability - and having 2 libraries that do the same thing will happen as long as people have the free will to develop software... there will always be someone trying to do something better - or differently.
BeOS provides image rendering support through translators... this allows the OS to register a "library" that is specialized in translating a certain picture format... a true BeOS HTML renderer would use this mechanism for all graphics...
XML doesn't really represent anything specific - so I'm not sure I would understand what you would do with a KHTML's XML logic either...
Are you asking weather it would be more efficient to link SVG with HkWebView and then to the OS or interlink them all ââ¬â which is more efficient? I think that if we were to use SVG as the native graphics format (like PDF is for Mac) then it would run independently. I think that the question of reusability (ESPECIALLY of graphics libraries) has already been established ââ¬â out of both preference and as far as KHTML, necessity.
Regardless of which browser engine is selected, it should of course be adapted to use translators. When it comes to SVG, however, how well can that be handled by translators? Creating translators that render vector graphics is of course not a problem (ie. take a SVG file and covert it to a pixel buffer), but can they support vector graphics beyond that? Also, how much functionality is necessary for a browser? Is rendering enough?
...but the thing is someone has got to port qt and then khtml, and i dont think it will be me..end of discussion;D (well maybe a little bit more..) talk is cheap (which doesnt mean is bad). but someone has to do the "dirty" work in the end.
...but the thing is someone has got to port qt and then khtml, and i dont think it will be me..end of discussion;D (well maybe a little bit more..) talk is cheap (which doesnt mean is bad). but someone has to do the "dirty" work in the end.
One wouldn't have to port all of Qt. What Apple did with WebCore was create an adapter called KWQ, which implements what KHTML needs from Qt and wrapps it around native libraries. Hopefully this would be easier with Haiku because Apple had to go from C++ to Objective-C as well, at least with Haiku both "ends" of the adapter would be in the same language.
khtml sounds more beos-ish. and all i need is native svg support, xml, xhtml, and html.
what do we need to port it? how would be go about porting it? we need to adapt it to server_app's function calls?
:edit:
oh ok now i remember.. khtml is using qt. so you have to port qt then to haiku first.
Thank god iââ¬â¢ve avoided this thread for as long as itââ¬â¢s been going :roll:
If we did ââ¬Åportââ¬Â KHTML/WebCore to BeOS, wouldnââ¬â¢t we do the same as Apple has done, make it a native binding to our O/S?
Thanks to the modularity of khtml, we can avoid working on some sections (svg) while weââ¬â¢d get the core working. Any team working on this will probably want to create an xml-kit so that it can be used separately, that should keep nae-sayers happier.
The way I see browsers for BeOS/Haiku in the future:
Net++ (or whatever) - a fast, lean native browser, it comes with Haiku.
Opera - they will come back, and if soon enough, we might not even need Net++.
Firefox/Mozilla - its a great browser, slightly memory heavy, but it does an awful lot. Future apps will run from this platform (Nvu, etc) It isnt the beos-way, but its the nicest non-native means we have.
Right now we have Firefox.
Opera will require patience (fingers crossed).
Anyone unhappy with this should vote with their feet and get involved with Nirvana.
NetOptimist
Maybe you'll find some interest in this project. It's dead, but the source code is available and it could be a good base to start from, as a lot of things have already been done...
NetOptimist
Maybe you'll find some interest in this project. It's dead, but the source code is available and it could be a good base to start from, as a lot of things have already been done...
Nope. Been there, done that. NetOptimist and Themis are both native projects that haven't really gotten anywhere. I've heavily tinkered with NetOptimist and it would need to be pretty much rewritten in order to handle CSS/CSS2 and DOM. One of the things that takes so long with a browser is the rendering engine. That would be the reason that Apple went the route it did in order to develop Safari.
I was thinking...
what about Mariner project? It was abandoned by netscape as a layout engine faster than gecko...
or instead of using XUL; how about a project that uses native Be widgets; just like project Camino or K-Meleon (i cant remember if epiphany uses GTK widgets..)?
The native widgets for Mozilla was skipped a year ago or so because they didn't work well at the time. Of course many bugs has been fixed by then, and I'm amazed that it ran at all at that time.
Still if we want to do anything with Mozilla embedding it would be the first step. I think many people will see what really can be done with it when that is done. Firefox does 'a lot' of unnecessary things at startup (in a lightweight browser point of view). We can use interfaces to plugin our own download manager and such. Embedding it would mean that UI, menus and so forth would use Be Widgets, and just the page would be a BView handled by Mozilla's layout engine.
i want compile Themis under a PhospourOS, but there is problem with socket/sys/socket.h is missing or something ... i want test it, becouse i know thats is free ... under a MIT license .... very nice ... |i have sources from cvs|
I think xml should be ditched and changed to something which person can actually read themselves and parse by computer. XML is a real pain in the arse. This in whole web.
Hehheh. It'll happen very soon anyway. :lol: It is not that obvious xml is unreadable vaporware format.
I think xml should be ditched and changed to something which person can actually read themselves and parse by computer. XML is a real pain in the arse. This in whole web.
Hehheh. It'll happen very soon anyway. :lol: It is not that obvious xml is unreadable vaporware format.
No he's right actually, XML is a tad tough to read.... the thing is, XML is a human-readable format, but not a human-understandable format..
but its NOT gonna leave the web anytime....
Ok - well... here's the deal. XML is already MAJOR BLOAT to data storage... if it's not human-readable enough for the people who need to use it, then they should... write an XSLT to spit it out in a human-readable format!
The beauty of XML is that you can literally transform it to whatever format you need to show it in without modifying the actual storage.
What kind of readable format would you envision as a replacement? I think there's a confusion about what XML is designed for.. It's a markup language - it's a way of describing things in an abstract way... it's not a word processor.
I think there's a confusion about what XML is designed for.. It's a markup language - it's a way of describing things in an abstract way... it's not a word processor.
Ah, finally someone said it! :)
I chuckle when people talk about using XML for things like databases. XML is for describing data, not necessarily organizing, formatting, or storing that data... those jobs are out of its context.
I think there's a confusion about what XML is designed for.. It's a markup language - it's a way of describing things in an abstract way... it's not a word processor.
Ah, finally someone said it! :)
I chuckle when people talk about using XML for things like databases. XML is for describing data, not necessarily organizing, formatting, or storing that data... those jobs are out of its context.
I assume you're supporting my argument somewhat then ;)
You know that even html structures, organises and stores data? You're right thought, xml itself is not bad. It is ill-used. BADLY ill-used. And I could see many better alternatives for what xml is designed for.
Less those which could actually replace it in work contexts where it is used. (when counting the ill-uses)
For a long time structured data had been passed between systems in a lot of formats, none of which had universal acceptance and most of which weren't in the least bit human readable. This is one of the cases where making a choice, any choice, is better than just everyone muddling along doing their own thing.
XML is pretty good. Humans can read it well enough to understand and diagnose problems (unlike binary only formats); it can be streamed (unlike formats with catalogs); the preferred encoding (UTF-8) is single byte and so naturally endian-neutral, and it compresses well with the de facto standard (Deflate) text compression.
Because of the "eXtensible" feature you can avoid inventing a new format just to solve a problem which has already been solved in another domain. You can pick up things like SVG, or RDF/XML and drop them into your spreadsheeet XML format, or as is being done already, into your XML web pages.
Now, if human readability was the only constraint, maybe you wouldn't choose XML. It's much easier for me to understand RDF written as NTriples than as RDF/XML and easier in some ways to read long-hand BIFF than GOffice XML spreadsheeets. But human readability, though important, is not the only thing they were aiming for.
Anyway, back closer to the real topic of the thread: the Amigans are a lot further behind the curve on web browsers than BeOS. They've had a bounty funded Mozilla porting project going so slowly that it takes them weeks to write a report explaining how slowly they're going. Porting kHTML isn't such a bad idea, but don't expect to realise any benefits from it unless you have long term dedicated people as Bezilla does now.
http://www.rebol.net/article/0108.html
This is the article i comply to...
the thing is, xml tries to be "one code for all uses" cuz of this, its too bloated. The other reason - its abused...
@umccullough: its no better cuz its a presentation format >.< However i feel TeX more readable than DocBook... it can just be me though
I'd just like to chip in that if anyone is considering writing a native BeOS browser, they should look at Epiphany and to a lesser extent Camino for two excellent examples of how to design a functional yet usable interface for a web browser. I suppose they might also interesting in that they demonstrate two different ways in which to embed Mozilla in a native application.
Im not a coder, I think we should keep KHTML out of scene for now, cuz it will involve porting Qt toolkit and all... Gecko is cross platform on the other hand.
Epiphany i think would be easier to port, cuz it uses POSIX and GTK+, while Camino is intended for OS X thus uses cocoa widgets....
X --> Epiphany
OSX --> Camino
Win --> K-Meleon
Be --> :(
I was a tad "inspired" by Epiphany, Camino and opera and began sketching an interface to suit Be's look and feel, yet be functional and usable
Im not a coder, I think we should keep KHTML out of scene for now, cuz it will involve porting Qt toolkit and all... Gecko is cross platform on the other hand.
KHTML is not dependant on Qt. It is as much cross-platform as gecko, though khtml is leaner, meaner, faster and more structurized.
That's also why so many alternative OS:es has chosen khtml (Zeta - though never released, MacOS, SkyOS, Syllable, AmigaOS etc)
Im not a coder, I think we should keep KHTML out of scene for now, cuz it will involve porting Qt toolkit and all... Gecko is cross platform on the other hand.
KHTML is not dependant on Qt. It is as much cross-platform as gecko, though khtml is leaner, meaner, faster and more structurized.
That's also why so many alternative OS:es has chosen khtml (Zeta - though never released, MacOS, SkyOS, Syllable, AmigaOS etc)
Hmm... when i was reading an interview of that guy who made AtheOS (now syllable), he said he had to make a wrapper for the Qt toolkit to implement it on AtheOS...
Yes, KHTML uses Qt. Apple made an adapter which wrapps the necessary Qt parts to native Cocoa calls. The others probably did the same thing. I guess it should be easier in C++ than in Objective-C, the main language for OS X development.
ealm is correct in that KHTML is leaner and more structurized than Gecko, which were strong reasons for Apple's choice.
Comments
Haiku Web Browser
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.
Haiku Web Browser
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
Haiku Web Browser
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.
Haiku Web Browser
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..
Haiku Web Browser
The fanaticism in this thread is starting to get weird...
Haiku Web Browser
Agreed :?
Haiku Web Browser
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:
2. Will you create a new engine or use an existing one?
2.1 [New Engine] Are there any existing projects that you could take a look at?
Assuming "use an existing one" here.
3. 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)
4. What engines are currently available (probably a bit dependant on license)? (Make a list, no discussion.)
5. What are the differences between the engines? (every engine on that list, no discussion.)
6. Which of those engines best fits the criteria listed in the initial brainstorm?
7. You have your engine.
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.
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.
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.
Relativity
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?
Haiku Web Browser
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?
Haiku Web Browser
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.
Haiku Web Browser
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
http://developers.slashdot.org/comments.pl?sid=50694&threshold=4&comment...
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
http://en.wikipedia.org/wiki/Comparison_of_layout_engines
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
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28HTML%29
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
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28XML%29
and XHTML
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28XHTML%29
the comparison for XML is incomplete..but I think Gecko is more XHTML and XML compliant than khtml
CSS comparison (very indepth)
http://en.wikipedia.org/wiki/Comparison_of_layout_engines_%28CSS%29
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..
Haiku Web Browser
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)
Haiku Web Browser
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.
Haiku Web Browser
fanton,
Lists are good. :D
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.
Haiku Web Browser
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.
Haiku Web Browser
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.
Haiku Web Browser
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.
Haiku Web Browser
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
Haiku Web Browser
And yet, if Microsoft was motivated to produce IE for Haiku and thats not what the project decided on, it would be a waste.
how do we port khtml?
to be honest, i think mr Dirty Harry said it quite nice.
khtml sounds more beos-ish. and all i need is native svg support (you could replace icons with svg ones eventually using the khtml's svg), xml (system configuration files could become xml), xhtml, and html.
what do we need to port it? how would be go about porting it? we need to adapt it to server_app's function calls?
[edit]
oh ok now i remember.. khtml is using qt. so you have to port qt then to haiku first.
an interesting find
http://dot.kde.org/1094924433/
so by porting qt to beos would mean you could have gecko too..
That would make sites that don't work with khtml (gmail)...WHAT? khtml does not support gmail...i didnt know this.
Re: how do we port khtml?
I don't understand - are you suggesting using KHTML as an OS Shell? -- for decoding SVG - all you need is an SVG library - not a whole HTML renderer -- and even better, since the AGG is already available to the app_server, it already has built-in SVG support...
And what are you expecting KHTML to solve with it's XML parsing? There are XML libraries for that too...
I think using KHTML as a multi-purpose OS support library is extremely backwards... if you truly want something that is BeOS-style, you'll use all the OS components to process SVG and read XML -- not a ported browser engine.
Haiku Web Browser
i really wish theres one library and one only for svg, one for xml, one for blablabal. not 2, 15 or 1543 libraries depeding on where you need it. you could take app_server's svg and move it in the translator, and use that same svg library in khtml (replacing the one already there). or maybe not ;D
Haiku Web Browser
KHTML depends on externals for all image processing anyway. The modulard design IMO is a plus becuase it makes it easier to upgrade components that interoperate with other OS functions
Haiku Web Browser
As mentioned by ar1000, almost all software uses libraries for modular functionality... This is essential for reusability - and having 2 libraries that do the same thing will happen as long as people have the free will to develop software... there will always be someone trying to do something better - or differently.
BeOS provides image rendering support through translators... this allows the OS to register a "library" that is specialized in translating a certain picture format... a true BeOS HTML renderer would use this mechanism for all graphics...
XML doesn't really represent anything specific - so I'm not sure I would understand what you would do with a KHTML's XML logic either...
Haiku Web Browser
fanton,
Are you asking weather it would be more efficient to link SVG with HkWebView and then to the OS or interlink them all ââ¬â which is more efficient? I think that if we were to use SVG as the native graphics format (like PDF is for Mac) then it would run independently. I think that the question of reusability (ESPECIALLY of graphics libraries) has already been established ââ¬â out of both preference and as far as KHTML, necessity.
Haiku Web Browser
Regardless of which browser engine is selected, it should of course be adapted to use translators. When it comes to SVG, however, how well can that be handled by translators? Creating translators that render vector graphics is of course not a problem (ie. take a SVG file and covert it to a pixel buffer), but can they support vector graphics beyond that? Also, how much functionality is necessary for a browser? Is rendering enough?
Haiku Web Browser
...but the thing is someone has got to port qt and then khtml, and i dont think it will be me..end of discussion;D (well maybe a little bit more..) talk is cheap (which doesnt mean is bad). but someone has to do the "dirty" work in the end.
Haiku Web Browser
One wouldn't have to port all of Qt. What Apple did with WebCore was create an adapter called KWQ, which implements what KHTML needs from Qt and wrapps it around native libraries. Hopefully this would be easier with Haiku because Apple had to go from C++ to Objective-C as well, at least with Haiku both "ends" of the adapter would be in the same language.
Re: how do we port khtml?
Thank god iââ¬â¢ve avoided this thread for as long as itââ¬â¢s been going :roll:
If we did ââ¬Åportââ¬Â KHTML/WebCore to BeOS, wouldnââ¬â¢t we do the same as Apple has done, make it a native binding to our O/S?
Thanks to the modularity of khtml, we can avoid working on some sections (svg) while weââ¬â¢d get the core working. Any team working on this will probably want to create an xml-kit so that it can be used separately, that should keep nae-sayers happier.
The way I see browsers for BeOS/Haiku in the future:
Net++ (or whatever) - a fast, lean native browser, it comes with Haiku.
Opera - they will come back, and if soon enough, we might not even need Net++.
Firefox/Mozilla - its a great browser, slightly memory heavy, but it does an awful lot. Future apps will run from this platform (Nvu, etc) It isnt the beos-way, but its the nicest non-native means we have.
Right now we have Firefox.
Opera will require patience (fingers crossed).
Anyone unhappy with this should vote with their feet and get involved with Nirvana.
NetOptimist
NetOptimist
Maybe you'll find some interest in this project. It's dead, but the source code is available and it could be a good base to start from, as a lot of things have already been done...
Re: NetOptimist
Nope. Been there, done that. NetOptimist and Themis are both native projects that haven't really gotten anywhere. I've heavily tinkered with NetOptimist and it would need to be pretty much rewritten in order to handle CSS/CSS2 and DOM. One of the things that takes so long with a browser is the rendering engine. That would be the reason that Apple went the route it did in order to develop Safari.
Haiku Web Browser
I was thinking...
what about Mariner project? It was abandoned by netscape as a layout engine faster than gecko...
or instead of using XUL; how about a project that uses native Be widgets; just like project Camino or K-Meleon (i cant remember if epiphany uses GTK widgets..)?
Haiku Web Browser
The native widgets for Mozilla was skipped a year ago or so because they didn't work well at the time. Of course many bugs has been fixed by then, and I'm amazed that it ran at all at that time.
Still if we want to do anything with Mozilla embedding it would be the first step. I think many people will see what really can be done with it when that is done. Firefox does 'a lot' of unnecessary things at startup (in a lightweight browser point of view). We can use interfaces to plugin our own download manager and such. Embedding it would mean that UI, menus and so forth would use Be Widgets, and just the page would be a BView handled by Mozilla's layout engine.
problem with compilation a themis
i want compile Themis under a PhospourOS, but there is problem with socket/sys/socket.h is missing or something ... i want test it, becouse i know thats is free ... under a MIT license .... very nice ... |i have sources from cvs|
Haiku Web Browser
Amiga is going KTHML, and has listed a few good reasons here: http://awebwiki.naff.dk/index.php/AWeb_and_KHTML
Haiku Web Browser
KHTML? K + HTML :)
I think xml should be ditched and changed to something which person can actually read themselves and parse by computer. XML is a real pain in the arse. This in whole web.
Hehheh. It'll happen very soon anyway. :lol: It is not that obvious xml is unreadable vaporware format.
Haiku Web Browser
I hope you're kidding...
Haiku Web Browser
No he's right actually, XML is a tad tough to read.... the thing is, XML is a human-readable format, but not a human-understandable format..
but its NOT gonna leave the web anytime....
Haiku Web Browser
Ok - well... here's the deal. XML is already MAJOR BLOAT to data storage... if it's not human-readable enough for the people who need to use it, then they should... write an XSLT to spit it out in a human-readable format!
The beauty of XML is that you can literally transform it to whatever format you need to show it in without modifying the actual storage.
What kind of readable format would you envision as a replacement? I think there's a confusion about what XML is designed for.. It's a markup language - it's a way of describing things in an abstract way... it's not a word processor.
Update: Ever open an RTF file in a text editor?
Haiku Web Browser
Ah, finally someone said it! :)
I chuckle when people talk about using XML for things like databases. XML is for describing data, not necessarily organizing, formatting, or storing that data... those jobs are out of its context.
Haiku Web Browser
I assume you're supporting my argument somewhat then ;)
Haiku Web Browser
You know that even html structures, organises and stores data? You're right thought, xml itself is not bad. It is ill-used. BADLY ill-used. And I could see many better alternatives for what xml is designed for.
Less those which could actually replace it in work contexts where it is used. (when counting the ill-uses)
Haiku Web Browser
For a long time structured data had been passed between systems in a lot of formats, none of which had universal acceptance and most of which weren't in the least bit human readable. This is one of the cases where making a choice, any choice, is better than just everyone muddling along doing their own thing.
XML is pretty good. Humans can read it well enough to understand and diagnose problems (unlike binary only formats); it can be streamed (unlike formats with catalogs); the preferred encoding (UTF-8) is single byte and so naturally endian-neutral, and it compresses well with the de facto standard (Deflate) text compression.
Because of the "eXtensible" feature you can avoid inventing a new format just to solve a problem which has already been solved in another domain. You can pick up things like SVG, or RDF/XML and drop them into your spreadsheeet XML format, or as is being done already, into your XML web pages.
Now, if human readability was the only constraint, maybe you wouldn't choose XML. It's much easier for me to understand RDF written as NTriples than as RDF/XML and easier in some ways to read long-hand BIFF than GOffice XML spreadsheeets. But human readability, though important, is not the only thing they were aiming for.
Anyway, back closer to the real topic of the thread: the Amigans are a lot further behind the curve on web browsers than BeOS. They've had a bounty funded Mozilla porting project going so slowly that it takes them weeks to write a report explaining how slowly they're going. Porting kHTML isn't such a bad idea, but don't expect to realise any benefits from it unless you have long term dedicated people as Bezilla does now.
Haiku Web Browser
http://www.rebol.net/article/0108.html
This is the article i comply to...
the thing is, xml tries to be "one code for all uses" cuz of this, its too bloated. The other reason - its abused...
@umccullough: its no better cuz its a presentation format >.< However i feel TeX more readable than DocBook... it can just be me though
Haiku Web Browser
I'd just like to chip in that if anyone is considering writing a native BeOS browser, they should look at Epiphany and to a lesser extent Camino for two excellent examples of how to design a functional yet usable interface for a web browser. I suppose they might also interesting in that they demonstrate two different ways in which to embed Mozilla in a native application.
Haiku Web Browser
Im not a coder, I think we should keep KHTML out of scene for now, cuz it will involve porting Qt toolkit and all... Gecko is cross platform on the other hand.
Epiphany i think would be easier to port, cuz it uses POSIX and GTK+, while Camino is intended for OS X thus uses cocoa widgets....
X --> Epiphany
OSX --> Camino
Win --> K-Meleon
Be --> :(
I was a tad "inspired" by Epiphany, Camino and opera and began sketching an interface to suit Be's look and feel, yet be functional and usable
Haiku Web Browser
KHTML is not dependant on Qt. It is as much cross-platform as gecko, though khtml is leaner, meaner, faster and more structurized.
That's also why so many alternative OS:es has chosen khtml (Zeta - though never released, MacOS, SkyOS, Syllable, AmigaOS etc)
Haiku Web Browser
SkyOS ships with Firefox.
Haiku Web Browser
Hmm... when i was reading an interview of that guy who made AtheOS (now syllable), he said he had to make a wrapper for the Qt toolkit to implement it on AtheOS...
Haiku Web Browser
Yes, KHTML uses Qt. Apple made an adapter which wrapps the necessary Qt parts to native Cocoa calls. The others probably did the same thing. I guess it should be easier in C++ than in Objective-C, the main language for OS X development.
ealm is correct in that KHTML is leaner and more structurized than Gecko, which were strong reasons for Apple's choice.