Use the source “luke” 
(grepping through there didn’t reveal it to me) 
4 Likes
Amazing work, I am really looking forward to trying this, but I’m worried this might cause fragmentation in the Haiku community, should we rely on a compatibility layer for something as essential as a web browser?
You may not use ported applications, but use only native
I have never understood the complaints about the presence of ported software in Haiku. Nobody forbids you to write native programs or use only native ones. That’s why haikuports exists, to contain ported software. Isn’t it so? You can want a native office suite as much as you want, but the reality is that without a ported office we won’t have any. I have been using Haiku as my only and main operating system on my home computer for several years now and I need the software here and now.
PS: By the way, the native WebPositive browser is built on haikuwebkit, which is also ported. Yes, haikuwebkit is more fully integrated with the system and more fully uses its API, but it is still ported, although it uses fewer layers between the program and the system. I’m all for being able to choose.
26 Likes
I 100% agree. And you port guys do amazing work!!! Thank you very much.
1 Like
Web browser engine is extremely complex software, much more complex then OS itself. Haiku development team is small and have to resources to make fully featured web browser. Serenity team make it own browser, but its compatibility with modern web is very poor. Even Microsoft abandoned their own browser engine Trident and switched to Blink.
So we have 3 possible choose of browser engines:
- Gecko (Firefox)
- Blink (Chromium)
- Webkit (Safari, Epiphany)
Firefox have its own very cryptic build system with a lot of hardcoding on common Linux distributions. It is currently not possible to try to build Firefox even if all dependencies are provided. Nobody form Haiku team knows how to adapt Firefox build system to Haiku.
Blink is Developed by Google and they refuse to accept patches for uncommon operating systems such as FreeBSD or Haiku. Blink need very powerful PC for building that I don’t have. Currently Blink is ported to Haiku in Falkon browser, but it crashes a lot for unknown reason. Investigating crash reason need ability to rebuild Blink from sources that is impossible on weak computer.
Webkit is currently best suitable for Haiku because it already works as part of WebPositive and Qt-based browsers. It is also more lightweight need much less resources for building. WebPositive implements native Haiku backend for Webkit, but it is incomplete and cause poor compatibility with modern web. Practice shows that Haiku team currently have no resources to complete Webkit native backend, but it may be possible in some future.
Qt based Webkit browsers exists on Haiku but unfortunately Qt Webkit is abandoned in new Qt versions and last supported version is already too old to support modern web.
So the best realistic option in current situation is using Webkit GTK based browser because it it can be ported with little effort, stable enough and have good modern web support. Other browsers can be ported/improved later when somebody will do it.
21 Likes
As long as the GTK interface can be adapted to Haiku’s Interface and it stays as a third party web browser in HaikuPorts, then I don’t see that as a problem.
Problem atm is that gtk3 and gkt3-wayland can’t co-exist I think, one needs xcairo the other cairo and both can’t be installed at the same time.
2 Likes
gtk3 will be built simultaneously with both backends. The wayland backend will be used by default, but you can choose to use xlibe with the GDK_BACKEND variable.
9 Likes
I am a bit confused by that because to me it looks like it took many hours of development effort to get into this state: writing a Wayland compatibility layer, porting GTK on top of it, etc. And I expect there will be some more work in making this look reasonably integrated with the OS.
Maybe my view of things is distorted but I would at least not say that native webkit is unrealistic. It needs some hours of work as well, sure. And I (together or against the other people in Haiku) have not always made the best decisions, for example in attempting to build our own HTTP library instead of using curl, in putting aside the work to migrate off webkitlegacy and then trying to implement the new webkit2 inter-process communications with BMessage instead of using the portable UNIX code, possibly also in deciding to use app_server and BBitmap for rendering instead of using cairo.
Not all is lost however, and it’s not difficult to switch back to a curl/cairo/unix ipc solution. In fact I have already done it for curl in the current test builds of haikuwebkit (in a way that we can now easily switch between the two with a simple compile time option). I think the plan is to do the same for cairo vs app_server, and then attempt to build webkit2 using Unix IPC? At that point we will be sharing quite a lot of code with webkitgtk, and the main problems with the current haikuwebkit should be gone. Then we can see about adding a nice API around that, that allows to easily integrate it into Haiku applications.
And we can reconsider moving back to our “native” code for one or more of this as the corresponding system libraries get better. And also, if we can switch between native and 3rd aprty libraries easily, we can compare them and see if a given problem is in our native libraries, or somewhere in shared webkit code.
22 Likes
Wayland is quite simple compared to X11 or internal GTK backend API so it is not a big problem. Sources are here: GitHub - X547/wayland-server: In-proc Wayland server for Haiku. It compiles in a few seconds into separate add-on so it is really easy to test new changes.
GTK need very few changes to run on Haiku with Wayland backend: haiku: fix Wayland build · X547/gtk@f8eb0ae · GitHub.
Webkit is hard to work with. It takes hours to build and for me Git shows mmap errors when pooling changes. Blink is even harder, I currently have no hardware capable to build it.
Why not have both? Have Webkit GTK that works just now (almost) and native backend when it ready.
4 Likes
if i were to get you acess to a build server IE a server with 32 64 cores massive ram etc, would that suffice for your build needs ???
Firefox “almost” worked
otter “almost” worked
falcon “almost” worked,
Nice there is another one on the list.
Granted webkit is not a bad engine but honestly, it sounds more like your time would be better spend fixing git? Webkit is Very close to a working webkit2, with cairo and curl, and it would have taken less time than doing all this other stuff you had to do to port gtkwebkit.
It never worked past Firefox version 2 that is more then 10 years old and incompatible with modern web.
Webkit Qt backend is abandoned 
Need too much resources to build. Of course it is not possible to fix crashes without building it. And Google is too negative at accepting patches for not so widely used OSes. For Webkit we at least in theory have possibility to upstream Haiku backend.
I would prefer that WebPositive will stay on native Haiku backend. It is a great chance to improve app_server 2D graphics rendering. It is nothing wrong to have 3rd-party web browser such as Epiphany. Windows users often install Chome that don’t look native anywhere.
8 Likes
Yes, it would be best. And personally I am working on improving the rendering of it.
But stuff like webkit2 is out of my comfort zone, webkit is not “that” scary imo. If you want to take a shot to make that build go ahead
Yes, users install chrome, and with it all the tracking that comes with it. Honestly I am happy chrome and firefox don’t run on Haiku. Epiphany is great but it will never be native or close to it, Personally I want an awesome webpositive. Though epiphany is nice to test against (I use safari on my phone for that also :D)
4 Likes
Yes, having both is nice
I was just reacting to your statement that WebKit GTK is “best realistic option in current situation”, and wanted to say that haikuwebkit is not that far behind.
All options are worth experimenting. And it’s also possibly good to stop going too far in a direction when it proves too complicated, costly (in terms of time sepnt), or just because things don’t go as expected and someone decide to abandon their engine as happened to QtWebKit.
It still all results in learning new things about web engines and porting software, so, not all is lost, even if there is in the end not so much progress for users during these steps.
16 Likes
Amazing work! Gnome Web is currently working on support for extensions, using the same format as Firefox. This will hopefully bring it closer to more established web browsers.
I also highly disagree with complaints that applications are being ported to Haiku. What would you actually do on Haiku without foreign applications? A Haiku without:
SDL
Emulators
Webkit
freetype
ffmpeg
GCC
There wouldn’t be any applications left. And let’s not forget about drivers. The ported network drivers, or the 3D acceleration that is being worked on shouldn’t happen either then, because drivers are being ported from another OS, instead of being written from scratch. This is pure insanity.
3 Likes
31 posts were split to a new topic: Port of Gnome Web (Epiphany)
A handful of questions
Could wayland be a replacement for the app server ?
Can the graphics drivers from wayland be recompiled on haiku and run under system control?