[webkit-dev] Queries regarding few Components in webkit
Adrian Perez de Castro
aperez at igalia.com
Sun Mar 17 08:29:16 PDT 2019
On Sun, 17 Mar 2019 09:08:10 -0500, Michael Catanzaro <mcatanzaro at igalia.com> wrote:
> It might be more realistic to try making an existing WebKit port work
> on Haiku (either WebKitGTK or WPE WebKit) rather than try to create an
> entirely new port.
You are forgetting that there is an existing, well-maintained WebKit1
port for Haiku. *That* should be the basis for a port to WebKit2. The
repository is available at:
As a matter of fact, according to the README in that repository, there
is already some ongoing effort to support WebKit2 in the Haiku port. You
should look into that instead of potentially wasting time redoing work
that has already been done by others.
> Previously you indicated that you were planning to create a new network
> backend for Haiku; that alone would be enough to occupy a developer
> full-time for a long while and doesn't seem very realistic. But that's
> just one small portion of developing and maintaining an entire WebKit
> port. Taking an existing port and making it run on Haiku would be much
Haiku has its own “libnetapi” system library, so IMO the goal should be
making WebKit use it (if it doesn't already — note that I am not familiar
with the insides of the Haiku WebKit port). You can see it in the upstream
Its API documentation is available here:
If using this is impossible, hard, or would need a lot of work in Haiku's
network library, then I would suggest using WebKit's libcurl network backend
to have something working at first (because the code it's already in the
WebKit repository and is known to work), and *then* once you have the rest
of the WebKit2 port running, look into switching from libcurl to Haiku's
built-in network library.
> On Sun, Mar 17, 2019 at 7:38 AM, Rajagopalan Gangadharan
> <g.raju2000 at gmail.com> wrote:
> > What is a WKRetainPtr ? where can I use it?
> It's a smart pointer for holding ownership of C API types, which you
> shouldn't be using. The C API is not stable and is slowly being
> retired. If you really don't want to use WebKitGTK or WPE WebKit, then
> you should create your own separate public API based on WebKit
> internals, not based on the C API. If you use the C API, your port will
> be difficult to maintain in the long run.
Agreed. Your public API should use Haiku types and existing conventions.
A good first step would be to check the exiting API for Haiku's WebKit1
port (see above, I linked the repository), keep the parts that still make
sense in a WebKit2 world, and add and modify others as necessary.
You can get more inspiration for API design from:
- The Haiku documentation itself: https://www.haiku-os.org/docs/api/
- The public APIs for existing WebKit2 ports:
* The GTK/WPE ports (both have a rather similar GLib-based API):
* The Qt port (the code for it is also in its own repo):
* The Cocoa ports (which has both Objective-C and Swift APIs):
> > What is WKContext and WKView (I think Webview is different from
> > WKView) -> as far my understanding is Context like the context menu
> > an os offers (ie right clicking provides copy,paste etc.)
> No, it's a library context object (corresponding to WebProcessPool). If
> you have two web contexts, you effectively have two separate instances
> of WebKit (e.g. separate NetworkProcess, separate data storage
> directories, separate everything) to avoid shared global state.
> > and View is where rendering takes place?
> This is correct.
> Good luck,
I also wish you a fun time hacking on WebKit, but *please* do make sure to
contact the Haiku developers and coordinate with them to avoid duplicating
efforts. Making a new WebKit port is a big task, and you will certainly have
much better chances of succeeding by making the most of existing work and
having the support of developers with knowledge of the target platform.
P.S: I am a bit of a BeOS fan myself, unfortunately I haven't used daily for a
long time, and never developed anything for the platform. I would love to see
Haiku have a working WebKit2 port for the platform!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: not available
More information about the webkit-dev