While I know you've got your plate full right now, Robin, I'm curious as
to whether the wx Socket classes and methods are anywhere in the near
future for wxPython?
I've had half-assed success getting wx and sockets to work together, but
it would be soooooo nice to have it integrated into the wx event loop!
And yes, I've tried Twisted's wxsupport reactor... While it works, it's
waaaay overkill.
OK, I'll duck back into my hole and get back to coding. Cheers! 
Jeff Grimmett wrote:
While I know you've got your plate full right now, Robin, I'm curious as
to whether the wx Socket classes and methods are anywhere in the near
future for wxPython?
No definite plans, but it is something I've thought about doing...
I've had half-assed success getting wx and sockets to work together, but
it would be soooooo nice to have it integrated into the wx event loop!And yes, I've tried Twisted's wxsupport reactor... While it works, it's
waaaay overkill.
A little less overkill may be to use the asyncore.py module in the stnadard library, derive some classes from ansyncore classes that turn the handle_read, handle_write, etc. methods into wx events that get posted to the GUI thread, while the asyncore.loop is running in a worker thread. I wouldn't mind putting something like this in to the wxPython library if it is general purpose and well organized.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
> as to whether the wx Socket classes and methods are anywhere in the
> near future for wxPython?No definite plans, but it is something I've thought about doing...
Well, I'll be pulling for ya 
A little less overkill may be to use the asyncore.py module in the
stnadard library, derive some classes from ansyncore classes
that turn
the handle_read, handle_write, etc. methods into wx events that get
posted to the GUI thread, while the asyncore.loop is running in a
worker thread. I wouldn't mind putting something like this in to the
wxPython library if it is general purpose and well organized.
Oddly enough, I had a real problem getting asyncore to even work for me,
with or without wx. What I ended up with was a server that used
threading.Thread() to handle connects. I blatantly stole the code from
python/Lib/test/test_asynchat.py (I *think* that's the actual file
name). I think it's hilarious that an asyncore test module doesn't USE
asyncore
Anyway, much as you suggested I created a worker thread that was 'aware'
of the app's top-level frame. I cheated a bit. Instead of a few extra
lines of code to implement messages, I just called self.win.LogIt() from
the thread. I suspect that this is incredibly dangerous but it was a
quick and dirty solution for what I needed. Source code is available if
anyone wants to pick on me
::pause::
Looking at the docs for wxSocketBase et al, it DOES look like it would
be POSSIBLE to 'simulate' the "real" wxSocketBase using built-in Python
classes and the worker thread approach to generate the various
wxSocketBase events. Superficially, anyway.
Boy, now I'm torn between trying to implement this myself and the
project that actially prompted this email in the first place.
Let me trot this by you: if we WERE able to implement wxSocket*
functionality in pure Python, would it be desireable to highjack the
wxSocket* name space, or would it be best to use a whole different name
space? That is, if identical functionality can be implemented...?
I gotta look back into asyncore again, too, and figure out what's up
with that...
Jeff Grimmett wrote:
Let me trot this by you: if we WERE able to implement wxSocket*
functionality in pure Python, would it be desireable to highjack the
wxSocket* name space, or would it be best to use a whole different name
space? That is, if identical functionality can be implemented...?
If so then there would be no reason to wrap the C++ wxSocket* classes and so there would be no problem with reusing the same names.
--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!
Jeff Grimmett wrote:
> Let me trot this by you: if we WERE able to implement wxSocket*
> functionality in pure Python, would it be desireable to highjack the
> wxSocket* name space, or would it be best to use a whole different
If so then there would be no reason to wrap the C++ wxSocket* classes
and so there would be no problem with reusing the same names.
Hmmmm... I might give it a whirl to see what I can come up with, but
don't wait up on me... 