Jay Tuley

NicePlayer 0.95 the Shiny Penguin by Jay

Although NicePlayer is still Mac OS X only and will probably stay that way, it’s now open source and what better animal than a penguin represent open source (even though it suggests linux)...plus NicePlayer’s icon and widgets are shinier (they literally have a sheen now) so that’s why this release is the Shiny Penguin1.

1 Previous releases were the Dark Horse and the Bad Wolf.

Open Source

NicePlayer is tri-licensed under the MPL, LGPL, GPL. They are all copyleft licenses, MPL (Mozilla Public Licenses) is the least restrictive it terms of reuse. MPL is not what “GPL-haters” like to call viral as it only pertains to the licensed code that you are modifying and not the rest of your projects code that is incorporating it.

Shiny Controls

I gave the controls sheen, they extend across the movie bounds continuously when the video is black it’s more obvious that they are controls and not strange floating symbols.

Subtitles

I’ve also added basic external subtitle support, it was something I wrote simple parsers for a year ago, but never added a renderer, I kept on putting it off, so finally decided to put it in this release get some feedback.

It’s already been reported that I don’t allow the encodings to be set for subtitles. When this was reported I figured it’d automatically work with UTF-8, but it actually automatically treats it as a c string unless a Byte Order Mark is at the front of the file. This typically doesn’t get added for UTF-8 because it can mess things up for some kinds of files (though it does not in this case).

So the next version I will change it to the 10.4 api’s, which have been improved for dealing with encodings. We probably will stick to making UTF-8 and UTF-16 the only guaranteed way of your encodings working (with out BOM being necessary for UTF-8), because even if most subtitles out there aren’t Unicode they should be, and it’s not hard to convert (we may include a simple converter next release too), and that is preferable to adding a huge list of encodings in the preferences.

Perian

Perian has helped shape some of the features for this release. I’ve been compiling from source seeing what is in store for version 1.0, such as matroska support. My test file had chapters,subtitles, and alternate audio all show up in QuickTime Player. So I added menus so they can be used with the CoreVideo engine in NicePlayer too. Also the current version of Perian has FLV support, so we added an association for that file type so you can opened by double click.

Virtual DVDs

Another program that inspired a feature was Virtual DVDs. Virtual DVDs allows you to wrap a VIDEO_TS folder in a bundle with the extension .vdvd which makes it double clickable from the finder to open in DVD Player. So I adopted their convention so you that can double click one of those same .vdvd bundles to open in NicePlayer as well.

Scary Transparency

Finally last feature I’d like to note is that we’ve made it possible to make movie windows transparent. I’m not sure there’s a good reason for it (beyond a couple people asking for it), but then again it only can be invoked via applescript (so it doesn’t clutter up the GUI). We have a default script under the heading “Just For Fun”.

Rundown

Here’s the official change list for 0.95:

  • 100%25 Open Source (MPL/LGPL/GPL)
  • Added support for Chapters, and enabling extra Audio and Video tracks for the Core * Video engine
  • Added basic support for external subtitle files
    • .ssa substation alpha,
    • .srt SubRip,
    • .sub MicroDVD
    • Added file type extension recognition for
    • .divx,
    • .vdvd (package around VIDEO_TS ala “VIrtual DVDs”),
    • .mkv (Matroska added in anticipation for future Perian support),
    • .ogg( for Theora/Ogg support provided by the xiph components),
    • .flv (for current perian support)
  • New fresh look
  • Added AppleScript-able Transparency, with a default script for applying it
  • Added preference for volume memory on creation of new windows
  • Added AppleScript vocabulary for determining full screen
  • Fixed bug that caused niceplayer to hang on quit after watching a DVD on a Core2Duo Macbook
  • Fixed bug involving not being able to unmute
  • Fixed bug involving changing window level in fullscreen
  • Fixed bug in auto dvd launching script
  • Fixed bug that sometimes would cause movies to show up black when opened off a removable disk
  • Fixed various crashes

STL-CocoaHeads Meeting (4/29) 2pm CST - Topics: Quartz * HUD * LLVM by Jay

Saint Louis CocoaHeads Meeting 4/29/06 2pm CST @ St. Louis Bread Company, 10740 Sunset Plaza, 63127

Meetings are casual and we don’t have to stick to topics, but here are some:

* Programing with Quartz. I’ll be bringing my copy of the book to show, it’s a very good book. Although it’s focused mainly on C, it’s good to know what’s going on behind the cocoa drawing classes, plus you can always use C directly in Objective-C, and the concepts directly transfer.
See Also: Programing with Quartz by Gelphman and Laden

* Resolution Independence. This is a hot topic these days with both higher dpi and larger LCD screens becoming more and more prevalent. Tiger has apis to support it, although most applications aren’t ready for it. Cocoa gets a lot of support for free, but there are a few gotchas. Also lately there have been several interesting post in Surfin Safari about the need to deal with High DPI in web design and the ideas behind it transfer between that and cocoa ui design, not to mention as of Tiger your seeing more and more UI designed with HTML.
See Also: Surfin Safari

* OpenHUD.
The HUD user interface debuted in Motion, then showed up in iPhoto, and now is in nightly builds of Safari, IWeb and is starting to show up in closed source shareware apps. St. Louisan Andy Matuschak started an open source project to provide an open API for this must have GUI style. Andy may or may not be able to come to the meeting this month, so we might just gloss over this topic and save it for another month.
See Also: OpenHUD Intro

* Real Universal Binary!

So I haven’t seen this mentioned anywhere but the LLVM project website, The Low Level Virtual Machine, released a new GCC 4.0 frontend that currently only works on Mac OS X (Both PPC & X86) and supports Objective-C/C++. If your unfamiliar with LLVM it can compile C to a bytecode representation about the same size a x86 binary (includes a JIT compiler too), the main goal of this project was to provide runtime optimizations and transformations, but there have been other extensions to this project such as providing memory safety for C programs. The implications of adding memory safety to Objective-C would be mean it could overcome one of it’s the biggest shortcomings compared to other modern programing languages. There are of lot of interesting potentials from this project and since Apple hired the lead developer last year, and now with the addition of objective-c support 4 months before the leopard preview, I think it’s not a bad bet to assume Apple is targeting Leopard Objective-C features based on LLVM?

From the Release Notes :

LVM 1.7 includes a brand new llvm-gcc, based on GCC 4.0.1. This version of llvm-gcc solves many serious long-standing problems with llvm-gcc, including all of those blocked by the llvm-gcc 4 meta bug. In addition, llvm-gcc4 implements support for many new features, including GCC inline assembly, generic vector support, SSE and Altivec intrinsics, and several new GCC attributes. Finally, llvm-gcc4 is significantly faster than llvm-gcc3, respects -O options, its -c/-S options correspond to GCC’s (they emit native code), supports Objective C/C++, and it has debugging support well underway.

5 reasons not to choose a Creative Commons license for code by Jay

Although Creative Commons licenses are fine for many types of content, you should probably think twice before using it for code, and here are my top 5 reason why:

5. Creative Commons has summaries for actual software licenses as well. — It may only be GPL and LGPL, however, if the summary feature attracted you to Creative Commons and you liked the GPL or LGPL license but thought they were too long for the average person to read; it’s not a bad reason to switch from Creative Commons.

4. Creative Commons is pretty plainly GPL incompatible. — Even the least restrictive Creative Commons version has a clause that allows the original author to remove the original copyright notice from derivative works. This is a restriction beyond those offered in the GPL thus you can’t combine Creative Commons code with GPL. This shrinks your Open Source target audience in the area of code reuse and contributions, but that’s your decision. See also Debian-Legal Creative Commons Summary.

3. While the Creative Commons Attibution summary reads like the new BSD license, it’s a summary, not a license, read the actual license you may not like it. — If it turns out all you liked was the summary, you should have used the new BSD license, the MIT license, or the U of I license, they are all pretty much the same and you don’t have to worry about summaries (they are easy to read).

2. Not OSI approved, and for good reason. — Nothing in the license sounds remotely like it could apply to software, and it’s not very neutral in it’s description of covered works. Sure if you change a word here and there, maybe it could apply to software, but if you have to change words around to make it work, it’s a pretty poor choice for your open source software. See also Open Source Definition. See also list of OSI approved licenses.

1. The Creative Commons F.A.Q. tells you not to use it for software. — And I can’t think of a better reason than that.

Class Clusters by Jay

Recently Elsewhere

Cocoa collection subclassing | Jens/Log disagrees Faux Collection Class Subclassing | AgentM and both have some bits on class clusters. AgentM’s is a rant about not being able to easily subclass collections, which I am sympathetic too recalling the joy of programing in smalltalk with its rich collection hierarchy. Jen’s is basically a response saying Class Clusters can be frustrating but their okay, just drink the koolade AgemtM. If you explain Class Clusters to someone, they makes sense, but when you try to use Apple’s or don’t know they are there, frustrating things can happen, and I don’t think that it’s really the class clusters fault. Making a composite class by wrapping or forwarding messages isn’t that much of a hassle, subclassing anything requires some knowledge of the class and Apple does document approaches to subclass class clusters, so I’m on the koolade camp on AgentM’s rant. However, I believe there are some bugs in the implementation of a few of Apple’s class clusters that cause many to think that all Class Clusters are evil.

FUD

I think there’s a lot of fear, uncertainty, and doubt in regards to class clusters. There really shouldn’t be though, Apple has a nice page describing the benefits of Class Clusters — Cocoa Objects: Class Clusters

See a class cluster really is really just a sneaky use of a Factory Method (GOF 107) to instantiate a subclass from an abstract superclass. It’s sneaky because its hides it all. alloc, rather than actually allocating, returns a Creator (probably a singleton) and init actually allocates your real product and returns it. As demonstrated here:

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
    id obj =[NSArray alloc];
    NSLog(NSStringFromClass([obj class]));
    NSLog(NSStringFromClass([[obj init] class]));
    [pool release];
    return 0;
}
2006-03-17 22:55:15.100 TestDataTypes[6105] NSPlaceholderArray
2006-03-17 22:55:15.101 TestDataTypes[6105] NSCFArray

This is all good, because the classes returned are all subclasses and being the good little object oriented programers we are, we never check what a class actually is. Instead, when need to runtime type check it’s only to determine if it’s a subclass or if it responds to a method or protocol and that should be just fine with class clusters.

If only using standard best practices when runtime type checking would keep us safe, unfortunately a few of Apple’s class clusters, mainly collection classes, are implemented in such a way that they break expected inheritance and expected polymorphism by advertising the wrong public interface for the returned private subclass (I don’t know if this was the case for NeXT or not, but I suspect it wasn’t). I’ll continue with some examples of where this implementation goes wrong.

Dumb Responses from Class Clusters with Multiple Public Superclasses

Here’s a Pop Quiz: What should this statement return?

[[NSArray array] isKindOfClass:[NSMutableArray class]];

Ideally it should return false because when we see the documentation on these public abstract classes, NSMutableArray inherits from NSArray.

However, actually this statement returns true because the private subclasses returned for both public abstract superclasses are the same class inherited from NSMutableArray known as NSCFArray.

Okay so the purpose of having the same class is for easy toll free bridging with Core Foundation, but you know, as long as the instance variables are the same, is Core Foundation really going to care about new methods or a different hierarchy in obj-c land? I’m thinking no in theory, but I’ve not tested and I’m much happier not digging into the C-ness of Obj-C and someone can prove me wrong or right if they wish. However, if you really really wanted to keep the same private class type between the two interfaces, you can always fake the expected hierarchy by making isKindOfClass: call isSubclassOfClass: on the appropriate abstract superclass’s metaclass, and really no one would be the wiser, Core Foundation or otherwise.

That was problem #1, and so you might be thinking to yourself well I don’t test for inheritance with cocoa programing often, most of the time I’ll test for specific methods out of habit, because cocoa programers tend to use informal protocols rather than having deep hierarchies anyway, so it’s not that big of a deal.

So our second pop quiz: What is the result of this statement?

[[NSArray array] respondsToSelector:@selector(addObject:)];

NSArray is not supposed to respond to addObject:. I know that, you know that, but a program is generally going to believe respondsToSelector: over what we think, and respondsToSelector: says true. Of course if you run this line:

[[NSArray array] addObject:@“test”];

you get an exception. Think about when you have a bunch of objects in a collection with various types, some may respond to addObject:, some don’t, and you want to use runtime checking to manipulate them appropriately. How are you suppose to take advantage of polymorphism of this method in this case without being able to trust respondsToSelector:.

There are simple work arounds to these problems, because they are only a handful of classes, but this is clearly a poor implementation of a class cluster, and I haven’t tested every class but I think all Mutable-NonMutable class hierarchies in Foundation on OS X suffer from this bug (Although GNUStep is A-OK from looking at the source), and I don’t think there’s a reason not to fix it, being that they are class clusters, all apple needs to modify are the private subclasses and people aren’t going to be using those methods currently because they return the wrong values that aren’t useful when wrong.

Demonstration of Problem and Fixability

I did write a few Unit Tests to clearly demonstrate this problem with NSArray. It also has a second target called ProperClassCluster that overrides some NSCFArray methods (using categories) to fix responses in inheritance & method testing. In that target I also swizzled the addObject: method to provide an example of returning the correct exception when calling a method that doesn’t exist on an NSArray. A real fix wouldn’t require these hacks, but this works for demonstration purposes. Download ProperClassCluster.zip (20k)

Yojimbo "Your effortless, reliable information organizer..." by Jay

Yojimbo “Your effortless, reliable information organizer…: “Yojimbo

(Via [GusMueller blog].)

So Yojimbo seems to be just what I’m looking for and I’m glad Gus pointed it out. However, I’m not sure if it really is a competing product with VoodooPad as he suggests. YoJimbo seems more like shoe box where you stash stuff while VoodooPad is more of a notebook, something you are constantly changing, revising, scratching out, rather than just storing for later use. I could really really use Yojimbo, I like to stash stuff, but the reason I’m not going to buy it is that it has zero Automator or AppleScript support, WTF! What I really want to be able to do is store my PDF web Receipts and Categorize them in on step from the print to pdf menu. Oh well I guess I can wait, as it’s only version 1.0.