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.
an interesting find
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.
