Just to add to the chaos, wouldn't a syntax like the following be interesting:
timer.connect('timeout()', slotfunc)
I realize that removes a bit from (not only some fundamental qt syntax :)) this
QObject.connect(timer, 'timeout()', self, 'myTimerBlew()')
but once you start adding optional
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
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.
