I have another pull request pending, with nice improvements to the UI, but I haven’t had the time yet to fix some crashes introduced with the new code. Thanks in advance to bladnman for this work. Will be released relatively soon (hopefully)!

I must admit that I am very happy to see some pull requests coming from HBB community (in spite of my rather unreadable code )

You can download the new version from HBB page, or just check for updates from within the application.

Since June 2012, Apple is only accepting sandboxed applications in the store, and some of ShelfMenu’s features will not work in this environment. It’s only two features which will stop working, but I fear they are quite important for many users:

1. Pasting the content of a snippet in the front-most application (both as it is or converted to plain text);
2. Adding a snippet using content selected in the front-most application (whithout having to copy it to the clipboard first).

The core functionality of storage space for your clips, no matter what they are, is not compromised, but it is now mandatory to use the system clipboard and it is not possible to communicate directly with other applications (ShelfMenu, as pretty much all other clipboard managers around, used to simulate the ⌘-c and ⌘-v shortcuts to achieve this).

Options…

There are a couple of options ahead, unfortunately no ideal one:

• Update the current application and remove the problematic features;
• Try to request a temporary exception to Apple for the application to be allowed to maintain the features, using special entitlements; I don’t really like this option because it is meant to be temporary and Apple can decide to pull the trigger at any time;
• Release a separate applicaiton in the store, so the users who don’t care about iCloud won’t have to bear a constant reminder that one of their apps is out of date (personally I can’t stand that…), and it will always be possible to revert to the old version (until some new version of the OS breaks it).

I have not included here the possibility of trying my luck and submit a non-sandboxed app, or leaving the App Store, because as far as I know Apple does not allow non-sandboxed apps to access iCloud).

As of now I am inclined to release a separate version of the application, which will be free for a couple of weeks to allow all current users to update. If you have suggestions or feel this is the wrong approach, please do let me know in the comments or directly.

Growl expects its development framework, included in your application, to communicate with the Growl service using local networking. This is not allowed by default in a sandboxed application, unless you request specific entitlements (making it more challenging to get the app approved by Apple). So, if you don’t need to add networking to your application, it’s better to use an XPC service, as recommended in the Growl documentation. This is explained in the Growl documentation in a synthetic way, here is what you need to do in some more details.

As explained in the documentation, the best way to use an XPC service to communicate with Growl, is to take the XPC bundle provided in the Growl framework (which is already compiled), rename it, sign it with your developer certificate, and copy it into your app bundle. This XPC already includes the necessary entitlements.

If you download the latest Growl SDK (2.0 at the time of writing), you will need two things:

• XPC Client/com.company.application.GNTPClientService.xpc
• XPC Client/xpc-rename-move.rb

I have stored these items at the root of my application (one level above the Xcode project), where I keep all application assets (icons master files, graphics, and anything not needed by Xcode to build my project). This is the root level I commit to my SVC (git in case you wonder what I use).

In the screenshot, com.cemacsoft.ShelfMenu.GNTPClientService.xpc is created during the build process by a script (see below). You need not to worry about this.

Next you need to add a step to the compile process, in Xcode. Easier seen than explained, have a look at the following screenshot.

In step 4, the script comes from the Growl documentation, with a change to the location of the original XPC (com.company.application.GNTPClientService.xpc) to match my config; setting it to “..” as in the screenshot will work if you store the XPC one level above your project, as I did.

XPC_START=".."
XPC_SCRIPT="$SRCROOT/../../scripts/xpc-rename-move.rb"
ruby "$XPC_SCRIPT" "$XPC_START" "$BUILT_PRODUCTS_DIR/$WRAPPER_NAME" "$CODE_SIGN_IDENTITY"

Hope this saves you some time.

In short:

• New: After conversion, automatically quit the application, put the Mac to sleep, or shut it down
• New: Auto save and load the conversion queue
• New: Burn subtitles – Only works with DVD VobSub subtitles (from DVD, MP4 and MKV sources) and ASS/SSA subtitles (from MKV sources)
• Fixed: Check on duplicates (not possible to add the same file twice)

As always, if you find any issue please do let me know!

• Are you sure you are paid the right salary?
• What should you expect if you get promoted?
• What is the right salary for your job in a different country?
• What about a different industry?

If you are interested, please let me know by registering here (I will notify you by email when the service is launched).

Needless to mention, your email will only be used to notify you about this service. Apologies for not having a more appropriate legal disclaimer: I will not sell, mis-use, give away, trade, or [insert your favorite evil action here] your email address!

Thank you in advance!

I am interested!

Currently (from v2.15), HandBrakeBatch crashes on Snow Leopard, although I have not used anything not-compatible with this OS. Actually there seems to be a problem with the last version of Xcode: even if I compile an older version of HBB with the latest Xcode, the result crashes on OS X 10.6. At first I though it was a problem with the garbage collector, but even after moving to Automatic Reference Counting (ARC, a long due migration), the application still crashes. Most likely there is something in the HBB project which causes this incompatibility: I can’t believe that the new Xcode simply does not work with 10.6. Still, at the moment I do not have the time to investigate further. Also, I do not know how many users are still on 10.6, but looking at Apple upgrade stats it must not be that many. I will raise a bug with Apple, but in the meanwhile I will drop the support for 10.6. Please add a comment here if you think support for 10.6 is important, if there is enough interest I will spend more time investigating. Also, if any of you still has a real 10.6 development machine and can fix the issue, I will be more than happy to integrate the code.

If you are on Snow Leopard and for any reason can’t upgrade, you can download HBB v2.14, the last version which works correctly with 10.6.

I will release v2.16 of HBB shortly: this version is code-signed, and won’t raise security alerts on Mountain Lion. If you find any new crashes, this might be linked to the move to ARC from Garbage Collection, please let me know!

Image courtesy of Leopard-Pitcures.com

This is not a big change, but I wonder how many Mac users will do it and accept a less secure environment. I could do two things:

1. Code sign the application with my developer ID
2. Publish HBB on the Mac App Store (MAS)

If I just code-sign the app, and continue distributing it on this website, it will still not work using the default configuration (which allows only the applications downloaded from the App Store to be executed). The only way for it to work out-of-the-box for new Mac users would be to release it on the App Store.

I expect the changes to the code to be minimal, but the complexity of the deployment would undoubtedly increase. Also, I would probably have to reorganize the github repository to avoid publishing personal information. License-wise all should be good with the terms of GPL, given that the source code will remain available to everybody on github.

If you happen to read this, please do let me know what you think (in the comments below, on twitter, or using the contact page)!

I have updated HandBrakeBatch to v2.15, with the new HandBrake and a couple of fixes. Let me know if you find any issues!

If you want more information on the trip, please check our blog. We are also collecting funds to help preserving the desert, thanks in advance if you decide to donate!

I will carry my Nikon D7000 with a couple of lenses (the new Nikkor 18-300mm, and the Sigma 8-16mm), photos will appear on my Flickr photostream when we are back!

The solution is actually quite simple, follow the instructions below to fix your file. The custom preset file is stored in your home folder: Library/Application Support/HandBrake/UserPresets.plist.

In this file (a regular XML file), an incorrect preset looks like this (to find these presets just to a search for Audio1):

<dict>
	<key>Audio1Bitrate</key>
	<string>160</string>
	<key>Audio1Encoder</key>
	<string>AAC (faac)</string>
	<key>Audio1Mixdown</key>
	<string>Stereo</string>
	<key>Audio1Samplerate</key>
	<string>Auto</string>
	<key>Audio1Track</key>
	<integer>1</integer>
	<key>Audio1TrackDRCSlider</key>
	<real>1</real>
	<key>Audio1TrackDescription</key>
	<string>English (MPEG) (2.0 ch)</string>
	<key>ChapterMarkers</key>
	<integer>1</integer>

	…

</dict>

If you check the highlighted line, you see that the tag name has the figure “1″ in the middle (sometime you might find Audio2 or some other number: that should not be there. Also, all the section should be enclosed in tags. A correct preset looks like so:

<dict>
	<key>AudioList</key>
	<array>
		<dict>
			<key>AudioBitrate</key>
			<string>160</string>
			<key>AudioEncoder</key>
			<string>AAC (faac)</string>
			<key>AudioMixdown</key>
			<string>Stereo</string>
			<key>AudioSamplerate</key>
			<string>Auto</string>
			<key>AudioTrack</key>
			<integer>1</integer>
			<key>AudioTrackDRCSlider</key>
			<real>1</real>
			<key>AudioTrackDescription</key>
			<string>English (MPEG) (2.0 ch)</string>
		</dict>
	</array>
	<key>ChapterMarkers</key>
	<integer>1</integer>
	
	…

</dict>

Correcting the format is simple:

1. In your favorite text editor, search for Audio1;
2. Copy and paste lines 2, 3, and 4 from the sample above (highlighted);
3. Change all Audio1 to Audio in the block (cf. line 2 in the first sample with line 5 in the second);
4. Close the tags (copy and paste lines 19 and 20 in the second sample);
5. Repeat steps 1 to 4 for all presets containing Audio1.

After doing this and replacing your preset file with the corrected one, all should work fine.

If you have any trouble, just send me the file; I will fix it for you.