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

List:       pykde
Subject:    Re: [PyKDE] new PyQt4 signal mechanism
From:       Phil Thompson <phil () riverbankcomputing ! co ! uk>
Date:       2006-01-29 17:20:29
Message-ID: 200601291720.29431.phil () riverbankcomputing ! co ! uk
[Download RAW message or body]

On Sunday 29 January 2006 4:33 pm, Detlev Offenbach wrote:
> Hi,
>
> I have a signal, that should be emitted from a Python method with a list of
> integers. I declared it like
>
>             self.emit(SIGNAL("dataChanged(int *)"), [index])
>
> However, when it triggers, I get a TypeError exception saying, that
> argument 1 is of the wrong type. What would be the correct signal
> definition?

That's a very good question.

A requirement of the new handling is that all signals are implemented in C++ 
under the covers (so that queued and inter-thread connections work). That 
means the signature has to be something that PyQt can convert the Python 
arguments to - which it can't in this case.

There are a number of options...

1. Revert to "old-style" connections in such a case. I don't like this because 
you lose the queued and inter-thread connections.

2. Treat "PyObject *" (or something similar) as a special case in code that 
parses the signature to allow any arbitrary Python object to be passed. This 
would have the side-effect of bypassing all the marshalling/de-marshalling 
that is going on when sending a Python signal to a Python slot.

3. Implicitly treat any such types as "PyObject *" as described above. The 
declaration you used would then work unchanged.

I need to think about this a bit more.

Phil

_______________________________________________
PyKDE mailing list    PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[prev in list] [next in list] [prev in thread] [next in thread]