[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: rfc: binary incompatible change
From:       Simon Hausmann <sh () caldera ! de>
Date:       2000-08-31 12:20:39
[Download RAW message or body]

On Thu, Aug 31, 2000 at 02:05:52PM +0200, Harri Porten wrote:
> Simon Hausmann wrote:
> > 
> > > If you do so I would like to sneak in a new virtual function for the
> > > damn window.open() problem as well. It would also affect only Konqueror.
> > 
> > Ahh, yes, I remember :-) (we said someting about adding the method to the BrowserHostExtension,
> > right?
> 
> Yes.
> 
> > Hmm, did we solve the problem of how to access the top-level BHE? (from khtml to konq) ?
> 
> 
> No. We didn't touch this issue, yet. Does that mean that the reuquest
> has to be propagated up to the top level frame ?

I have to admit that I forgot what we originally discussed :-( (and I don't have the mails
anymore :-(

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 ) .

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 ;-)

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 & );

But I'm afraid I'm missing something from the original discussion :-}

David ? :-)


Bye,
 Simon

[prev in list] [next in list] [prev in thread] [next in thread]