Is Chromium available as a pre-compiled .pkg package or is there a browser based on Chromium for Haiku?
no no chromium however there is a native webkit port and is what Web+ is based on try that… there are also several QT based browsers that use webkit.
What is the advantage of QT browsers? Any they any good?
Web+ is your best bet I think the package is acalled Webpostive you can use the installoptionalpackage command on the command line to install it. The pacakge manager isn’t quite finished yet so an install script for common package is still used.
Yes, but WebPositive comes with Haiku already! 
What is new on the subject?
Chromium vs Firefox — whith is simpler to port?
Neither is easy. But why do you need an n+1 browser? Why not fixing/improving the existing one? Why do you expect miracle for an other port? A dirty port is always possible, ofc, but what would it bring? It would be also pretty crashy in the first decade and both of them have plenty dependencies, which all of them have to play well together, to be usable as you experienced them on other OS. Do you expect the port from a handful developers, fans? If you have a good reason to have yet another browser port, then start to work on it and if it looks reasonably good somebody will joint to you to help.
Perhaps a possible alternative to porting Google Chrome is to get Falkon (formerly QupZilla) working on Haiku. It utilizes Qt WebEngine, which uses Google’s Blink browser engine. There’s already a version of QupZilla available on HaikuDepot; maybe someone could build upon that and get Falkon working instead.
You’ll have much the same experience with Falkon as with Otter browser… just a different UI as both use QTWebkit.
Otter browser in the repo aims to imitate Opera which is a good UI so I don’t see the need for Falkon though in the grand scheme of thing’s it would probably be easy to port. I don’t think you’ll see chromium any time soon as it would require too much custom work on the UI.
Firefox could happen though, probably as soon as we get hardware accelerated 3d support… then we’d have an accelerated browser on top of Vulkan via gfx-portability (which is what seems to be worked on for Firefox on Linux and has been making some big improvements there.). Firefox seems to be the only browser attempting to push into multithreaded rendering also which is an ideal fit for Haiku. The mozilla guys are fixing a lot fo portability issues by using rust and portable libraries… so hopefully it would be mostly just fixing minor build issues to get it working someday.
Note servo doesn’t build for some reason, it’s a problem with pip and virtualenv being somehow broken.
both use QtWebkit
Nope. According to Falkon’s about page:
Falkon is a KDE web browser using QtWebEngine rendering engine
and about the browser engine used:
QtWebKit is now deprecated and new versions are using QtWebEngine.
So instead of arguing lets just present the facts.
Both Otterbrowser actively, and Falkon/Qupzilla in the past and as is in the repo support QtWebkit. The browser itself is basically just the UI, so as QtWebkit gets updates… all browser UIs that use it get improvements even if they are no longer maintained upstream. QtWebkit itself is probably a dead project as of about a year though there is still some work done on it by Otter browser people.
Otter Browser also supports QtWebEngine actively, and Falkon only targets it. QtWebEngine will likely only be usable once we have hardware acceleration much like Firefox.
QtWebEngine is what needs to be ported mostly. Once that happens the rest will fall in line.
1 Like
I would much prefer if people would spend some effort improving the already working and maintained native port of WebKit. I’m leaving pleinty of easy bugs to fix, in the hope someone else will look into them. But no, people will “look, squirrel!” and attempt porting Chrome or Firefox instead. What can I do then?
3 Likes
At least for those clamoring for a Chrome port, a possible alternative would be to natively port its Blink engine. That alone would open up more potential features for web browsing under Haiku, not to mention that application components using it (e.g. Chromium Embedded Framework, Electron, QtWebEngine) would now become feasible to bring over. At the moment, it and Gecko are the two most actively developed and open-source browser engines out there. Someone correct me if I’m wrong, but isn’t Apple the only major contributor left for WebKit since Google forked away?
Addendum: What would be more effort to get a native port of, Blink or Gecko? For the former, it is a fork of Webkit that has started diverging a bit. As for the latter, an earlier version was already available (in BeZilla) but it was such a long time ago and current versions are quite architecturally different in many aspects. I am genuinely curious as to the answer for this one.
If you ignore Samsung (EFL, Tizen) and Igalia (GTK, Epiphany, + embedded stuff), then yes, Apple is alone on WebKit 
In any case, WebKit is already ported and even if it was just Apple, still maintained. So it is less effort than porting Blink or Gecko and it also “opens up more potential features for web browsing under Haiku”. Why restart from scratch after we invested man-years of effort in it?
3 Likes
Why restart from scratch after we invested man-years of effort in it?
Well, you don’t. Despite its diverging codebase, Blink is still a Webkit fork. That means that some of the code used for bringing its parent over to Haiku can be reused to make the porting process faster. How much of it can be exactly is what I don’t know; that said, it will probably be a not-insignificant amount considering that they still have many similarities (for now).
No, not at all. Blink was forked from WebKit when it became clear that it was effectively two codebases in a single SVN repo. Different JavaScript engines, different approach to portability (WebKit plugs to native APIs for text rendering, etc, as much as possible; while Blink is more “give me an OpenGL surface and I’ll take it from there” - and similar things happen for the HTTP implementation, etc).
Also, the fork was, what, 4 years ago? Do you expect the codebases are still that similar after such a long time?
5 Likes
Do you expect the codebases are still that similar after such a long time?
To a certain extent, yes. They both were originally based on the same codebase. That being said, I did still acknowledge their divergence:
For the former, it is a fork of Webkit that has started diverging a bit.
and
Despite its diverging codebase, Blink is still a Webkit fork.
Okay for that “a bit” portion, I will admit that may have been an underestimation in hindsight. But the point still stands that Blink was forked from Webkit.
Back to the question of bringing either Blink or modern-day Gecko to Haiku. Would it take more effort of porting the former (originally a fork of Webkit, which already was ported) or updating the latter to a recent version (the last one was from decades ago)? Both will probably take lots of effort (moreso than maintaining the Webkit port), but both are also being worked on more actively and support more web standards/technologies. So, which one is it?
Frankly some of us just really like Firefox… so Firefox it is ahem. Also the new multithreaded rendering stuff in FF really makes the squirrels go wild 
But I think you have a valid point for the other webkit browsers even though they technically rank a bit higher on the features supported, they loose out to Web+ being native. Honestly personally I’d rather buy you a few pizzas and let you fix low hanging fruit in a project you already have a grasp on. But if you find someone interested in working on the webkit port with you that’d be great too.
I really miss adblocking on Web+ a hosts file can help but still… Also I’ve noticed that it crashes/hangs a lot more on my hardware than on a VM so squints. What hardware do you mostly test it with Pulkomandy? could video driver affect this too? One of my peeves is the system color prefs not being respected so I may take a jab at that. Deskcalc and Tracker offend there also.
Would it be possible to do blocking at the network kit level? One of the ways firefox has been speeding up browsing is delaying loading of trackers… perhaps there are some good ideas there.
Blocking at network level would not get much smarter than an hosts file. There isn’t much knowledge about the data being managed there.
My hardware is an old Dell Vostro v131 laptop. I also have a more recent desktop machine but I prefer working on the laptop because I’m often on the go and want to be sure I have my sourcecodes around
Crashes are more likely related to running out of memory, although this should improve once Haikuwebkit 1.6.7 lands in the repos (I fixed an important memory leak there).
2 Likes
Well when it happens I see there are a ton of Cryptoques and BUrlProtocol.HTTPs in processcontroller… it seems when it’s working normally these come and go instead of sticking around. Also my netbook has 8GB… so OOM is unlikely.
Also my laptop has 4 cores / no hyperthreading, it’s an AMD A4-5000, I’m guessing your’s has 2 cores + hyperthreading? I don’t conceive of that causing that big of a difference though.