Bling

The more critical points about Safari 4 are the changes to its user interface though. Some of them, like ‘Top Sites’ are vacuous pieces of crap (enquire within to make me argue that it’s visual overload, much less effective than typing the first letter of the address and may waste your time by reminding you of the existence of websites you shouldn’t visit so often), but unlike many other types of crap Apple introduced in the past years, these can be easily and turned off and ignored without any problem.

Cover Flow and lost opportunities

The same uselessness statement could me made about Cover Flow bookmarks, I suppose, but to be honest I hardly ever use my bookmarks at all, so to me it seems mainly a waste of effort (and judging from what I heard others say, a rather unreliable one at that as Safari doesn’t seem to be good at actually fetching those images. Personally I also consider that feature a missed opportunity. Not only did Apple decide to litter our hard drives with hundreds of megabytes of web page screenshots (opening the folder of which may be a good way to visualise the privacy implications of web bugs - particularly Google), they also missed out on the opportunity to create a good solution for this that offers search and offline access as well.

To me the current implementation of Safari seems ridiculous. For each page you visit it stores a reference in your browsing history, it saves a file with the page’s text for Spotlight searches and it saves a screenshot of the page for its Cover Flow bookmarks. Yet, there seems to be no way to actually look at the screenshots Safari stores for you. They are not displayed by Quick Look when invoked on browsing history items and they are neither used to give you an impression of one of those history items when you are offline. To me, saving a web archive with the actual page in it (plus a screenshot, possibly, for performance) would seem much more logical. And it would make those situations when you discover a page you visited in a Spotlight search while you don’t have internet access much less frustrating.

Tabs

Another big debate among browser users was Apple’s re-location of the tab bar into the window’s title bar which existed in some beta versions of Safari 4. While I could appreciate the space savings of that, I thought it was more irritating than useful in the end. Simply because it made the window’s title bar look extremely busy and made things hard to click. In addition, that idea also ruined other subtle display methods in Safari: The unique lock icon location for encrypted sites and the full window width page title. Without the latter it’s quite hard to see the page’s name at a glance.

Surprisingly Apple listened to the loads of the feedback they must have received on this issue and the released version of the browser come with traditional style tabs. Those aren’t perfect either, but apparently they’re the best you can do when working with the ‘tab’ metaphor. In particular, they still suffer from horizontal overflow problems, as tabs to everywhere. And Apple’s insistence on only giving you an overflow chevron with no way to actually move between the tabs doesn’t make that any better. In fact, they added some fancy background colouring to the menu coming out of the overflow chevron, presumably to give you a better idea about the context you’re looking at. But I am not really sure it helps me figure out anything.

The following two screenshots are an example of that. I opened six tabs in a narrow Safari window which could only fit four of them in. In the beginning, with the fourth tab selected, it looked like this:

This makes sense to me, assuming that the light colour indicates the visible tabs and the dark colour indicates the hidden tabs. Then I paniced and switched to the last tab:

Now, with the same window width and tab arrangement, seeing three of both the light and the dark items suggests that my initial idea about the meaning of the colours was wrong. I guess I’ll just have to avoid looking at this. Tabs aren’t good for you anyway.

Progress

Another contentious issue was that of the progress indicator. Safari used to have a progress indicator which coloured in the address field according to the page’s progress at being loaded. While a progress indicator that gives quantitative information may be extremely problematic on a conceptual level for loading web pages - you have to display some progress immediately after the request is sent to let the user know something is happening but you have no clue at that stage how long it will take to complete everything - I think that Safari used to fake it reasonably well.

Nobody wants to read precise information from the progress indicator. Usually people just want to see that (a) their request is being processed and that (b) some progress is happening. That is, you want a bit of the progress bar to appear as soon as a click is made and then you wa old nt the progress bar to move at a reasonable speed as long as data are coming in. That way a stalled progress indicator may give you a hint that something isn’t working properly and that a reload may be in order. Particularly in low-bandwidth situations, which web sites and browsers don’t seem to be particularly good with, this is a useful feature.

Apple decided to remove the progress indicator in the betas, replacing it by a tiny spinning progress indicator at the very right hand side of the address bar in beta versions. This was very irritating as the visual impact of that tiny graphic was so low that you always had to consciously look at that tiny bit of screen space to see whether or not the progress indicator appeared. Definitely a change for worse, big enough to penetrate Apple’s bug reporters (perhaps people at Apple are even using Safari themselves…).

Their ‘solution’ to the problem was to not just display the progress indicator but provide an easily visible dark background around it which you’ll immediately notice without having to make an effort to look for it. That certainly solves the biggest problem with the new progress indicator seen in the betas. The other problem, however, of seeing whether there is actual progress in the file transfers or whether they have stalled, remains.

I’d certainly like to read the reasoning that went into putting engineering resources into making the progress indicator worse than it was before. Seems illogical to me, particularly as Apple missed out on what looks like the only potential advantage of an indeterminate progress indicator to me: The ability to let it spin when further resources are loaded after the page finished loading, like many of those fancy web 2 pages like to do.

Reload button

Another problem with Safari 4 is that Apple moved the Reload button to the right hand side of the address bar. Web browsers were born with the reload button at the left hand side of the window. More importantly, they were born with the Reload button close to the Back and Forward buttons, which not only makes sense but also keeps distances short when navigating with the mouse. Internet Explorer 7 broke that tradition and its wrongly placed Reload buttons remains the second most annoying thing about it (the first item in the list, naturally, being the rendering mistakes which make me need the reload button and non-trivially test in that browser in the first place).

Safari is keen to follow in Internet Explorer 7’s steps in this respect and moves its combined Reload and Stop button far away from the other navigation buttons. That irriates the hell out of me - and apparently a few other people as well. As there seems to be no point in holding one’s breath (and Apple’s software regime on the Mac hasn’t reached iPhone level fascism yet), a little bit of clicking yielded this:

It’s not as good as the Safari 3 original as it doesn’t reflect the state change from Stop to Reload but it may be a reasonable approximation until somebody discovers a better fix. You can grab a copy of the files here and use them at your own risk.

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

• Marks all addresses as ‘Home’ or ‘Work’ in the exported file, so the iPod doesn’t ignore them because they’re marked ‘Other’
• Uses the pronunciation form of names whenever available. This isn’t a good solution. A good one should only do this if the real name can’t be displayed on the iPod (because it’s in Thai or Tamil, say) and then it should also check on the glyphs needed to display the pronunciation form (I suppose someone speaking Thai may want to note the pronunciation of a German name in their own writing). So, yup, this solution isn’t very good. It does work for my needs, though, and it’s Apple’s job to do this properly.
• Adds people’s birth dates to the comment section for a contact.
• Adds people’s first AIM address to the comment section for a contact. Obviously people using other services would prefer to use other or additional services here.
• Includes only the first two e-mail addresses for a contact. – Why that? I usually keep all old e-mail addresses for people, so Mail can still display the correct photo even with messages I received years ago. I am also still hoping that one day Mail will offer smart folders for each person in your address book – and you’d need all their past addresses for that. Usually I’ll make sure I have the newest addresses at the top of the list, so having the first two will give me the relevant ones without unnecessarily cluttering the iPod’s screen.

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 put together the files I changed for download:

Mac OS X.3-X.5:

You need to add the German localisation, replace the icon and patch the JavaScript.

Mac OS X.6:

You only need to add the German files and replace the icon.

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.

Go to the relevant folder

cd /System/Library/Frameworks/Carbon.framework/Frameworks/HIToolbox.framework/Resources/

Make a backup copy of the Extras.rsrc file, just to be paranoid

cp Extras.rsrc ~/Desktop/Extras.rsrc

Move the Extras.rsrc file

sudo mv Extras.rsrc ExtrasBackup.rsrc

Download the patch resource file

sudo curl -o Extras.rsrc http://earthlingsoft.net/ssp/blog/other/ExtrasPatch.rsrc

Patch a little

sudo /Developer/Tools/ResMerger -append -srcIs DF -dstIs DF ExtrasBackup.rsrc -o Extras.rsrc

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/

mv iTunes.rsrc iTunesBackup.rsrc
curl http://earthlingsoft.net/ssp/blog/other/iTunesPatch.rsrc > iTunes.rsrc

/Developer/Tools/ResMerger -append -srcIs DF -dstIs DF iTunesBackup.rsrc -o iTunes.rsrc

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.