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 <br>
<br>
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 <br>
<br>
self.connect('message', self.on_message)<br>
<br>
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.<br><br><div><span class="gmail_quote">On 2/19/06, <b class="gmail_sendername">David Boddie</b> <<a href="mailto:david@boddie.org.uk">david@boddie.org.uk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Sun Feb 19 15:30:53, Giovanni Bajo wrote:<br><br>> Phil Thompson <phil at <a href="http://riverbankcomputing.co.uk">riverbankcomputing.co.uk</a>> wrote:<br>><br>> > (In fact I don't see why Qt still needs SIGNAL() and SLOT() - maybe
<br>> > the speed penalty of the alternative is more an issue at the C++<br>> > level.)<br>><br>> Nah. There's boost::signal, which is a full-blown signal/slot implementation<br>> which works totally at compile time and has zero overhead. In fact, there is
<br>> technically *nothing* that moc does which cannot be done with C++ and some<br>> advanced tecniques. But Trolltech seems to like the separate compilation<br>> step more than templates.<br><br>Indeed, but see these documents for a more complete discussion:
<br><br><a href="http://doc.trolltech.com/4.1/templates.html">http://doc.trolltech.com/4.1/templates.html</a><br><a href="http://scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html">http://scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html
</a><br><br>I think one of the motivations for using a preprocessor-based approach is<br>the continued lack of support for certain C++ advanced techniques with some<br>compilers. Nonetheless, the first document aims to provide other
<br>justifications for using moc.<br><br>> > So, what so you think? Is dropping them to much of a cultural change?<br>> > (Of course they could also be made optional.)<br>><br>> I'm fine with dropping them as long as they're optional.
<br><br>I also think it's fine to make them optional. Some people might appreciate<br>the explicit nature of SIGNAL and SLOT in their code.<br><br>I imagine it's still possible to distinguish between signals and slots with
<br>this method, and continue to allow signals to be connected to signals without<br>ambiguity.<br><br>David<br><br>_______________________________________________<br>PyKDE mailing list <a href="mailto:PyKDE@mats.imk.fraunhofer.de">
PyKDE@mats.imk.fraunhofer.de</a><br><a href="http://mats.imk.fraunhofer.de/mailman/listinfo/pykde">http://mats.imk.fraunhofer.de/mailman/listinfo/pykde</a><br></blockquote></div><br><br clear="all"><br>-- <br>Patrick Kidd Stinson
<br><a href="http://pkaudio.sourceforge.net/">http://pkaudio.sourceforge.net/</a><br><a href="http://pksampler.sourceforge.net/">http://pksampler.sourceforge.net/</a>