···
On 27 December 2014 at 12:49, C M cmpython@gmail.com wrote:
I have access to a Mac computer and would like to test a wxPython application on it. I haven’t used a Mac in many years (since G4 days!), and have never tried Python on it. I don’t know which OS it has, but could find out. Probably 1-2 before Mavericks.
Is there anything I ought to know before I dive in?
One thing to be aware of is that recent Mac OS X operating system versions expect applications and installers to be digitally signed which requires spending money to join the Apple Developer Program. Some open-source installers like wxPython are not digitally signed in the way Apple expects them to be signed, so you might need to bypass Apple’s security checks, otherwise you can get some strange errors like “this application is damaged” or “this application can’t be opened because it is from an unidentified developer”. If you have any problems like this, have a look at “Security & Privacy” in “System Preferences” - you can select “Allow applications downloaded from anywhere”. Or you can right-click / control-click an application / installer, and then click Open from the right-click menu, which can open some unsigned applications.
I guess my not-well-thought-out plan would be to install Python from Python.org (I know Macs come with it, but I’ve heard that’s iffy for wxPython?),
I use Python from Python.Org on Mac OS X almost exclusively, and I’m happy with that choice. I did have an issue (not wxPython-specific) with the built-in Python on a Mac once where the HTMLParser module threw an exception suggesting that it differed from the HTMLParser.py from the Python.Org Python, but I couldn’t find the Mac version of HTMLParser.py - I could only find HTMLParser.pyc and HTMLParser.pyo in /System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/, so it was difficult to isolate what was different about the HTMLParser.py used by Apple. So with that experience in mind, I’m happy with my choice to use the Python.Org Python, where everything is completely open-source.
One thing to be aware of is that most Mac OS X builds of Python generally contain both the 32-bit and the 64-bit architectures in Mach-O binaries. This used to be a problem with wxPython 2.8 which only provided 32-bit binaries. If you weren’t careful, you could find yourself running a 64-bit Python and trying unsuccessfully to load a 32-bit wxWidgets shared library. wxPython 2.9 and 3.0 provide 32-bit/64-bit binaries which eliminate this problem.
I currently prefer wxPython 2.9 on Mac OS X over wxPython 3.0. Because there are far less Mac OS X wxPython users than Windows users, it is conceivable that Mac-specific bugs might not be identified and resolved as quickly as they would be on Windows. I came across a strange issue with wxPython 3.0 on Mac OS X recently which I haven’t yet resolved: http://wxpython-users.1045709.n5.nabble.com/Modal-dialogs-and-threads-on-Mac-OS-X-with-wxPython-3-0-td5723206.html
Also, I’d love to try to make an executable while I’m at it, if I have the time (I should have hours of access), using GUI2Exe. Any tips there?
If you are distributing stand-alone applications built with py2app or GUI2Exe, then be aware that providing both architectures (32 bit and 64 bit) will mean a bigger download for your users. I use py2app and I’m very happy with it - I’ve never tried GUI2Exe. For distributing a py2app-generated application bundle (MyApplication.app) in a DMG, this method seems to work well: http://stackoverflow.com/questions/96882/how-do-i-create-a-nice-looking-dmg-for-mac-os-x-using-command-line-tools In case you are not already aware, a Mac OS X application bundle (MyApplication.app) is really a folder, not a single file, so you need to archive it in a single file (e.g. a DMG) before distributing it. If you want to provide a setup wizard, you can investigate PKG installers, but they too are really folders (not single files), so they still need to be archived in a DMG, so that your users can download a single file.
If you want to make your application look native on Mac OS X, you should be aware of the Apple Human Interface Guidelines, and you should be aware of the default system font sizes you get in wxPython - you might find that when you port your application to Mac OS X, some widgets get a default font size of 13pt, which can make your window’s layout look different on Mac OS X from how it looks on other platforms. On Mac OS X, I reduce the default font size on some of my wxPython widgets from the default system font size (13pt ?) to 11pt. I don’t know the official native Mac font sizes for all Mac OS versions, but here’s an old reference: http://apple.stackexchange.com/questions/20898/what-is-mac-os-x-lions-finder-font
then start downloading/installing all the other libraries (laborious), then use Dropbox to get my .py files over there and try it. Is there anything really beyond that, in terms of wxPython (and, if you wouldn’t mind also saying, Python…or matplotlib…), that I need to know?
I haven’t tried matplotlib on Mac OS X.
To build and install Python modules containing C code etc. you will need to install the Xcode command line tools. Some Mac OS X Python developers like using Homebrew, but I don’t use it.
This may sound obvious, but when you port an application to a different operating system, you might find some bugs which are actually legitimate bugs on all operating systems (e.g. updating the GUI from a worker thread), but they might show up more on one operating system than on another, so they might appear to be OS-specific bugs at first.
Hope this helps,
James
Thanks,
Che
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.