[PyKDE] Dropping SIGNAL() and SLOT() in PyQt4?

Patrick Stinson patrickkidd at gmail.com
Wed Feb 22 18:44:09 GMT 2006


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" syntax its hard not to ask...

On 2/19/06, Patrick Stinson <patrickkidd at gmail.com> wrote:
>
> 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.ex, I implemented something like the resource system with pyqt3, but
> theirs is much simpler, and a very acceptible way of doing things. also, the
>
>
> Using something like SIGNAL and SLOT is conceptually and syntactically
> much cleaner than templates, and that's what a lot of (most?) people look
> for. glib just uses a string for their connections, as in
>
> self.connect('message', self.on_message)
>
> which I consider to be very pythonic. Both pygtk and pyqt offer quite a
> lot of improvements over their c/c++ orignals, and I think these
> improvements should each be considered. Leaving SIGNAL in as an options
> sounds like a good comprimise.
>
> On 2/19/06, David Boddie <david at boddie.org.uk> wrote:
> >
> > 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 full-blown signal/slot
> > implementation
> > > which works totally at compile time and has zero overhead. In fact,
> > there is
> > > technically *nothing* that moc does which cannot be done with C++ and
> > some
> > > advanced tecniques. But Trolltech seems to like the separate
> > compilation
> > > step more than templates.
> >
> > Indeed, but see these documents for a more complete discussion:
> >
> > http://doc.trolltech.com/4.1/templates.html
> > http://scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html
> >
> >
> > I think one of the motivations for using a preprocessor-based approach
> > is
> > the continued lack of support for certain C++ advanced techniques with
> > some
> > compilers. Nonetheless, the first document aims to provide other
> > justifications for using moc.
> >
> > > > So, what so you think? Is dropping them to much of a cultural
> > change?
> > > > (Of course they could also be made optional.)
> > >
> > > I'm fine with dropping them as long as they're optional.
> >
> > I also think it's fine to make them optional. Some people might
> > appreciate
> > the explicit nature of SIGNAL and SLOT in their code.
> >
> > I imagine it's still possible to distinguish between signals and slots
> > with
> > this method, and continue to allow signals to be connected to signals
> > without
> > ambiguity.
> >
> > David
> >
> > _______________________________________________
> > PyKDE mailing list     PyKDE at mats.imk.fraunhofer.de
> > http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
> >
>
>
>
> --
> Patrick Kidd Stinson
> http://pkaudio.sourceforge.net/
> http://pksampler.sourceforge.net/
>



--
Patrick Kidd Stinson
http://pkaudio.sourceforge.net/
http://pksampler.sourceforge.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20060222/6ac45edd/attachment.html


More information about the PyQt mailing list