Hi Gustavo, On Mon, 2008-10-20 at 23:51 -0200, Gustavo Noronha Silva wrote:

On Mon, 2008-10-20 at 16:07 +0100, Andrew S. Townley wrote:

...

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.

I take it that you intend to feed the renderer with HTML code contained in memory, without writing it to files. I think what you are looking for is still not really implemented for WebKit/GTK+, and might be this:

https://bugs.webkit.org/show_bug.cgi?id=17147

That's correct. I don't want to deal with a bunch of temp files, and the protocol I want the users to see isn't "file:". I'd also have to walk the whole structure to dump it to disk each time any of it changes, etc. This approach isn't practical for what I'm doing since it's essentially the entire application. In theory, yes--the bug would give me what I need. It all depends on what the API looks like and how much interceptor functionality exists. I don't think it needs to be extremely granular, but if it allowed you to internally handle network requests, it would deal with all of the protocol handling challenges without requiring protocol handlers. While similar, they are actually different beasts. What I'm talking about allows you much greater integration capability via embedding WebKit vs. allowing WebKit-based applications to handle different protocols. Does anyone know the ETA of this fix? In looking at the patch for image loading, I think it's not going in the right direction, although it could be used as the basis for a more generalized signal, perhaps something similar to the url_requested signal in GtkHTML. In this case, the link_clicked isn't as important.

...

Any information on how this sort of behavior can be accomplished with the existing GTK+ api would also be welcome.

Well, you may be able to replace/edit the contents of the page by using the JavaScriptCore API directly. It doesn't sound very elegant/high level to me, but is possible today =).

Ummm.... no. ;) -- Andrew S. Townley <ast@atownley.org> http://atownley.org

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 <ast@atownley.org> http://atownley.org