The day’s lessons were much more of a refresher course than anything else. There were no standout challenges, nor any revelatory discoveries. But, a few things did strike me.
The learning process, thus far
I need to be careful about waiting too long between the studies and the related blog. The things that were fresh on my mind quickly fade; guess I’m still getting used to the blogging process.
One thing I had forgotten was just how chatty Objective-C / Cocoa is. I feel like I’m constantly instantiating objects for one purpose: to help two other objects talk to each other to pass one small piece of data, one time. I’m often wishing I could just get the start and end points of a process to talk to one another directly. For example, if I’m looking at NSTask, I need to connect an input NSPipe, then init an NSFileHandle to write an NSString that was converted to NSData to feed into the standard input pipe. The whole process must also be set up on the standard output end to get the returned text. Make a pipe to fit to the task, then grab the pipe’s file handle to get some data that we reformulate into a string.
Why can’t NSTasks connect directly to one another, perhaps through “pipeTo:” and “pipeFrom:” handlers? The pipes and file handles and data objects all seem to be part and parcel of the process in general, so I suppose I feel that NSTask should just do that automatically. I’ll write more about specific experiences with NSTask-related objects in the next blog.
There is definitely something to be said about the feeling of empowerment one gets with the Cocoa APIs. With very little code, getting a drag and drop graphic preview to appear representing the dragged item is kind of magical. I don’t mean magical in the “Bindings are kind of magical” way, but rather in the, “I truly feel I’ve been given a powerful set of tools I can leverage to greater purposes” kind of way.
Here’s hoping this week’s Apple announcement gives Cocoa developers a whole new platform for leveraging our skills and further aggrandizes the Cocoa development community to the world.
Cut, Copy, Paste and Drag and Drop are dead simple
I had forgotten how easy it can be to get very “Mac-like” behavior with very little code. The drag and drop example in Chapter 23 did reveal something unusual that I recall from many years ago. When setting attributes on an NSFont, we can also attach bold and italic through use of NSFontManager. An NSShadow may also be applied. Look, the font is FLOATING OFF THE SCREEN!
However, the returned font, when queried for sizeWithAttributes: (which returns an NSSize that bounds the attributed string), does not seem to take the NSShadow nor italics into account when computing the returned size. As such, the drag and drop thumbnail is a clipped version of the graphic being displayed.
This seemed to be an issue even for the Finder, especially in 10.4 and 10.5. Dock items with descenders in the file name could be seen to be cut off by a few pixels. I responded to someone’s developer forum posting about the returned size inaccuracy by pointing out how Apple seemed to have the same issue. No one had noticed it, and it seems to me that the issue remains, or I have some mental block on how to get a proper size returned. There may be a solution in the NSString Application Kit Additions, boundingRectWithSize:options:attributes:
Categories are awesome
What an amazingly powerful tool, though I suppose it runs the risk of implementing methods that already exist (sometimes I find it easy to overlook the existence of a method I need for a task). I’ve seen some forum postings responding to developer questions saying to use some method that is from a private category she wrote for herself. Clearly it can be easy to forget that a very useful tool WASN’T written by Apple.