Jay Tuley

Well, if Napster can’t get market share with porn that will sure be the sign to give up.

Call Me Fishmeal.: Frameworks are Teh Suck, Err.:

Creating shared frameworks is a lot of hassle for third-party developers of consumer software, introduces instability into the development process, and encourages slower and larger applications. Code sharing is better accomplished through creating new directories for shared code in subversion and judiciously including only the files and resources needed by any application in its Xcode project.

This seems really target towards the common practice by cocoa developers that lump a lot of unrelated classes together. (I’ve done it before too, and this year started re-factoring into smaller more specialized and logically organized frameworks, because a hodgepodge framework does suck) A large lump of unrelated classes is hardly the definition of a framework. Also I should note that this article omits the use of cross project references that gets rid of most of the configuration and versioning issues mentioned. It also omits the use of frameworks for sharing open source that adds the pros of being easier for other developers to use and contribute changes back.

I don’t like ranting on my blog, but it happens anyway, and today it’s because of what Xcode 2.2 did

OMG, do you know how many nested functions I use, a lot more than in that screen cap. It’s not even a warning, I keeps me from doing any other work on my projects until I change each one. Crap! It’s wasn’t in any release note as far as can tell. I’ve finished remove the ones directly in NicePlayer (the resulting code looks so ugly). Now I’m working on the frameworks that use them, even though there isn’t an immediate, as they are still compiled, but I’ll have to do it at some point anyway so I might as well do it now.

The reason I use Nested Functions is mainly that they work as closures and make it easy do HOF enumerations in Objective-C (collect, detect, select, reject, inject — aka. map, find, filter, remove, and fold). Now I have to declare functions outside of @implementation and pass everything I use into a context pointer (which gets old pretty quick) and also be wary of my naming conventions.

Normal enumeration’s in objective-c suck

	
NSEnumerator *enumerator = [anArray objectEnumerator];

id object;

while (object = [enumerator nextObject]) {
    // do something with object…

}

	

So most of those lines are the same every time you do an enumeration. There are simpler ways to make that enumeration suck less then my prefered. Such as a foreach() style syntax loop that reduce the code to setup the enumeration to one line.

See Jonathan Rentzsch’s paper Improving Cocoa ObjC Enumeration or Micheal Tsai or Micheal Tsai’s blog entry Cocoa Enumeration. However macro magic only goes so far, because it has to create variables you can’t see, Micheal Tai’s way seems to reduced the chance of collisions to a reasonable amount, and while Jonathan Rentzsch’s way works fine with loops in the same scope, it doesn’t look like it would work nested. Aside from the downside of macro magic, I prefer HOF over foreach as HOF’s are a mini design pattern that give some insight into what a loop is doing helping with readability.

There exist smalltalk like block solutions for Objective-C such as F-Script and OSFoundation, however these solutions use blocks as strings, which works, but keeps me from using them for my enumerations. As a side note I use F-Script for debugging often (there’s nothing better than an interactive shell).

HOM enumerations seems like a good way to do things, especially when you read Marcel Weiher’s paper Higher Order Messaging all of those enumeration examples look really clean. However, in practice, most of the time I’m doing things that don’t work with HOM enumerations, or to use HOM would require junking up classes with methods that are only used in one instance and don’t have any business being in them. It breaks down in really simple common cases, such as converting an array of file paths in to anything.

id imageFromPath(id each, void* context){
    return [[[NSImage alloc] initByReferencingFile: each] autorelease];

}


	
NSArray* anArrayOfImages = [anArrayOfImagePaths collectUsingFunction:imageFromPath context:nil];

I don’t see how to do this with HOM with out either doing it in two passes (this could be many more passes in a more complicated example):

NSArray* anArrayOfImages = [[NSArray arrayWithObject:[NSImage alloc]] collect] initWithFilePath: anArrayOfImagePaths];
[[anArrayOfImages do] autorelease];

or adding a method to NSString or NSImage to produce a image from a string, the first would be awful design wise, the second might be okay in this case, but with a more complicated and specialized construction it would probably also be bad as well.

I think I should clarify that I think HOM is really good, and better than what we have now for non enumeration uses mentioned in that paper and could help lessen the ridiculous verbosity of Objective-C syntax a lot.

So I’m left with lots of trade off on the enumeration front.

Nested functions helped alleviate another objective-c ail, the lack of private methods. If you had to do any recursion or just wanted a convenience method for use in just one method, you could use a nested function rather than a fake private method with some combination of underscores and prefixes, it just did a little bit to keep your hidden interfaces smaller.

Not having nested functions anymore is getting me close to switching to bridged languages like python or ruby, but I’m looking hopeful toward Marcel Weiher’s Objective-Smalltalk. I even know what my first project would be when Objective-Smalltalk comes out.

So I was thinking, I’ve been having bad luck on predictions, in reference to an old blog post I made about how Apple won’t start sellomg video downloads. But as I re-read it, I actually left it to whether the next iMac was designed to be mounted on a wall or not, huh, that’s actually kinda eerie (although the screens still aren’t very big).

It’s not as eerie as DB’s post Convergence Kills which I was pretty much nay-saying with that post of mine in regards to DB’s of Apple becoming a the benevolent DRM dictator. I think Jonathan Rentzsch made a good point at Evening at Adler that maybe tolerating DRM because of it’s not so bad now, may cause consumers issues in the future with worse less reasonable DRM. I now have a new perspective with over a year later of events, along with my new grudge in regards to my NicePlayer, a freeware, mac only, QuickTime based player that uses Apple’s own APIS for playback, can’t even playback Apple’s DRM video content, I might be joining the grassy knoll camp now.

Ultimately, even though Apple is expanding their DRM reach, they may not be able to prevail against the cable & satellite companies, but of course those companies will just have their own DRM.

So I think, at the suggestion of Robert, I’m going to get in the habit of naming each release of NicePlayer with the Adjective Noun. 0.92 was the Dark Horse which end up pretty accurate, I said so at the time based on versiontracker downloads compared to that of other alternative movie players for mac. Excluding MPlayer and VLC which get a huge amount of downloads, NicePlayer is probably only second to DjoPlayer (MPlayer based) in Download rates on versiontracker.

However there has been recent evidence of NicePlayer being a Dark Horse, while NicePlayer is still quite unknown, there was a review on MacMod’s Video Player Roundup comparing QuickTime Player, Windows Media Player, VLC, MPlayer, and NicePlayer, and the conclusion found VLC the best with NicePlayer as runner up.

Niceplayer is one of the best. For watching movies, the onscreen controls are near perfect. With a little work on file compatibility, Niceplayer would quickly reign supreme over the other Mac video players.

If only file compatibility require just a little work. NicePlayer is mostly and most importantly a user interface, and for file compatibility, we have very basic plugin interface that really lets you plug in any cocoa view as a replacement and you just have and have it respond to a few commands. So I’m hoping for third party action on the file compatibility front. You can find out more on the NicePlayer Plugins page such as how to make one, and what plugins already exist.

Why so Bad?

So why call 0.93 the Bad Wolf you say? Chose it at random that’s all…it just sounded good…does it matter? But you’ve heard that before? You’ve heard it lots of times? Everywhere you go? Two words following you? Nah, just a coincidence, like hearing a word on the radio and then hearing it all day.

Obscure Cult Sci-fi references aside, there are a few Bad Wolfish things NicePlayer does, such as has a somewhat controversially script menu. Apple provides a global script menu but it’s not a great experience for application specific commands, and especially not useful if you want to provide some default scripts to novice users. Some people say you should only use the Apple provided menu, but there also prominent apple apps with their own menu too. NicePlayer has taken a side and it’s CocoaScriptMenu (since I wrote it for this app). The other thing I added in this release somewhat Baddish was an easter egg, something of no value what so ever, but is now a hidden feature. What is you ask? Well since a signature feature of NicePlayer is the ability to have floating movie windows, the new hidden feature is the ability to have movie windows lay below the desktop icons, see I said useless, but fun :D and hidden. And finally Robert’s been battling the Tiger DVD Framework, for some reason the framework has been degrading functionality wise as of late, so the DVD plugin is a bit of a workaround this version.

Other than that I wouldn’t say 0.93 is Baddish, unless of course this is a case when bad means good. This version should be much more stable, it should work better on 10.3.9 than the last one, it smartly handles non-square pixels with DV footage, and can send us crash reports if you install Smart Crash Reports.

The Full Run Down

What’s new in Version 0.93 (v394)

• Can switch playback engines on the fly


• Detects correct aspect ratio of DV footage (Tiger only)


• Can open content nested content by opening it’s folder


• Integrated AppleScript Menu


• Manually change aspect ratios via the script menu


• General stability enhancements


• Increased applescript vocabulary


• Support for Smart Crash Reports if you have it installed (http://www.unsanity.com/smartcrashreports)


• Fixed bug that caused windows to disappear


• Fixed bug that caused NicePlayer to crash when launched on a case-sensitive file system.


• Fixed multiple bugs with dvd playback on tiger


• Fixed bug with playlists occasionally opening improperly