Queries regarding few Components in webkit
Hello guys, I am trying to use Webkit for Haiku(trying to create a minibrowser) I have few quick questions. 1) What is a WKRetainPtr ? where can I use it? 2) 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.) and View is where rendering takes place? Thank you guys! Regards, G.Rajagopalan
Hi, 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. 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 easier. On Sun, Mar 17, 2019 at 7:38 AM, Rajagopalan Gangadharan <g.raju2000@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.
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, Michael
Hello, On Sun, 17 Mar 2019 09:08:10 -0500, Michael Catanzaro <mcatanzaro@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: https://github.com/haiku/webkit 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 easier.
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 repository here: https://git.haiku-os.org/haiku/tree/src/kits/network/libnetapi Its API documentation is available here: https://www.haiku-os.org/docs/api/group__network.html 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@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): https://webkitgtk.org/reference/webkit2gtk/stable/index.html * The Qt port (the code for it is also in its own repo): https://github.com/annulen/webkit * The Cocoa ports (which has both Objective-C and Swift APIs): https://developer.apple.com/documentation/webkit
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. Regards, -Adrián 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!
This is great, thank you so much! On Sun, Mar 17, 2019 at 8:59 PM Adrian Perez de Castro <aperez@igalia.com> wrote:
Hello,
On Sun, 17 Mar 2019 09:08:10 -0500, Michael Catanzaro < mcatanzaro@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:
https://github.com/haiku/webkit
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 easier.
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 repository here:
https://git.haiku-os.org/haiku/tree/src/kits/network/libnetapi
Its API documentation is available here:
https://www.haiku-os.org/docs/api/group__network.html
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@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): https://webkitgtk.org/reference/webkit2gtk/stable/index.html * The Qt port (the code for it is also in its own repo): https://github.com/annulen/webkit * The Cocoa ports (which has both Objective-C and Swift APIs): https://developer.apple.com/documentation/webkit
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.
Regards,
-Adrián
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!
On Sun, 17 Mar 2019 21:03:33 +0530, Rajagopalan Gangadharan <g.raju2000@gmail.com> wrote:
This is great, thank you so much!
You're welcome! Quick addition: after sending my previous e-mail I kept browsing around the Haiku website, and it looks like one of the ideas for this year's Google Summer of Code is precisely migrating to WebKit2. You can see the full list of GSoC ideas here: https://www.haiku-os.org/community/gsoc/2019/ideas Maybe you will want to apply, but at least you can see there that there is one contact person (IRC: PulkoMandy) who would be mentoring the porting effort, so I suppose it would be good to contact them to coordinate :) Cheers, -Adrián
On Sun, Mar 17, 2019 at 8:59 PM Adrian Perez de Castro <aperez@igalia.com> wrote:
Hello,
On Sun, 17 Mar 2019 09:08:10 -0500, Michael Catanzaro < mcatanzaro@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:
https://github.com/haiku/webkit
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 easier.
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 repository here:
https://git.haiku-os.org/haiku/tree/src/kits/network/libnetapi
Its API documentation is available here:
https://www.haiku-os.org/docs/api/group__network.html
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@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): https://webkitgtk.org/reference/webkit2gtk/stable/index.html * The Qt port (the code for it is also in its own repo): https://github.com/annulen/webkit * The Cocoa ports (which has both Objective-C and Swift APIs): https://developer.apple.com/documentation/webkit
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.
Regards,
-Adrián
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!
Non-text part: text/html
Hi, We are already in contact and the work will indeed be based on the Haiku fork. While I can mentor the Haiku side of the project, I think it is a good idea to rely on you all for the WebKit side of things. I hope this will allow us toget one second developer working on the Haiku port, so I can do more than just keeping our port up to date. On the current state of our port: the network backend is working, it's not perfect but we don't currently plan switching back to curl. The webkit2 work is only some very early steps and has stayed untouched for the past 4 years, so there may not be this much to recover from it. The Webkitlegacy parts are used in production, but we have not made them a public api, so that we can switch to webkit2 more easily (only our browser will need an update) Thanks for your support and answering Rajagopalan's questions! -- Adrien/PulkoMandy Haiku port maintainer
Hello everybody, I have some more queries as im trying to port webkit2 to haiku. How do I set up the drawing area for webkit to render its stuff ( the functions that render in drawingareaproxy, webpageproxy..etc) Thank you Regards Rajagopalan
participants (4)
-
Adrian Perez de Castro
-
Adrien Destugues
-
Michael Catanzaro
-
Rajagopalan Gangadharan