I look at it from the perspective of attracting users. Most of us here, people who are interested and involved with the Haiku community, will probably start using Haiku while R1 is even in the Beta stage. We may even attract some old BeOS users who have since moved on to an actively updated OS. At some point, however, it only makes sense that we should hope attract fresh users: people who perhaps have never even heard of or used BeOS.
To old/current BeOS users, and those of us involved in the community, a native web browser is cool project and a neat idea. And, there are even some advantages: slight performance gain and consistent OS wide look and feel. Such a project, as many have pointed out, is a monumental undertaking; it is the same order of magnitude as Haiku itself. But, even if such a project did come to fruition, and achieved complete standards compliance with javascript and some plugin support, I have a feeling lots of new users would end up using firefox, just cause there’s a good chance they were using it on whatever platform they are migrating from.
A native browser is NOT going to attract new users. In fact, it is likely to be completely ignored by many of them, even if its just as good or better than the BeZilla port. Computers and connections are fast enough these days to make the performance difference a moot point. People will choose to use what they are used to, rather than nit-picking over microseconds. Such a project would suck a lot of resources from the community and I don’t think its worth it. Furthermore, I highly doubt such a project even would get to be as good or better than Firefox.
All that said, we are talking about open source. People contribute because they are interested and inspired by what they are doing. There are things other than a web browser that I think would be more useful to Haiku, but its not like we can just say “cancel the browswer project and put those developers on xxx project”. If people in the community want to code a browser, thats what they’re going to do. Personally, however, if such a project ever gets off the ground, I will choose to make my contributions elsewhere. My interest lies in seeing Haiku become a robust platform that can someday be a serious competitor in the OS world.
But, even if such a project did come to fruition, and achieved complete standards compliance with javascript and some plugin support, I have a feeling lots of new users would end up using firefox, just cause there's a good chance they were using it on whatever platform they are migrating from.
I for one am mostly interested in Firefox and Thunderbird at this point - but that’s because I use them and like them in my Windows environment.
When I use other people’s machines - I suggest that they try them, and use them as opposed to Outlook Express and IE. It’s a relatively easy sell for Windows users - because the switch is fairly effortless and they can always switch back if they don’t like it.
Asking people to try a new OS isn’t nearly as easy, but once you get them hooked on Firefox, Thunderbird, and OpenOffice (yeah, i know) – then they have very little reason NOT to try an alternative OS as long as it supports these “big three” (my opinion). They know what to expect from the apps because they should have the same functionality from platform to platform.
Cross-platform software is a bridge, not just a “hack”. It helps users to be comfortable in different OS environments… Once they’ve made the switch, then SURE, they’ll try out a native browser and appreciate it’s elegance and speed, but it’s less likely that they’ll ever reach that point without a cross-platform choice to use as a bridge.
Cross-platform software is a bridge, not just a "hack". It helps users to be comfortable in different OS environments... Once they've made the switch, then SURE, they'll try out a native browser and appreciate it's elegance and speed, but it's less likely that they'll ever reach that point without a cross-platform choice to use as a bridge.
Agreed. Certainly I hope the BeZilla team keeps up its good work for this reason, regardless of what other projects may crop up. As for OpenOffice.org, hopefully yT will be helpful and contribute some of their work back to the community so that that will be possible along with R2 (since it won’t be possible at all while we’re still using 2.95, right?).
Agreed. Certainly I hope the BeZilla team keeps up its good work for this reason, regardless of what other projects may crop up. As for OpenOffice.org, hopefully yT will be helpful and contribute some of their work back to the community so that that will be possible along with R2 (since it won't be possible at all while we're still using 2.95, right?).
I’m probably completely mistaken here but I’m not sure the compiler version is the limitation… newer versions of GCC can be used on BeOS/Haiku - it just doesn’t generate binary-compatible C++ object code.
Oh, ok. Makes sense; OOo is a very big complex piece of software. There are probably lots of other problems that prevent it from running at the moment.
hello, i’m new to the forum and i’d like to present my project/ideas. I’m a big fan of BeOS from years but i’ve always tried to use it as often as possible but something has always forced me to return using Windows: more “matured” software, updated drivers, and so on. Now that BeOS is no more i’ve hope to see something (good) happening with Haiku: a good desktop OS. I see also Zeta as a way to push commercial software (maybe also games, drivers and so on) into our system but i can sadly notice that the core software (browser, email client, etc) is too slow developed. low level things (work on haiku kernel, servers, drivers, etc) are active but what people see and use, the software are stuck.
My idea is to have a good system to use, and a good system is a well integrated enviroment with this and that software that is fast, logically integrated from an application to another, and so on. BeOS is all this and i want that this can continue and improve.
It would be nice to create something from scratch but the lack of developers is something to not hide and to think about. My idea is to use existing resources from other “worlds”, adapt to our system and build around it a BeOS interface. Successfull examples of this logic are the use of GCC, CUPS, SANE.
Talking about browsers, we have Firefox and is a great piece of software, but it’s slow and generally not integrated and developed to fit perfectly into the OS. I don’t want to say is bad, but is a third party software. Probably it can be improved by the bezilla team but i feel we need also something more native.
So i’ve said to myself “I want to contribute” and i’ve started to analyze how to create a new browser. I’ve come to this strong points to follow:
- the interface must be simple, uniform and powerful, starting to the Net Positive one and taking ideas from other browsers.- the browser can be used integrated in another application (reusability)- the interface must be customizable by plug-ins that add new functionalities (the target is something like Firefox but skinnability is something to make in the OS, not the browser in our case)- MIME types must logically be used in the browser. you download an mp3 and you can listen in the browser itself if you want. you have a quicktime file and you see in the frame of the web page.- the rendering engine must be pluggable to the browser. The interface is always the same but the user can use and/or develop a plug-in to view pages. The rendering plug-in must respect a certain browser API to work. We could have a KHTML rendering engine, a Gecko one or, not so ironically, a commercial Opera one. This idea is similar to the last Netscape that can use the Mozilla or IE engine, but the Haiku one will be opensource- the default/first rendering plug-in must be easy to mantain and develop. To have this we need to use an opensource engine already functional. I will append a note to this point below.- integration with BeOS must be accomplished. Things like drag-drop of links, send of mails, etc.- Last but not least, the APIs have to be clean and easy to use, specially for integration of the browsering in other applications.
Here is the simplified diagram of the browser structure:
Actually i’m studying how to compile the KHTML code with as less as possible modifications of the original code. My preference to this library is because i think that it could be easier to maintain a C++ source more than WebCore (that is also in Objective-C). Gecko in the other way is huge and need much more experience to handle it, so maybe a Gecko renderer will be created later. Returning on KHTML, I’d like to create a wrapper of the QT calls made in the sources, not a full QT port, so if future patches of the engine can be integrated without comparing all the code and so on.
While working on this i’ll write the browser API (things like “load page of the file x”) fitting the page frame in a initial browser interface. After that i’ll work on networking for loading pages over internet and their chaching/history. After this i’ll upgrade more the interface and build the 2 managers (the renderer and plug-in ones).
I’ve not much experience in OS programming so i cant much help developing Haiku kernel or the servers, but i’d be pleased to use my knowledge for making new software for this system. I hope people can help me on KHTML to speed up the process, if we can encapsulate well the thing we can be half the way Contact me and we can organize better the work. After Christmas i’ll have 2 weeks to work freely on it
What do you think of the project? Any suggestions? I’ll post another thread to have ideas from you (for the interface)
Bye
Elvencode, drop me a note at gyoder at stny dot rr dot com. Ever since the last WalterCon, I’ve been meaning to work on getting KHTML to build by implementing the minimum amount of Qt that it uses. We should coordinate on it and divide up the work.
WebCore is partially written in ObjectiveC.
There’s a GTK version of WebCore by Nokia, though i don’t recall how far they progressed.
an email from Phillippe Houdoin (2004-apr)
Quote:
You'll find the latest JavaScriptCore 125 BeOS quick port I made some
months ago here:
http://philippe.houdoin.free.fr/phil/beos/JavaScriptCore-125-BeOS.zip
BeIDE projects and binaries are included.
No change was required to build libpcre.a. To build kjs, aka
libJavaScriptCore.so, small changes were required.
Some #ifdefBEOS#include <missing headers> #endif here and there,
and a BeOS thread specific implementation of
Interpreter class locking feature in internal.cpp and it seems to
works.
I’ve not yet run the newest JavaScript tests on it, just the very
simple test.js file that was already there in the 96 version.
That’s something that should be done, obvioulsy.
I’ve also a small issue with an assert in Collector::allocate() which
fail in kjstest bin app because they allocate a Global object before
they instanciate the Interpreter object (who need this global object),
so the Interpreter lock count is zero at this time.
I commented out this (new in 125 version) assert for the moment.
Two more pieces of info that may be useful for your enterprise:
“WebCore can render D/X/HTML code using a thin QT=>Native wrapper. YellowTab has ported all the Konqueror code in WebCore, and a part of the QT wrapper code. The left over pieces shouldn’t be an amazing amount of work to finish, just needs some time.”
hello, i'm new to the forum and i'd like to present my project/ideas. I'm a big fan of BeOS from years but i've always tried to use it as often as possible but something has always forced me to return using Windows....
hi, i’ve been doing that too. the reason is zeta doesn’t have the tools i need. most applications are small and useless. in zeta there is no opensource nor commerical software but only to unupdated leftover from beos.
i think porting opensource software to haiku and finishing haiku is high priority.
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
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
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.
Contact me and we can organize better the work. After Christmas i’ll have 2 weeks to work freely on it 
