Current snapshots now support emitting arbitrary Python objects, ie. objects
that have no corresponding C++ type.
In PyQt3 a connection between a Python signal and a Python slot (ie. a
callable) is implemented directly and doesn't involve Qt's signal/slot
mechanism at all. Therefore no
PYSIGNAL() has already been dropped in PyQt4. This was possible because Qt4
makes it easier to look up whether a particular string is a Qt signal
signature or not. There is no reason why this approach cannot be extended to
distinguishing between signals and slots, ie. rely on a slightly slower
Pazar 19 Şubat 2006 14:23 tarihinde, Phil Thompson şunları yazmıştı:
PYSIGNAL() has already been dropped in PyQt4. This was possible because Qt4
makes it easier to look up whether a particular string is a Qt signal
signature or not. There is no reason why this approach cannot be extended
to
On 19.02.06 12:23:00, Phil Thompson wrote:
signature or not. There is no reason why this approach cannot be extended to
distinguishing between signals and slots, ie. rely on a slightly slower
dynamic lookup rather that the type information SIGNAL() and SLOT() provide.
(In fact I don't see
Phil Thompson [EMAIL PROTECTED] wrote:
(In fact I don't see why Qt still needs SIGNAL() and SLOT() - maybe
the speed penalty of the alternative is more an issue at the C++
level.)
Nah. There's boost::signal, which is a full-blown signal/slot implementation
which works totally at compile time
On Sun Feb 19 15:30:53, Giovanni Bajo wrote:
Phil Thompson phil at riverbankcomputing.co.uk wrote:
(In fact I don't see why Qt still needs SIGNAL() and SLOT() - maybe
the speed penalty of the alternative is more an issue at the C++
level.)
Nah. There's boost::signal, which is a
Hi,
I'd like to know if its reasonable that a build with debug symbols of
PyQt3 is faster than without, when using concatenation (with 4 parts)?
I experience this here, when I forget the -u switch it seems like it
takes forever to build the parts (IIRC more than an one hour). However
when using
As I wrote to a friend recently, qt has always been more of a good
interface than a chunk of unique functional code. IMO, the reason qt is
so successful is that it defines a standard way to do all the
usual stuff, and that makes our code easier to read, and easier to
understand while writing it.
