if themis is halfway clean written then we should add it to the haiku-tree to get it further developed, i think.
it is mit-licensed and a native beos app; it would be the perfect net±substitute…
g400 wrote:
if themis is halfway clean written then we should add it to the haiku-tree to get it further developed, i think. it is mit-licensed and a native beos app; it would be the perfect net+-substitute...
If the developers were available, they’d be just as able to contribute code to it outside the Haiku repo…
Quote:
If the developers were available, they'd be just as able to contribute code to it outside the Haiku repo...
ah… ok.
i just thoght it could get more attention this way… and net+ was also part of the system itself…
Skoe, if you’re serious about making a native webbrowser for R5/Haiku,
then i strongly suggest working with the BeZilla team to get embedding working properly.
http://www.livejournal.com/community/bezilla/
An HTML engine is a serious chunk of code.
For at least the next few years, the BeOS/Haiku community simply cannot compete with Mozilla’s community in terms of development, userbase, etc.
It’ll also allow more time to be devoted to the actual GUI.
And reading up on XULRunner might be a good start:
Back around May and June of this year, I was giving a serious look into what would be involved in having a native web browser for BeOS. I would first like to say that the BeZilla team has done an amazing job. The Firefox / Mozilla source tree is IMO uglier than any horror movie I’ve ever seen, so getting anything like that to work is short of miraculous. I can live with the bugs in the official 1.5 release from a little while ago because I know how hard it is. Many efforts at embedding the Gecko rendering engine have been made over the years, but none of them ever worked the way they should have.
My opinion is to go the OS X / Syllable route and port KHTML. There is AFAICT less overhead than with the XPCOM technology that Mozilla is based on. To be blunt, a good browser is hard. Period. It is a project on the size of Haiku itself.
If there is anyone out there who does not have much experience with coding for BeOS, but has plenty of experience working with Qt, that person should seriously look into working on porting the browser. Doing the port would be helpful in learning the API and be an immense boon to the community. I just wish there were takers. As tight-fisted as I am with my money (for lack of it), I certainly would pay good money even for a good commercial version.
Ok, before I got heavily involved with Mozilla I wanted to work on KHTML, and just as Darkwyrm says, it’s elegant.
Unfortunatly build-system configuration is something I hate, so I joined Mozilla and learnt how to get things done there. As the interest for Webcore seems to increase it might be time to try and wake up a project that has been slumbering: Nirvana. I’ve already talked to some people about it recently and it would be good if a joint effort could be made.
Here is the google-group: http://groups.google.com/group/nirvana-browser?lnk=li
Here is the Berlios page: http://developer.berlios.de/projects/nirvana/
Also I don’t know if Darkwyrm was talking about embedding Gecko under BeOS or in general, but the main reason embedding under BeOS doesn’t work is in the widget-code for BeOS. It starts the message-looper for handling Mozilla messages in a nsAppShell->Run. In embedding that function is never called. A long time ago I actually had a half-running embedding app upp, although it didn’t render correctly. I havn’t had time to work on that as priority has been on Firefox and Seamonkey. I don’t see any major problems in the way of getting embedding working except some time and effort.
Hi,
I think people would use Firefox anyway. It’s not really about the best program/os ever but what people like.
I bet if IE was available for BeOS people would use it 
Offtopic:
What the hell is with all K’s and Be’s or B’s in KDesktop or BeOS? Like KHTML.
fanton wrote:
I bet if IE was available for BeOS people would use it :D
I think not. The idea of a truely native webbrowser for Haiku seems good to me, but the problem would be to code a proper render. Not impossible but it requires something different. Leave Gecko and KHTML and all those behind, and go another way. Look at the really small OS’es, like AmigaOS4 and other such modern OS’es with extremely small system resource usage. Get inspiration from them, rather than the large bloated systems used by the majority. Look at FoxIt PDFreader, to see how a PDF-reader is done properly. A browser should have pretty much the same size, extensions not accounted for.
fanton wrote:
Offtopic: What the hell is with all K's and Be's or B's in KDesktop or BeOS? Like KHTML.
Well, it’s just like all the apples on Apple and all the MS’es on Windows and so on. Call it lack of creativity 
Please don’t feel offended.
Why yet another browser project that will never finish? I know it’s very intriguing to write a browser, but we should keep in mind that there are not enough developers for such a project. We should concentrate on things that really improve the user-experience.
And I think that people do use the best application. Firefox is cool because it’s easy to use and configure. If it were a little bit faster I would love it. At university we use Linux and we have five or six browsers and I got crazy when I had to find Konqueror’s option to disable auto-saving password. Well, I gave up because I could not find it within five seconds. In Firefox I just open the preferences dialog and immediately see where to find these settings. Also, after a clean install I only change the default website, disable password and form completion, and maybe (at university) set the cache size down. That’s it! Look at the settings in IE. It takes half an hour to configure IE after a Windows reinstall just to make it comfortable to use. Why? Because I have to re-read all possible settings to remember which of them I normally change.
If KHTML is faster then we should make it our native HTML framework and create a browser around it. But make the browser as easy or even easier to use than Firefox.
Please don’t spend the time on writing a new engine. We need serious software. Otherwise nobody will use it because it does not display all pages correctly or because it’s incomplete.
But we also need native QT and GTK ports. And Haiku must be finished. Then, we need drivers (Intel integrated graphics cards, for example). An office suite (yT is already porting OpenOffice which isn’t BeOS-ish enough, later we need at least Abiword + gnumeric + some presenter). We also need Java (when will the port be finished?). Please take a look at our wiki:
http://www.haiku-os.org/wiki/index.php?title=Software_Wishlist
Here you will find enough projects. For example, you could work on the Haiku media player to do the things listed on the wiki page. I would love to have TrueCrypt ported to Haiku some day (after the high-priority tasks are finished). An NTFS driver would be cool. There are so many things that would improve our productivity and the user experience much more than a new browser project. BeOS had too many of those just-for-fun projects that vanished as quickly as Be Inc.
OFFTOPIC, again (last time!):
@wkornew
I would add to your list the following:
Instead of gimp i would try improving GimpShop which is Gimp that looks like Photoshop (it’s still beta i think).
p7zip is a 7zip port available in linux only as a shell command. Can do all that 7zip does but no gui. Can extract tar, gzip, bzip2, zip, rpm? (and a couple more) and of course 7z. This could replace all other commands like tar -xvf … or gunzip… A native Haiku gui frontend for p7zip would be nice for example
openoffice.org 2 is very good! i never used abiword. but openoffice has all i ever need. i never ever ever had the feeling a feature was missing. even has a database engine (a la access). but needs java i think.
fanton wrote:
OFFTOPIC, again (last time!):@wkornew
I would add to your list the following:
Instead of gimp i would try improving GimpShop which is Gimp that looks like Photoshop (it’s still beta i think).
p7zip is a 7zip port available in linux only as a shell command. Can do all that 7zip does but no gui. Can extract tar, gzip, bzip2, zip, rpm? (and a couple more) and of course 7z. This could replace all other commands like tar -xvf … or gunzip… A native Haiku gui frontend for p7zip would be nice for example
openoffice.org 2 is very good! i never used abiword. but openoffice has all i ever need. i never ever ever had the feeling a feature was missing. even has a database engine (a la access). but needs java i think.
Audacity is HORRIBLE
The Old “SampleStudio” source code is opensource, however, Xentronix are being quite forceful on the trademarks policy. Its a native BeOS app, a quick renaming would make it a decent audio editor. Audacity is not a decent audio editor.
No point in using p7zip for anything but 7zip, as removing other commands === destroy shell scripts, destroy portable software, destroy build systems, etc, etc.
MYOB wrote:
Audacity is HORRIBLE
No, it’s not. It’s FANTASTIC! (That remark is about as intelligent as yours. You are too fast to shoot down ideas…)
MYOB wrote:
The Old "SampleStudio" source code is opensource, however, Xentronix are being quite forceful on the trademarks policy. Its a native BeOS app, a quick renaming would make it a decent audio editor. Audacity is not a decent audio editor.
Define decent audio editor and indecent. Instead of just spreading BS. Audacity handles many different audio formats, loads instantly and has an intuitive and simple, but efficient UI.
So apart from your hatred against any non-BeOS native application, what is it that is SO wrong about Audacity?
MYOB wrote:
No point in using p7zip for anything but 7zip, as removing other commands === destroy shell scripts, destroy portable software, destroy build systems, etc, etc.
I agree with you on that one. However, I don’t think we will need support for 7zip very much. Bzip2 is more important.
…
And now for something completely different (C) Monty Python
When the amigans can handle a sort-of port of GTK then we can do the same. I really like their approach about a GTK->MUI translation layer, where the GTK-widgets are implemented by native widgets, with the GTK-code working as a sort of wrapper around the native widgetset. It gives applications a native look and feel which IMO is very important.
See for yourself:
http://www.amigasoft.net/misc/gtk/gtk2.jpg
http://sourceforge.net/project/screenshots.php?group_id=141931
And read more here:
http://www.amiga.org/modules/news/article.php?storyid=6535
Mr.Jones - the one and only ( I think 
)
Edited: Removed a screwed up url-tag
looking at how you people answer, i think each one of you has an unique perspective of what is useful to him/her. i don’t mind audacity. myob hates it. Mr.Jones loves it i think other people don’t care or use something diffrent.
rather than creating a new browser i think you people should fill wkornew’s list using some form of voting, or polls, or talking trough on forums.
i’m neither against nor for creating a new browser based on gecko or khtml. but why make a new browser when firefox will do?
Mr.Jones wrote:
MYOB wrote:Audacity is HORRIBLENo, it’s not. It’s FANTASTIC! (That remark is about as intelligent as yours. You are too fast to shoot down ideas…)
MYOB wrote:The Old "SampleStudio" source code is opensource, however, Xentronix are being quite forceful on the trademarks policy. Its a native BeOS app, a quick renaming would make it a decent audio editor. Audacity is not a decent audio editor.Define decent audio editor and indecent. Instead of just spreading BS. Audacity handles many different audio formats, loads instantly and has an intuitive and simple, but efficient UI.
So apart from your hatred against any non-BeOS native application, what is it that is SO wrong about Audacity?
MYOB wrote:No point in using p7zip for anything but 7zip, as removing other commands === destroy shell scripts, destroy portable software, destroy build systems, etc, etc.I agree with you on that one. However, I don’t think we will need support for 7zip very much. Bzip2 is more important.
…
And now for something completely different (C) Monty Python
When the amigans can handle a sort-of port of GTK then we can do the same. I really like their approach about a GTK->MUI translation layer, where the GTK-widgets are implemented by native widgets, with the GTK-code working as a sort of wrapper around the native widgetset. It gives applications a native look and feel which IMO is very important.
See for yourself:
http://www.amigasoft.net/misc/gtk/gtk2.jpg
http://sourceforge.net/project/screenshots.php?group_id=141931
And read more here:
http://www.amiga.org/modules/news/article.php?storyid=6535
Mr.Jones - the one and only ( I think
Edited: Removed a screwed up url-tag
Audacities UI is directly out of a 1994-era childs drawing, its utterly disgusting and completely unusuable
Audio formats are the responsibility of the media kit, NOT an application.
wxWidgets is one thing thats “So” wrong about Audacity, its UI is the next thing thats wrong with, not using B* classes for media work is another, and so on. WRT media, non native apps just suck on BeOS.
bzip2 is already supported in BeOS and in Haiku. However, its not a suitable ‘default format’ as it doesn’t do BeOS filesystem attributes, only zip does.
The way GTK+/GTK2 works makes it -extremely hard- to implement GTK widgets as anything other than drawing controls onto a portable canvas. GTK 2.8 makes this even harder. Don’t expect that Amiga approach to be sustainable in the long run.
Not to be rude, but could we get back on topic. This was almost starting to be interesting. Start that up in a thread of it’s own.
fanton said:
Quote:
i'm neither against nor for creating a new browser based on gecko or khtml. but why make a new browser when firefox will do?
Simply because there is only so much that mozilla.org will allow the BeZilla team to commit to CVS.
For instance, if they wanted to add replicant functionality or some other BeOS-specific functionality to the gui, they’d be SOL.
Also, there are times when updates to the mozilla code for other platforms breaks or generally fouls up the BeOS port. Thus requiring the BeZilla team to spend unplanned time and effort to fix those bugs, instead of continuing progress.
IMVHO the initial investment of time and effort to get
1. a HTML rendering engine embeddable
2. a basic native browser utilizing #1
would eventually make up for itself in the flexibility granted to the developers working on the actual browser.
There’d be no need for all of the dancing through hoops and leaping across pits to get a patch that took 3minutes to code checked in.
take a look at http://www.livejournal.com/community/bezilla/ and check out how long the average bug exists before a patch is committed to the repository.
finally, there’s numerous patches that can’t be fixed due to dependencies outside of BeZilla’s access.
Not to sound condescending (or to take shots at the BeZilla team), but there are quite a few reasons I can think of for BeOS to have its own browser. Speed, for example. Firefox is acceptable but nowhere near as fast as anything built for BeOS from the ground up. I imagine that if Net+ had the same features as Firefox does, it would still be faster. OS integration would be immensely easier, too.
Another reason is overhead. Firefox has its cross-platform goodness because the entire UI is written in whatever language/API it’s called (IDL, I think) and that adds to overhead. IMO, it’s akin to going through a big bureaucracy to get anything done. While the underlying technology the entire browser is based on would still be there, cutting down on the cross-platform code would increase speed and reduce overhead.
Like mmadia mentioned, features also come to mind. Wouldn’t it be nice to have a browser which has built-in ad-blocking features? AFAIK there isn’t a browser out there with that.
I have mentioned this before to the Bezilla team, but what stops you from forking Firefox?
koki wrote:
I have mentioned this before to the Bezilla team, but what stops you from forking Firefox?
I had the same thought. Why not fork it? K-Meleon (for Windows) is a fork of Mozilla, and much quicker than Firefox and Mozilla.
Of course the fork can’t use original icons and themes, nor the name, but who cares? BeOS like icons would be better, and if we should use non-BeOS like icons, it ought to be the Tango Project. But alas, they are not that BeOS-like. They look more like a blend of KDE and Gnome (and we don’t want that).
I’m not even sure about using the Gecko engine, but it’s easier than writing an engine from scratch, and a wiser choice than KHTML.