Recently I started using some kode (UKKQueue) that Uli Kusterer published as open source. Instead of just including the source files in my software I decided to wrap it in a framework.
One of the advantages of taking someone else’s kode and wrapping it in a framework in this manner is that it makes you stop and take the time to examine the kode. It’s great that you have kode that you didnt’ write and you haven’t succumbed to the “not invented here” phenomena, but you’re still using this kode in your application. You need to do your homework and examine what it is your plugging into.
Uli’s kode is solid and many people have already hammered at it. But sometimes it’s good to make trivial changes to get that feeling of ownership. For instance: Some people like the { on the line after the function implementation, and some people like the { an the same line as the function implementation. This is a trivial coding style difference; but if while you are reading the source kode you change it to your preferred style you will gain a sense of ownership. Or maybe this isn’t true at all and I’m trying to justify the fact that I do this when reading kode that I’m including in my project.
Here is a more concrete example of something I changed. In the file UKFileWatcher.h Uli uses a category to define the protocol UKFileWatcherDelegate. There is nothing wrong with this. In fact, it is the standard by which Objective-C libraries are written. This is the way Apple defines delegate protocols in their API.
@protocol UKFileWatcher
// +(id) sharedFileWatcher; // Singleton accessor. Not officially part of the protocol, but use this name if you provide a singleton.-(void) addPath:(NSString*)path;
-(void) removePath:(NSString*)path;
-(id) delegate;
-(void) setDelegate:(id)newDelegate;
@end// -----------------------------------------------------------------------------// Methods delegates need to provide:// -----------------------------------------------------------------------------@interfaceNSObject(UKFileWatcherDelegate)-(void) watcher:(id<UKFileWatcher>)kq receivedNotification:(NSString*)nm forPath:(NSString*)fpath;
@end
Personally, I prefer formal protocols So I changed the kode to use a formal protocol. At the end of the day, the code is functionally equivalent, but I twiddled with the knobs while I read the kode.
Brent Simmons started an email group discussion about creating a new mail client in Cocoa. You can read the discussion here. So I’ve decided to describe how I use mail. Please forgive the overuse of the first person singular, but I’m essentially describing a user profile of myself so it’s unavoidable.
I try to follow the inbox zero (action-based email) philosophy as much as possible. I file most messages in a folder called archive. I do, however, have another folder called receipts for online purchases and a couple of other folders for professional topics. I try to keep my inbox clean, but usually have 1 to 5 items that are read but in my inbox until I’ve acted on them.
I am not a full-time independent software developer. I do release software in my spare time and work full-time in the enterprise Java space. So I don’t have to trudge through as many emails as some people. I also rarely subscribe to mailing lists, and when I do, I always subscribe in digest form. After reading a digest from a list, I delete it. I do not save it so I can search it in my email client. The list is archived on the web and if I need to look for something I look for it on the posted archives.
I am interested in the way email is presented and managed. Here is how I currently use Mail. I do not use three pane mode. I minimize the mail windows as small as possible. If I want to read a message, I double click it. I then right click on the message and file it in a folder to archive it once I’ve read it.
My main problem with using mail this way is it is not easy to change from the inbox to another mail folder. When I do, I create a new view window (File -> New Viewer Window). I then make that window larger and use it to search for old messages.
As you may have guessed, I am interested mainly in the UI and information hiding. My current inspiration for product design would be ZenWare.
I looked high and low for a switch interface similar to the Time Machine switch. The iPhone uses this style of interface all the time with the UISwitch. Since I couldn’t find an implementation, I bit the bullet, created one and added it to CocoaMondo Kit 1.1.
Please don’t abuse this control and replace all your checkboxes with switches. Use common sense. A good guildine is to use a switch for a desktop application when the state of the switch has fare reaching implications. For example: The switch disables or enables the core functionality of the application.
Cocoa Mondo Kit 1.1
If switches are used sparingly then the user will hopefully pay closer attention when enabling or disabling them.
A year ago I released the MondoTextField. Well I’ve modified the component, made some bug fixes, and wrapped it in an Interface Builder plugin called Cocoa Mondo Kit.
Cocoa Mondo Kit 1.0
It’s seems slightly silly to release an Interface Builder plugin with only one component, but including the component as a framework is much cleaner than importing a bunch of source files.
On the first point, I’ve inserted a read only DVD into my machine and am shown a “Files Ready to be Written to Disc” section. How is this helpful and not confusing to regular users? Why do I care that Windows really wanted to write a file to the DVD but can’t because it’s read only?
The second point is more subtle. The column headers don’t even apply to this icon mode. You can’t resize them in this view. They are there in case you decide to switch to a view mode that might need them. Again, how is this helpful and not confusing to regular users?
Matthieu Cormier has been developing and releasing Macintosh software since 2003. He is pursuing a full-time career as a Macintosh developer but keeps getting roped into bland web-based enterprise projects.