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.
Post a Comment
Member since:
2007-07-26
Member since:2005-07-06
Member since:
2005-08-07
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.
Member since:2008-11-27
Member since:2007-04-13
Member since:2005-07-08
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.
Member since:2005-07-06
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.
Member since:2006-07-14
Member since:2009-06-09
Member since:2005-08-07
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:
Bingo. That's why "native" fits in this context.
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
Member since:2006-01-26
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.
Member since:2005-08-11
Member since:
2006-01-03
Member since:2005-07-11
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.
Member since:
2005-07-26
- "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
Member since:
2005-07-06
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.
Member since:
2008-08-01
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
Member since:
2006-08-17
Member since:2009-03-20
Member since:2009-01-09
Anything else is stupid philosophical discussions.
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.
Member since:
2005-08-07
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