The first is that we now use the 10.6 SDK for building against (we haven't completely decarbonated the engine yet, that will be a gradual process over the next couple of releases).
The second is that it is now much easier to build the Mac engine out the box - indeed it builds fine with Xcode 5.x and thus should also build fine with Xcode 4.x with no hacks required. The only thing you need to do is copy MacOSX10.6.sdk from an older Xcode version into 'Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs'.
In terms of changes, the cocoa port has been done against what I would call a 'prototype' version of the Platform API - this will be a simple C API that replaces various abstractions in the main engine source (such as MCScreenDC) and will be iterated over all platforms through time. It still needs a lot of work, but is 'good enough' for Cocoa which is the main focus at the moment. The result of this is that most of the 'osx*' files have now gone and the Mac port uses a generic set of 'desktop-*' files as a bridge between the old abstractions in the engine (still needed for other platforms) and the new Platform API. The platform implementation itself is split into 'platform-*' files which are platform independent, and 'mac-*' files which contain the Mac-specific implementations of the Platform API. Once we have migrated all platforms to the Platform API, the 'wrapper' abstractions in 'desktop-*' will be removed and the platform API calls rolled into the main platform-independent part of the engine. (Thus eliminating MCScreenDC and platform-specific portions of other classes such as MCStack).
The other most significant change that will impact those of you who have Mac externals is that 'the windowId' is no longer a Carbon WindowPtr. It is now the global 'windowNumber' of the NSWindow (the 'windowNumber' is a Window Server ID). You can fetch an NSWindow from a given windowNumber (assuming the window is in the same process) using [NSApp windowWithWindowNumber: t_window_id]. The most important upshot of now using NSWindows is that we now also use NSViews - you can now successfully embed a NSView within an NSWindow owned by LiveCode. Do this, add your NSView as a subview of [t_window contentView]. Indeed, doing this in revBrowser resulted in deleting a whole whack of old code, and simplified things considerably - I suggest looking at the revbrowser source if you interested in looking into leveraging this.
The current status of the Cocoa port is that it is relatively stable, and almost feature complete. There are the following things to bear in mind:
- Backdrop support is currently non-existent - I've had a couple of attempts at getting it to work but have (as yet) been unsuccessful. Cocoa does not have an idea of WindowGroups which Carbon does, and there does not seem to be a viable replacement.
- Drawers are currently unimplemented - drawers are not NSWindows in Cocoa, they are just NSViews which is causing issues with integrating support for it.
- QuickTime support has been refactored into separate files (out of MCPlayer!) and a QTKit implementation of the player (MCPlatformPlayer) has been developed - however, this support is not weakly linked yet (which we will need to do for MacAppStore support).
- There is no AVKit implementation of the player yet (which will be needed for Mac AppStore apps which use multimedia features).
- Cursors sometimes stick or do not change to resize cursors - this issue is being investigated
- Drag-drop cursors (particularly the 'no drop' sign) do not stick properly - this is being investigated
- Cmd-Shift-'_' does not work in the S/E (I've still yet to work out what exactly Cocoa is doing with this particular key combination - it seems to be somewhat strange!)
- Running on a Retina display can cause issues with themed scrollbars - this is being investigated
