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. f
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 t
On Sun Feb 19 15:30:53, Giovanni Bajo wrote:
> Phil Thompson 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 implem
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 t
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
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
> 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
distinguishing between signals and slots, ie. rely on a slightly slower
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 conversi
