I don't have a Mac, but I have heard a report that wx.Timer() doesn't
work on Macs, and apparently doesn't work on a few other platforms as
well (they were nebulous). The docs for wxPython 2.8 don't list Timer
instances as being platform limited, and I cannot find any bugs claiming
that they don't work on a Mac.
Can someone on a Mac try the wx.Timer demo for me? I suspect that the
individual is incorrect, but I don't have the ability to test it on the
Macintosh platform (they work fine on Linux and Windows).
- Josiah
The wxTimer demo works fine for me.
wxPython 2.8.1.1, OS X 10.3, PowerPC Mac
David
···
-----Original Message-----
From: Josiah Carlson [mailto:jcarlson@uci.edu]
Sent: Friday, February 16, 2007 10:52 AM
To: wxpython-users@lists.wxwindows.org
Subject: [wxPython-users] wx.Timer and Mac
I don't have a Mac, but I have heard a report that wx.Timer()
doesn't work on Macs, and apparently doesn't work on a few
other platforms as well (they were nebulous). The docs for
wxPython 2.8 don't list Timer instances as being platform
limited, and I cannot find any bugs claiming that they don't
work on a Mac.
Can someone on a Mac try the wx.Timer demo for me? I suspect
that the individual is incorrect, but I don't have the
ability to test it on the Macintosh platform (they work fine
on Linux and Windows).
- Josiah
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org
There's some issues with using wx.Timer as a driver for an external
event loop (I presume this is related to the python-dev discussion).
The old Twisted wxreactor did this and there were a ton of problems
with it - sometimes the timer fires too much, leaving wx unresponsive,
sometimes it doesn't fire enough, leaving the network slow.
There's a current problem on the mac with the timer events not firing
right if you're moving a window or have a menu open. I'm not sure if
thats been resolved recently or not.
The overall point is that using fast wx.Timers as an event loop driver
is fraught with peril as a generic solution. The current twisted
approach (drive the twisted event loop in a secondary threat, execute
code in the main thread via wx.CallAfter) is quite a bit nicer. You
could probably write asyncore infrastructure that worked the same way.
···
On 2/16/07, Josiah Carlson <jcarlson@uci.edu> wrote:
I don't have a Mac, but I have heard a report that wx.Timer() doesn't
work on Macs, and apparently doesn't work on a few other platforms as
well (they were nebulous). The docs for wxPython 2.8 don't list Timer
instances as being platform limited, and I cannot find any bugs claiming
that they don't work on a Mac.
Can someone on a Mac try the wx.Timer demo for me? I suspect that the
individual is incorrect, but I don't have the ability to test it on the
Macintosh platform (they work fine on Linux and Windows).
>
> I don't have a Mac, but I have heard a report that wx.Timer() doesn't
> work on Macs, and apparently doesn't work on a few other platforms as
> well (they were nebulous). The docs for wxPython 2.8 don't list Timer
> instances as being platform limited, and I cannot find any bugs claiming
> that they don't work on a Mac.
>
> Can someone on a Mac try the wx.Timer demo for me? I suspect that the
> individual is incorrect, but I don't have the ability to test it on the
> Macintosh platform (they work fine on Linux and Windows).
There's some issues with using wx.Timer as a driver for an external
event loop (I presume this is related to the python-dev discussion).
The old Twisted wxreactor did this and there were a ton of problems
with it - sometimes the timer fires too much, leaving wx unresponsive,
sometimes it doesn't fire enough, leaving the network slow.
There's a current problem on the mac with the timer events not firing
right if you're moving a window or have a menu open. I'm not sure if
thats been resolved recently or not.
That's what he ended up saying.
The overall point is that using fast wx.Timers as an event loop driver
is fraught with peril as a generic solution. The current twisted
approach (drive the twisted event loop in a secondary threat, execute
code in the main thread via wx.CallAfter) is quite a bit nicer. You
could probably write asyncore infrastructure that worked the same way.
Coincidentally, I already have:
http://wiki.wxpython.org/index.cgi/AsynchronousSockets
- Josiah
···
"Chris Mellon" <arkanes@gmail.com> wrote:
On 2/16/07, Josiah Carlson <jcarlson@uci.edu> wrote: