PowerTunes 1.1.1, now compatible with iTunes 9
Posted on September 18, 2009 by Brian Webster
Filed Under News, PowerTunes, Updates, iTunes | Comments Off
PowerTunes 1.1.1 was released today, which now provides full compatibility with iTunes 9, along with a couple other miscellaneous bug fixes. The main points of improvement in working with iTunes 9 are:
- The fix dead tracks, playlist/track copying, and merge functions now work with iTunes 9
- PowerTunes now understands the new layout of the iTunes media folder (formerly known as the iTunes music folder). The main place this affects things is to improve locating multiple tracks when using the Fix Dead Tracks command.
- PowerTunes now also recognizes the new default folder name of “iTunes Media” where applicable
So, if you have any older version of PowerTunes and have iTunes 9, I highly recommend using the “Check For Updates” menu item to update to the latest version.
PowerTunes compatibility with iTunes 9
Posted on September 9, 2009 by Brian Webster
Filed Under News, PowerTunes, iTunes | Comments Off
Apple released a new version of iTunes today, version 9.0, which adds several major new features to iTunes. Some of the changes in the new version will cause several features of PowerTunes not to work properly with iTunes 9.0 installed. The affected features are:
- Copying tracks and playlists between libraries: you will not even be allowed to drag and drop tracks or playlists on a library to attempt to copy them
- Merging libraries: an error message will be displayed almost immediately upon starting a merge
- Fixing dead tracks: no items will be displayed in the dead tracks list, even if dead tracks are present in the library
An update for PowerTunes will be published soon that will address the issues listed above. Preliminary testing indicates that all other features of PowerTunes work normally with iTunes 9, so you can continue to switch between your libraries, create new libraries, find orphaned tracks, and so forth using the current version of PowerTunes (1.1). If you do experience any problems with PowerTunes 1.1 and iTunes 9.0, please use the “Contact Support” menu item in the Help menu, or e-mail support@fatcatsoftware.com
You can check the “Automatically check for updates” checkbox in the PowerTunes preferences window to be notified when the update is made available, and/or keep an eye on this blog for further postings.
Preprocessing InfoPlist.strings files in Xcode
Posted on September 3, 2009 by Brian Webster
Filed Under Cocoa, Development | Comments Off
Xcode provides a handy feature called “Info.plist preprocessing” that allows you to specify placeholder values in your plist that are then automatically replaced by Xcode with values you specify in your build settings. The most common use of this is to place the current build’s version number in one or more appropriate places in the Info.plist file. This lets you change these kinds of values in one place, rather than having to track down every usage in the Info.plist and replacing them manually.
In addition to the Info.plist file itself, you can also have one or more localized InfoPlist.strings files included in your application bundle. There are some strings in the Info.plist (e.g. CFBundleGetInfoString) which are displayed directly to the user, and thus need to be localized. Putting these keys in InfoPlist.strings instead of directly into Info.plist allows you to have localized versions of these strings.
However, Xcode’s Info.plist preprocessing only covers the actual Info.plist file, and not the various InfoPlist.strings files you may have included in your application bundle. This means that if you have a version number or some such that you want to keep up to date in one of these strings, you have to resort to replacing them manually, which is both error prone and a pain in the ass. I was able to solve this problem for my own project, and thought I’d share the details here in case it came in useful to anyone (and in case I forgot how to set it up in a future project and needed some help from my past self 
)
To get things working, I enlisted the help of a neat little tool called wincent-strings-util, courtesy of Wincent Colaiuta. It performs several tasks, but one of them is specifically geared towards doing this kind of substitution in a .strings file. In my setup, I simply include a copy of the tool in my project repository, so no installation is required and the build “just works” wherever you check out the project.
To get the substitution to be done when doing a build in Xcode, I defined a new build rule in my target to use a custom script to handle Info.plist files. To do this:
- Choose “Edit Active Target” from the Project menu, click on the “Rules” tab, then click the “+” button down at the bottom of the window to add a new build rule.
- From the “Process:” pop-up menu, select “Source files with names matching:” and then “*/InfoPlist.strings” in the field next to the pop-up. When I first tried this, I entered simply “InfoPlist.strings”, but that didn’t work because the match is against the whole path of the file, and not just the filename, so the * is necessary to match any file named “InfoPlist.strings”.
- From the “using:” pop-up menu, select “Custom script:”, then enter the following script text:
cd "${BUILT_PRODUCTS_DIR}" && ${SRCROOT}/DevFiles/wincent-strings-util --info "${INFOPLIST_PATH}" --strings ${INPUT_FILE_PATH} --output /tmp/${INPUT_FILE_NAME} --encode UTF-16LE - Where it says “With output files”, click the “+” button and enter “/tmp/${INPUT_FILE_NAME}” for the output filename
You can click here for a screenshot showing the completed build rule setup. A couple things to note:
- My major source of problems in getting this working was trying to deal with spaces in the various path names (my product name is “PlistEdit Pro”), and splicing together multiple build setting environment variables was not working well. That’s the main reason the script does a “cd” into the build directory, then works from there. That’s also the reason that I spit the output file into /tmp rather than somewhere inside the Xcode build folder, since trying to get it working there was more headache than it was worth.
- As I said, I keep a copy of wincent-strings-util inside my source repository. In my case, in lives in a subfolder named “DevFiles”. You should of course change this path in the script to the location where you choose to store tho wincent-strings-util executable
- The “With output files” section tells Xcode where to look for the result of the custom script. Xcode will then copy that result file into the appropriate location inside your built application bundle. If you do change where the –output argument of wincent-strings-util goes, make sure to change the output file to match.
Finally, to actually do a substitution, simply put a key from your Info.plist into the InfoPlist.strings file, enclosed in chevron brackets («»). For example, I have the following entry in my InfoPlist.strings file:
“CFBundleGetInfoString” = “PlistEdit Pro version «CFBundleShortVersionString», Copyright 2004-2009 Fat Cat Software.”;
This will replace the «CFBundleShortVersionString» placeholder with the value stored under CFBundleShortVersionString in the main Info.plist file. I have my Info.plist preprocessing already set up to include the version number of the build for CFBundleShortVersionString, so this will propagate that to the InfoPlist.strings files, and my version number will display correctly in the Get Info window for all localizations.
RSS 2.0