wxPython 4.0.7.post2 Released

"To QTKit, or not to QTKit..."

wxPython 4.0.7.post2 is now available at PyPI, with some additional files at Extras

This post-release changes a wxWidgets configure option on macOS so the build will be forced to use AVFoundation instead of QTKit. This ensures that wxMediaCtrl will work on macOS 10.15+, where all support for QTKit has been removed.


This is a companion discussion topic for the original entry at https://wxpython.org/news/2019-11-12-wxpython-407post1-release/index.html

Thank you. That was way faster than I expected.

David

Yeah, I figured making a new 4.0.7 release with just this change was better than pushing out a 4.1 release too soon.

Hi Robin,

  I'll give you too much context so you can decide how much you

care. I don’t want to waste any of your time, but I hope you can
give me some advice or suggestions about how best to proceed.

  I have historically built the Mac version of my software for

distribution on my oldest version of MacOS, version 10.10.5
Yosemite using py2app and recently PyInstaller. As I understand
it, the version you build on affects what versions your
distributed program will run under, so I err on the side of using
an old version to maximize support for users using very old
hardware. (I probably need to revise my procedures and move to a
later MacOS as my “base” version, but that’s an issue for another
day.)

  When I installed 4.0.7.post2 on MacOS 10.15 Catalina, wxMediaCtrl

from the wxPython Demo works. Yay. Great progress, amazingly
fast. I’m thrilled.

  When I install 4.0.7.post2 on MacOS 10.10.5 Yosemite, wxMediaCtrl

from the wxPython Demo crashes. I got a segmention fault 11 once,
and haven’t been able to figure out the crash codes for the second
time I tried it. (It looks like a LayoutConstraints error, but
I’m not sure that makes sense.) Reverting to wxPython 4.0.6.0 has
resolved the problem and I can again use the wxMediaCtrl Demo on
MacOS 10.10.5. But as you know, 4.0.6.0 doesn’t allow wxMediaCtrl
on Catalina. (Results on 10.14 Mojave are mixed, more
complicated.)

  Do you have any sense of which MacOS versions will support

wxPython 4.0.7.post2 with wxMediaCtrl?

  I'm initially thinking I have to support at least Mojave and

Catalina on my next release based on 4.0.7.post2, and maybe I
could do a build for older versions of MacOS using 4.0.6.0 if
there’s any actual demand for it. Does this sound like a
reasonable strategy? (I still get support requests for older
MacOS versions, but probably not much in the way of new sales or
upgrades, so I can probably live with this.)

David

Although the builds are now using a newer version of the MacOSX SDK, both wxWidgets and wxPython builds are using the -mmacosx-version-min=10.9 compile flag, which is supposed to make it possible for the binaries to be used on any macOS since 10.9.

I was also under the impression that it would be better to build on an older version of OSX to help aid compatibility. But I’ve been told enough times now that I’m starting to believe it, that setting MACOSX_DEPLOYMENT_TARGET while compiling or using the -mmacosx-version-min flag is the real way to ensure backwards compatibility with the older platforms. My understanding of how that is accomplished is that when individual APIs do not exist on an older platform that they are seen as having a NULL value in the code, and that code using them is supposed to test that to ensure they are callable. If the wxWidgets code is not testing some API for NULL that it should be, then that could be the source of your segfault.

I just tried it on a 10.10 VM and also saw the program self-terminate. It looks like the “LayoutConstraints” mentioned there are not due to wxLayoutConstraints, but something in the Cocoa libs. Interestingly, I also see those messages if I modify the program to not load a media file to start playing immediately, so those messages may actually be something to do with how the widget is created or initialized.

As for a minimum OS version that wxMediaCtrl will actually work… I’ve just tested the demo with 4.0.7.post2 on macOS 10.15, 10.14, 10.13 and 10.12. I don’t have a 10.11 install to test on, but being able to go back as far as 10.12 seems pretty good.

Hi Robin,

wxPython-4.0.7.post2’s wxMediaCtrl works under the very narrow circumstances of the Demo, but unfortunately not so much elsewhere. I can load and play video files in the Demo, but I’m still getting seg faults when I try to load the SAME video files in my own application. I see the problem on MacOS 10.12.6 Sierra with Python 3.7.5 and 10.15.1 Catalina with Python 3.8.0.

I’m still exploring the details, but I think it has to do with media size. I embed videos in a larger application, usually shrinking the image from its original size in a Sizer to fit in just a portion of the screen. Here’s a little bit of the error trace from the MacOS crash report:

          Termination Signal:      Segmentation fault: 11

          ...

          Thread 0 Crashed:: Dispatch queue: com.apple.main-thread

          0 libwx_osx_cocoau_core-3.0.0.4.0.dylib 0x000000010b7765cb wxWindow::DoGetSize(int*, int*) const + 43
          1 _media.cpython-38-darwin.so 0x000000010c2e6633 sipwxMediaCtrl::DoGetSize(int*, int*) const + 115
          2 libwx_osx_cocoau_core-3.0.0.4.0.dylib 0x000000010b900eaa wxSizerItem::DoSetWindow(wxWindow*) + 58
          3 libwx_osx_cocoau_core-3.0.0.4.0.dylib 0x000000010b901016 wxSizerItem::wxSizerItem(wxWindow*, int, int, int, wxObject*) + 182
          4 _core.cpython-38-darwin.so 0x000000010ad8c8f5 meth_wxSizer_Add(_object*, _object*,  _object*) + 629

I interpret this as the MediaCtrl being unable to cope with changing size using DoGetSize(), something the Demo does not require it to do.

I don’t think the seg faults are due to errors in my code. I use the same code on Windows 10 with wxPython 4.0.7.post2 and on MacOS 10.12.6 Sierra with wxPython 4.0.6 with no issues.

I think I’ll try to adapt the wxMediaCtrl Demo by adding a sizer to make the video resizable in order to create a simple example to demonstrate the problem. I’ll post that when I have it “working,” but it might not be until early next week.

David

Hi Robin,

  Sorry for the delay.  It's amazing to me how much work gets in

the way of doing my job.

  I've attached a simple example file.  You'll want to edit the

LoadFile() method to point to video files that exists on your
computers, line 66 for Windows and line 68 for MacOS. This file
demonstrates the failure I consistently see with the wxMediaCtrl.

  On Windows 10 (Python 3.7.3, wxPython 4.0.7.post2) and on MacOS

10.12.6 Sierra (Python 3.7.5, wxPython 4.0.6), this file works
perfectly.

  On MacOS 10.12.6 Sierra (Python 3.7.5, wxPython 4.0.7.post2),

MacOS 10.14.4 Mojave (Python 3.8.0, wxPython 4.0.7.post2), and on
MacOS 10.15.1 Catalina (Python 3.8.0, wxPython 4.0.7.post2), it
consistently fails on startup, giving a segmentation fault 11
error.

  (I am unable to install wxPython 4.0.6 on MacOS 10.14.4 Mojave to

test there. I get a compiler error during “pip3 install
wxpython==4.0.6”, but have not had time to pursue this further.
If this is an important data point, let me know and I’ll pursue it
further.)

David

Video_Catalina.py (2.86 KB)

Hi,

  The *.py file WAS attached to this message, but has gotten

stripped off. Trying again with a *.zip file, definitely
attached. If this doesn’t work, what’s the secret of attaching a
sample file with Discuss?

David

Video_Catalina.zip (1.31 KB)

I saw both attachments, so maybe it’s a Discourse trust level setting somewhere as to whether it’s visible or not… In addition to the default image file and zip extensions I added .py to the list of allowed file types when I set up the site. I’ll see if I can find anything else about it in the settings. Did you make your posts with the attachments on the site, or did you do it by replying to the notification emails? There are additional settings for posts coming from email…

I’ll take a closer look at your sample app when I have some time. Does it matter what kind of video file is used?

Hi Robin,

  I don't think it matters what kind of video you use.  I think the

process crashes when the sizer is trying to do it’s magic, before
the video file is loaded. The point of loading a file is to show
that the code works with earlier wxPython versions.

Thanks for looking into this.

David