rate() does not work with wxWidgets version > 3.0.0

[schodet]

When using wxWidgets 3.0.2 with vpython, the rate function only returns when the mouse move.

See https://groups.google.com/forum/?fromgroups&hl=en#!searchin/vpython-users/rate/vpython-users/sIjW42s3V2w/1DkCYlDLBgAJ

I can see the problem on an OS X system, installing vxpython using homebrew.

[BruceSherwood]

"Classic" VPython will receive little or no further support:

http://vpython.org/contents/announcements/evolution.html

The only way to get a working version of Classic VPython may be to use a standard installer from vpython.org.

[repagh]

The fix is a single line, in site-packages/visual_common/create_display.py, change
if _isMac and not _evtloop.Dispatch(): return
to
if _isMac and not _evtloop.DispatchTimeout(1): return

Can this be fixed? I had this issue with wxpython 3.0.2 through macports.

[BruceSherwood]

Again, Classic VPython is no longer supported:

http://vpython.org/contents/announcements/evolution.html

Moreover, it's not clear how making such a change would affect Matt Craig's intent to "offer to continue to build an Anaconda conda package until the official end-of-life of Python 2.7 in 2020, as long as building the package does not require substantial modification to the Classic VPython codebase", since this sounds like it would break the building of installers that use an earlier version of wx.

[sspickle]

It appears that DispatchTimeout existed before wx 3.0.0, but that only after 3.0.0 (i.e., 3.0.1 and after) did this symptom appear. Since it doesn't actually require building any new classic vpython installers I think it would be worth my time to simply test this change against the anaconda version to see if it breaks anything before completely refusing to accept the change. Of course if it does end up breaking things, we'll probably need to exclude it, or only accept it after there are added conditionals to avoid such breakage. Thoughts?

[BruceSherwood]

If you're willing to do that, great. I'm concerned about the risk of breaking what exists. Is there a downside to requiring an earlier (compatible) vesion of wx?

[sspickle]

The trouble with pinning wx to 3.0.0 is a) many of these package managers encourage users to "update to the latests" early and often which will result in a broken install and b) other systems that use wx may require a newer version resulting in unnecessary headaches. If this fix solves the problem, and doesn't cause breakage with older versions, why not include it in the repo? Especially since we don't have to build installers to incorporate it.

BTW, the proposed fix seems to work OK with the anaconda binary on OS X using wx 3.0.0:

(py27)aluminum:~ steve$ python -c 'import wx; print wx.version()'
3.0.0.0 osx-cocoa (classic)

It also runs correctly withing the classic vpython environment.

I'll check Windows next. More soon.

[sspickle]

Of course, windows should be immune from any effect since the line starts with:

if _isMac and ...

[sspickle]

OK, works on Windows wx 3.0.0 as well. I checked it in. Hopefully this will resolve the issue. Thanks Rene for the patch. I'm assuming this was a deliberate change in behavior in wx, but I have no idea what the motivation for the change was. Do you know? Thanks.

[repagh]

No, I don't know the reason. The documentation of 3.x explicitly says that
the call will block if no events are available, for 2.8 it only says the
call will return false if the event loop has to be ended.

Op ma 30 mei 2016 om 14:32 schreef Steve Spicklemire <
notifications@github.com>:

OK, works on Windows wx 3.0.0 as well. I checked it in. Hopefully this
will resolve the issue. Thanks Rene for the patch. I'm assuming this was a
deliberate change in behavior in wx, but I have no idea what the motivation
for the change was. Do you know? Thanks.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#79 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/ACqkDQZBzU7e9Qe04J_ZKfAEvpy51J4_ks5qGtjmgaJpZM4HmR6s
.