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

List:       kfm-devel
Subject:    Re: rfc: binary incompatible change
From:       Lars Knoll <lars () trolltech ! com>
Date:       2000-08-31 13:21:49
[Download RAW message or body]

Hi,

I think I have a (a bit hacky) way of implementing a createNewFrameSync call 
without loosing binary compatibility:

My proposal is to add a signal to KPart, which requests a new frame:

class KPart {
	...
signal:
	createNewFrameSync( KPart *& newFrame, const KUrlArgs &args );
};

khtmlPart can then use the signal to request a new frame:

	...
	KurlArgs args = ....;
	KPart *newPart = 0;
	emit createNewFrameSync( newPart, args );
	if( !newPart ) return; // do nothing

konqueror connects to this signal, and initializes the new frame in the 
connected slot. This works, because signals are processed synchronously. Apps 
that do not connect to the signal will not break, because nothing will happen 
for them.

Opinions?

Lars


On Thu, 31 Aug 2000, Harri Porten wrote:
> [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]