I’ve started looking into the HaikuWebKit framework and thought this thread could be a good place to collaborate. I’ve downloaded and tried to compile HaikuWebKit. I made it all the way through JavaScriptCore but inside the Haiku-specific code in WebCore I ran into multiple instances of a single issue.
Since WebKit is compiled without runtime type information or exceptions, dynamic_cast doesn’t work. In the instance of LLVM, which is also built without RTTI, there is a dyn_cast template that replaces dynamic_cast without needing type information at runtime at all. It uses compile-time constants. I just wanted to make a public note of this because I know that there are difficulties with WebPostitive and I wanted to help.
If WebKit_GTK is up-to-date and using the latest Linux version of the user-interface, would it be any less work cherry-picking changes from there to HaikuWebKit or would it make any difference? According to the documentation in HaikuWebKit, the last attempt at making Web+ multi-threaded was in 2019. I like the idea of being able to test on a working browser and eliminating dependencies one by one rather than chasing a moving target from behind.
Does that mean that Web+ uses GStreamer already? Does that mean that Gnome Web can be adapted to MediaKit? Personally, I think being able to cross-check against both versions would be best to reveal bugs in one that’s not the other.
No, it doesn’t. webkit is a cross platform project, the code to use this stuff exists but haikuwebkit is not wired to use it. why would we use gstreamee for example when webpositive can access the media kit which already uses ffmpeg?
@nephele
You didn’t get the joke. I switched the MediaKit and GStreamer support to the Linux port and the Haiku port respectively, but it was supposed to be an example of an interoperability stress test for the code base.
Haiku is becoming an operating system of API wrappers so making a MediaKit wrapper for GStreamer headers might nullify the point of the argument, but leveraging ports for starters and then reducing out redundancy in the OS and apps over time was the development strategy. Of course making wrappers for APIs that aren’t commonly used or are too system-specific to be ported, doesn’t make sense either, which is why I asked.
if gstreamer doesn’t have a haiku backend already one could be added, that sounds easier than trying to maintain abi compatibility to foreign software.
In any case, haikuwebkit can be adjusted to use more common linux stuff, and this would make it easier to upstream. But the downside is that we loose system integration.
Even if we were to use a foreign drawing system it would make more sense to me to only use it for webkit atleast and leave gtk out of it, otherwise we get into the wierd situation that haiku provided haikuwebkit in the base install that depends on gtk.
anyhow: if you want to work on webkit2 support you are free to use curl, a foreign renderer, gstreamer etc. we can always see to later use our more native stuff instead, after webkit2 atleast works for us : )
and yes, webkitgtk running on haiku will probably be great to test against. But I’d rather not use it as my everyday browser : p
It’s not so easy. GStreamer is based on GLib event loops and not BLooper. Mixing GLib and BLooper event loops in the same software is not easy, and in the same thread, nearly impossible. And WebKitLegacy is a single-thread design for the most part.
Also, this would mean every install of Haiku would need to have GStreamer installed, which means it would also have GLib and many other libraries. That would be a failure of what we try to do with Haiku: providing a consistent set of core system libraries, designed by the same people, and which can be used together easily. If we fail at that, we just become a bad Liunx distro who for some reason is using a different kernel to run exactly the same software as all other Linux distros. Is that what we want to be?
We already have a native haikuwebkit. It’s a different thing to have a port of something until we get a native option, but now we’re talking about deprecating the native option to replace it with a port. Why not just fix the native thing instead? It can’t be that hard?
