[PyKDE] Re: sip SIGNAL/proxy problem

[Jim Bublitz]

On Wednesday December 24 2003 12:05, Phil Thompson wrote:
> On Sunday 21 December 2003 9:26 pm, Jim Bublitz wrote:
> > There appears to be a sip problem as described in the
> > following PyKDE list thread:
> >
> >     [PyKDE] un-connectable signals (probably sip bug)
> >
> > Basically the situation is this (WId is just an example of
> > the general problem):
> >
> > WId is defined in qwindowdefs_x11.sip as:
> >
> >     typedef unsigned long WId;
> >
> > In kdecore/KWinModule, the *signal*:
> >
> >     void windowAdded (WId);
> >
> > is defined.
> >
> > kdecore proxies unsigned long, so the following should work
> > :
> >
> >     wm = KWinModule ()
> >     wm.connect (wm, SIGNAL ("windowAdded (unsigned long)"),
> >         someSlot)
>
> Just to confirm that the problem is that SIP uses the real
> types in signals whereas MOC uses the supplied types without
> worrying about what the real type is. For example...
>
> typedef unsigned long WId
>
> signals:
> 	void sig(WId);
> 	void sig(unsigned long);
>
> SIP will complain because the signatures are the same. MOC
> won't - but the C++ compiler will.
>
> I can change SIP, but it generates a QObject based proxy class
> that contains a handler for each unique signal defined in the
> module. Therefore, if the above example signatures were in
> different classes then the changed behaviour would mean that
> the proxy wouldn't compile.

> Are there any examples like this in any PyKDE module?

I only found one signal that takes unsigned long as an argument, 
and it doesn't clash with a defined type in either its class or 
module as far as I can tell. I also found one signal that uses 
pid_t (typedef'd from int), but it's in a signature unlikely to 
be duplicated anywhere else.

It appears that WId, KIO::filesize_t from the original post, and 
pid_t above are the only instances where this happens, and in 
each case there isn't a signal with a clashing signature, even 
at the module level.

Considering Python programmers could care less about typedefs in 
these cases, and there being only 3 instances with no apparent 
clashes, I could probably just handle this via #defines, or you 
could implement the simplest sip modifications as above. If we 
do run into problems, it seems sip will catch them, and I can 
work around them as there shouldn't be many problems cropping 
up.


> If not then I can just change the behaviour to be MOC-like.

Seems like the best choice, or I can use #defines.

> If so then I need to do something more complicated.

Doesn't appear necessary.

Jim