Development: wxMac
Building under 10.6 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 1The 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" 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.
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 ...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
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.