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

[Andrew S. Townley]

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