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?
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."
i've contacted YellowTab some months ago asking about that port but they didn't respond me. They didnt told me if they are using it or not, so my only alternative is doing it myself using porting ideas from other projects (like the Syllable and Webcore ones). Now with shadow we'll start to convert that code. It's the harder thing i think, more that the networking part.
fanton wrote:
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.
yes, i hope in few years to see Haiku (but also Zeta, if they'll create a good 2.0 version) as a valid alternative to Windows and Linux. Something that "just work good", where you can browse, listen to music or see videos, create office documents in a clean way. No slowness, no cryptic things to do to set software or the OS, etc.
But to have this we need to create it :wink:
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."
The first is from 2003 and has never been actioned upon, and came at the same time as ODBC and Java were being promised for R1, so don't rely on the port actually existing. Zeta has JavacriptCore in it, but as has been shown above, thats far easier to port. I'm not sure what, if anything, it uses it for right now though.
BTW for anyone that cares, i have been in the planning phase for building a simple Web Browser for the past 6 months. I was hoping to write an IRC Client before actually implementing the browser (To get to know the BeAPI more), and i still hope to do that.
My real problem is that none of my computers want to run BeOS :x.
Oh and i've take a look at KHTML, and it doesn't look too bad. I especially like the netscape idea of having multiple rendering/layout engines :wink:
Sorry, feel the need to add my opinion to the pot.
Best reason to develop a seperate web browser
mmadia wrote:
1. a HTML rendering engine embeddable
elvencode wrote:
- the browser can be used integrated in another application (reusability)
Since HTML is consistently used to develop help systems,
I would have to believe a reusable renderer to be very useful.
But at what point does this get overboard? Duplicating everything firefox does seems to be a waste of resources, especially when there are other needs that aren't being filled. The one thing that is really needed right now is a new Flash Player. Firefox and any other browser on BeOS is limited in use to me because of this.
I like the idea of a bhtmlview. It kind of follows into my idea of creating a translation type kit for file parsing and rendring. Having the parser as a system available resource would allow any app to use it for any need. Such as help systems, file reconition etc.. It would work just like the translation kit only with flat text formats, like html, pdf, doc, man pages, xml, etc... This way you could provide the traditional add-on hierarchy to rendering, parsing, even the tokenizer. Allowing for easy updates as changes happen to the standards and specs. Easing the compatibility woes of in app parsing and rendering. This type of system wide document reconition would fit well into the traditional spirit of Be that we want to keep alive "do it the Be way!"
One thing a few weeks of using Be has shown me is that we need a browser that's as good a Be citizen as Net+ but as capable as Firefox. I rate the web browser as probably the most important thing for an operating system these days and I don't think we should settle for Firefox when we could have something that was lighter and more Be like...
One thing a few weeks of using Be has shown me is that we need a browser that's as good a Be citizen as Net+ but as capable as Firefox. I rate the web browser as probably the most important thing for an operating system these days and I don't think we should settle for Firefox when we could have something that was lighter and more Be like...
In my opinion, the best solutions I've heard tossed around still are an embeddable HTML rendering view either based on KHTML or Gecko and a native wrapper app.
One thing a few weeks of using Be has shown me is that we need a browser that's as good a Be citizen as Net+ but as capable as Firefox. I rate the web browser as probably the most important thing for an operating system these days and I don't think we should settle for Firefox when we could have something that was lighter and more Be like...
In my opinion, the best solutions I've heard tossed around still are an embeddable HTML rendering view either based on KHTML or Gecko and a native wrapper app.
I Agree, however the way the renderer is embeded should be flexible enough to use KHTML AND* Gecko, and also anything else (Say, a native one if ever written).
* I don't mean dynamically changing, like netscape does with Gecko/IE. I mean being able to change it in the source code.
One thing a few weeks of using Be has shown me is that we need a browser that's as good a Be citizen as Net+ but as capable as Firefox. I rate the web browser as probably the most important thing for an operating system these days and I don't think we should settle for Firefox when we could have something that was lighter and more Be like...
In my opinion, the best solutions I've heard tossed around still are an embeddable HTML rendering view either based on KHTML or Gecko and a native wrapper app.
I Agree, however the way the renderer is embeded should be flexible enough to use KHTML AND* Gecko, and also anything else (Say, a native one if ever written).
* I don't mean dynamically changing, like netscape does with Gecko/IE. I mean being able to change it in the source code.
This should be part of a more generic Editor/Viewer API (text, images, etc.). For example, then you could embedd BeMail as a viewer in Tracker. Also add a tree view to the left and you have a full-blown email client. Well, not exactly, but with queries and grouping you would have something really cool...
In my opinion, the best solutions I've heard tossed around still are an embeddable HTML rendering view either based on KHTML or Gecko and a native wrapper app.
I Agree, however the way the renderer is embeded should be flexible enough to use KHTML AND* Gecko, and also anything else (Say, a native one if ever written).
* I don't mean dynamically changing, like netscape does with Gecko/IE. I mean being able to change it in the source code.
This should be part of a more generic Editor/Viewer API (text, images, etc.). For example, then you could embedd BeMail as a viewer in Tracker. Also add a tree view to the left and you have a full-blown email client. Well, not exactly, but with queries and grouping you would have something really cool...
If viewing apps like BeMail were to be embedable without changes, the mechanism would have to work without the app knowing it, so the browser wouldn't have to do anything special. It might be questionable how useful this approach is, though. You probably wouldn't want to embed the full app, but rather just a view of the mail content and headers.
For an API to embed parts of other apps wherever you like, we already have replicas. A browser view as a replica would be useful, but I'm not sure whether the replica code should be part of the browser app. With the suggested bhtmlview, one would have the most reusable component IMO, as this could be used by any app directly, and we could also have a tiny app that exposes the bhtmlview as a replica, perhaps with a simple right-click menu interface on top.
Skoe: I think a bhtmlview consisting of a minimalistic code base (wrapper code) on top of the engine would fit your requirement quite nicely. Hopefully the code would only include what one would have to rewrite for each engine anyway, so writing a new view exposing the same API would be a drop-in replacement for the default/first bhtmlview.
One thing a few weeks of using Be has shown me is that we need a browser that's as good a Be citizen as Net+ but as capable as Firefox. I rate the web browser as probably the most important thing for an operating system these days and I don't think we should settle for Firefox when we could have something that was lighter and more Be like...
In my opinion, the best solutions I've heard tossed around still are an embeddable HTML rendering view either based on KHTML or Gecko and a native wrapper app.
Indeed. There is little point to us writing our own rendering engine - that would go against the point of open source software, wouldn't it?
As for Gecko vs KHTML, all I can say is that I think Safari (KHTML) is better than Camino (Gecko) but that just be a case of implementation. I'm sure either is fine.
This should be part of a more generic Editor/Viewer API (text, images, etc.). For example, then you could embedd BeMail as a viewer in Tracker. Also add a tree view to the left and you have a full-blown email client. Well, not exactly, but with queries and grouping you would have something really cool...
I think in the case of BeMail - wouldn't it just be a text view, RTF view, or an HTML view combined with a MIME or UUENCODE decoder? I would think BeMail would be a consumer of these as well.
I think the idea of a native web viewing component (html/css/javascript/etc) would be the more Be like approch to the problem. Plus if it is implemented in the classic Be way (modeled after the translation kit) nothing stops people from using a ported Gecko or khtml on their system. I don't want to get into the "not built here" mentality I just feel that with the level of integration that the web and html has with modern desktops a home grown hierarchy is the way to go.
I think the idea of a native web viewing component (html/css/javascript/etc) would be the more Be like approch to the problem. Plus if it is implemented in the classic Be way (modeled after the translation kit) nothing stops people from using a ported Gecko or khtml on their system. I don't want to get into the "not built here" mentality I just feel that with the level of integration that the web and html has with modern desktops a home grown hierarchy is the way to go.
The browser would be original but, the idea of creating a whole new rendering engine and getting it up to the spec of compatability would 1) be a large undertaking and 2) create another engine to worry about in web development and compatability. KHTML is a strong engine with solid performance and compatability with standards. Building a native kit and getting it to pass acid2 would be challenging and is secondary to the construction of an OS. That is not to say that we should not have an equivilant of WebKit for integration - but I feel that it should be based on KHTML
KHTML is a strong engine with solid performance and compatability with standards.
I beg to differ. It isn't that swell, and is generally less compliant then Gecko.
ar1000 wrote:
and getting it to pass acid2 would be challenging
Last i checked, Opera/Firefox/IE/Konq/Mozilla/etc all failed the acid 2 test.
ar1000 wrote:
but I feel that it should be based on KHTML
So do i...For now. I think that for R2, a native layout engine should be more appropriate. One thats designed, and designed specifically for use with BeOS features and API.
I think its a nice idea to have html viewing/parsing capabilities built into the system. But i still think to use gecko because its more popular than khtml. Firefox market share is aroudn 10% (maybe more), which makes it good enough to use it despite how annoying it is..
i also DO NOT think that what the os provied is the only way for viewing htmls. people should still be able to install firefox ven if its slower and chunckier. i know i would, even if its lower, jsut for the hell of it!!;D
I think its a nice idea to have html viewing/parsing capabilities built into the system. But i still think to use gecko because its more popular than khtml. Firefox market share is aroudn 10% (maybe more), which makes it good enough to use it despite how annoying it is..
Windows is more popular to ââ¬â why don't we just use that. The challenge is to find the better web engine not the most popular, I think the better one is KHTML. It is streamlined and more standard compliant.
damnyou got a point;D.......kind of hard for me to combat your argument...gecko is not that bad frist of all..damn i cant fight it..probably it doesnt matter too much.......well in beos spirit i guess youre right.....hmm..ok do that
would it be part of translation or would be a kit all by itself? theres also xhtml, css/css2, xml that are very important.....so if khtml can do that...i know for xml you can use something else......then its all fine with me.....
im still going to install firefox though...cause im used to it...BUT i would try your kit anyway or broswer out of curiosty.....
[edit]popular software is good cause you get a lot of help for it.....the more its used the more youve got a change someone solved some problem already..and all you need to do is google...but theres a balance between a crappy popular piece of software and less popular (bit still known) good software..i would nevr go for ie's crappy rendering madness..NO WAY..
AHH! I actually have no idea how to develop this kit. I conceptually understand the process but I don't know a programming language yet. I want to learn Objective C though (because I wan't to develop a restaurant reservation program for Mac)
i have no idea either...thats why i talk so much...i know enough c++ objects to get me started and with enough pations can build a gui app in beos....i also know some networking at c level...but im no expert...
if you really want to you can do it...it will take you a long time...but its possible..........i think you can build it in objective c++...not shure but i think beos was build in c++, except the kernel...
coding is mostly about spending time to raed....NOT remembering function names....you need a good khtml refrence and api....a good undestaing how kits/servers work aare made...the midi/translation kits/servers are probably the easiest i think start looking at that....i have no idea...anyeay...some suggetions..i have no idea...i would like to helpbut im not very superconfigend and not much time...but i could do stuff...i know programming enough for me to like it ;p
and i still like gecko...reminds me of fallout 2 hehehe
Assuming that the Haiku browser will be implemented as a special BView, how will developers control it? I would assume that the basic BHtmlView would be created by passing a basic HTML page, in a really large string, to the constructor or similar. However, how would a developer pass externally linked files, like CSS stylesheets and Javascript snippets? For most things, it would probably be possible to just make a single file HTML, such as for help pages, but most Internet web pages aren't made like that.
So how would this BHtmlView be passed external files?
--Walter Huf--
Windows is more popular to ââ¬â why don't we just use that. The challenge is to find the better web engine not the most popular, I think the better one is KHTML. It is streamlined and more standard compliant.
Philosophically, I think it's a bad idea to challenge too many standards at once. As you point out, Windows is more popular -- which means that we are already breaking a standard, as it were, by doing something different. That's a tough enough hurdle all by itself. Any additional standard-breaking means that we're just piling more hurdles on top of each other.
Consider productivity suites, for example: I love Gobe Productive dearly, and it will always, always, always be my first choice of productivity software. I dearly hope that Gobe gets going again, or the source code is released, or some other Haiku-like group of coding gods decides to reverse-engineer the thing. It's just a beautiful program. I like it infinitely better than Microsoft Office, and vastly better than OpenOffice.
HOWEVER, it's also completley alien to most people, who are stuck with Microsoft office. Some of them, inexplicably, even like it. Now imagine that you're trying to convince one of them to use Haiku. Here's your pitch: "Hey, check out this fabulous new operating system: it'll feel kind of weird for a while, but once you get used to it, you'll find that it does everything faster and easier and better than Windows does."
You'll lose some people right away, and, well, those ones who are beyond help. But for the ones who remain, you've now got another pitch to make: "Oh, you'll have to also learn this new productivity suite, which is vastly better but also totally different than your old productivity suite. And as for all your old documents... well, most of them should... kinda... import..." That's a much bigger hurdle, and you'll lose most of the rest of them at that point. And that is Haiku's loss, not just Productive's.
This is why, even if I don't like OpenOffice very much, it is essential that it be ported over to Haiku. That way, your second pitch can be: "here's this Office Suite which is 100% compatible with all of your old documents, and has nearly the same interface and workflow and everything!" That's a much, much easier sales job. Of course Productive will still be around, and the ones who are smart can catch onto it later. Gotta fight your battles one at a time. I think in the above example, it's quite obvious why.
Now, when it comes to a HTML layout engine, it's a much more subtle thing, but this dynamic is still at work. I don't know anything about how it is to work with KHTML vs. Gecko on the backend of a system, so I can't address that issue. And I can say that, from the consumer's point of view, as long as they produce the same output, it doesn't really make that much of a difference. However, from the perspective of a web designer, I can say that KHTML makes me a little nervous, simply because I've never validated any of my pages against it. It isn't enough of a factor in the market to worry about. So that's one consideration. Particularly if we're aiming for Haiku to be accepted in a business environment -- and I think there's no reason not to aim that high -- it's very important that the business be assured that it is seeing exactly what everybody else is seeing.
Another consideration is: how many developers are used to working with Gecko? How many are used to working with KHTML? If one has a much larger number of developers, then that is the one that Haiku should almost certainly use. That gives us a larger base of programmers to recruit from. We can say: "hey, why don't you develop web applications for this cool new operating system? And look! You can use the same HTML layout engine that you always use! There's hardly anything new to learn!" See how that's a much easier argument to make?
Once Haiku has enough users and developers and overall momentum to start throwing some of it's own weight around, it'll be another matter. From the beginning, a program should request the particular HTML engine that it'll be using. If it becomes obvious that a home-grown HTML layout engine would be superior, that can be added on later. You can go ahead and break compatibility, because new and updated applications will have to request the native engine directly, while old applications still use the old engine. That's a little bit crufty, admittedly, but there's no reason why it needs to be that way for long. The great thing about free and open-source operating systems and software is that there is never a disincentive to upgrade, so (unlike, say, Windows) there's no need to keep kruft hanging around forever (except perhaps to support legacy hardware). After a Moore's generation, the older engine can thus be removed from the default Haiku installation.
All true ââ¬â but the fact remains that if Haiku is setting out to do something as ambitious as create an OS, it may as well use components that are as strong as possible. Gecko is more forgiving, but KHTML is more predictable and supports more standards. It is currently the only engine to correctly render (pass) the acid2 test. Haiku seeks future adoption and growth so it should use a rendering engine that 1) Is growing in popularity (yes. . it is) 2) Is the most standards compliant 3) Has a stable backing force (a strong community in KDE and a corporate development in Apple Computer). Gecko might take a month less work but in the end, the engine will be less impressive than KHTML. I can't force it to happen of course, but I would like to see Haiku develop a stable, well os-integrated fork of KHTML.
plus to be honest..i stil stick by my decision to use firefox. hehe..i never get tired of saying it. because 1. its already made, you don't have to redo it. 2. its made by smart people dedicated to only making browsers (these peopele know what their doing) and 3. its used by lots of people or enough for me to get help.
but on the other hand, its cool making a browser cause i learn how to program, learn how to build a browser..
the only reason im not using linux is beacuse i don't have photoshop. and the prices of macs scare me.
if you look closely linux is starting to copy windows interface. why? becuase its trying to steal people away from windows. haiku's advantage over linux is the gui! that's it. few tweaks and will look like xwindow/windows gui, which will corrupt people.
so my opinion is use whats already there, for now. and help out with the really important things for example server app, drivers.
1) Firefox is a bit shit
2) I don't think this community should hold any delusions of breaking the Windows monopoly over the next few years!
Since we're not really here to take over the world or make money, I say we focus on building the best damn desktop OS around instead of pandering to a potential user base by relying on the familiar second or third best (if it was possible to port MS Office and IE, should we?). The way I see it, making that OS involves making an incredible web browser that feels well integrated and usable. Firefox isn't and won't ever be because it has to be cross platform and support plug ins, themes and what not. I find I end up using Net+ 95% of the time because it doesn't feel like an app, it's a natural extension of the rest of the interface (like StyledEdit, BeMail and People are). I can close the last Net+ window and then remember that I needed to do something else and five seconds later I'll be back online looking at the page... but woe be unto him who closes the last Firefox tab! FF is a clunky beast of an app and far too hungry and complex for what a browser should do: display web pages.
Assuming that the Haiku browser will be implemented as a special BView, how will developers control it? I would assume that the basic BHtmlView would be created by passing a basic HTML page, in a really large string, to the constructor or similar. However, how would a developer pass externally linked files, like CSS stylesheets and Javascript snippets? For most things, it would probably be possible to just make a single file HTML, such as for help pages, but most Internet web pages aren't made like that.
So how would this BHtmlView be passed external files?
--Walter Huf--
Yay, a SANE POST.
I would have some sort of simple API, where the component is given a URL/Filename, or some sort of file handle. Then component then goes off and retrives/parses/rendered that file, and downloads all other required files into a cache - and similarly parsing/rendering them too when appropriately designated by the main file's parser.
One of my biggest goals is to write a Web Browser, and a layout engine is a huge step in the right direction. I have been planning (As in thinking about, and sketching some designs) of making one for almost 6 months (Give or take a bit).
My two biggest problems are procrastination and a lack of a Be OS. I am unable to compile Haiku (Or BeOS applications) on Windows or FreeBSD, and i am unable to run BeOS R5 on my main computer (With or without BONE). BeOS does run on my laptop, but it has no means of communication from the outside world - It's USB is busted, it has no supported ethernet (It has a PCMCIA Card, that i've never gotten to work), and it doesn't have a CD Burner. Also, i can't afford Zeta 1.1.
I am slowly trying to get Haiku to compile on FreeBSD (I've built the kernel, but the current problem is the kernel.so wont link).
But anyway, as soon as i can i will start to develop so sort of BWebView. (Not BHtmlView, which in my view is redundant since it's outdated and should be shunned upon).
1) Firefox is a bit crap
2) I don't think this community should hold any delusions of breaking the Windows monopoly over the next few years!
Since we're not really here to take over the world or make money, I say we focus on building the best darn desktop OS around instead of pandering to a potential user base by relying on the familiar second or third best (if it was possible to port MS Office and IE, should we?). The way I see it, making that OS involves making an incredible web browser that feels well integrated and usable. Firefox isn't and won't ever be because it has to be cross platform and support plug ins, themes and what not. I find I end up using Net+ 95% of the time because it doesn't feel like an app, it's a natural extension of the rest of the interface (like StyledEdit, BeMail and People are). I can close the last Net+ window and then remember that I needed to do something else and five seconds later I'll be back online looking at the page... but woe be unto him who closes the last Firefox tab! FF is a clunky beast of an app and far too hungry and complex for what a browser should do: display web pages.
Keep it elegant and keep it light is what I say.
-Paws
Keeping it elegant and light -- Is what i agree with. KHTML or a native layout engine is the way to go. Gecko isn't.
Oh and BTW: Haiku wont have that large a user base to start with, but it will grow many times faster then Linux or *BSD. People want an alternative to Windows they can trust -- Let's make one safe, elegant and easy to use desktop alternative.
Gecko can probably be light, it's just that the Mozilla/Firefox/Thunderbird apps arn't and the layout of the project makes it hard to see how to strip it down to the parts you want. I don't think an embedded version will be bad, although it will not be perfect either.
Skoe - I'm really talking more about implementation, as in how it presents itself to the user and works with rest of the desktop.
The case for KHTML/Gecko against a new engine is that we'd perpetually be playing catch up, and the case against Gecko for KHTML is apparently it's more insulated and thus easier to port. I wouldn't know where to start if I were to do this myself but this is something I feel strongly about and I hope that my programming skills soon progress to a level where I can do something useful.
The question is how difficult it would be to rip gecko out of firefox? It's not really 'meant' for that, is it? KHTML is apparently quite separate from Konqueror.
Gecko can probably be light, it's just that the Mozilla/Firefox/Thunderbird apps arn't and the layout of the project makes it hard to see how to strip it down to the parts you want. I don't think an embedded version will be bad, although it will not be perfect either.
Gecko by nature is heavier.
And in response to keep it light ââ¬âàKHTML is light but powerful, HkWebView could be powered by KHTML as easy as its own engine. I am ALL FOR INTEGRATION, but I think that KHTML as base is the lighest and most feature-complete wya to start (not in objective-c, as I think I may have introduced to to the topic in a tangent ââ¬â I want to learn it for my own reasons).
I totally aggree that Haiku will grow faster than linux ââ¬â it is not meant to be a poweruser os ââ¬â it is a user os that, like firefox, will have good features and show a better alternative to windows on the x86 platform.
The question is how difficult it would be to rip gecko out of firefox? It's not really 'meant' for that, is it? KHTML is apparently quite separate from Konqueror.
Keep in mind that Gecko has already been "ripped" out of Mozilla Suite in order to build FireFox...
I'm a linux user, and was having a lot of problems with Firefox crashing on pages using flash. So, I started using Opera on linux-- I love open source but i'm not a fanatic, if a closed source app will get the job done better then i'll use it, _especially_ if its also totally free.
Eventually I found a website that described the problems I was having, and offered a fix (editing some X.org file...don't really remember). Stability is much better now, but I still really like Opera and use it sometimes too (right now!). I know there was a BeOS version of Opera back in the day, and I also remember reading some statement by someone at Opera about how with BeOS dying, it was no longer worther keeping alive.
But, Opera seems to be fairly portable (supported on Windows, Linux, MacOS, Solaris, FreeBSD, and a host of mobile platforms), so how popular do you think Haiku has to get before we've got a chance of seeing Opera ported? Would the seemingly large number of Firefox haters out there use it over Firefox?
If Opera was availble, would it somewhat stifle the motivation for a native browser project (as in, is the motivation for such a project a genuine desire for a native browser, or just something that _isn't firefox_)
I'm a linux user, and was having a lot of problems with Firefox crashing on pages using flash. So, I started using Opera on linux-- I love open source but i'm not a fanatic, if a closed source app will get the job done better then i'll use it, _especially_ if its also totally free.
Eventually I found a website that described the problems I was having, and offered a fix (editing some X.org file...don't really remember). Stability is much better now, but I still really like Opera and use it sometimes too (right now!). I know there was a BeOS version of Opera back in the day, and I also remember reading some statement by someone at Opera about how with BeOS dying, it was no longer worther keeping alive.
But, Opera seems to be fairly portable (supported on Windows, Linux, MacOS, Solaris, FreeBSD, and a host of mobile platforms), so how popular do you think Haiku has to get before we've got a chance of seeing Opera ported? Would the seemingly large number of Firefox haters out there use it over Firefox?
If Opera was availble, would it somewhat stifle the motivation for a native browser project (as in, is the motivation for such a project a genuine desire for a native browser, or just something that _isn't firefox_)
Interestingly enough, Opera pretty much started on BeOS... but it hasn't been maintained since 3.x. Until Mozilla Suite/FireFox came along, Opera 3.62 (?) was pretty much the only viable browser option on BeOS besides Net+...
I'm not sure if they'd consider a new port of it to BeOS/Zeta/Haiku - but I guess it's possible given their willingness to support just about any platform (embedded devices, etc).
WebCore: has objective C. Qt dependencies resolved in a C/Obj. C layer. I forget what Apple named this.
Gecko: refers to the HTML rendering engine. Even though FireFox and SeaMonkey work in BeOS, certain aspects need to be re-written so that Gecko can be embedded into native applications. Embedding basically consists of creating a libgecko.so that contains a proper interface that native applications can utilize.
2~3 years ago, when i naively attempted to continue even earlier attempts:
Gecko was more standards compliant, better error-handling but had a much larger code base(~50mb) and was primarily single threaded.
KHTML/WebCore have a much smaller code base (~5mb) and is multi-threaded at the cost of less standards compliancy, a smaller developer base, and WebCore is written in Obj C, which most BeOS/Haiku/Zeta devs don't do.
If these discussions materialize into coding attempts,
I'll gladly help out, especially if there's relatively easy-enough-to-learn stuff that can be done.
Gecko's heaviness isn't that big, although probably heavier than KHTML.
There is an embedded project in Mozilla, but no one so far has finished of the BeOS-code to work with the embedding. I more or less know what needs to get it working. In fact I have had it running with a fast hack just to prove that it isn't that far of. It didn't render anything but it starts and initializes correctly.
The problem with the attempts so far has been that the messaging backbone was never started with the code-paths done in embedding, so with a hack to force it started embedding does run. I have an old screenshot of this.
I would be working on it if I had any time, but work and Real Life is keeping me busy. My priority has also been on Firefox before embedding, but I think that priority might change.
If I had to choose the easiest way to get somewhere, and probably easier to maintain due to the close relationship with other Gecko-based products and Bezilla-teams work on those project: Gecko
If I had to choose what would be most 'Be'-isch and in style: KHTML
I won't be working on setting up the autoconf/make structure of KHTML to do the port though. That's one thing that's sure. Autoconf/make is so ugly. Someone started working on setting up a Webcore-project for BeOS, if that code could be rescued we would at least be of the ground...
It's lemon's project, but he wanted more devs. I mentioned it earlier in this thread. Fyysik doesn't know much more than I do, unfortunatly. Check the google-group for more info: http://groups.google.com/group/nirvana-browser
youre all wrong....if you dont go with the flow you wont have any friends...
i disliked some people's posts because it is full of that DO IT MY WAY OR DIE! ideology ;p
my post will probably annoy some people. but look closely. the WORST way to make friends is to ask them to play with you and you make the rules. you wont have any friends.
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.....
beos attitude is very xenophobical by the way (or osophobical). like why nameing everyting be? beMail, beThis, beThat. dogmas are very dangerous. thats like puttign SS in front of everything..
AND I STILL LIKE FIREFOX, despite the burning posts agaisnts it..i can feel the heat right now......;DDDD
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. :wink:
Comments
Haiku Web Browser
i've contacted YellowTab some months ago asking about that port but they didn't respond me. They didnt told me if they are using it or not, so my only alternative is doing it myself using porting ideas from other projects (like the Syllable and Webcore ones). Now with shadow we'll start to convert that code. It's the harder thing i think, more that the networking part.
yes, i hope in few years to see Haiku (but also Zeta, if they'll create a good 2.0 version) as a valid alternative to Windows and Linux. Something that "just work good", where you can browse, listen to music or see videos, create office documents in a clean way. No slowness, no cryptic things to do to set software or the OS, etc.
But to have this we need to create it :wink:
Haiku Web Browser
The first is from 2003 and has never been actioned upon, and came at the same time as ODBC and Java were being promised for R1, so don't rely on the port actually existing. Zeta has JavacriptCore in it, but as has been shown above, thats far easier to port. I'm not sure what, if anything, it uses it for right now though.
Haiku Web Browser
Wow that's a lot of replies in one week :shock:.
EDIT:
BTW for anyone that cares, i have been in the planning phase for building a simple Web Browser for the past 6 months. I was hoping to write an IRC Client before actually implementing the browser (To get to know the BeAPI more), and i still hope to do that.
My real problem is that none of my computers want to run BeOS :x.
Oh and i've take a look at KHTML, and it doesn't look too bad. I especially like the netscape idea of having multiple rendering/layout engines :wink:
Haiku Web Browser
Sorry, feel the need to add my opinion to the pot.
Best reason to develop a seperate web browser
Since HTML is consistently used to develop help systems,
I would have to believe a reusable renderer to be very useful.
But at what point does this get overboard? Duplicating everything firefox does seems to be a waste of resources, especially when there are other needs that aren't being filled. The one thing that is really needed right now is a new Flash Player. Firefox and any other browser on BeOS is limited in use to me because of this.
Haiku Web Browser
I believe a BHtmlView would be great.
Even better would be a BHtmlView that can use a light-weight haiku layout engine, KTML, or gecko at the users option.
Haiku Web Browser
I like the idea of a bhtmlview. It kind of follows into my idea of creating a translation type kit for file parsing and rendring. Having the parser as a system available resource would allow any app to use it for any need. Such as help systems, file reconition etc.. It would work just like the translation kit only with flat text formats, like html, pdf, doc, man pages, xml, etc... This way you could provide the traditional add-on hierarchy to rendering, parsing, even the tokenizer. Allowing for easy updates as changes happen to the standards and specs. Easing the compatibility woes of in app parsing and rendering. This type of system wide document reconition would fit well into the traditional spirit of Be that we want to keep alive "do it the Be way!"
Haiku Web Browser
One thing a few weeks of using Be has shown me is that we need a browser that's as good a Be citizen as Net+ but as capable as Firefox. I rate the web browser as probably the most important thing for an operating system these days and I don't think we should settle for Firefox when we could have something that was lighter and more Be like...
Haiku Web Browser
In my opinion, the best solutions I've heard tossed around still are an embeddable HTML rendering view either based on KHTML or Gecko and a native wrapper app.
Haiku Web Browser
I Agree, however the way the renderer is embeded should be flexible enough to use KHTML AND* Gecko, and also anything else (Say, a native one if ever written).
* I don't mean dynamically changing, like netscape does with Gecko/IE. I mean being able to change it in the source code.
Haiku Web Browser
This should be part of a more generic Editor/Viewer API (text, images, etc.). For example, then you could embedd BeMail as a viewer in Tracker. Also add a tree view to the left and you have a full-blown email client. Well, not exactly, but with queries and grouping you would have something really cool...
Haiku Web Browser
If viewing apps like BeMail were to be embedable without changes, the mechanism would have to work without the app knowing it, so the browser wouldn't have to do anything special. It might be questionable how useful this approach is, though. You probably wouldn't want to embed the full app, but rather just a view of the mail content and headers.
For an API to embed parts of other apps wherever you like, we already have replicas. A browser view as a replica would be useful, but I'm not sure whether the replica code should be part of the browser app. With the suggested bhtmlview, one would have the most reusable component IMO, as this could be used by any app directly, and we could also have a tiny app that exposes the bhtmlview as a replica, perhaps with a simple right-click menu interface on top.
Skoe: I think a bhtmlview consisting of a minimalistic code base (wrapper code) on top of the engine would fit your requirement quite nicely. Hopefully the code would only include what one would have to rewrite for each engine anyway, so writing a new view exposing the same API would be a drop-in replacement for the default/first bhtmlview.
Haiku Web Browser
Indeed. There is little point to us writing our own rendering engine - that would go against the point of open source software, wouldn't it?
As for Gecko vs KHTML, all I can say is that I think Safari (KHTML) is better than Camino (Gecko) but that just be a case of implementation. I'm sure either is fine.
Haiku Web Browser
I think in the case of BeMail - wouldn't it just be a text view, RTF view, or an HTML view combined with a MIME or UUENCODE decoder? I would think BeMail would be a consumer of these as well.
KHTML
Personally, I prefer KHTML. Not that that matters much :)
Haiku Web Browser
Even I prefer KHTML, but someone needs to port it first :roll:
Haiku Web Browser
I think the idea of a native web viewing component (html/css/javascript/etc) would be the more Be like approch to the problem. Plus if it is implemented in the classic Be way (modeled after the translation kit) nothing stops people from using a ported Gecko or khtml on their system. I don't want to get into the "not built here" mentality I just feel that with the level of integration that the web and html has with modern desktops a home grown hierarchy is the way to go.
Haiku Web Browser
The browser would be original but, the idea of creating a whole new rendering engine and getting it up to the spec of compatability would 1) be a large undertaking and 2) create another engine to worry about in web development and compatability. KHTML is a strong engine with solid performance and compatability with standards. Building a native kit and getting it to pass acid2 would be challenging and is secondary to the construction of an OS. That is not to say that we should not have an equivilant of WebKit for integration - but I feel that it should be based on KHTML
Haiku Web Browser
I beg to differ. It isn't that swell, and is generally less compliant then Gecko.
Last i checked, Opera/Firefox/IE/Konq/Mozilla/etc all failed the acid 2 test.
So do i...For now. I think that for R2, a native layout engine should be more appropriate. One thats designed, and designed specifically for use with BeOS features and API.
Haiku Web Browser
I think its a nice idea to have html viewing/parsing capabilities built into the system. But i still think to use gecko because its more popular than khtml. Firefox market share is aroudn 10% (maybe more), which makes it good enough to use it despite how annoying it is..
i also DO NOT think that what the os provied is the only way for viewing htmls. people should still be able to install firefox ven if its slower and chunckier. i know i would, even if its lower, jsut for the hell of it!!;D
Haiku Web Browser
Haiku Web Browser
damnyou got a point;D.......kind of hard for me to combat your argument...gecko is not that bad frist of all..damn i cant fight it..probably it doesnt matter too much.......well in beos spirit i guess youre right.....hmm..ok do that
would it be part of translation or would be a kit all by itself? theres also xhtml, css/css2, xml that are very important.....so if khtml can do that...i know for xml you can use something else......then its all fine with me.....
im still going to install firefox though...cause im used to it...BUT i would try your kit anyway or broswer out of curiosty.....
[edit]popular software is good cause you get a lot of help for it.....the more its used the more youve got a change someone solved some problem already..and all you need to do is google...but theres a balance between a crappy popular piece of software and less popular (bit still known) good software..i would nevr go for ie's crappy rendering madness..NO WAY..
Haiku Web Browser
"my kit"
AHH! I actually have no idea how to develop this kit. I conceptually understand the process but I don't know a programming language yet. I want to learn Objective C though (because I wan't to develop a restaurant reservation program for Mac)
Haiku Web Browser
i have no idea either...thats why i talk so much...i know enough c++ objects to get me started and with enough pations can build a gui app in beos....i also know some networking at c level...but im no expert...
if you really want to you can do it...it will take you a long time...but its possible..........i think you can build it in objective c++...not shure but i think beos was build in c++, except the kernel...
coding is mostly about spending time to raed....NOT remembering function names....you need a good khtml refrence and api....a good undestaing how kits/servers work aare made...the midi/translation kits/servers are probably the easiest i think start looking at that....i have no idea...anyeay...some suggetions..i have no idea...i would like to helpbut im not very superconfigend and not much time...but i could do stuff...i know programming enough for me to like it ;p
and i still like gecko...reminds me of fallout 2 hehehe
BHtmlView external linking
Assuming that the Haiku browser will be implemented as a special BView, how will developers control it? I would assume that the basic BHtmlView would be created by passing a basic HTML page, in a really large string, to the constructor or similar. However, how would a developer pass externally linked files, like CSS stylesheets and Javascript snippets? For most things, it would probably be possible to just make a single file HTML, such as for help pages, but most Internet web pages aren't made like that.
So how would this BHtmlView be passed external files?
--Walter Huf--
Haiku Web Browser
Philosophically, I think it's a bad idea to challenge too many standards at once. As you point out, Windows is more popular -- which means that we are already breaking a standard, as it were, by doing something different. That's a tough enough hurdle all by itself. Any additional standard-breaking means that we're just piling more hurdles on top of each other.
Consider productivity suites, for example: I love Gobe Productive dearly, and it will always, always, always be my first choice of productivity software. I dearly hope that Gobe gets going again, or the source code is released, or some other Haiku-like group of coding gods decides to reverse-engineer the thing. It's just a beautiful program. I like it infinitely better than Microsoft Office, and vastly better than OpenOffice.
HOWEVER, it's also completley alien to most people, who are stuck with Microsoft office. Some of them, inexplicably, even like it. Now imagine that you're trying to convince one of them to use Haiku. Here's your pitch: "Hey, check out this fabulous new operating system: it'll feel kind of weird for a while, but once you get used to it, you'll find that it does everything faster and easier and better than Windows does."
You'll lose some people right away, and, well, those ones who are beyond help. But for the ones who remain, you've now got another pitch to make: "Oh, you'll have to also learn this new productivity suite, which is vastly better but also totally different than your old productivity suite. And as for all your old documents... well, most of them should... kinda... import..." That's a much bigger hurdle, and you'll lose most of the rest of them at that point. And that is Haiku's loss, not just Productive's.
This is why, even if I don't like OpenOffice very much, it is essential that it be ported over to Haiku. That way, your second pitch can be: "here's this Office Suite which is 100% compatible with all of your old documents, and has nearly the same interface and workflow and everything!" That's a much, much easier sales job. Of course Productive will still be around, and the ones who are smart can catch onto it later. Gotta fight your battles one at a time. I think in the above example, it's quite obvious why.
Now, when it comes to a HTML layout engine, it's a much more subtle thing, but this dynamic is still at work. I don't know anything about how it is to work with KHTML vs. Gecko on the backend of a system, so I can't address that issue. And I can say that, from the consumer's point of view, as long as they produce the same output, it doesn't really make that much of a difference. However, from the perspective of a web designer, I can say that KHTML makes me a little nervous, simply because I've never validated any of my pages against it. It isn't enough of a factor in the market to worry about. So that's one consideration. Particularly if we're aiming for Haiku to be accepted in a business environment -- and I think there's no reason not to aim that high -- it's very important that the business be assured that it is seeing exactly what everybody else is seeing.
Another consideration is: how many developers are used to working with Gecko? How many are used to working with KHTML? If one has a much larger number of developers, then that is the one that Haiku should almost certainly use. That gives us a larger base of programmers to recruit from. We can say: "hey, why don't you develop web applications for this cool new operating system? And look! You can use the same HTML layout engine that you always use! There's hardly anything new to learn!" See how that's a much easier argument to make?
Once Haiku has enough users and developers and overall momentum to start throwing some of it's own weight around, it'll be another matter. From the beginning, a program should request the particular HTML engine that it'll be using. If it becomes obvious that a home-grown HTML layout engine would be superior, that can be added on later. You can go ahead and break compatibility, because new and updated applications will have to request the native engine directly, while old applications still use the old engine. That's a little bit crufty, admittedly, but there's no reason why it needs to be that way for long. The great thing about free and open-source operating systems and software is that there is never a disincentive to upgrade, so (unlike, say, Windows) there's no need to keep kruft hanging around forever (except perhaps to support legacy hardware). After a Moore's generation, the older engine can thus be removed from the default Haiku installation.
Haiku Web Browser
All true ââ¬â but the fact remains that if Haiku is setting out to do something as ambitious as create an OS, it may as well use components that are as strong as possible. Gecko is more forgiving, but KHTML is more predictable and supports more standards. It is currently the only engine to correctly render (pass) the acid2 test. Haiku seeks future adoption and growth so it should use a rendering engine that 1) Is growing in popularity (yes. . it is) 2) Is the most standards compliant 3) Has a stable backing force (a strong community in KDE and a corporate development in Apple Computer). Gecko might take a month less work but in the end, the engine will be less impressive than KHTML. I can't force it to happen of course, but I would like to see Haiku develop a stable, well os-integrated fork of KHTML.
Haiku Web Browser
skybum has a point
plus to be honest..i stil stick by my decision to use firefox. hehe..i never get tired of saying it. because 1. its already made, you don't have to redo it. 2. its made by smart people dedicated to only making browsers (these peopele know what their doing) and 3. its used by lots of people or enough for me to get help.
but on the other hand, its cool making a browser cause i learn how to program, learn how to build a browser..
the only reason im not using linux is beacuse i don't have photoshop. and the prices of macs scare me.
if you look closely linux is starting to copy windows interface. why? becuase its trying to steal people away from windows. haiku's advantage over linux is the gui! that's it. few tweaks and will look like xwindow/windows gui, which will corrupt people.
so my opinion is use whats already there, for now. and help out with the really important things for example server app, drivers.
Haiku Web Browser
Really? Come on, that's a large leap of faith there.
Haiku Web Browser
Good point.
I still hopes that will be the same with haiku.
Development of a high quality OS, not development of all kinds od programs.
Haiku Web Browser
Two points relating to the last few posts:
1) Firefox is a bit shit
2) I don't think this community should hold any delusions of breaking the Windows monopoly over the next few years!
Since we're not really here to take over the world or make money, I say we focus on building the best damn desktop OS around instead of pandering to a potential user base by relying on the familiar second or third best (if it was possible to port MS Office and IE, should we?). The way I see it, making that OS involves making an incredible web browser that feels well integrated and usable. Firefox isn't and won't ever be because it has to be cross platform and support plug ins, themes and what not. I find I end up using Net+ 95% of the time because it doesn't feel like an app, it's a natural extension of the rest of the interface (like StyledEdit, BeMail and People are). I can close the last Net+ window and then remember that I needed to do something else and five seconds later I'll be back online looking at the page... but woe be unto him who closes the last Firefox tab! FF is a clunky beast of an app and far too hungry and complex for what a browser should do: display web pages.
Keep it elegant and keep it light is what I say.
-Paws
Re: BHtmlView external linking
Yay, a SANE POST.
I would have some sort of simple API, where the component is given a URL/Filename, or some sort of file handle. Then component then goes off and retrives/parses/rendered that file, and downloads all other required files into a cache - and similarly parsing/rendering them too when appropriately designated by the main file's parser.
One of my biggest goals is to write a Web Browser, and a layout engine is a huge step in the right direction. I have been planning (As in thinking about, and sketching some designs) of making one for almost 6 months (Give or take a bit).
My two biggest problems are procrastination and a lack of a Be OS. I am unable to compile Haiku (Or BeOS applications) on Windows or FreeBSD, and i am unable to run BeOS R5 on my main computer (With or without BONE). BeOS does run on my laptop, but it has no means of communication from the outside world - It's USB is busted, it has no supported ethernet (It has a PCMCIA Card, that i've never gotten to work), and it doesn't have a CD Burner. Also, i can't afford Zeta 1.1.
I am slowly trying to get Haiku to compile on FreeBSD (I've built the kernel, but the current problem is the kernel.so wont link).
But anyway, as soon as i can i will start to develop so sort of BWebView. (Not BHtmlView, which in my view is redundant since it's outdated and should be shunned upon).
This is how KHTML Looks (It's a bit complex IMHO):
http://developer.kde.org/documentation/library/3.4-api/khtml/html/classKHTMLPart.html
And KHTML's site:
http://khtml.info/wiki/index.php?title=Main_Page
Keeping it elegant and light -- Is what i agree with. KHTML or a native layout engine is the way to go. Gecko isn't.
Oh and BTW: Haiku wont have that large a user base to start with, but it will grow many times faster then Linux or *BSD. People want an alternative to Windows they can trust -- Let's make one safe, elegant and easy to use desktop alternative.
Haiku Web Browser
Gecko can probably be light, it's just that the Mozilla/Firefox/Thunderbird apps arn't and the layout of the project makes it hard to see how to strip it down to the parts you want. I don't think an embedded version will be bad, although it will not be perfect either.
Haiku Web Browser
Skoe - I'm really talking more about implementation, as in how it presents itself to the user and works with rest of the desktop.
The case for KHTML/Gecko against a new engine is that we'd perpetually be playing catch up, and the case against Gecko for KHTML is apparently it's more insulated and thus easier to port. I wouldn't know where to start if I were to do this myself but this is something I feel strongly about and I hope that my programming skills soon progress to a level where I can do something useful.
-Paws
Haiku Web Browser
Ah,
And from what i hear, Gecko would be alot harder to port due to it being Objective C. Qt is quite similar to the BeAPI...
Haiku Web Browser
Gecko isn't written in ObjectiveC... and its already ported, more or less. What do you think Firefox is running on?
Haiku Web Browser
The question is how difficult it would be to rip gecko out of firefox? It's not really 'meant' for that, is it? KHTML is apparently quite separate from Konqueror.
Haiku Web Browser
Gecko by nature is heavier.
And in response to keep it light ââ¬âàKHTML is light but powerful, HkWebView could be powered by KHTML as easy as its own engine. I am ALL FOR INTEGRATION, but I think that KHTML as base is the lighest and most feature-complete wya to start (not in objective-c, as I think I may have introduced to to the topic in a tangent ââ¬â I want to learn it for my own reasons).
I totally aggree that Haiku will grow faster than linux ââ¬â it is not meant to be a poweruser os ââ¬â it is a user os that, like firefox, will have good features and show a better alternative to windows on the x86 platform.
Haiku Web Browser
Keep in mind that Gecko has already been "ripped" out of Mozilla Suite in order to build FireFox...
Haiku Web Browser
This is admittedly off topic, but:
I'm a linux user, and was having a lot of problems with Firefox crashing on pages using flash. So, I started using Opera on linux-- I love open source but i'm not a fanatic, if a closed source app will get the job done better then i'll use it, _especially_ if its also totally free.
Eventually I found a website that described the problems I was having, and offered a fix (editing some X.org file...don't really remember). Stability is much better now, but I still really like Opera and use it sometimes too (right now!). I know there was a BeOS version of Opera back in the day, and I also remember reading some statement by someone at Opera about how with BeOS dying, it was no longer worther keeping alive.
But, Opera seems to be fairly portable (supported on Windows, Linux, MacOS, Solaris, FreeBSD, and a host of mobile platforms), so how popular do you think Haiku has to get before we've got a chance of seeing Opera ported? Would the seemingly large number of Firefox haters out there use it over Firefox?
If Opera was availble, would it somewhat stifle the motivation for a native browser project (as in, is the motivation for such a project a genuine desire for a native browser, or just something that _isn't firefox_)
Haiku Web Browser
Interestingly enough, Opera pretty much started on BeOS... but it hasn't been maintained since 3.x. Until Mozilla Suite/FireFox came along, Opera 3.62 (?) was pretty much the only viable browser option on BeOS besides Net+...
I'm not sure if they'd consider a new port of it to BeOS/Zeta/Haiku - but I guess it's possible given their willingness to support just about any platform (embedded devices, etc).
Looks like they still have a forum for it:
http://my.opera.com/community/forums/forum.dml?id=7
Hmm, guess there was an Opera 2.1 for Windows before it ever existed for BeOS... oh well, BeOS was the first place I ever saw Opera ;)
Haiku Web Browser
KHTML: no objective C. Qt dependencies.
WebCore: has objective C. Qt dependencies resolved in a C/Obj. C layer. I forget what Apple named this.
Gecko: refers to the HTML rendering engine. Even though FireFox and SeaMonkey work in BeOS, certain aspects need to be re-written so that Gecko can be embedded into native applications. Embedding basically consists of creating a libgecko.so that contains a proper interface that native applications can utilize.
2~3 years ago, when i naively attempted to continue even earlier attempts:
Gecko was more standards compliant, better error-handling but had a much larger code base(~50mb) and was primarily single threaded.
KHTML/WebCore have a much smaller code base (~5mb) and is multi-threaded at the cost of less standards compliancy, a smaller developer base, and WebCore is written in Obj C, which most BeOS/Haiku/Zeta devs don't do.
If these discussions materialize into coding attempts,
I'll gladly help out, especially if there's relatively easy-enough-to-learn stuff that can be done.
Haiku Web Browser
I think i was thinking about WebCore :P.
KHTML Seems to be the more viable option...
Haiku Web Browser
Gecko's heaviness isn't that big, although probably heavier than KHTML.
There is an embedded project in Mozilla, but no one so far has finished of the BeOS-code to work with the embedding. I more or less know what needs to get it working. In fact I have had it running with a fast hack just to prove that it isn't that far of. It didn't render anything but it starts and initializes correctly.
The problem with the attempts so far has been that the messaging backbone was never started with the code-paths done in embedding, so with a hack to force it started embedding does run. I have an old screenshot of this.
I would be working on it if I had any time, but work and Real Life is keeping me busy. My priority has also been on Firefox before embedding, but I think that priority might change.
Here's a link on Gecko embedding: http://developer.mozilla.org/en/docs/Embedding_Mozilla
Haiku Web Browser
If I had to choose the easiest way to get somewhere, and probably easier to maintain due to the close relationship with other Gecko-based products and Bezilla-teams work on those project: Gecko
If I had to choose what would be most 'Be'-isch and in style: KHTML
I won't be working on setting up the autoconf/make structure of KHTML to do the port though. That's one thing that's sure. Autoconf/make is so ugly. Someone started working on setting up a Webcore-project for BeOS, if that code could be rescued we would at least be of the ground...
Haiku Web Browser
Whilst looking at berlios.de it appears that a project has been setup (by the team of lemon and fyysik) to port KHTML to BeOS/Haiku.
http://developer.berlios.de/projects/nirvana/
Regards
Simon Kennedy
Re: Haiku Web Browser
It's lemon's project, but he wanted more devs. I mentioned it earlier in this thread. Fyysik doesn't know much more than I do, unfortunatly. Check the google-group for more info: http://groups.google.com/group/nirvana-browser
Edit: Fixed quote
Haiku Web Browser
wow flames!! ;D
youre all wrong....if you dont go with the flow you wont have any friends...
i disliked some people's posts because it is full of that DO IT MY WAY OR DIE! ideology ;p
my post will probably annoy some people. but look closely. the WORST way to make friends is to ask them to play with you and you make the rules. you wont have any friends.
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.....
beos attitude is very xenophobical by the way (or osophobical). like why nameing everyting be? beMail, beThis, beThat. dogmas are very dangerous. thats like puttign SS in front of everything..
AND I STILL LIKE FIREFOX, despite the burning posts agaisnts it..i can feel the heat right now......;DDDD
Haiku Web Browser
hehe...and if you contradict me you will all go to hell;DDDDD (thats another ideology)
Haiku Web Browser
I love firefox too :) - but I'm mostly a windows user ATM.
Haiku Web Browser
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. :wink: