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-... Sent from the Webkit mailing list archive at Nabble.com.