Hi Trent, Bob, etc. Sorry for the late reply. It's been a busy week. I've altered wxPython's downloads page to hopefully be clearer and more up-to- date. As for the ANSI/Unicode issue, I made Unicode a little more prominent but ANSI still gets quite a lot of downloads, so I'm hesitant to make it hard to get to. But I've made the Unicode builds the first ones so as to encourage those who don't know/care to just click on Unicode, so if that does make a big difference in the number of people who download ANSI, we can re-evaluate moving it later. (I simply don't know how many people actually need the ANSI build for their app to work...) I also added the Universal binaries pre-release build, along with a note explaining the Tiger-only issue and giving a blueprint for lipo'ing the PPC and Universal builds if anyone wants to try that to see if it works on Panther. ;-) (I don't have time to attempt it right now.) URL is here:
http://wxpython.org/downloads.php Thanks, Kevin On Apr 17, 2006, at 1:26 PM, Trent Mick wrote: > [Trent] >>> wxPython on the Mac seems to be painful right now. > > [Kevin Ollivier wrote] >> Suggestions and contributions welcome! :-) > > My apologies, I was being unfairly brief. > Some suggestions: > > - A review of the Mac OS X-related text on > http://www.wxpython.org/download.php > Some of that info is misleading: > > '''wxPythonOSX needs a "Framework" build of Python 2.3, also > known as > MacPython-OSX.''' > > To be fair explaining the myriad Python's out there for Mac OS X is > hard. This sentence though connotes the wrong thing: that > wxPython is > only available for Python 2.3. > > '''If you would like to try Python 2.4.x on Panther or Tiger then > you > can get an installer here''' > > Again, to be fair, giving a download link for the current Python for > Mac OS X (whatever that really means) is a moving target. There > *is* a > Python installer at that link, but it is no longer a recommended > one. > > As well, some mention of the x86 arch issues would be helpful for > users. > > Okay, *one* suggestion. :) I don't currently use wxPython at all. > > >>> 1. You need to get the correct build for your version of Python. For >>> ActivePython 2.4.x or MacPython 2.4.x that means getting one of >>> the >>> builds with "-py24" in the package name. >> >> Of course, this is pretty much the same as with every other (binary) >> Python extension, isn't it? > > Yes, I didn't mean to imply that wxPython is special here. > > >>> 2. They have "ansi" and "unicode" builds. From what I can tell the >>> "ansi" builds are probably only useful for Mac OS X 10.2.x >>> compatibility. If you are using Mac OS X 10.3 (Jaguar) or greater >>> then I'd stick with the "unicode" builds. >> >> The ansi builds are for people who haven't considered Unicode support >> when building their wxPython apps, and thus might have issues when >> their data is automatically converted to and from Unicode. In ansi >> mode, it just passes the actual 'bytes' around, so the user is in >> total control over how the data is encoded. It took me a couple days >> of auditing my codebase before I got everything working with Unicode, >> and while I'm glad I did, up until that point I (and users of my app) >> were doing just fine with ANSI builds. >> >> But yes, in general, Unicode is the recommended build on OS X, or any >> modern platform for that matter. > > If that is the case then I'd suggest having the link to the unicode > build the only obvious one. Those requiring ANSI builds can be pointed > to the SF.net "Files" page and/or a Unicode vs. ANSI wiki page. > > The current http://wiki.wxpython.org/index.cgi/UnicodeBuild, which > *is* > linked to there, probably already does a good job here. > > >> There aren't any Intel-only binaries, but packages containing >> Universal binaries (built using the Universal MacPython Framework) >> was finished up late last week and are just awaiting being uploaded >> to the wxPython SF site. So it should be pretty soon. > > That's good news. > > >>> Unfortunately I was also able to *install* it on Mac OS X 10.4/ >>> Intel but it doesn't work (importing "wx" fails) because the >>> binary modules in wx are for ppc while the running Python is x86. >> >> Right. About the only thing we could do at this point is to add a >> command-line check on the architecture of the Python binary and bomb >> out if it's incorrect. I could go ahead and add such a test, although >> I think the OS X Installer will just give a generic "you are not >> allowed to install this package" message, which is arguably just as >> confusing to the user.... We could also add ppc to the filename, >> though I think it will easily be missed. > > Yah, Apple's packaging tools are a pain. Great for braindead simple > stuff, but quite limiting for anything custom. > > > Trent > > -- > Trent Mick > [EMAIL PROTECTED] _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
