KHTMLpart (more precisely: it's KParts::BrowserExtension) emits openURLRequest[Delayed]() when clicking on links that are not simply anchors on the same page. This makes it easy for an embedding application to hook in functionality such as - blacklists / whitelists of URLs - warnings about specific URLs - redirecting / rewriting specific URLs - implementing application-specific pseudo-URLs such as "about:" without the need to write a kio-slave - ... kwebkitpart (more precisely: it's KParts::BrowserExtension) emits openURLRequest[Delayed]() in some situations, and thus embedding applications will have to connect to and react on this signal, anyway. But for most navigation all you get is an openUrlNotify() after the fact. On a cursory look it would seem to be easy to change kwebkitpart to be consistent with KHTMLPart in this respect. See QWebPage::LinkDelegationPolicy . Thus, please make kwebkitpart emit openURLRequest[Delayed]() whenever the user clicks on a link, and leave it to the embedding application to handle this.
No it is not easy to do this. QWebPage::LinkDelegationPolicy only works for a user clicking on a link and the link being a <a> tag with href. If the link uses javascript or the request is generated behind the scenes by scripts using ajax calls, then QWebPage will not emit linkClicked at all. Hence, you cannot delegate all the requests from QWebPage to another object. As a result, I had to resort to lots of hacks to make the QtWebKit/KPart integration work. If you want to embed QtWebKit, I suggest you use kdewebkit from kdelibs directly instead of kwebkitpart. That is what I recommend. Due to the difficulty of making QtWebKit integrate into KPart, kwebkitpart makes several assumptions and most of those tend to be skewed towards Konqueror integration.