Only yesterday I did my little bit of complaining about shortcomings of the iPod. And today – well, yesterday as well technically as I prefer posting here shortly after midnight, Franz Ferdinand’s new album was released. First impressions suggest that it’s highly enjoyable. But more importantly, its title is You Could Have It So Much Better.
Going by this positive motto, I looked at yesterday’s problems again and decided that I can have it so much better and I’ll just improve the situation for me and my iPod. While all the music management on the iPod is done by iTunes which determines everything you see there all the way to the sorting order, the situation is quite different for contacts on the iPod.
All iTunes (and formerly iSync) does there is to generate a ‘VCF’ file from the data it finds in your address book and copy it to the iPod’s Contacts folder (at least that’s what happens on my iPod… I don’t know whether the current photo-savvy models do some more trickery to include the photos from your address book). And in fact, possibly to make cross-platform compatibility easier, you any drop any ‘VCF’ file – which is nothing but a bunch of concatenated VCARD records – into the iPod’s contacts folder and the iPod will attempt to display the contact information therein.
Thus all I needed to do to solve some of the problems I described yesterday was to generate my own ‘VCF’ file with all the extra data I want and without the problem that certain addresses aren’t displayed. To do that I decided to write a little AppleScript, that goes through my address book and
It works pretty well for me. As we’re dealing with AppleScript here it means writing this small file will take quite some time. And it means we’re enjoying AppleScript’s typical quirks – somehow I needed to make a call to UnicodeChecker to ensure the file is properly encoded as UTF-16, thus using for good what I consider a quirk in AppleScript’s handling of encodings. But in total it does work and I can now enjoy a Contacts list with names, all addresses and birth dates on my iPod.
Grab yourself a copy of the script. And make sure to look at its readme and to adjust the file location at the very top of the script to whatever is appropriate for your iPod before running the script.
Update: The first version of the script was still flawed in that it didn’t transfer all addresses in a way that the iPod would display them. In the current revision, addresses are now inserted into the contact’s comments and everything seems to be present.
]]>Well, I’m just a voice in your earpiece
Telling you no, it’s not all right.
You know, you could have it so much better.
You could have it so much better.
If you tried…Franz Ferdinand – You Could Have It So Much Better
You will not need this patch for iTunes 7.3 and higher as Apple finally restored the proper artist sorting there. It was necessary for iTunes 5, 6, and 7.0 and for iTunes 7.1 and 7.2 it was crucial to apply it before first launching the application. —— The patch also seems that it works in a similar way on iTunes for Windows. All you need to do is find a folder iTunes.Resources in the folder of your iTunes application there to locate the same file I describe the change for below.
For other languages than English, iTunes 5’s localisation replaces the ‘The’ by the appropriate article from the respective language. This sorts local bands just fine. But as everyone is listening to English bands as well, it will leave English bands sorted badly and makes them hard to find – a situation that has been better in the later versions of iTunes 4. Here I’m trying to give a description on how to fix the problem yourself. While it’s not particularly nice, it isn’t a terribly hard thing to do. To be able to do this you’ll need a text editor and use an account that lets you write to the iTunes application. You may want to make a backup copy of the complete iTunes application in case things go wrong.
The first steps are to quit iTunes and open iTunes’ package in the Finder. To do that control-click the application and select the third item in the menu that appears. It should read something along the lines of ‘Show Package Contents’ in your langauge. This will open a new window showing a folder ‘Contents’. Open that folder and also the folder ‘Resources’ contained in it.
Within the Resources folder there are many different files and folders. Folder whose name end in ‘lproj’ are relevant for the localisation. iTunes will load data from the folder that corresponds to your preferred language. For many languages the proper name is used but for others, like Swedish, an abbreviation like ‘sv’ is used. Go and find the folder that is appropriate for your language and open it. Within the folder is the file ‘Localizable.strings’. This is the file containing the relevant strings and we are going to change it. So if you haven’t made a backup copy of iTunes a few paragraphs ago be sure to at least make one of this file before you change it.
Now open that file in a text editor. TextEdit in its standard setup will work for this but any other editor that can handle Unicode files will do as well. If the file doesn’t look right, and accented or other ‘special’ characters like the © sign in line 17 look garbled something went wrong and you should try to explicitly open the file as a UTF-16 encoded one.
Once the file is open, find the relevant strings. They are around line 345 and labelled by ‘146.xxx’, where xxx is a number. Note that the x-es start with 001 and increase in numbering. The German version of those strings looks like this:
/* ===== Reordered Artist Strings ===== */
"146.001" = "Die ";
"146.002" = "%1, Die";
"146.003" = "die ";
"146.004" = "%1, die";
"146.005" = "DIE ";
"146.006" = "%1, DIE";
It Tells iTunes that when it finds a band whose name starts with ‘Die ’ to sort it as if the ‘Die’ were appended at the end, in the form “%1, Die”, where %1 is supposed to denote the remainder of the band’s name. Note two things here. First, capitalisation is important, i.e. there have to be separate entries for instances of the same word with potentially different capitalisation. And second, in the lines with odd numbers there is a space at the end of the string. You shouldn’t forget that as it ensures that, e.g. ‘Thelonious Monk’ won’t be sorted as if his name were ‘lonious Monk, The’.
All that remains to do now is to add the additional re-sorting instructions you may want. Just add two new lines containing the strings to match and replace and make sure their numbers increase appropriately. Make sure that you’re not missing any of the quotation marks or semicolons! The most obvious addition would be something like this:
"146.007" = "The ";
"146.008" = "%1, The";
"146.009" = "THE ";
"146.010" = "%1, THE";
"146.011" = "the ";
"146.012" = "%1, the";
That’ll sort the English names. And once you’re at it you may think about adding strings for other languages as well. Perhaps add ‘Les’ as well for French, or add ‘Der’ and ‘Das’ as well for German. I am not sure whether the latter ones are appropriate, though, but as you’re changing stuff yourself now, you can adjust things to match your taste…
As for ‘matching your taste’ you could also abuse this to re-sort things more boldly. I.e. if you’re a big fan of Mando Diao and think it’d be nice to have them listed at the top of your iTunes and iPod artist lists rather than having to find them in the middle of hundreds of bands you could try adding something like
"146.013" = "Mando Diao";
"146.014" = "00001";
which should make sure the band is listed very far at the top. I’m not really recommending to do this as it makes the list less logical, but it could be useful to some.
After saving the file with the changes made, you should be able to start iTunes again and it should sort band names in the way you intended.
Finally let me note that you’re doing all this at your own risk and any future updates to iTunes, in case they don’t fix the problem anyway, may reset your changes so you’ll have to apply them again. If you want changes for several languages, you’ll have to update the ‘Localizable.strings’ file for each of them. Please don’t complain about those inconveniences, at least not to me… but if you’ve made it up to here you’re probably looking for that kind of trouble.
If you really enjoyed doing this, you may also be interested in looking at my old iTunes patch which makes the little arrows next to song, band and album names which take you to the relevant section of iTMS or your music library more subtle.
]]>
That’s not only annoying for the user but also quite stupid. The system knows where I am, which language I prefer and whether I’m using metric units. From these informations quite a good guess regarding the preferred temperature scale could be made: E.g. Having German as the preferred system language, not being located in the U.S. (or Jamaica) and preferring metric units should allow a pretty safe prediction in favour of degrees Celsius.
All this is quite annoying and really puts me off the weather widget which I otherwise like for its shiny prettiness and its forecasts. So I decided to have a look at it. After all the Dashboard is mostly driven by JavaScript which means you can read the code and change it. And my hope was that even with my JavaScript experience being rather low-key (I’d say a single digit number of lines so far), I should be able to figure out what goes wrong, why it goes wrong and how to fix it.
Looking at the relevant scripts made me realise that closed source software has a definite advantage. While you can’t fix things yourself and can’t learn from what other people did, it also keeps you from thinking that the people who wrote the software should be embarrassed. It seems that the Weather widget gets it wrong in a number of places. Ranging from a lack of resources or interest in localisation to really, erm, odd ways of programming and weaknesses in spelling.
My first impression while looking at the code was that the widget isn’t as bad as it seems as it in fact has hooks for localised strings all over the place in its JavaScript code. It even contains a string UseCelcius which can be set to zero or one and determines the widget’s default temperature scale. It also showcases a strange form of humour or ignorance about the spelling of Mr Celsius’ name – which is found throughout the JavaScript code. I’d like to make the sad sidenote at this place that the Google fight Celsius vs. Celcius ended with the ridiculous score of 8.4million:1.3 million. Eeek.
Thus a quick solution for the problem was to just localise the widget myself. With about twenty strings this wasn’t too hard to do and has the advantage of giving me German day names as well for the forecast:
And while I was at it, I also updated the widget’s icon to display a temperature that’s reasonable in Celsius and localised the name as well. Unfortunately you can’t have localised icons so the original icon had to be overwritten for this.
But then, just for the heck of it, I thought I should try whether I could now use Fahrenheit temperatures with my new version of the widget. And the result was that I couldn’t in the German localisation. Hence another look at the JavaScript code was needed and it exhibited two things. First, that the choice of Fahrenheit or Celsius is stored on a per-widget basis. Doing this probably avoids the (IMO small) problem of having to update all widgets which are already running to reflect the change. But it is also the reason why we had to re-set the temperature scale to Celsius for each new widget we opened before. Personally I think a global preference would be better here. And second, the preference for the temperature scale to be used is saved like this:
widget.setPreferenceForKey(isCelcius ? true : null, createkey("celcius"));
I.e. if the scale is Celsius we save ‘Yes’ and if it isn’t we save nothing at all. In particular this is the reason why I couldn’t save the Fahrenheit scale in my German localisation. Luckily a problem that could be fixed with a few keystrokes.
I put together the files I changed for download here. The archive contains a readme, the localisation files for German, the modified icon and a patch for the main JavaScript file. Enjoy at your own risk.
After installing X.4, I started to feel how much I got used to that patch and somehow I couldn’t find it again, which was a pain. With the new ‘unified’ window type in X.4 the whole window situation has become even more tricky and people are trying all sorts of things such as changing window types on application launch to replace the metal theme by either the unified or the normal window type – depending on whether they have a toolbar or not. Pierre Chatel’s new Unifier hack works along those lines and can give pleasant results in some applications.
Seeing that and its shortcomings increased my taste for getting rid of the metal windows once more, so I had a look around in the System folder. The relevant UI graphics seem to come from the HIToolbox framework which is part of the Carbon framework. Interestingly they are stored in resource files rather than those supposedly more modern techniques of having a separate image file for each graphic. (I say supposedly there because resource files seem far superior to me. The ‘modern’ technique just looks like a convenience for developers at the cost of making things slow to copy and – I assume – also slower to load).
Unfortunately Apple have dropped any support for editing resource files with OS X. Which means playing with them is as royal a pain as you can have. Despite there being attempts at having native resource editors on OSX (ResFork, ResTool), neither of them is any better than our ancient friend ResEdit – which is the only application I use in Classic these days.
Due to ResEdit’s age, it can’t deal with the data fork resource files which became en vogue with OS X. So you’ll have to convert the files OS X uses before editing them and re-convert them afterwards. (This can be done quite easily in the Terminal doing something like
touch newFile to create a new file and
cp DFResFile newFile/rsrc to copy a data fork resource file into its resource fork. It’s complicated enough to annoy you when you have to do it the fifth time in a row. And too easy to be worth making an Automator action for.
Once ResEdit is running, you’ll want to take a look at the PXN# resources where all the graphics are stored. ResEdit can’t edit those (and neither can the newer editors as far as I can tell) and the format looks like a bit of a pain. I learned that there’s a very simple Classic application with the nice name Pixie that’ll convert the resources to strangely arranged images and back.
For my purposes using an all black image (that should probably have a width divisible by 4) with Pixie was good enough so this wasn’t as painful as it sounds. This doesn’t make the window look black as there still seem to be some masks and gradients at work. Replacing the most offending resource (ID 4460) with my newly created one, gave me what pretty much looks like the same effect that the old patch I had downloaded gave. Plainly grey windows with a light gradient.
I assume this could do with slightly nicer graphics and a better understanding of what’s going on. But as what comes out was good enough for me, I decided that I won’t spend more time on fixing the bug that are metal windows – although I’d be interested in seeing other improvements.
If you want those changes as well, I’ll offer them as a handy download akin to the patch for iTunes last year. It should go without saying that you’re totally on your own with the instructions that follow and that playing around with them can seriously ruin your system. Perhaps even following my instructions precisely will, I don’t claim that I know what I’m doing. So be careful. You’ll need a Terminal window and an administrator account for this to work…
Warning: this will only work on PowerPC based Macs. For Intel based Macs a different file needs to be patched with a different file. To do that replace every occurrence of ‘Extras’ in the commands below with ‘Extras2’. Read more about the Intel situation.
And that’s essentially it. You may want to clean up after yourself and get that backup file out of the system folder. Applications you launch afterwards should have metal-less metal windows.
]]>Beware – to follow those steps you will need to have Apple's developer tools installed and you'll be exposed to using the Terminal application. Read: This won't be a good experience.
First quit iTunes and then start the Terminal where you change into iTunes' intestines
cd /Applications/iTunes.app/Contents/Resources/Then move the original resource file out of the way and download the file I prepared containing the lighter shade arrows and the non-metal background.
mv iTunes.rsrc iTunesBackup.rsrc curl http://earthlingsoft.net/ssp/blog/other/iTunesPatch.rsrc > iTunes.rsrcNow do the patching:
/Developer/Tools/ResMerger -append -srcIs DF -dstIs DF iTunesBackup.rsrc -o iTunes.rsrcYou'll see two warning messages while this is running. Seeing them suggests that things worked as they should.
And that's it already. Now keep your fingers crossed and hope that iTunes launches regularly when you try to start it. Keep in mind that it's your own problem if you wreck your copy of iTunes this way.
]]>