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

List:       kfm-devel
Subject:    Re: rfc: binary incompatible change
From:       Harri Porten <harri () trolltech ! com>
Date:       2000-08-31 12:49:33
[Download RAW message or body]

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

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