[PyKDE] BrowserExtension.createNewWindow(KURL, URLArgs, WindowArgs, ReadOnlyPart)

[Phil Thompson]

On Saturday 23 September 2006 12:25 am, Jim Bublitz wrote:
> On Friday 22 September 2006 14:06, Paul Giannaros wrote:
> > There are two createNewWindow signals in KParts::BrowserExtension to
> > notify browser hosts that a new window has been requested.
> > createNewWindow(KURL, KParts::URLArgs) is supported, but I can see on the
> > PyKDE docs that createNewWindow(KURL, KParts::URLArgs,
> > KParts::WindowArgs, *&KParts::ReadOnlyPart) is not supported. The second
> > signal is (as far as I can see) used in KJS and emitted when JavaScript
> > creates a new window so that you can set the emitted KPart to your new
> > KHTMLPart and the two can communicate via JavaScript on the webpage.
> > Is there any chance of this signal being supported in some way? If only
> > KHTMLPart::setOpener/setOpenedByJS were not private then there would be
> > no need for it to be.
>
> Here's the relevant portion of kparts/browserextension.h:
>
> // KDE invents support for public signals...
> #undef signals
> #define signals public
> signals:
> #undef signals
> #define signals protected
>
> ...
>
> void createNewWindow( const KURL &url, const KParts::URLArgs &args,
>                         const KParts::WindowArgs &windowArgs,
>                         KParts::ReadOnlyPart *&part );
>
>
> The problem for PyKDE/sip is the reference to a pointer in the last
> argument. There are a couple of issues here I'm not sure about, and need
> Phil's input on:
>
> First, is it possible to write %MethodCode for a signal (even a "public"
> signal)? I seem to recall it wasn't possible, but there's always a good
> possibility my memory is wrong.

Your memory is correct. It's been on the TODO list for some time, but more 
from the point of view of completeness rather than demand for it.

However, if these arguments are being used to return values from the slot to 
the signal then that implies a broken design as they shouldn't be so tightly 
coupled.

> If not, then would it work to add some C++ to the sip file to connect to
> this signal (would require a special connect method to init the connection,
> I'd think) and then re-emit a signal, connect to an invented signal or call
> a method compatible with sip? Can I create a new signal in the sip file
> just by sticking a signal declaration in the %TypeHeader block and then
> referencing it like a normal signal in class block in the sip file?

No - the SIP generated shadow class doesn't include isn't put through moc. You 
would have to consider creating a proxy class in C++ and link that in with 
the SIP generated code. You've still got problems making a connection though.

Phil