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> &lt;<a href="mailto:david@boddie.org.uk">david@boddie.org.uk</a>&gt; 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>&gt; Phil Thompson &lt;phil at <a href="http://riverbankcomputing.co.uk">riverbankcomputing.co.uk</a>&gt; wrote:<br>&gt;<br>&gt; &gt; (In fact I don't see why Qt still needs SIGNAL() and SLOT() - maybe
<br>&gt; &gt; the speed penalty of the alternative is more an issue at the C++<br>&gt; &gt; level.)<br>&gt;<br>&gt; Nah. There's boost::signal, which is a full-blown signal/slot implementation<br>&gt; which works totally at compile time and has zero overhead. In fact, there is
<br>&gt; technically *nothing* that moc does which cannot be done with C++ and some<br>&gt; advanced tecniques. But Trolltech seems to like the separate compilation<br>&gt; 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>&gt; &gt; So, what so you think? Is dropping them to much of a cultural change?<br>&gt; &gt; (Of course they could also be made optional.)<br>&gt;<br>&gt; 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&nbsp;&nbsp;&nbsp;&nbsp;<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>