Summary: | [GTK] Implement webkit_web_view_load_bytes() in WebKit2 | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Gergely Polonkai <gergely> | ||||
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Enhancement | CC: | berto, bunhere, cdumez, cgarcia, commit-queue, gustavo, gyuyoung.kim, mrobinson, sergio | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Gergely Polonkai
2014-07-08 11:35:05 PDT
load_string() like in webkit1 limits the API to null terminated array of characters, so in this case I would use webkit_web_view_load_bytes() that receives a GBytes. That way we can take a reference and create an API::Data object without duplicating the memory. How about (for 1.x compatibility reasons) implementing both? _load_string() may internally convert the null-terminated strings into GBytes and call _load_bytes() maybe. I don’t know how hard it would be, even navigating the sources is hard for me as a webkit newbie… Created attachment 234704 [details]
Patch
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API (In reply to comment #2) > How about (for 1.x compatibility reasons) implementing both? _load_string() may internally convert the null-terminated strings into GBytes and call _load_bytes() maybe. I don’t know how hard it would be, even navigating the sources is hard for me as a webkit newbie… I think load_string is a confusing name in any case, so in case of adding a new (convenient) API to load a const char, it would be load_data that receives const char + data length. But I think it's very easy for users to simply create a GBytes. I agree, wonder how that impacts bindings though, does anyone know if it can be made idiomatic for js and python? Comment on attachment 234704 [details]
Patch
The API looks good to me, fwiw.
Comment on attachment 234704 [details]
Patch
The API looks fine to me too.
Committed r171740: <http://trac.webkit.org/changeset/171740> Comment on attachment 234704 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=234704&action=review > Source/WebKit2/ChangeLog:9 > + random data in the web view using the given MIME-Type, encoding Hopefully the data isn't random. Arbitrary? (In reply to comment #10) > (From update of attachment 234704 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=234704&action=review > > > Source/WebKit2/ChangeLog:9 > > + random data in the web view using the given MIME-Type, encoding > > Hopefully the data isn't random. Arbitrary? Oops, yes, you are right, bad english translation in my head. |