Development: wxMac

Building under 10.6 Snow Leopard

Building on Snow Leopard for Snow Leopard

When trying to build wx under 10.6 you might - on certain machines - end up with errors like this:

./src/common/intl.cpp: In static member function ‘static int wxLocale::GetSystemLanguage()’:
../src/common/intl.cpp:2060: error: ‘smScriptLang’ was not declared in this scope
../src/common/intl.cpp:2060: error: ‘GetScriptVariable’ was not declared in this scope
../src/common/intl.cpp:2061: warning: ‘GetScriptManagerVariable’ is deprecated (declared at
    /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Script.h:993)
../src/common/intl.cpp:2061: warning: ‘GetScriptManagerVariable’ is deprecated (declared at
    /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Script.h:993)
make: *** [baselib_intl.o] Error 1

The reason is that the default compiler on 10.6 is gcc 4.2, and if you are on a Core 2 Duo which is 64-bit capable, you end up compiling Carbon-only 2.8 for 64 bits which fails, due to the lack of 64-bit Carbon support. If you want 64-bit wxWidgets on OS X you'll need 2.9+ and configure -with-osx_cocoa - see below; but remember that 2.9 is not an official, stable release and wxOSX/Cocoa is not yet complete.

So, to compile with 2.8 on a 64-bit Mac, you have to explicitly indicate the architectures you want:

arch_flags="-arch i386"
./configure CFLAGS="$arch_flags" CXXFLAGS="$arch_flags" CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags" ...

This makes the library and samples build nicely for Intel 32-bit targets, and you can also add -arch ppc to the arch_flags so that you can build universal binaries.

Building on Snow Leopard for older versions of MacOSX

If you want to target previous versions of MacOSX, you will also need to specify

-isysroot /Developer/SDKs/MacOSX10.5.sdk -mmacosx-version-min=10.5

or use

--with-macosx-sdk=PATH  use an OS X SDK at PATH
--with-macosx-version-min=VER   build binaries which require at least this OS X version

Note that on Mac OS X 10.6, gcc 4.2 is the default compiler and this means the resulting binaries only run on 10.5+, but not on 10.4. If you want to build apps that can be deployed on 10.4 then you must switch the gcc version. You can then avoid specifying architecture flags, as the default architecture with the gcc 4.0 version in 10.6 still defaults to 32-bit compilation. You can use:

./configure CC=gcc-4.0 CXX=g++-4.0 LD=g++-4.0 ...

or

export CC=gcc-4.0
export CXX=g++-4.0
export LD=g++-4.0 
./configure ...

Patch needed

Please note that there is a bug in wxMac 2.8.10 in wxFontDialog, which manifests itself on Mac OS X 10.6 by the dialog disappearing as soon as it is shown. To fix this, please apply this patch to your source: https://svn.wxwidgets.org/viewvc/wx/wxWidgets/branches/WX_2_8_BRANCH/src/mac/carbon/fontdlgosx.mm?r1=44296&r2=61800

Building 32/64 bit Universal Binary

Build ppc64

Works on 10.5 (and probably on 10.6)

In the configure script add this line at line 1497:

cross_compiling=yes

search for cross_compiling=yes and add the line outside the two if statements

Then configure:

set arch_flags="-arch ppc64 "
../configure -with-osx_cocoa --disable-shared --disable-compat24 --enable-unicode CFLAGS="$arch_flags" CXXFLAGS="$arch_flags" CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags"

"If you get an error with the tiff library, turn it off with --with-libtiff=no"

"If you get an error about Quicktime not having ppc64, turn off Quicktime links with --enable-mediactrl=no --enable-sound=no"

Build ppc, x86, x86_64

set arch_flags="-arch x86_64 "
../configure -with-osx_cocoa --disable-shared --disable-compat24 --enable-unicode --enable-universal-binary CFLAGS="$arch_flags" CXXFLAGS="$arch_flags" CPPFLAGS="$arch_flags" LDFLAGS="$arch_flags" OBJCFLAGS="$arch_flags" OBJCXXFLAGS="$arch_flags"

lipo each into one binary

lipo -output libwx_baseu_net-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_baseu_net-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_baseu_net-2.9-.a
lipo -output libwx_baseu_xml-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_baseu_xml-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_baseu_xml-2.9-.a
lipo -output libwx_baseu-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_baseu-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_baseu-2.9-.a
lipo -output libwx_osx_cocoau_adv-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_osx_cocoau_adv-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_osx_cocoau_adv-2.9-.a
lipo -output libwx_osx_cocoau_aui-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_osx_cocoau_aui-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_osx_cocoau_aui-2.9-.a
lipo -output libwx_osx_cocoau_core-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_osx_cocoau_core-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_osx_cocoau_core-2.9-.a
lipo -output libwx_osx_cocoau_html-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_osx_cocoau_html-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_osx_cocoau_html-2.9-.a
lipo -output libwx_osx_cocoau_media-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_osx_cocoau_media-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_osx_cocoau_media-2.9-.a
lipo -output libwx_osx_cocoau_propgrid-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_osx_cocoau_propgrid-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_osx_cocoau_propgrid-2.9-.a
lipo -output libwx_osx_cocoau_qa-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_osx_cocoau_qa-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_osx_cocoau_qa-2.9-.a
lipo -output libwx_osx_cocoau_richtext-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_osx_cocoau_richtext-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_osx_cocoau_richtext-2.9-.a
lipo -output libwx_osx_cocoau_stc-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_osx_cocoau_stc-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_osx_cocoau_stc-2.9-.a
lipo -output libwx_osx_cocoau_xrc-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwx_osx_cocoau_xrc-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwx_osx_cocoau_xrc-2.9-.a
lipo -output libwxjpeg-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwxjpeg-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwxjpeg-2.9-.a
lipo -output libwxpng-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwxpng-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwxpng-2.9-.a
lipo -output libwxregexu-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwxregexu-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwxregexu-2.9-.a
lipo -output libwxscintilla-2.9-.a -create ../../osx-build-cocoa-unicode-x86-ppc-x86_64/lib/libwxscintilla-2.9-.a -create ../../osx-build-cocoa-unicode-ppc64/lib/libwxscintilla-2.9-.a

wxOSX, wxMac, wxCocoa, Carbon and Cocoa

Status

At WWDC 2007 Apple stated that all new GUI features will only be available from the Cocoa API, this was in line with our roadmap for wxMac which was published here earlier. The current implementation of wxMac in the 2.8 branch is based on the Carbon API while in trunk wxMac has broadened and was renamed wxOSX.

wxOSX née wxMac

All common OS X code is using the core frameworks available, so for example the wx drawing API is using CoreGraphics everywhere. The GUI source part has three flavors named after the APIs used. There is a wxOSX_CARBON which is mainly the complete and proven code base with slight updates, a wxOSX_COCOA which is using Cocoa (obviously) and where we will be pulling in source from the wxCocoa port, and last but not least wxOSX_IPHONE which is using the Cocoa Touch API that exists only on the iPhone and the iPod touch.

Rationale for Pulling in wxCocoa source vs Pushing wxMac into wxCocoa

[CS] the current port of wxMac is more complete and tested than the wxCocoa port, that's why I want to do the rearrangement this way, with code being from the wxCocoa port being reused into the wxOSX-Cocoa implementation rather than the other way round. And since I've already done quite a lot of that work as of August 2008 things really proved to be easier that way. We don't lose existing implementations that way while making sure we can benefit from David Elliott's great work.

HIToolbox [done]

wxOSX is using a pImpl based implementation so that common code can be used wherever possible. While the Carbon flavor in trunk obviously has been tested extensively and is the most complete implementation, we added native Cocoa implementations, so that users can always test their applications against trunk and different implementations and switch back to Carbon if they stumble across a not yet implemented or problematic area. Cocoa Touch will be implemented more fully, once wxOSX-Cocoa has reached good quality.

Next Steps

Testing

Now that the source for osx-cocoa has been committed, we can all start testing on the c++ level and also building wxPython based on this variant.

iPhone Interface Integration

The iPhone has a very distinct interface, so creating the core GUI of an application running on iPhone should be done using the native Interface Builder Tools from Apple. But the processing, faceless part (or simple GUI parts like message boxes etc) can be done using wx. We should offer a neat integration for a GUI designed Interface Builder into wx, much like there is the bridge for native .RC integration on MS-Windows.

Think different...

Many things on OS X are very familiar, and yet some are very different. Having your app running on Mac without paying attention to certain details will always make it look 'foreign', i.e. a 'ported app' something Mac users are very critical of, while following the Mac way of doing things will help you make it a success.

Learning Macintosh Programming

Since so few people know so little about this:

• Development: Mac Programming.
• a useful list: List of error codes

Putting Menu Items in the Help Menu

Create a wxMenu and put your items into it. Then append that to the menu bar naming it "Help", or using the static member variable wxApp::s_macHelpMenuTitleName. Those items will automagically go to the OS supplied Help menu.

Common Pitfalls

Getting Your App to Run

• App Not Getting Input When Run