PyDispatcher in the wild (Always nice to see work-product get used...)
Written by
on
in
Snaking.
"Golden Spud" has posted an introduction to his attempt to bring PyQt's signals/slots mechanism to wxPython. He's not using all of PyDispatcher's capabilitites (for instance, he's matching the consumer and producer signatures manually instead of letting PyDispatcher unify the arguments), but it is interesting to see it get used. (I didn't create PyDispatcher, I just help administer the project, btw).
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Matthew Scott on 07/07/2004 9:47 a.m. #
Heya Mike...<br />
<br />
Noticed your linky link and your commentary, so I thought I'd write back :)<br />
<br />
I became a fan of PyDispatcher over a year ago when Pat O'Brien introduced it to me, but since you've been the one who has been working on its innards more recently, I thought I'd ask you about this:<br />
<br />
I'm curious how the little "uberwx" (I really couldn't think of a better name at the time *LOL*) example could be improved with regards to consumer/producer signatures as you described.<br />
<br />
Is the following related to what you're referring to?<br />
<br />
There is a little bit of uberwx.py that I scratched my head at having to implement due to a problem I was having (uberwx.StaticText.SetLabel). Basically, I had to override that method so it would accept an argument named "text" and not something else. This is because the "textChanged" signal sent by uberwx.TextCtrl sends an argument named "text", and in the wxd2.py example, if I didn't override SetLabel as described above it would complain about method signatures and so forth.<br />
<br />
If that isn't related... Perhaps I will post some more info to the PyDispatcher mailing list with the other ways I tried and the problems that I (am pretty sure I) ran into when trying to use arguments instead of named arguments. <br />