Re: [webkit-dev] Equivalent of WebKit/Qt's link delegation policy in WebKit/Gtk+?
Am Tue, 24 Feb 2009 17:56:58 + schrieb "Andrew S. Townley" : > 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. > > [...] > > On Tue, 2009-02-24 at 05:31 -0800, lkcl wrote: > > > > what that would tend to suggest, therefore, is that you create a > > customised version of libcurl which supports your own formatted > > urls. > > > > [...] Hey, note that some time ago the WebKitGtk hackers decided to drop support for libcurl and always work with libsoup. If you check out the source from the repository by now, you have to build with libsoup. The idea is that you want to be able to access the network implementation and by far the most effecient approach is to expose the SoupSession* and SoupMessage* objects where appropriate. So you don't have to fork or customize anything. Support for custom URI schemes is planned in libSoup for the future. Further more Glib is going to support networking functionality. And you don't depend on WebKit supporting a particular feature. If your use case is missing, file a feature request, the libSoup maintainer is a nice person :) Regards, Christian ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Equivalent of WebKit/Qt's link delegation policy in WebKit/Gtk+?
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
+/
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
http://atownley.org
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Equivalent of WebKit/Qt's link delegation policy in WebKit/Gtk+?
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-WebKit-Gtk%2B--tp20072050p22180940.html
Sent from the Webkit mailing list archive at Nabble.com.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Equivalent of WebKit/Qt's link delegation policy in WebKit/Gtk+?
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 <[EMAIL PROTECTED]> http://atownley.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Equivalent of WebKit/Qt's link delegation policy in WebKit/Gtk+?
Hi Paul, On Mon, 2008-10-20 at 17:49 -0700, Paul Pedriana wrote: > Is it possible to handle this at the resource loading level as opposed > to the mouse clicking level? Wouldn't the former catch all URI loading > pathways as opposed to just clicked links? I need to solve this same > problem as you but haven't got to it yet. In my case it's less about > overriding http:// and more about supporting custom://. You're right. I'm actually going to need both. Thanks for mentioning it. -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Equivalent of WebKit/Qt's link delegation policy in WebKit/Gtk+?
On Mon, 2008-10-20 at 16:07 +0100, Andrew S. Townley wrote: > Hi, Hello, > 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 > 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 =). See you, -- Gustavo Noronha Silva <[EMAIL PROTECTED]> GNOME contributor: http://www.gnome.org/ ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Equivalent of WebKit/Qt's link delegation policy in WebKit/Gtk+?
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. I thought you might be able to do something with the navigation-requested signal, but this doesn't appear to allow you to substitute content for the URI. In digging around in the source tree, I discovered that the Qt port allows you to get the linkClicked signal, provided you've registered the appropriate link delegation policy with the WebView. Is this functionality planned for the GTK+ version? Is someone currently working on implementing it? If the answers to this are no, does anyone have any pointers for how to implement something similar for the Gtk+ version? I'm not used to the Qt syntax, so I can't find the code where it interacts with the core WebKit classes to accomplish this functionality. I'd be willing to give this a go or at least help someone who is working on this, as it is essential for what I'm doing and my only other alternative is to use the soon-to-be-unmaintained GtkHTML(3) from Gnome svn. Any information on how this sort of behavior can be accomplished with the existing GTK+ api would also be welcome. Thanks in advance, ast -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
