Vivaldi for Haiku?

Has anyone tried contacting Vivaldi to see if they will build a version of their browser for Haiku? It is my browser of choice now and would be a great addition to Haiku. We need a more modern browser and the first WebKit2 or other modern engine that is built for Haiku will have a leg up on getting adoption as the preferred Haiku browser.

1 Like

WebPositive is using a modern version of WebKit. WebKit1 vs WebKit2 is just the version of the API used to interface with the engine, and has no consequences on the support for web technologies or anything. We should of course try to keep it more up to date (not very hard) and continue to improve our rendering code (not so easy, the non-OpenGL parts of the code are not always at the center of attention from other ports) and network code (a little easier, but it would be nice if it was not just me taking care of it).

As for Vivaldi, it uses the Blink engine from Chromium, so it is not easier to port than Chromium, plus I’m not sure what their license is and if we’re allowed to port and distribute it.

More choice of web engines would be nice in any case. Competition may motivate me to make Web+ better :wink:

1 Like

[quote=“PulkoMandy, post:2, topic:5491, full:true”]
As for Vivaldi, it uses the Blink engine from Chromium, so it is not easier to port than Chromium, plus I’m not sure what their license is and if we’re allowed to port and distribute it.[/quote]
Parts of Vivialdi are closed source, which is why we would have to ask them to port it, we couldn’t.

[quote=“PulkoMandy, post:2, topic:5491, full:true”]
More choice of web engines would be nice in any case. Competition may motivate me to make Web+ better[/quote]
If we could get the support of a major browser vendor that already has a modern working guts and just needs to put an interface over it for Haiku, that would free up time for you to do other things :slight_smile: It would boost their presence and user base and give us a big plus for available features. So many things now are web based that you don’t always need native applications. I have started using NextCloud which gives you notes, bookmarks, todos, calendar and even an RSS feed reader.

Knowing the effort that were required to port WebKit, I doubt it would be any different for any other engine. You can’t really expect it to be a “./configure ; make” kind of thing. They need fine grained control on a lot of platform specific stuff: threads, memory management, processes, sometimes live generation of code for JavaScript JIT, how to put pixels on screen, which network backend to use, etc. If it was an easy and short task, it would have been done already.
Moreover, our work on WebKit is much more than just bringing a browser to Haiku. The ultimate goal is to have a BWebView that can be easily embedded in other applications, and used to render web pages inside them. This has already led to several improvements to the OS itself over the year: better APIs for text rendering and drawing layers in app_server as well as tracking bugs in the affine transform support and its interaction with clipping; a complete HTTP support library that made it possible and easy to write apps such as Weather, HaikuDepot, fRiSS, HaikuToDo, and the like, and would also make it possible to have a Dropbox filesystem or other stuff making use of REST APIs. A browser isn’t all there is to the web, and it is yet another place where we can show how it pays off to have a fully integrated operating system, where everything just fits together, and how we manage to make this work even with web apps. It is indeed a long road to get there, but it is an interesting challenge, too. Much more than just porting an existing browser and running that, I think.


You might want to give Otter Browser a try. Otter is available thru Haikuports. I’ve been playing with various builds of Otter for the past month on the latest X86 builds (I switch back and forth between X86 and X86_gcc2 builds). If you do decide to try Otter, be advised it’s still requires work. The builds are still unstable, and do crash although it is getting better with the later builds. I modified the recipe in Haikuports to build the weekly builds and I’m currently running a weekly build dated 3/13. You’ll also have to modify the recipe or manually add both /home/config/cache/Otter and /home/config/settings/Otter/otter/sessions.




One thing I forgot to add. One of the main reasons I started playing with the weekly builds was all the builds until I believe 3/6, you would be bombarded with SSL warnings that would pop up on every site that you visited. I used to either disable javascript or disable cipher in preferences to get around the SSL warnings.

I guess it uses QtWebKit for rendering? This works ok but is even older than the native WebKit port, so I don’t expect it to do much better than WebPositive. I happily accept bug reports in places where it does, however :slight_smile:

Otter main development has switched over to QT Web Engine for development…which opens up that other can of worms. Happily though, it still will build using QT Webkit unlike Qupzilla which switched to Qt Web Engine for rendering in versions 2.0 and above.

Thanks, I will take a look at this. One thing that really seems to trip up Web+ is online file storage systems. I found google drive worked the best, but I have recently deleted my google account and am totally google free.
I found the recipe on the haikuports github site, but to be clear to others who may read this it is not available on HaikuDepot.

There is a more or less known problem in our WebKit port with uploading files.

However, I think Dropbox, Google Drive and the like would be much better implemented as native filesystems (userlandfs or fuse), rather than through the browser?

1 Like

Yes that would be nice :slight_smile: There seems to be a lot of interest in GSOC so maybe if there are more applicants than projects these would be a good backup option.

1 Like

How did you build Qt5.8.0? After all, to build it you need a Flite, but it’s not built under x86_gcc2

I was able to build QT 5.8.0 on x86 by removing the dependencies for both flite, and flite development. Flight is a run-time speech synthesis engine, and I thought it wasn’t really required for the build of QT 5.8.0.Be advised though, if you build QT 5.8.0, it takes an extremely long time to build.


I forgot to mention, you don’t need to build QT 5.8 in order to build Otter Browser. I did a bunch of builds of Otter using Qt 5.5 that was available thru Haiku Depo for x86.

Yeah, I know. I now have Qt 5.7.1.
I use Otter Browser myself, and I also build its weekly builds:

It have html5 support?

Unfortunately, no.

I just finished building gstreamer and gst_plugin pkgs. I’m going to rebuild QT, and see if I can get gstreamer functioning under QT multimedia.