Development: wxMac
Building under 10.6 Snow Leopard
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.