Some tweaks.

git-svn-id: svn://dev.iconfactory.net/Projects/Software/UIKit/trunk@5039 d3437ac4-8b1b-0410-be28-b75ab53cb89f

README.md

@@ -20,9 +20,9 @@ The UIKit port in Chameleon starts at a very low level and attempts to go so far
 
 The interface between AppKit's NSViews and NSWindows and Chameleon's UIWindow and UIViews occurs at the "screen" level. UIKitView is an NSView which you add to your NSView hierarchy in whatever way you want. The UIKitView hosts a UIScreen instance which is home to UIKit's interface elements.
 
-Each UIWindow belongs to a UIScreen, and UIViews must exist on UIWindows. This should all worked the same as you've come to expect on iOS. An important difference here is that Mac applications often have more than one window. If you use UIKitView on more than one window in your app, be aware that this means your application how has more than one UIScreen and as a result some methods such as [UIScreen mainScreen] may suddenly do unexpected things. When porting Twitterrific code from iOS, this was one of the most difficult aspects initially as a vew things were making assumptions about there only being a single, main screen as that is normal on iOS devices. Be aware of it.
+Each UIWindow belongs to a UIScreen, and UIViews must exist on UIWindows. This should mostly work the same as you've come to expect on iOS. An important thing to note is that Mac applications often have more than one window. If you use more than one UIKitView in your app, be aware that this means your application how has more than one UIScreen and as a result some methods such as [UIScreen mainScreen] may suddenly do unexpected things. When porting Twitterrific from iOS, this was one source of unexpected bugs as a few things were making assumptions about there only being a single, main screen since that is normal on current iOS devices.
 
-Once a UIKitView exists and there's a UIScreen available to work with, your code can proceed to build a UIWindow and UIViews on top of it and be largely unaware that it is actually running on OSX instead of iOS. For those cases where you need to customize some UI, <tt>UIUserInterfaceIdiomDesktop</tt> has been added so that your code can differentiate between running a pad or a phone. To keep code cross platform, the following is a good way to structure things so that Apple's UIKit doesn't encounter the unknown <tt>UIUserInterfaceIdiomDesktop</tt> symbol:
+Once a UIKitView exists and there's a UIScreen available to work with, your code can proceed to build a UIWindow and UIViews on top of it and be largely unaware that it is actually running on OSX instead of iOS. For those cases where you need to customize some UI, <tt>UIUserInterfaceIdiomDesktop</tt> has been added so that your code can differentiate between running on a pad, phone, or desktop. To keep code cross platform, the following is a good way to structure things so that Apple's UIKit doesn't encounter the unknown <tt>UIUserInterfaceIdiomDesktop</tt> symbol when compiling for iOS:
 
 	if (UI_USER_INTERFACE_IDIOM() == UIUserInterfaceIdiomPhone) {
 	// iPhone
@@ -34,13 +34,15 @@ Once a UIKitView exists and there's a UIScreen available to work with, your code
 
 You can usually just create an instance of your iOS app's UIApplicationDelegate object and then pass it into UIKitView's helper method <tt>-launchApplicationWithDelegate:afterDelay:</tt> which will emulate the startup process of an iOS app (it will even attempt to show a Default.png if a delay is given). You might perform this step in your NSApplicationDelegate object's <tt>-applicationDidFinishLaunching:</tt> method. It is not necessary to use UIKitView's helper method to "launch" your app, but it can be a good way to get started.
 
+Generally the interfaces to the classes are the same as Apple's documented interfaces. Some objects have additional methods that are useful for OS X and are defined in (ClassName)AppKitIntegration.h headers which are not included by the standard UIKit.h header. To easily include all AppKit extensions into your code, import <UIKit/AppKitIntegration.h> when compiling on OS X. There are also a couple of non-standard UI classes defined such as UIKey and UIViewAdapter that I designed out of necessity. (Keyboard handling in particular is a weak spot of Apple's current UIKit and so I developed my own rough API in place of anything "official" being documented by Apple.)
+
 ## Examples
 
 Right now there's hardly any demos or examples or documentation. There's a simple app called BigApple in the Examples folder which might be enough to get started. It also shows how the UIKit Xcode project can be referenced from another Xcode project and setup as a dependency so that it is built automatically when the BigApple project is built.
 
 ## Authors
 
-The Chameleon project was created by Sean Heber (Twitter: [@BigZaphod](http://twitter.com/BigZaphod/)) of The Iconfactory and wrote nearly 100% of the initial version over several months. Craig Hockenberry (Twitter: [@chockenberry](http://twitter.com/chockenberry/)) was the first user/tester of Chameleon and found many holes and edge cases in the implementation.
+The Chameleon project was created by Sean Heber (Twitter: [@BigZaphod](http://twitter.com/BigZaphod/)) of The Iconfactory and he wrote nearly all of the initial version over several months. Craig Hockenberry (Twitter: [@chockenberry](http://twitter.com/chockenberry/)) was the first user/tester of Chameleon and found many holes and edge cases in the first implementation.
 
 ## License