[prev in list] [next in list] [prev in thread] [next in thread]
List: pykde
Subject: Re: [PyKDE] Dropping SIGNAL() and SLOT() in PyQt4?
From: "Patrick Stinson" <patrickkidd () gmail ! com>
Date: 2006-02-22 18:44:09
Message-ID: 94ef510602221044udc06f55jb563070580f0d4ab () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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 s=
o
> 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 writin=
g
> it. f.ex, I implemented something like the resource system with pyqt3, bu=
t
> 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@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.htm=
l
> >
> >
> > 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@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/
[Attachment #5 (text/html)]
Just to add to the chaos, wouldn't a syntax like the following be interesting:<br>
<br>
timer.connect('timeout()', slotfunc)<br>
<br>
I realize that removes a bit from (not only some fundamental qt syntax :)) this<br>
<br>
QObject.connect(timer, 'timeout()', self, 'myTimerBlew()')<br>
<br>
but once you start adding "optional" syntax its hard not to \
ask...<br><br><div><span class="gmail_quote">On 2/19/06, <b \
class="gmail_sendername">Patrick Stinson</b> <<a \
href="mailto:patrickkidd@gmail.com">patrickkidd@gmail.com </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;"><span class="q">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></span><div><span class="q"><span \
class="gmail_quote">On 2/19/06, <b class="gmail_sendername">David Boddie</b> <<a \
href="mailto:david@boddie.org.uk" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"> david@boddie.org.uk</a>> \
wrote:</span></span><div><span class="e" id="q_10983db86ad558aa_3"><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" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">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" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">http://doc.trolltech.com/4.1/templates.html</a><br><a \
href="http://scottcollins.net/articles/a-deeper-look-at-signals-and-slots.html" \
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)"> \
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" \
target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
PyKDE@mats.imk.fraunhofer.de</a><br><a \
href="http://mats.imk.fraunhofer.de/mailman/listinfo/pykde" target="_blank" \
onclick="return top.js.OpenExtLink(window,event,this)">http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
</a><br></blockquote></span></div></div><br><br clear="all"><div><span class="q" \
id="q_10983db86ad558aa_5"><br>-- <br>Patrick Kidd Stinson <br><a \
href="http://pkaudio.sourceforge.net/" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)">http://pkaudio.sourceforge.net/</a><br><a \
href="http://pksampler.sourceforge.net/" target="_blank" onclick="return \
top.js.OpenExtLink(window,event,this)"> http://pksampler.sourceforge.net/</a>
</span></div></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>
_______________________________________________
PyKDE mailing list PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic