With Google Summer of Code underway for the Haiku project, the first results start coming in. The most exciting so far is the work being done on a native multi-process WebKit browser, worked on by Ryan Leavengood and GSoC student Maxime Simon. They’ve got an interface, and they’ve got most of WebKit to build.
They’ve been working on this project for about a month now, and so far, they’ve got a prototype of a multi-process browser, modelled after Google Chrome. Because Leavengood had already done work on WebKit, they had a good starting point. From what I understand, they currently employ a very, very basic rendering engine that displays a bitmap – this rendering engine will be replaced by WebKit once that port is completed.
They’re currently working on or have completed the following aspects:
- diverse forwarding from main process to render process (mouse move, mouse click…)
- a bookmarking library
- a toolbar
- support for multiple rendering processes
- tab management
The work on the WebKit port is progressing nicely. WebKit actually consists of two parts, JavaScriptCore and WebCore, and both of these parts compile on Haiku now. The hard work is still ahead, however: combining the two, and integrating them into the browser.
Chrome is quite clearly the source of inspiration for this browser, and that’s a good thing, as Chrome’s multi-process design really fits well into the BeOS world. Tab management will be modelled after Chrome’s, according to Leavengood. The following things are currently on the to-do list:
- make WebKit work ( some essential functions specific to the platform have to be implemented ),
- integrate it into the browser,
- port the Chromium networking code (this could be an article on this blog),
- improve the back and forward buttons,
- create an omnibox-like url field,
- and other mysterious things…
i really feel joy every time i read about some progress of haiku
I know it! I felt like this when I got my first OS X beta disk in the mail. Sooooooo close and still a good year away.
Or what is a non-native browser? A browser needing a JVM or CLR to run? Or one that runs inside an emulated OS (but why would it be called a Haiku browser in the first place)?
Please do not abuse the word ‘native’. It really turns off technical people. ‘Native’ means just that a program runs on a processor without emulation. Somehow I am pretty sure that it’s not what the author means. It might mean that it has been written specifically for Haiku, or that it uses Haiku’s default graphics toolkit, or that it is well integrated (file associations, etc.), or that it is ‘quick and snappy’ as opposed to ‘slow and bloated’, or that it just has a cool yellow tab at the top. The word ‘native’ has become a catch-all phrase here at OSnews lately and could mean anything from the above list or nothing at all. Wouldn’t it be more informative to say ‘dedicated’, ‘having a platform-specific look and feel’, ‘well integrated’, etc.?
I know that the ‘nativeness’ comes from the linked article. Still it is an article in its own right on OSnews (as opposed to a simple page 2 link), so I would expect the term to be either dropped or explained.
Just want to add that there seem to be only 4 or 5 tickets left on their todo list before they will begin the progress of finally releasing the Haiku Alpha LiveCD =)
Edit: (damn I always press Reply instead of Post Comment)
Edited 2009-06-22 13:15 UTC
There have been 4 or 5 tickets for some months. 5 months before Christmas 2009 it was 7 left. They are not simple issues, it seems.
True that there’s only been 4 or 5 Alpha milestone tickets open the last few months, but if you check closely you’d see some were fixed and new ones discovered. Four of the six currently open tickets were opened in the last few months, with only one being from the original alpha tickets. so far over 180 alpha tickets have been fixed. And most of the items on the Alpha status wiki page have been marked off as being done now as well. But yes the remaining open tickets appear to be tough ones to fix.
http://dev.haiku-os.org/wiki/R1/AlphaStatus
One thing to note is that it is now possible to create a bootable Haiku CD iso image and burn that to a CD in Haiku (or burn that iso using whatever burning program you normally use)… and then boot it and run it as a live CD, it’s not the fastest and it’s still being worked on, but it’s mostly working now.
Native means that it will make an extensive use of the Haiku API.
Opening images, sending BMessages between processes, GUI/widgets, threading, networking – there are cross-platform APIs that can do all this. Or you can take the do-it-yourself path and implement your own GUI(like Mozilla did) or message passing between processes(like Chrome).
A true native Haiku browser should use the native APIs to implement these tasks – resulting in less bloat and better integration.
No, English has many different definitions of words. Its not be used incorrectly, nor is that obscure of usage. Any “technical” person should have no trouble understanding the context the word is used in.
Correct. This is from a linguistics major. (clapping)
First of all – my initial post was a bit to inflammatory, sorry about that.
That’s true, and not only with English. But the problem is that a word with a precise meaning in this context (native ~ running without run-time translation) gets other unrelated meanings. Obviously this makes things harder to understand.
In this case you’re right – most browsers are compiled to machine code for speed anyway (that’s also true for Mozilla, regardless of XUL), so one can figure out that ‘native’ needs to mean something else here. But the problem can get more complicated. For example – is Tomboy ‘native’? After all it’s part of the GNOME project, uses a typical UI, is well integrated. Quoting BluenoseJake:
So you could say that Tomboy is as native as it gets. But then it’s also not native – it requires a CLR and thus it is not even available for all of the platforms supported by GNOME. Don’t you agree that the word ‘native’ can cause confusion here?
Btw. it seems that there are no major ‘native’ Windows browsers. Firefox/Seamonkey use their own theming engines, same for Opera and Chrome. IE uses custom widgets starting with at least version 4 (resizable toolbars). The most ‘native’ browser seems to be K-meleon, and that also seems to have changed lately. But honestly: how many Windows users care about K-Meleon?
Edited 2009-06-23 11:09 UTC
Really, you’re just sounding like an ass now… those who actually care know what was meant by the context in which this was used…
FWIW, I have had similar ongoing, pointless, endless discussions about “native” and what that means when discussing partially-ported software… and it just gets boring and tedious after a while.
Bingo. That’s why “native” fits in this context.
This may sound silly, but can Google patent their “multiprocess” web browser design?
Not knowing Chrome’s internals, I venture a guess that there is little truly -new- about its multiprocess design, but merely application of good architectural concepts that have been around for a very long time, and thus little reason to grant a patent. There may be some prior art in the browser ‘Voyager’ included with QNX, and likely countless other software.
– “omnibox-like url field”
If any of the developers are reading this (Maxime, Ryan and co), please make omnibox-like url field an optional component, so that one can replace it with a traditional separated url + search widget instead.
We like choice
For those of you who don’t know what an omnibox is; http://dev.chromium.org/user-experience/omnibox
OK, I feel like I’ve woken up in an awesome alternate reality here …
I can’t believe Haiku has come as far as it has, it’s looking really slick now! A webkit-based, process separated browser would be … well, better than what I’m using on Linux 😉
Fantastic stuff, can’t believe how this project keeps zipping along.
When the naming issue appears, I will vote for new generation’s “NetPositive” brand, sir!
Oh, speaking about native software. I do want those nice add-ons support too, which was a great thing back to the glorious BeOS days. And, btw, Mozilla-way to manage add-ons/plugins is very well & easy to use (not through developer’s perspective of course, but from the point of ordinary user).
Thanks again, guys. Haiku progress is so exciting right now, but you’re know it, more than anyone else
Native browser = doesn’t use JVM or CLR or XUL and is fully compiled into native machine code. That is the only definition.
Anything else is stupid philosophical discussions.
XUL isn’t a virtual machine. Nice consistent definition you gave us there.
In this context you’re wrong. You’re speaking as a hardware person who’s talking about programming the machine. In the context that ‘native’ is used in with this case, the meaning is different. It means that the software uses the API’s that are available in the operating system’s environment (native) to solve problems. This refers to topics such as IPC, synchronization, etc. Obviously, native doesn’t always refer to hardware & microcode. The processor isn’t the only part of the computer that has an environment, the software has one too. You’d do well to be mindful of that.
… if using student forces is the right thing to do. their code generally sucks hard and it’s maintainers who screams in agony because of immature architecture and code full of stupid bugs.
I recently gave Haiku a spin on my ASUS EeePC 901 from a USB key, and found it very much like the BeOS of old. The included Firefox was an older version, but still quite functional. What was really noticeable was the lack of WiFi support–the wired connection works, but Haiku doesn’t even begin to have basic WiFi support, it has nothing to do with there being a lack of drivers, there’s a lack of interface for the drivers to hang on to! Other wise I was impressed by Haiku on my EeePC, but without ACPI and without WiFi there’s simply no way I can justify it for every day use.
I understand there is a project underway to add WiFi from BSD drivers, I just wish that had been the focus of the GSOC rather than a “native” web browser.
Still, it’s been almost ten years since BeOS died, it would be nice to see some more progress to show for it. I want my batmobile dammit!
–bornagainpenguin