El mié, 16-10-2019 a las 19:38 +0100, Gavin Smith escribió: > (please CC me in responses as I am not subscribed to the list) > > I'd like to ask what is the future of the DOM access functions that > were deprecated in WebKitGTK+ 2.22.0. The documentation advises using > a "JavaScriptCore" API instead. > > https://webkitgtk.org/2018/09/03/webkitgtk2.22.0-released.html
Yes, current DOM bindings API marked as deprecated will be removed in the next binary version bump. > I think it would be unfortunate if this functionality were removed. The functionality is not removed, everything you can do with the DOM API can be done with JSC (https://webkitgtk.org/reference/jsc-glib/stable/index.html) > The DOM access gives programs a way to access information inside the > HTML pages that are being displayed. Even if it can be done by > running > JavaScript, this information needs to come back to the controlling > program and this would require some kind of protocol for > communicating > over a textual channel between the JavaScript and native halves of > the > program. I think it is simpler to be able to do everything in C. I'm not sure I understand. You can use the JSC API from C like you do with the DOM API. You can take a look at epiphany code to see how it uses the JSC API to access the DOM. > This is for a program to read locally installed HTML documentation. > See > > https://lists.gnu.org/archive/html/bug-texinfo/2019-10/msg00010.html > > and the earlier thread > > https://lists.gnu.org/archive/html/bug-texinfo/2019-04/msg00042.html > > for more context on what we are trying to achieve. > > As an aside, it would be even better if you could have direct DOM > access in the main thread, as was the case with WebKitGTK version 1. I guess you mean, from the UI process, instead of the main thread. The DOM is in the web process, and that can't be changed. > I > don't think there is any benefit for the multi-thread model for this > use case. Yes, probably not for this use case, but the multi-process architecture is the only one right now, and we can't maintain both. Btw, regarding the communication between UI and web processes, we have recently landed a patch to add a user message API, so you won't have to use your socket based one. See https://bugs.webkit.org/show_bug.cgi?id=202847 > We could have the slightly bizarre situation of it being easier to do > processing on the HTML files separately (to do it robustly, with some > HTML parsing library), than to extract the information from the > embedded browser engine. > > PS I could only subscribe to this mailing list by moving the date on > my computer back 5 minutes, otherwise I got a "Please take a few > seconds to fill out the form before submitting it." message. Weird... > _______________________________________________ > webkit-gtk mailing list > webkit-gtk@lists.webkit.org > https://lists.webkit.org/mailman/listinfo/webkit-gtk > -- Carlos Garcia Campos http://pgp.rediris.es:11371/pks/lookup?op=get&search=0xF3D322D0EC4582C3
signature.asc
Description: This is a digitally signed message part
_______________________________________________ webkit-gtk mailing list webkit-gtk@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-gtk
