[moving this thread to kfm-devel] Simon Hausmann wrote: > I have to admit that I forgot what we originally discussed :-( (and I don't have the mails > anymore :-( I *tried* to forget about this issue (dislike) but the entries on bugs.kde.org remind me again every day ... > IIRC we aggreed on putting the new method into BHE and requiring the caller to fill in the > serviceType variable of the URLArgs ( in order to ensure that the request can be processed > syncroniously by Konqueror (otherwise konq has to determine the mimetype -> async ) . Correct. > The question is: How can khtml query the BHE of the host/shell ? For inside khtml we can > traverse "upwards" via parent() && parent->inherits( "KHTMLPart" ) . > > So what we could do is to check if the parent() provides the BHE (as child object) . > > However I don't really like that solution... :-) > > How about doing it the other way around: The host/shell tells the part (upon creation for example) > that it provides the BHE interface. We could store that reference in the BE object. > > (total confusion .. BE, BHE, EB, EHB, EBHHBEHE, HEHE ;-) I already wanted to ask about the difference but the code below enlightens me a little bit. > Talking in code: > > BrowserExtension: > > void setParentBrowserHostExtension( BrowserHostExtension * ); > BrowserHostExtension *parentBrowserHostExtension() const; > > BrowserHostExtension: > > // default impl returns 0L > virtual KParts::ReadOnlyPart *createFrameSync( const KURL &url, const KParts::URLArgs & ); Looks good. What I thought of is solving the problem via signals (in case a bic change is not possible anymore). Keep on using the old KHTMLPart::urlSelected() and letting Konqueror fire of a signal (containing the Part pointer) into the direction of the embedded widget. Is that feasible ? I'm not sure if sub-frames or whatever would make this impossible. We would certainly use the top level KHTMLPart only. Sigh. Something for KDE 2.1 ? I'm not sure if I can stand the "bug reports" until then. Harri.