Jay Tuley

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 Penguin¹.

¹ 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

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.

So I started making some default scripts and other script examples for NicePlayer. I then realized that I needed keyboard shortcuts on the CocoaScriptMenu. DVD Player’s script menu just uses numbers in order, I don’t like that, another solution I considered was to have some kind of separate config, either gui or text file. However, since renaming is required to order and change the menu text in CocoaScriptMenu, that could get a little complicated.

Keyboard Shortcuts

The solution I settled on was to add the keyboard shortcut itself to the filename. I feel this implementation ended up working really well. The main worry I had was that user error could end up disrupting the host application’s keyboard shortcuts, but the script menu is loaded later than the other menus, so it’s menu shortcuts have the least precedence and thus show up blank if a user tries to duplicate a shortcut. To facilitate adding keyboard combos to file name, I came up with an ASCII representation for the modifiers that kinda look like the real symbols and all require shift to create them (so they won’t reduce the possible representable keyboard short cuts). The symbols are as follows

∗ – Command

$ – Shift

^ – Control

%25 – Option

To create a short cut you add it between two curly braces in the file name before the file extension, ordering the modifiers before the key character, such as Hello World {∗^$H}.scpt for command-control-shift-H.

However after implementing this, I realized most people are going to be using a filesystem that supports unicode, and this can look a lot prettier. So I added support for these shortcuts, not just in the ascii, but using this UTF8:

⌘ – Command (0×2318 PLACE OF INTEREST SIGN)

⇧ – Shift (0×21E7 UPWARDS WHITE ARROW)

⌃ – Control (0×2303 UP ARROWHEAD)

⌥ – Option (0×2325 OPTION KEY)

And you can surround them by LEFT & RIGHT SQUARE BRACKET WITH QUILL (0×2045 & 0×2046) instead of curly brackets. Such as Hello World ⁅⌃⇧⌘H⁆.scpt

While UTF8 looks a bit neater, for safety sake, all my default NicePlayer scripts will use the ASCII way. And the ASCII way is also easier to type, so I’m guessing it will end up being the preferred way, but it’s left up to the user.

You can even add Function Key shortcuts by just typing out {F13} or {⌃⇧F2} or even {∗F16}.

and this scheme should cover a great majority of the possible keys, getting all of them however would require more parsing, which I don’t really see the need at this point, but is possible in the future.

The down side is that I added a new instance variable to the Command classes, so if you do any subclassing of these classes you’ll need to recompile those subclasses with this framework Versioning and Compatibility (not a big deal as CocoaScriptMenu is meant to be embedded not shared).

Count of Scripts

I added a method to the menu generator to count the number of scripts, this can be used to determine whether or not scripts are currently installed.

Panther Compatibility

I did a little bit of hacking to give developers basic usage of the framework under 10.3.9, but I haven’t done any testing with other 10.3ness such as compiling under GCC 3 or actually compiling on 10.3. That said with these compatibility additions there’s a little more work needed when adding support for new filetypes or being more specific with filetypes, as I pretty much just fake the UTI stuff when it runs in Panther and thus more faking or a better solution is required, but if you don’t care about 10.3 then you can continue to not worry about it.

PS

MarsEdit rocks, I wrote this post in it and didn’t have to worry about the UTF8 characters, they were safely converted to html Entities.

The Sunday Project

So last sunday I started on something new, really it’s a feature for NicePlayer, but also a feature in a lot of other existing apps out there, and could be useful in a lot of cocoa programs that don’t have this feature yet, so I wrote my implementation as an embedable framework, and am releasing under the MPL/LGPL/GPL (my latest preferred OSI approved license for those who notice what license I release under).

So here’s a riddle, what do iTunes, DVD Player, Xcode, FlySketch, NetNewsWire, MarsEdit and BBEdit all have in common?

Give up?

They all have one of these (more or less):

Their own script menu.

Uses in NicePlayer

Having a script menu in NicePlayer has been something in the back of my mind for a while. There are some features requests, while really simple, are very specific to individual user needs and we can’t justify adding a feature. Sometimes there are features requests that just don’t fit into Robert’s or my idea of NicePlayer, and we barely have enough time to add the features we want to add, so in the next release users can add their own menu commands in this script menu.

One of the features introduced in 0.92 of NicePlayer was an option to remove the fixed aspect ratio. Maybe you want to distort the movie, maybe the aspect ratio is just slightly off, this feature works in those cases, and only adds one more menu to the window and is inline with adding basic window options in the Window menu that we did before. However this isn’t useful when someone has a lot of media that is consistently using non-square pixels. In the case of standard media formats, the proper behavior of NicePlayer should be to automatically adjust (this feature has been added for the DV codec when using the CoreVideo plugin in the next version of NicePlayer 0.93). However there are people out there for some reason, how have media that is encoded with non-square pixels for no standard reason, and there isn’t a way to detect the correct aspect ratio. It turns out writing an AppleScript with the current NicePlayer dictionary to set a Window to a different aspect ratio is pretty trivial, so this is one of the scripts we’ll likely include in the next release (since its one the scripts i’ve been using to test anyway).

I think the main benefit of having the script menu, will be nicer integration with other apps. Whether having it integrate with a cataloging app, Toast, or just organizing with the finder, there seem to be many potential uses in this respect.

CocoaScriptMenu.Framework in Your Own Program

The framework is called CocoaScriptMenu.Framework and available on my software page. It’s not my favorite name of the software I’ve written, but I think it’ll help in being google-able for those wanting it’s feature. I’m releasing it as version 1.0, and as I said before under the MPL/LGPL/GPL license. The basic way to use it is to:

1. Add the framework binary to your project
2. Add the framework to a copy phase that puts it into the Frameworks folder of your app bundle
3. Add this line [[CSMScriptMenu sharedMenuGenerator] updateScriptMenu]; somewhere right after the nib loads (while including <CocoaScriptMenu/CocoaScriptMenu.h> for that file of course)

And that will give you a typical script menu once you compile and run your app.

Features

I wrote typical, as not all script menus are the same. I tried to add what I felt were the best features of all the script menus, while being able to behave, depending on how you use it, like 80%25 of the script menus I’ve seen with out any extra customization. Some of the features are

• It looks for scripts in Application Support/AppName/Scripts in all domains.
• You can make submenus by nesting folders.
• You can add a menu separator by adding a file or folder with a dash as it’s name.
• You can order scripts, separators, and folders using a two digit prefix on the file name (two digit prefix not required).
• It runs AppleScripts, Automator Files (.workflow), Application Bundles, and Shell Scripts (sh/python/perl/whatever but remember you need executable permission for shell scripts).
• It automatically updates the menu, without relaunching the application, as you add items or folders nested inside the script folder, unless that folder didn’t exist at Application Launch.

Extending w/o Modifying

The singleton [CSMScriptMenu sharedMenuGenerator] has 4 optional delegate methods that allow you to keep the core functionality but make some slightly different script menus without having to modify the source (although modification is certainly an option. (warning most of this is untested as I use only the default implementation of each of these in NicePlayer)

-(NSMenuItem*)showScriptFolderMenuItem;

If your delegate implements this method, it needs to return a NSMenuItem that should be used instead of the Open Scripts Folder menu item. An example would be a menuitem with a submenu with an open command for each each script folder in the domains. The default behavior is a menuitem to open the first location returned by the delegate method -(NSArray*)scriptLocations; in the finder.

-(NSArray*)argumentsForShellScripts;
The default implementation returns nil. Implement this method in your delegate if you want to pass string arguments to any shell script. (is not used for AppleScripts, Application Bundles or Workflows)

-(id)scriptMenuItemOrItems;
This should return something that has a subMenu or menu getter for an NSMenu. This NSMenu is what the script menu items get added too. You may also return an array to add the script menu in multiple places in your app. The default implementation adds a Script Menu in-front of the Help menu and returns it.

-(NSArray*)scriptLocations;
The default implementation, returns the paths to Application Support/MainBundleName/Scripts for every domain that the path exists, with the User domain guaranteed first. Also creates the folder for the user domain if it doesn’t exist.

Extending by Modifying

So in version 1.0 the script running implementations are very basic. They are setup as a Class Cluster, with the CSMCommand class providing the public interface and several subclasses that implement script running for various types of scripts or executables.

Diagram of class hierarchy:

alloc on CSMCommand returns a singleton instance of CSMPlaceholderCommand. CSMPlaceholderCommand’s initWithScriptPath: works as parameterized factory method and depending on the path passed in returns the correct concrete implementation allocated and initialized.

So to extend the implementation of script execution for an existing file type, you would just modify one of the subclasses. To add a new filetype you would modify the initWithScriptPath: factory method and add a new subclass.

initWithScriptPath: uses Apple’s Uniform Type Identifiers to determine which concrete class to instantiate, so order does matter, make sure you add the more specific type checks in the beginning of the method and the more general towards the end.

There are a lot of ways that I can think of that the concrete script execution classes could be improved, however for NicePlayer these all work well, thus I figured for version 1.0 it was better to stick with the basic implementation and release it now, rather than try and over engineer. So I’ll wait and see if people need more or not, not to mention they have the option of contributing code.

Updated at Cocoa Script Menu Revised 1.01