[webkit-dev] Equivalent of WebKit/Qt's link delegation policy in WebKit/Gtk+?

Andrew S. Townley ast at atownley.org
Tue Feb 24 09:56:58 PST 2009

Hi Luke,

I don't think that'll be necessary to do what I want with the new
navigation-policy-decision-requested signal handling.  I think I can
just intercept these nicely when they happen and do the right thing.

What your suggesting is much closer to how you add a custom URI scheme
to Mozilla, and it isn't what I want.  I want to be able to react from
the container application directly when something like this happens
rather than to have an isolated mechanism which is independent of the
main app.

I think there is value in having custom libraries for particular URI
schemes in a similar manner to Mozilla, but it wouldn't solve my problem
without going through several seemingly unnecessary hoops.

I haven't had a chance to try this yet because I (or someone) needs to
add the support for the required classes in the Ruby/WebKit-GTK+
binding, and I've had other priorities.  It is on my list because I'd
like to have it as an option where I'm using Ruby/GtkHTML[1] today.
However, as per the previous post, I really need bi-directional
communications between the hypermedia view and the containing
application, and I haven't yet seen a good way to make this happen
directly in memory without using some kind of intermediate protocol,
temporary files or JSON (which, given gwibber's experience, seems to be
extremely fragile).



[1] http://atownley.org/projects/ruby-gtkhtml3/bzr/2009-01-07T10:41:39

On Tue, 2009-02-24 at 05:31 -0800, lkcl wrote:
> 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
> the rather daft workaround that has to be done is that the desktop-based
> loader goes and loads the source_file.html from
> - with other
> portions of 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.
Andrew S. Townley <ast at atownley.org>

More information about the webkit-dev mailing list