Andrew S. Townley-3 wrote:
>
> Hi,
>
> I'm trying to work with the GTK+ WebKit from svn/trunk to do rendering
> for my application. Unfortunately, I'm having some troubles.
>
> Unlike the majority of users, I don't need WebKit to access URIs on the
> Internet. I need to be able to intercept them and display custom HTML
> content to allow navigation of some complex, in-memory data structures.
>
>
hi andrew,
so (summarising from previous posts) you need to support {makeupaurl}://
what that would tend to suggest, therefore, is that you create a customised
version of libcurl which supports your own formatted urls.
this brings me back to the issue i raised a few months ago of "clean"
library design - the one about vector-tables.
what webkit _should_ be doing is, instead of linking against curl (and thus
forcing people to use or rewrite curl) is to have a function which passes in
a pointer-to-a-struct-containing-pointers-to-all-of-curls-functions:
extern "C" {
/* whatever these are supposed to be, matching libcurl headers, make it so
*/
typedef (*curl_open_fn_t)(void* state_info, char *url, ...);
typedef (*curl_read_fn_t)(void*state_info, int len, char *buf);
....
struct libcurl_functions {
curl_open_fn_t *open_fn;
.....
};
void WebKitInitCurlLibrary(struct libcurl_functions *vector_table);
} /* extern "C" */
doing things this way has the important side-effect of making all AJAX calls
go through the external (customisable) library, not just "open a page".
in this way, it would be possible for example for pyjamas-desktop to add
"python://" as a URL, or to provide a URL type where filesystem access to
/home/accountname/whatever was actually _allowed_ - for certain small
portions of "allow".
also, it's rather inconvenient for a desktop-based loader, where the code is
loaded off of /home/username/source_file.html to then be "banned" from
accessing the internet, just because the source code for the application was
loaded from the user's desktop. especially when the access being done is
AJAX.
the rather daft workaround that has to be done is that the desktop-based
loader goes and loads the source_file.html from
http://127.0.0.1/workaround_appplication_url/source_file.html - with other
portions of http://127.0.0.1 doing ProxyPass Redirects!
which is all a bit ridiculous, involving Apache2 in the equation, when with
a tiny bit of effort, libcurl could be even be dropped-out at runtime and a
replacement dropped in (dso loaded).
l.
--
View this message in context:
http://www.nabble.com/Equivalent-of-WebKit-Qt%27s-link-delegation-policy-in-WebKit-Gtk%2B--tp20072050p22180940.html
Sent from the Webkit mailing list archive at Nabble.com.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
