Being a big fan of avoiding dependency hell wherever possible, I was overjoyed to discover CocoaPods. CocoaPods is a dependency manager for Cocoa projects. Instead of manually downloading and adding frameworks and components to a Cocoa project, CocoaPods does it for you.
Specify the libraries for your project in an easy to edit text file. Then use CocoaPods to resolve all dependencies, fetch the source, and set up your Xcode workspace.
To use ACEView with CocoaPods, add it to your project’s pod file, follow the instructions for adding a pod to your project on the CocoaPods site.
As a step on the journey towards becoming a first-class Cocoa citizen, ACEView has attained its very own documentation!
I’ve documented the publicly-accessible classes as best I can, using the wonderful appledoc tool. One may view the ACEView documentation online, in the relevant header files, or build it for use within Xcode. If ACEView is included via CocoaPods and appledoc is installed, the documentation will be generated automatically!
I wanted to use Connection Kit for my current project, but ran into issues as it requires a few other frameworks to function. Many months ago I worked around this by copying the internal framework’s source files directly into Connection Kit.
Everything went well until I updated Connection Kit. Suddenly it required more internal frameworks, and copying their source became impractical.
Merging some convenient (but old) code I found laying around into a new project, I came across this build error:
Undefined symbols for architecture i386: "_GetCurrentKeyModifiers", referenced from: -[Class mouseDown:] in Class.o ld: symbol(s) not found for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation)
Scrolling through the source for this class, I found calls to GetCurrentKeyModifiers() scattered about. This function is from Carbon, the AppKit way to get the same thing is:
[[NSApp currentEvent] modifierFlags]
Swapping out GetCurrentKeyModifiers() calls for this cleared those build errors right up.
The NSPopOver, a new addition to the Cocoa toolkit since OS X 10.7, is an excellent way to give the user feedback on actions requiring their input. In my use case, I needed to be able to show an NSPopOver containing a multiline label populated with a string of varying length.
Getting the NSPopOver, NSView & NTextField all working perfectly was very basic.
Ensuring that the NSPopOver’s NSView & NSTextField resized appropriately was more challenging.
I needed to get the rectangle that my string would fill when drawn. A short Google search led me here: SO: NSString sizeWithAttributes: Content Rect. As I know I’ll be doing this again, I made a category of NSString that provides this.
The rest was simple:
1 2 3 4 5 6 7 8 9 10 11
NSSize size = [string sizeWithWidth:200.0 andFont:[textLabel font]]; [view setFrameSize:NSMakeSize(size.width + 30, size.height + 30)]; [textLabel setFrame:NSMakeRect(15, 15, size.width, size.height)]; [textLabel setStringValue:string]; popover.contentSize = view.frame.size; [popover showRelativeToRect:[textField bounds] ofView:textField preferredEdge:NSMaxXEdge];
The NSString+Size category is available here: Cocoa Categories.
After doing this, I rethought my approach and streamlined it by creating a category on NSPopover, which is available in the above repository. I wrote about the process here: User Feedback & the NSPopover.