All links are under permissive license and are written to work with webkit, add extension functions and plugins.
These two links below serve as references:
Webkit already natively supports webextensions.
We can likely use this functionality once we switch to the webkit2 api.
1 Like
Do i understand correctly that none of the listed addon can be used with Web+ at this moment and they are listed here as a wishlist?
It would be references or code examples, understanding how they are implemented, it is possible to learn and create own solutions!
Before we talk about add-ons and apps running over the WebPositive, we should complete the browser almost first.
2 Likes
Yes, we need to have a browser ready, the references are as future possibilities!
Sorry if this question sounds stupid, but as far as Iāve seen, all browsers available for Haiku are Webkit-based. I know thereās a pretty of the WebKit engine for Haiku. But is it planned/possible to have a Chromium-based browser in the future?
Chrome is now not best way to serfing, especially on windows this monster eat many of
chunk memory. Itās a memory leak i don;t know.
Please check WEB ( [Epiphany) browser itās a best in Haiku @ this moment.
1 Like
Blink (the engine beind Chrome and Chromium) is owned by Google and they are extremely unreceptive to supporting anything else than Linux, MacOS, and Windows. All patches for supporting other systems (FreeBSD, OpenBSD, ā¦) are rejected. So, personally, I think it is a waste of my time to write such code. Someone else might do it (and then they have to maintain their patches forever since Google wonāt adopt them).
On the other hand, WebKit is developped by several companies (Apple, but also Igalia who maintains the GTK and āWPEā (embedded Linux and other embedded platforms) versions, Sony for the PlayStation, etc). They support the BSD systems and would be happy to also include the Haiku port in their git repository. This is why we are using WebKit as the engine for WebPositive.
I canāt comment for the other browsers, as I am not involved with them. But it seems the WebKit based ones were easier to get running? They donāt rely on haikuwebkit, they use the GTK or Qt versions of WebKit instead, so this work is unrelated to the WebKit running WebPositive. However, the fact that we basically managed to port WebKit 3 times and get reasonably working browsers, while the one experiment with Blink resulted in a very unstable browser, hints to WebKit generally being easier to handle?
3 Likes
I think for a full port they want us to have more paid devs looking at it, which is understandable (currently Iām the only one trying to upstream stuff and didnāt have much time, which is to be expected for a hobby)
nevertheless we already upstreamed fixes in shared code to webkit not specific to Haiku and they were happy to accept it, so itās definetely nice in that regard.
(note: one webkit contributor suggested we might start with a jscore only port at the start, might be a good idea, fuchsia is supported in the same way)
In the long run, once we have webkit2 working we can definitely see what parts can be upstreamed additionally 
as for blink vs webkit the problem is that they differ in design goals, blink wants
to control the rendering completely and use their oen libraries. As such it operates more like a black box, it is very opinionated in how it operates.
Webkit on the other hand allows us to use native code or libraries for almost everything we want, in our port this includes text rendering, font handeling, drawing of html controls, html default colors etc. It allows us to create a haiku browser much more directly, and we profit from the development beeing done for say macos and its goals there (mostly support modern web standards, but not optimize for adware, webkit actually has a very efficient adblocker builtin)
3 Likes
You really want to open that barn door? I think no
1 Like
I donāt think they care if the devs are getting paid. They need someone to take care of the port, and do maintenance to it, so it does not add too much extra work to them. One thing they require is setting up a build bot for their āEWSā (Early Warning System) that builds all proposed changes to WebKit before they get merged, and runs the tests on it. Otherwise they canāt guarantee that the code will keep running, and they donāt want to keep the dead/broken code in their tree.
Well, the requirement Iāve heard was three paid devs atleast, and Iām not sure if that was ment for only working on webkit or on haiku and webkit.
I guess we can upstream a bit and if we can proove we can maintain that theyād probably be fine with it. Would definetely require more than just me though
Really it does not matter if people are getting paid or not. Why would they care? Three full-time devs is probably what they meant. But we already got the Haiku port upstreamed a few years ago with less than that, and then it became unmaintained a few years later and was removed again.
I donāt think there are any written rules about this in WebKit, so it just depends who you ask. There is a bit of politics in attracting the attention of people that would be more supportive of us to get the patches merged.
1 Like