Submitted by BeOS came with a relatively straightforward browser called NetPositive, or Net+ in shorthand. Especially by today’s standards, it can hardly do anything more complicated than rendering basic HTML, so it isn’t of much use. Luckily, Haiku has a successor now, born out of the HaikuLauncher conceptbrowser we talked about earlier: WebPositive.
Development on HaikuLauncher has only accelerated after we first talked about it not too long ago. HaikuLauncher has now once again been reduced to a mere browser shell, and a new codebase has been split off from it called WebPositive – the actual browser.
“Of course my continuous updates to the package I posted in my first article will probably have spoiled most of the surprise, but HaikuLauncher has been reduced again into just a bare browser shell, while a new codebase, WebPositive, has been split off from it,” Stippi writes, “Using WebPositive has become a whole lot more pleasing in the meantime.”
The list of improvements that have gone into the project over the past ten days is staggering: smooth scrolling, auto URL completion, favicon support, a rewritten tab view, a stop button, more keyboard shortcuts an even some mouse actions, and a whole boatload of bug fixes and performance improvements.
“So far, I’ve been working full-time on WebPositive, often from ninish in the morning to about midnight, with some pauses in between of course,” Stippi details, “Except for missing bookmark support and an almost useless browsing history menu (because seemingly unsorted), WebPositive has become quite usable – which makes me very happy of course.”
A lot of work is still ahead, such as context menu support, a way to change application settings, persistence across WebPositive sessions, and more. Beyond those basic features, Stippi wants to look at HTML5 and plugin support.
It’s hrf instead of href on the screenshot link
Web+ FTW!
This’ll make or break Haiku. People will be drawn to the platform because the web will work as well as anywhere else, and stay for the native apps.
I would love to see something a bit more radical as far as browser layout though. I feel the browser tabs, location and buttons should go on the _bottom_ of the window. I always thought this was a more natural, obvious place for navigation as it moves content closer to the top of the page, and the location bar also works as a status bar, telling you the current location. I also find it easier to look at the bottom of the screen, below the reading line, than at the top of the screen which is further away.
Or better yet make the tabs “panel” dragable around the window just like the haiku menu
I can see how people can be comfortable with different layouts (or full on shortcut keys in the cause of some) I think that sort of configurability is what is really needed not fancy themes like seems to be the trend (seen firefox 3.6 anyone)
Edited 2010-03-04 15:27 UTC
Somewhat OT: there was an old (R4, I think) app for BeOS called ActiveApp, it more-or-less did what you described in an application-agnostic way. It was a free-floating vertical tab bar, listing all of the child windows for the currently-active application – clicking one of the tabs/buttons would bring that window to the front.
Sadly, all of the download links seem to be dead so I never got a chance to try it in Haiku.
Well that sounds like it would be replaced by some modification to stack&tile
Deskbar has an expanded view that lists all running windows of the running applications.
One of my weekend hacks from the early naughties that lives on. 😀
Edited 2010-03-05 14:20 UTC
Of course, considering the browser is in infancy maybe I’m expecting too much but:
1. I was actually expecting it to look like NetPositive, whose interface I really liked (probably out of nostalgia)
2. Tabs inside a tab? That feels weird. Haiku needs an native tab/window manager..
Haiku has an amazingly flexible architecture. It would be interesting to add replicant capability to Web+. This would allow you to embed a browser object ANYWARE in Haiku.
How cool is that?
Even better than being a replicant – which WebKit design currently make a bit hard to do – a BWebView object is in the work…
That’s not entirely accurate, you can only embed it into something that actually accepts replicants. Tracker implements this by embedding a replicant shelf in the desktop, but that’s not something automatic/universal, nor is it desirable in all cases anyhow.
I installed it in haiku and it gives me an error…:(
What type of error message?
If you’re using a GCC2-build of Haiku, it will NOT run WebPositive (which is a GCC4-built app and requires Haiku GCC4 or GCC4-hybrid)
If you’re using a GCC4-build of Haiku (it says “GCC4” in the “About This System” program, under the revision of Haiku), then the only error message I’ve gotten is that WebPositive wants some “libsqlite3.so.0” and “libxml2.so.2”.
Type “libsq” in the search bar over at HaikuWare, to get the 82Mbyte zip archive of all the GCC4 .so files you’ll need for everything (I think) you could possibly imagine.
Then WebPositive worked fine, for me.
It runs just fine on a gcc2hybrid. There is no need to go with a gcc4 or gcc4hybrid installation of Haiku. Especially since the official release of Haiku R1 will be a gcc2hybrid.
This raised another question I’ve been pondering for a while. Anyone knows why they feel it is so important to be backward-compatible with BeOS?
How many programs written for BeOS actually has any meaning today? Aren’t they all dated by now in one way or another?
For one, it provides a limited scope at least. It prevents people from arbitrarily expanding the API/ABI and instead focus on making the system just work properly, as well as, and even better than BeOS did.
There was at least one closed-source library that a few apps still use, Marco’s liblayout (http://bebits.com/app/3363) it is used in SoundPlay and Wonderbrush, and likely some other apps that are still useful.
I suspect Wonderbrush will eventually be migrated to Haiku’s built in layout kit system (which is unfinished, and the public API hasn’t been solidified yet). I gather there still isn’t a replacement for SoundPlay that is nearly as awesome… and only an older version of SoundPlay runs on Haiku due to the use of some private API from BeOS…
Actually, Web+ works with gcc2 hybrid too. At least for me. Good work Stippi!
What … kind of error did you get.
Please, Please, Please tell me it was
Errors have occurred.
We won’t tell you where or why.
Lazy programmers.
or
The code was willing
It considered your request,
But the chips were weak.
or
To have no errors
Would be life without meaning
No struggle, no joy
And not some stupid boring error message. The NetPositive Haiku error messages were one of my favorite things about the os. Considering the name of the OS is Haiku, it *needs* to have web browser errors in Haiku.
or
“These three are certain:
Death, taxes, and page not found.
You, victim of one”
or
“Something you entered,
Transcended parameters.
The site is not known”
or
“With searching comes loss
And the presence of absence:
The site is not found”
Yes! Exactly! I loved the error messages in Net+ – they always put a smile on my face.
I took it for a spin over at the ACID benchmarks and SunSpider.
I renders ACID1 content 100%. ACID2, with only one small flaw on the nose. ACID3 gets a 98/100 with “Linktest Failed”.
And, on my Athlon XP system, I get 4,390ms on SunSpider!
Opera and FireFox get vastly slower scores, in Ubuntu, on the same system. But Chrome (which also uses WebKit) blows FireFox/Opera outta the water and manages to even outdo WebPositive (1,000ms+ vs. 4,000ms+) for now.
But I am so shocked by how well WebPositive performs, overall, even at this stage of it’s development, I can’t tell you how enthusiastic I am to see future releases!
Oh, and just in case you’re wondering… WebPositive on a Pentium II/266 (Intel 440BX board) with 128Mb of RAM… gets… 33,000ms!!! I think that’s VERY impressive, considering Opera on a 64-bit 1.8GHz Sempron (3200+), in Ubuntu (Intrpid Ibex) gets 15,000ms+! That’s just a little over twice as slow… on a system that has 1/8th the RAM, 1/7th the processing power (266MHz x 7 = 1.862GHz), on a 100MHz FSB!
Go, Stippi, Go!!!! AUSA!
That part at least is a bit less surprising for the moment ; Web+ currently isn’t using JavascriptCore’s JIT mode due to it crashing for not yet determined reasons. Once this has been fixed, the times should be noticeably better.
Info on implementing replicants:
http://www.haiku-os.org/documents/dev/replicants_more_application_t…
Here is Web+ displaying a webpage in Japanese:
http://haikuzone.net/files/temp/2010-03-05_webpositive-jp.png
Using rev. 286 with configured to use the Takao font set.
…and I am hoping that at least 1 out of 10 people commenting on form or functionality of the apps that have been presented here or on the Haiku site will actually get down and dirty and write something for Haiku.
Heck, when it goes Beta I think I will be writing little apps here and there, utilities and such, that people might find useful.
I would love to get something like TortoiseSVN on Haiku, and with the flexible file system, I think that should be quite possible. Oh the fun we might have!
Just use the command line?
You missed the point. The point was that it is easy and fun to develop utilities on BeOS/Haiku, especially with its heavily attribute-flxible-database-like file system.
Seems to be a stunning app.
Or at least interest in a webkit port on Be/Haiku, given what buggy unstable TRAIN WRECK every Gecko engine based browser on the platform has been.
Taking it for a spin, they’ve made more progress the past three years since we first saw Webkit on Haiku rendering beBits back in ’07 than we’ve seen with any of the Mozilla based browsers over the past DECADE.
Good work guys!
Ouch! That’s a little harsh. I thought BeZilla was pretty good in its time. Yeah, it rarely remained stable and yeah, I ran R5 with Bone.
The man speaks truth, Mozilla have really got their work cut out for them with the mobile space. WebKit browsers are popping up everywhere, and Mozilla only have a release on N900, and that’s it. I hope to see Gecko available much wider then that as WebKit needs the competition (they cheat with CSS selectors for speed gains)
When Apple forked KHTML they made an ‘unpouplar’ at the time move.
In hindsight, I’m so very glad that they did. They clearly made the right decision.
In truth, it’s an entire new system, and needs of new apps.
WebPositive shows us that a brilliant app can be small
Is the best browser that I have seem already