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). Cheers, ast [1] http://atownley.org/projects/ruby-gtkhtml3/bzr/2009-01-07T10:41:39 +0000/ 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 > 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. > -- Andrew S. Townley <a...@atownley.org> http://atownley.org _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
