I have been amazed by UTIs since first seeing them as they look like a reasonable way to unify the legacy (Mac File and Creator type), internet (MIME-Type) and stupid (file name extension) ways of identifying file types. UTIs maintain backwards compatibility while opening the way for future development [I totally want to see integration with Unix’ file command. But I fear we’ll have to wait for the day when technology has advanced enough to provide all the power of a PDP-11 in a pocket size package before we can expect to see that.] and a wider use [e.g. non-file data-types, like the clipboard]. Thus I consider them and their proliferation across the Mac APIs a good thing.

The basic idea for UTIs is quite simple: software can specify them in ‘reverse domain name notation’ (e.g.: public.text, public.xml, com.apple.quicktime-movie), it can specify which other methods of file type identification a UTI is equivalent to and it can assign other UTIs which the new UTI conforms to. Those conformances give a system of inherited types and you’ll find that public.xml → public.text → public.data. Graphing those relations is the task this text is about.

The first step towards achieving that is collecting the data making up that graph. Apple’s documentation only lists a few examples and the biggest bunch of ‘standard’ UTIs is listed in the ‘CoreTypes’ bundle in MacOS X’s system folder.

In principle Launch Services should know about all UTIs on the machine [considering the output of lsregister -dump] but as we are in hacking mode here and I’m not familiar with Launch Services, I went for the dumb option: collect all Info.plist files on the system in which the UTIs are stored. Spotlight fails me for that, locate gives quick and incomplete results (lacking non public readable folders) and this bit of command line junk runs slowly but yields what seems to be a complete list that I stored in a file:

sudo find -s / | grep Info.plist | sed 's/\(.*\)/"\1"/g' | xargs -L 5 grep --files-with-matches TypeDeclarations

Said file is then used by a PyObjC script which reads the property lists, collects the UTIs and the relations between them and creates a GraphViz file. A colleague recently introduced me to GraphViz which converts simple text input algorithmically into graphs. Those aren’t perfectly pretty and can be a bit hard to control, but with more than a dozen items, it seems to be a reasonable way of avoiding the tedium of manual graph layout.

I am then running the created GraphViz file through the twopi tool using

twopi -Nfontname=Helvetica -Tpdf /tmp/UTIGraph.gv > /tmp/UTIs.pdf

which creates a reasonable layout.

Of course I had to start tweaking things a little, soon after seeing the graph the first time. As loads of UTIs conform to public.data or public.bundle or some sort of zip archive, that was making the graph quite messy. Hence I decided to clean things up a bit by suppressing those conformances and expressing them by the node’s shape or colour. I also removed all the single nodes and placed them separatedly. (An attempt to group things better seems to fail with the twopi tool).

As I was using PyObjC anyway, I figured I could just use NSWorkspace to grab the relevant icons. This resulted in a very heavy PDF file which creates all sort of scrolling FAIL in X.5’s Preview along with a less than impressive speed. (In fact, one version of the file even stumped Illustrator when opening it in there.) So slightly more control was needed, to scale down all icons to a 128×128 size and to avoid using the generic document icon for all files without custom icons.

While I’m at this: can anybody tell me a good way to compare NSImages? The only way I could find was using iEqualToData: on a TIFFRepresentation. But I couldn’t find a way to create a working hash of the image data. [In addition to that, the image nerds among you may enjoy comparing the PNG compression ratios achieved by Cocoa in different versions of OS X. Personally, I can only recommend using GraphicConverter for the task: with its best and slowest setting it routinely saves ¼ to ⅓ for the images I save in PNG format.]

A few more steps of manual intervention to single out all UTIs which do not conform to any ‘interesting’ UTIs - thus uncluttering the graph - gave this:

The PyObjC script isn’t exactly pretty and to work it requires (a) the folder /tmp/UTI-Icons, (b) the installed GraphViz Software and (c) a file named Info-Plists.text in the same folder as the script, each line of which is a path to an Info.plist file. As a consequence I wouldn’t recommend anybody to even look at it. But if you must, you’ll find it here. Furthermore, the full size PDF is available from my public DropBox folder and you can see a large, roughly annotated, bitmap at Flickr. Unfortunately I couldn’t find an easy way to turn the large image into a Google map. [And I’m somewhat annoyed that software and computers aren’t better at dealing with such files.]

Beneath the hood

It seems that Safari 4 will bring quite a few improvements under the hood. Faster JavaScript, fancy new CSS effects, local storage and improved scores on random standards tests. I suppose that those are good things. Things that are worth implementing and refining early so - for a change - browsers are ready once the web designers get their act together.

Those changes are as unnoticeable as they are amazing. None of the sites I am using seems to behave differently today in Safari 4b than it behaved last week in Safari 3. Which probably is a good thing or simply proves that I just don’t surf enough.

And who’s going to bitch about such technicalities anyway?

Zooming

Web browsers could zoom into pages from day one. Pressing ⌘-+ simply increased the base font size, thus making text larger and potentially more legible. This has always been problematic to a certain extent as web designs which use images have a tendency to break down after a step or two of this: The graphics are included as fixed size bitmaps and (due to both bad / lazy designers and the limitations of HTML / CSS) they don’t scale along with the text. Hence, the font sizes may end up being blown out of proportion to the size of the decorative banner ads or so…

At some stage the strategy of re-interpreting web page zooming as a zoom into the page - increasing the size of everything on the page proportionally - was introduced (many years ago by Opera, I think). This strategy neatly avoids the problem of layouts breaking and Safari 4b both implements it and uses it by default. The setting for it are easily accessible in the View Menu.

Personally I prefer ‘old-school’ HTML resizing. Both because I’m an old fart and because I prefer narrow browser windows and despise web ‘designers’ who think they should have a say about the size and shape of my browser window. Having the new resizing option feels like it gives more power to them as increasing a page’s text size will likely blow said page out of the window size I want to use.

Visual Bookmarks: Cover Flow

Safari 4b1 offers two ways of visualising bookmarks. The first is having a Cover Flow view mode when browsing bookmarks. I think this is a ‘nice’ idea because it’s sometimes easier to recognise pages visually than remembering their name. On the other hand: When did you last browse your bookmarks?

I realised I never browse my bookmarks. The links I need frequently are in my bookmarks bar and I know where they are because I use them frequently. The other links are in my bookmarks for (a) sentimental value, (b) because I forgot to delete them or (c) autocompletion.

Autocompletion is important. Even more so if you have a device with a crappy keyboard like an iPod touch or an iPhone. Once you have a link in your bookmarks, it’s much more accessible on these devices. Hence bookmarks need to be there, but they hardly ever need to be seen.

In fact I used these graphical bookmarks as an opportunity to quickly go through all of them. The screenshots usually let you see easily when a bookmark has stopped working and points to an error page. There were plenty of such broken bookmarks in my collection - particularly on music and computer related sites. Presumably because they are run by the most technically illiterate people. Even more embarrassingly, most of the music sites still exist, just the links broke because the moron who ‘designed’ the Flash-atrocity site in 2004 thought entering the domain name should immediately redirect you to the ‘/index.php’ path while the douchebag who re-‘designed’ the even worse Flash+Web-2-atrocity site in 2007 considered a redirect to ‘/index.asp’ more appropriate. Both being morons of course meant that nobody thought about creating redirects beforehand and nobody checks the 404 logs either. Tada, job well done and ‘designer’ paid with the money from my CDs! And as Safari - optimistically - doesn’t show you the URL you are about to bookmar thus not giving you the opportunity to scrutinise and fix it easily, you end up having that worthless crap in your bookmarks.

Visual Bookmarks: Top Sites

The other 3D novelty in Safari 4b1 is the Top Sites view. It displays a gratuitously 3D view of thumbnails of the pages Safari considers your favourite ones:

It seems that Apple still love the feature at this stage as they added a non-removable button for accessing it (which for some incomprehensible reason works differently from the Bookmarks button right next to it) to Safari’s Bookmarks Bar and make Safari open any new tab or window displaying it despite you having told Safari that you always want it to open new tabs and windows with a ‘blank’ page years ago. Let’s say I was not impressed. And even less so was my boss when I wanted to ‘quickly look something up on the web’ and the screen seen above appeared…

Ah well, I am not sure I’ll like this feature. It needs to download loads of stuff in the background through a helper process, it seems impossible to add specific pages to it at the moment and it furthermore includes the horrifying trend of being so poorly designed that it needs an ‘Edit’ button (this may be excusable on a simplistic device like the iPod touch or iPhone on which editing will be the exception and interaction is coarse but I find this just embarrassing in everyday editing applications like Safari or the Address Book, this being the 21st century and all). So, no, I’m not convinced. But if I could remove the button for it from my Bookmarks Bar, it would just be some useless code in my Safari binary rather than a constant annoyance.

Comment: Archiving

Let me take a moment to comment on the features above. Obviously the developments for Safari 4 established quite a bit of infrastructure for saving and updating thumbnail graphics of the pages you view. To me that seems to be solving the wrong problem and at best an intermediate performance-enhancing step one may need to do when doing The Right Thing™.

At the moment Safari saves three kinds of web page related items: your bookmarks, a log of the pages you recently visited and thumbnail images. Both the bookmarks and the log of the pages you visited are indexed by Spotlight and thus somewhat accessible. Unfortunately neither of these is Quick Look enabled, meaning that you will know something in the page you visited yesterday contains the text you are interested in, but you cannot immediately access it ‘see’ the page in question.

It seems that the ‘right’ thing would be storing proper webarchives of the visited pages. That may be a bit more effort than the current approach but it would have the advantage that even web history items would not only be findable via Spotlight - they’d also be viewable right away, even without an internet connection.

I’ve been in that situation a number of times and I can tell you the following: it’s nice that you can search the content of your web browsing history using Spotlight. But finding something in there while you don’t have an internet connection is incredibly frustrating - much more so than not finding it at all. Of course only unworthy sub-humans will come into situations without internet access in Apple’s mindset, but I take the liberty of thinking it’s something worth keeping in mind - even more so as it enables you to see the page the way it looked yesterday when you thought it was interesting, an aspect that can play a role when having in mind the large number of blog-style sites with frequently changing content we have today.

Address Field

Safari 4b1 comes with a redesigned address field. It appears they’re generously stealing from the improvements Firefox users have been enjoying for a while there. And it’s a welcome change. Safari’s URL autocompletion becomes much more competent by this, offering a somewhat reasonably ordered selection of completions from your bookmarks and history items. I welcome these improvements.

This isn’t quite perfect yet. One thing they still haven’t fixed is Safari’s unwillingness to invoke autocompletion after hitting the backspace key: Say you want to go to Google and accidentally type ‘gog’, then you realise you missed an ‘o’ and hit the backspace key. In all likelyhood ‘go’ would autocomplete to ‘google.com’ already, so Safari should try that. But it doesn’t. Seems like a trivial oversight to me and I couldn’t yet figure out why Safari doesn’t do it.

Another, even more significant omission is that the address field only completes addresses. I totally expect it to complete bookmark names as well.

But that isn’t all there is to Safari’s new address field. It comes with the Add Bookmark +-button affixed to its left side. Yes, that does look neat and may be another hat-tip to Firefox and its even more elegant / lazy solution to bookmarking, but it annoys the hell out of people like myself who don’t want a button for creating bookmarks in their toolbar. In fact, I prefer thinking about said ‘toolbar’ as the ‘navigation’ bar, and creating bookmarks has nothing to do with navigation, so it doesn’t appear there. I am perfectly capable of using a menu, hitting ⌘-D or using drag and drop (for which spring loaded elements in the Bookmarks Bar would have been nice) when I want to create a new bookmark.

Going on, on the right hand side of the location field, we now see the Cancel / Reload button in there. It doesn’t really look like a button. but it looks like what you see on the iPod. That’s rubbish. 15 years of web browsing taught my muscle memory where a reload button is supposed to be. And that location is left of the address field and not inside it on the right. In fact I still find the location of the reload button the single most irritating ‘feature’ of IE7 whenever having descend into those fields.

Whenever you visit a site whose connection isn’t only encrypted but also deemed particularly secure by Safari, the right hand side of the address field will also host the name of the SSL-certificate holder. Potentially shortened, with a funky fadeout and - strangely far away from the lock icon which remains in the page title. This is no dealbreaker but I find it a bit irritating. Wouldn’t the lock icon be better accommodated next to the address and the certificate owner’s name?

Another point is progress indication. Safari used to indicate its progress of loading a page by colouring in the address field with a blue bar. That scheme of progress indication was pretty much a sham because with a browser’s progress indicator you need ‘instant gratification’ to assure users the click they just made has been registered but you have no clue whatsoever how long the page will take to load at that moment. Hence, at that point, you have to display some amount of progress which is completely independent of what’s going on for real.

From that point of view, the indeterminate ‘spinning wheel’ progress indicator used by Safari 4b1 is technically more correct. But it’s simply too hard to see. That large and blue bit of progress indicator appearing on the screen was very obvious, a small and grey progress indicator appearing at the far end of the address field is pretty much invisible. You - or at least I - don’t just see it but have to consciously look for it, which is by far too much effort for me.

Arguments have been made that people are more hesitant to actually use a page before loading has ‘completed’ and that the less visible progress indicator encourages them to use the page before that. That’s an interesting point, but I can’t remember the last time Apple cared for pensioners or people with slow internet connections…

Finding

Safari 4b1’s Find field has been pimped as well. Using Google’s instant search completion recommendations you can now be even lazier and share your partial thoughts with Google as well. It’s a nice convenience. The menu popping up while you type in the Find field also contains a ‘Find’ command which will search for the typed text in the current page.

As this command is at the very far end of the menu, 20 items in or so, I find it highly inaccessible, particularly when navigating with the keyboard, which I am likely to do as I have just been typing in a search term. This needs extra fine tuning, say in the form of making the up-arrow go to the last menu item when you’re in the find field or highlighting the matches for the search term on the current page (which implies other problems, though).

Strangely, the popup menu that goes with the (empty) Find field lacks both a Clear Recent Searches command and that plain Find command which is attached to the bottom of the popup menu while you are typing. Those aspects could be more friendly, useful and consistent.

Tabs

Let’s move on to the big elephant in the web browser. Safari 4b1 comes with twisted tabs. Instead of being just above the page, the tabs live in the browser window’s title bar now. That’s just odd but my current stance is to give it a few days to see how much of the ‘odd’ impression comes from the look being new and differing from the standard Mac GUI (which of course itself is a bad thing in my book).

One thing this change has going for it is that it tries to be more logical. Lukas Mathis discusses the hierarchy of the browser UI in detail, making that point clear (and explaining why Coda keeps feeling odd even after long usage). So, in the Safari 4b1 image of the world, each tab is a browser and comes with its own address bar and Google field inside it (at the moment these fields’ behaviours are slightly different when you change tabs while typing in there, the Google field lovingly carries whatever you typed to the new tab, while the address field doesn’t do that) which makes more sense conceptually.

On the other hand you now have a Bookmarks Bar conceptually ‘within’ each tab and it can contain folders which offer to open all their items in tabs. That ends up being a bit mind boggling or even destructive as you might expect that command to just replace the current tab by many new tabs and may be shocked that it destroyed the content you had in other tabs. Perhaps this will be improved as further builds emerge, but I see a conceptual problem here: you want a Bookmarks Bar, you want it close to the browser display, yet it doesn’t really belong inside each tab but it belongs to the whole application. Tricky one. To me the only logical conclusion seems to be to not use the Bookmarks Bar at all and hope that URL autocompletion will fit the bill. That would solve the problem with the Top Sites icon, save vertical space and get the browsing done nonetheless: Win-win-win.

After discussing things somewhat neutrally so far, let’s get to the bile. Those in-titlebar tabs just irritate the hell out of me. I assume that Apple will come up with better close and move icons for them, and the web has been full of (correct) remarks on how irritating and unclear the tabbed title bar’s behaviour is: what will come to the front when I click? the window? the tab? Where can I click to move the window? Where can I click to move a tab? Can I recognise a window as a window among other windows of the OS? To me neither of these questions has a clear or satisfactory answer.

I guess getting used to them might improve that situation a little and Apple improving the design a bit by using better icons and colours (e.g. currently I simply don’t see at all that there are tabs when only two are open as there is so much blank space in the title bar that I don’t perceive the window as tabbed) may fix things a bit more. But I’d be cautious here: There’s a reason why all windows should look and work the same. These Safari windows don’t and that makes them difficult to use.

However, the argument that can be made here is vertical space. On today’s wide computer screens we have horizontal space without end but we can only read 80 characters in a row in that direction. Which makes the vertical space much more precious when it comes to reading as any scrolling action is an extra effort. And from that point of view I can appreciate the effort, even though I am not convinced the space savings are great enough to justify all those strange visuals in the Safari tabs.

Vertical

As the preciousness of vertical space is one of my favourite topics, let’s make a rest here and take this a bit further. Apple saved some space by unifying the window’s title bar with the Tab Bar and I already eliminated the Bookmarks Bar for good a few paragraphs ago. So what’s left? The address field, a.k.a. the Toolbar in Apple’s terminology. That bar takes up further vertical space and is not used most of the time as only the back button is needed regularly.

Indeed, Safari can hide the address field and you can temporarily unhide it using ⌘-L. You can enter an URL then and after hitting return, the bar will be hidden again. That’s quite efficient, leaves you with a clear screen and in case you do a fair bit of your browser navigation by keyboard, this looks like a feasibly option which maximises the browsing space at first.

Unfortunately Safari’s implementation of the auto-hiding is somewhat buggy and after a while of browsing and URL editing the address field will cease being hidden and become permanently visible again. Hence such a browsing strategy never really works out in Safari as it existed so far (and Apple’s stupid non-A-Z keyboard equivalents for those commands make trying to hide / unhide the ‘bars’ by keyboard equivalents an exercise in frustration).

In my opinion it’d be cool if Safari could just show the most relevant buttons on the side of the window - as horizontal space is cheap, that’d be revolutionarily cool and useful. - Uh, wait, I may just be a closet-fan of IE5/Mac:

Fin

OK, that’s it. Safari 4b1 is a bigger step UI-wise than I would have expected. Yet, many of its changes seem gimmicky and not fully thought through. Be it for offline-viewing of my surfing history or for the fact that they tried to nick the best browser features left and right without visibly demonstrating that they’re also convinced by the underlying ideas (say, Google Chrome’s multi-process architecture is completely missing).

Even though Apple is becoming quite Microsoftish in the way that they ship WebKit with their OS and you practically can’t remove it from the machine without breaking loads of things, Safari remains just a browser. It’s a µ between it or Mozilla’s or Google’s or Opera’s browsers and switching is not a big deal if one starts disliking one’s current browser. Let’s see where this takes us.

Safari 4 has been released since. Why not read the post on it and on working around its shortcomings as well?

The pain can be reduced by having a copy of the system CD on a spare hard drive partition. The machine can easily copy the DVD over and in case you need it - i.e. after the proverbial shit hit the equally proverbial fan - you’ll have an install medium that’s quite quick. Unfortunately Apple’s system DVDs or Disk Utility don’t come with instructions how to make such a copy.

Pierre Igot recently discussed this issue for the slightly different topic of installing system software on a machine without a DVD reader. And along the same lines - though tested for Mac OS X.5 on my current MacBook only - I can recommend the following steps:

1. Make sure you have a hard drive large enough to contain the install DVD (10GB should be plenty, 8 will do)
2. Use the command

   asr restore --source /Volumes/Mac\ OS\ X\ Install\ DVD --target /Volumes/Empty Hard Drive/ --erase --disableOwners

   In which volume names are adjusted for your setup of course.

There’s no step 3. The magic asr command will copy the image over to the hard drive partition, deleting the previous contents of the partition in the progress and ‘blessing’ the partition to be recognised as bootable in the process. It’s really quite an easy thing to do.

Unfortunately all of these kinds of progress are displayed in a window of their own. Which means that you can easily end up with different progress windows covering each other and having to ‘manage’ your progress windows to actually benefit from the information they display. To me it would seem much cleaner to have a single window which displays all the progress panels for file or Finder based tasks. That would seem less disorganised.

You are invited to add your pet loves and hates at the end.

XCode

XCode has become faster and more powerful in its third incarnation. The slowness of Cocoa’s text engine is pretty much forgotten and XCode can now open and syntax-colour large source files quickly enough that an onlooking Linux person doesn’t have enough time to recite the benefits of emacs along with a full list of key bindings. That is an extremely welcome improvement.

Just like code folding is. Having it invalidates excuses for not having lengthy comments, say, and it can simplify understanding structures and problems on a global level. Unfortunately XCode 3 seems to have shipped so immaturely that code folding is wildly incomplete and buggy. A rather obvious problem is that red or black markers in the editor’s scroll bar, which indicate compilation problems, appear in the wrong position when lines have been folded above the error. Another is that the foldings aren’t reliably persistent which they certainly should be if they are to be useful.

A neat new feature of XCode’s editor is its ability to ‘refactor’. In a way I am a bit disappointed by this because I used to think that ‘refactoring’ is a big computer sciency thing where you re-think your application and re-design its data structures for a new version to make things better, more efficient and fantastically future-proof. In XCode’s terminology (and quite possibly in reality - my respect for all programmers who spent a hard night ‘refactoring’ just dropped!) refactoring means that you re-name some variables. Probably all for the sake of consistency, beauty and future-proofing as well - but somewhat less spectacular than what I had in mind.

That said, it is a wonderful feature. You click a variable in your code, it will become underlined and an arrow button appears to its right (most of the times, anyway). That button will contain a menu which activates ‘refactoring’ and after selecting it, any change you make to the variable’s name will be copied to all other occurrences of that variable name as well. In effect this means that you are much more likely to end up with good variable names simply because replacing the bad ones you initially put there is easy.

Just be warned that XCode’s interpretation of the Edit all in scope command is a bit - ahem - idiosyncratic: When I define a variable inside an if branch, I (and my debugger) consider the scope of that variable to be that branch only, XCode’s refactoring, however, will happily rename all other variables with the same name inside your method but outside that branch as well. I rate this somewhere between ‘not helpful’ and ‘dangerous’.

The new XCode version also cleaned up a few other things to make your work more streamlined. Compilation errors will now show up amidst your code, the Run and Debug modes work more similarly and the debug mode has generally been improved. Most notably you just need to hover over variables in your code while debugging to see their value and inspect them. Thousands of clicks and sighs will be saved this way.

XCode’s breakpoints gained a GUI for things like playing a sound or logging some string or backtrace as well as the ability to have Global, that is cross-project, breakpoints. That’s great for those of us who program occasionally and forget whatever little they know about the gritty gdb commands in between. That said, the GUI implemented here is far from perfect once again:

After just a few uses I noticed that: (a) you cannot use the scroll wheel in the breakpoint list when there are expanded items with text fields in them, (b) switching between the different actions like Log, [Play] Sound &c deletes the settings you made in your previous choice; that’s very inconvenient and bad for experimentation, (c) no Undo (but at least Copy and Paste work, so it’s still better than an iPhone…), (d) no Duplicate command, (e) after expanding a breakpoint by clicking the triangle at the left of the breakpoint you always have to click the ⊕ button at its far right side; that’s annoying; relocating the buttons or simply letting a double click in the area have the same effect would be handy.

XCode’s help now seemingly gained the ability to automatically subscribe to documentation updates, download and install them (in what seems to be universally considered the most resource hogging background process Apple gave us so far) and thus save you the hassle of that login, download and install process.

Another addition -  which may well end up being a star of XCode -  is the Research Assistant, an inspector window that displays information and documentation about the method, variable type or function your cursor is currently on. It’s a wonderful idea which could be tremendously useful if it were well implemented. But it’s still quite far from that.

Even in my shallow experience the Research Assistant is one of the main factors making XCode 3 terribly sluggish - waiting a full second before seeing what you typed appear on screen sluggish, that is. This needs major improvement. Allegedly there are cutting edge technologies like multi-tasking or multi-threading which let applications look up one thing without stalling your typing while doing that. Let’s hope Apple catch up with those technologies at some stage. The Research Assistant also isn’t terribly good at displaying information for many things it should know about. Specifically it doesn’t display information when you click into a child part of a struct or Objective-C 2 property statement or when you click into one of the methods of your own classes. - Nice idea, but not really there yet.

XCode’s autocompletion improved as well. But it remains ridiculously bad. I don’t think I ever used an autocompletion feature which so consistently managed to suggest the most useless autocompletion when several possible completions are available. Making this perfect should be hard but a bit of work might lead to considerable improvements already: XCode has a lot of information at hand, it knows about Apple’s data types and the functions/methods belonging to them, it knows about your classes and it knows the code you use close to where you are typing. Humans and even dull logic will probably manage to complete [bezierPath moveToPoint: NSMak in a useful way - a task which is already too hard for XCode’s autocompletion. And this is just a random example I had on screen at the moment. There are many many others you will come across.

I am lazy, so I really want to use autocompletion, but with XCode’s - as it is today - I frequently think that it would have been quicker to type things myself than to wait for the autocompletion suggestion to appear or to fight XCode to provide me the correct autocompletion. This is even harder and frustrating because even after using it for a while I am unable to predict what hitting the tab key will do. You cannot develop ‘muscle memory’ for the autocompletion for (at least) two reasons: The first is that you cannot simply type a few letters and hit tab. You have to wait for a moment before hitting tab until XCode has caught up with you. That costs time and ‘flow’. And then, XCode seems to try to be ‘clever’ about the default completion it suggests. Which could be a good thing. But somehow I found that in most cases it’s just not clever enough and hands me the wrong completion.

Objective C 2

Objective-C - the best programming language since Basic or Pascal - got a version bump as well. And it surely resolves the single thing Objective-C lacked in comparison with RealBasic: Garbage collection. While, personally, I think that Objective-C’s retain-release concept really isn’t so bad once you got the idea, leaving out all those explicit retain, release or autorelease calls will certainly make programming more fun and less of a hassle.

I’m sure there will also be situations where having proper garbage collection will solve real memory management problems. Just as there will be situations where it will hurt performance. In fact, I am fairly sure that I already observed such a situation in a fun little project where I ended up using 60MB of extra RAM while displaying an animation. Probably just being able to release the images in question as soon as you don’t need them anymore rather than waiting for the garbage collector to feel like doing the job could avoid this generous waste of precious RAM.

Properties look great as well because - as big as my love for brackets may be - it’s quicker to type than accessor or Key-Value-Coding methods. I’m lazy in that way. XCode’s autocompletion still mostly sucks when you are using properties and I am not sure whether I fully grasped the concept and its consequences yet. (What’s the cost of using a property? Does it really make sense to access a class’ instance variable via self.myInteger? I keep thinking that it may be the ‘cleaner’ version of doing things but that in many cases it’s probably just an absurd waste of CPU cycles - i.e. global warming. So what’s the responsible thing to do?) My lazy self is also a bit disappointed that setting up a property requires three lines of code in three different locations. I was thinking more about a single magic statement in a single place. As XCode’s ‘refactoring’ also fails to make renaming properties easy by offering to change both the source and header file and listing all other places where the property is used by files (code and nibs) in the project, this isn’t entirely convenient.

Objective-C 2’s new looping techniques are very welcome as well. I doubt that anybody will miss having to type NSEnumerator all over the place. I certainly won’t.

Interface Builder

One of the more problematic parts of X.5’s developer tools is the completely reworked Interface Builder. While re-engineering and re-writing the ancient Interface Builder application to better match today’s Cocoa environment with things like Bindings and the iPhone runtime environment around is most likely a good idea, the application itself seems terribly under-engineered and prematurely released to me.

Somehow the new Interface Builder seems to require a lot more screen real estate than its predecessors with its huge, overly animated and split viewed Library palette being the most obvious problem. Just try creating a medium sized window on a MacBook screen. It will end up being frustrating because you’ll either have the Library palette covering your window or you’ll have to fight the battle between the Library and Inspector palettes about who is on top. That’s not very convincing.

Interface Builder’s - just like XCode’s - New File window is a matter of bad design as well. Rather than carefully using the space in that huge window to make all relevant items that can be created clearly visible, you’ll easily find yourself in a situation where you see scrolling views and many subitems which makes things look much more complicated than they really are.

Other things that regularly drive my nuts in the new Interface Builder are that it seems even worse at dealing with localisations than its predecessors (easy switching between different language versions of the same UI element would seem like an obvious thing to do), that it makes it ridiculously non-obvious how to instantiate one of your own classes in a nib file and that its bindings editor still sucks full time (no good preservation of what you enter, no help autocompleting key paths and no friggin’ way to make the Inspector window wide enough to even see your full key path, FAIL, FAIL, FAIL) which makes other points like the new icons for nib and xib files that simply don’t stand out in your XCode file list and thus needlessly hard to find seem minor in comparison.

Uh, and Interface Builder’s pseudo HUD, small, overly auto-scrolling action method selection window is probably something for which you want a copy of the HIG engraved in some hard material just so you can slap the people who implemented this with it.

Documentation

Apple have a proud history of shipping all that nice Cocoa stuff and giving us sub-standard documentation and examples along with it. My impression is that this situation has improved a little but hasn’t changed fundamentally yet.

The problem with this is that it can waste a lot of time or create sufficient frustration to simply discourage people - particularly those of us who’re only in this for the fun - from trying things. In many places of Cocoa the behaviour of the framework is un(der)-defined by the documentation. Be it because Apple are too stingy to have more exhausting documentation written as they don’t care about their developers or because they don’t know themselves. Giving Apple the benefit of the doubt one could hope that the people working there and making the frameworks actually know those details and can explain them. Then please make them share that knowledge, it will save time over and over again around the world!

Then there are small things in XCode’s documentation browser which could be smoother. Say, when I’m entering NSMenuItem into the search field I keep getting the legacy NSMenuItem protocol as the first result. I am even warned about this being a deprecated way of doing things and (after scrolling) I’ll get a link to the new class, but wouldn’t things be, um, useful if the Help gave me the thing I’m looking for right away?

Another aspect of documentation - which is quite ‘in character’ for Apple, though - is that it’s not very candid about what doesn’t work. This kind of information can be tremendously helpful as it keeps people from wasting time trying things that are hopeless. What about a comprehensive guide to all Cocoa controls indicating which of them can realistically be used with Bindings, say?

The final point are examples. Many people, including myself, find examples a very valuable form of documentation as they don’t just theorise about the frameworks but show you how things are done. With a bit of luck you can even nick some code from them. In some areas (Quartz Composer, Audio?) the examples seem to be quite comprehensive and give you a good starting point for not just using those technologies in a simple way but really digging into them. In other areas, however (CoreData and Bindings come to mind), the examples are far from covering the whole problem space. I think that having more of them could make learning the underlying technologies much easier (particularly for ‘magic’ technologies like CoreData which you are not going to understand fully).

Code Signing

MacOS X.5 is full of technology for code signing. It has good and bad sides. Let me discuss what it does first.

The essential idea for code signing is to authenticate an application. A developer can create a certificate and sign his application. While - just as with encryption certificates - it takes quite a bit of extra effort to make sure such a signature really authenticates the developer, this at least gives you a way to determine whether two different versions of an application originated from the same developer (modulo the developer’s incompetence at handling his certificate, that is).

Mac OS X.5 already uses this in a number of ways. The best one of them is the keychain. If an application has been signed by the developer and you allow that application to access your keychain, the keychain will now remember not just the application and its version but the developer’s certificate. If you download an update for the application, the keychain will recognise that it has been signed by the same developer and the application will be granted access to the keys without further ado. This means there is one less annoying dialogue asking the user for permission to access the keychain. Which makes it more likely that users will take those requests seriously when they do appear. It’s a good thing.

Other areas where Mac OS X.5 uses code signing is for its firewall and its nanny mode. In the latter, code signing is used more destructively: Rather than letting people execute any code, only certain ‘trusted’ applications which are pinned down by the signatures of their developers (or the signatures OS X.5 adds if there is none) are allowed to accept network connections or to be used by the kids.

Obviously things easily become a bit creepy once we venture in this direction. For example because of the automated code signing by the OS, applications can be modified without you really knowing about it. And obviously once you have these technologies in place for the good intentions they are also easily available for bad ones.

I suppose the iPhone is a prominent example for this. Essentially it’s Apple’s decision whose code can run on the iPhone. That toy is not a computer at all but a highly controlled environment. Apple dictates its rules and it will be interesting to see when the first applications are found to be against Apple’s arbitrary terms and conditions and will be banned from iPhones. Would instant messaging be fine? Would route planning be OK for third party software on the iPhone or did Apple make an ‘exclusive’ contract with some software company for that already? Is porn in or out? And if it’s out, who gets to decide what porn is? Is VoIP OK? Or an application displaying The Guardian? Or one displaying Fox News for that matter? Do we really want someone else deciding which software may run and which doesn’t?

Well, the iPhone and Mac OS X.5 have the technology to censor away. Currently it’s a mere possibility but what will happen in X.6, .7, .8? We don’t know. The code signing doesn’t seem to be fully documented yet (another aspect which makes this a bit creepy) so the full power isn’t entirely clear at the moment. But it appears that using the codesign utility you can sign pretty much everything from a Unix command line tool to a OS X bundle. And the detailed settings appear to give finely levelled control about which parts of a bundle are covered by the signature. When will applications start trying to refuse running when their signature isn’t matched? When will frameworks which Apple ship but don’t want other applications to use simply fail to initialise when the application using them hasn’t been signed by Apple?

We’ll have to see how this plays out. If I am not mistaken they have done a similar thing on Windows for ages with drivers. Whenever a hardware company doesn’t cough up the money for Microsoft’s certification and a driver is installed some dialogue box comes up asking people whether they really want to continue installing an unsigned driver. I haven’t watched many Windows users but none of those I saw seemed to even register that warning, they just dismissed it because that’s the natural thing to do. Which to me means that if signing technology is to have any practical effect it has to be drastic. Things need to not work when they are not signed. And that’s a bit of a scary prospect as it makes a completely walled in computing experience - one that one wouldn’t consider a computing experience at all in some classical sense - seem quite realistic.

Interesting question: Does XCode support convenient code signing yet? There is a field for entering the key to use for singing in the build target inspectors. But entering something there never did much for me. When compiling the project with the xcodebuild command, however, it looked like a signature was created.

But as technology ‘develops’ I have a machine now whose Airport connection routinely fails and, since the X.5.3 update whose Ethernet connection fails as well when there’s a high load on the machine. Fan-friggin-tastic. My inner conspiracy theorist assumes it’s a scheme by Apple to move the whole internet onto iPhones. Haha.

Another point where the Mac ruled pretty much forever was support for multiple screens. No matter what you hooked up, the computer would generally make reasonable sense of it and options to adjust the multi-screen desktop to your liking were never far off. And I have never seen a Mac cause significant problems when trying to hook up an external screen. — Until last week that is. The crappy CRT in the office started flickering. Which meant I got a different crappy CRT as a replacement which looks just the same from the outside. And it worked just fine with the MacBook the first time I used it. When attaching it the second time with Apple’s ridiculously overpriced ‘MacBook to VGA adaptor’ the screen just gave me an OVERRIDE SYNC ERROR message. All capital letter FAIL, that is.

I first hoped, I had just destroyed the crappy screen. But the fact that the crappy X-Terminal in my office could use the screen just fine, hinted that the carefully ‘crafted’ combination of a MacBook and Mac OS X was to blame. Some combinatin of deleting all preference files remotely looking like they are WindowServer or Monitor related, restarting the machine and replugging the screen at the right moment, solved the problem. Temporarily. Attaching it the next time gave an OVERRIDE SYNC ERROR once more. Now that sucks. It’s exactly the reason why I’m not using Linux or Windows. I want this to ‘just work’.

(If you want to trigger extra bugs in OS X, start playing with the ‘Rotate Screen’ options OS X offers for the secondary screen. I ended up with my secondary screen being all blue and completely unusable after having used that while trying to explore this problem. More Suck.

Then I managed to write down the good old Beatles → Oasis → Travis → Starsailor → Keane line of musical descent and dodgily compared it to the descent Speak → Phone → Instant Message → SMS → Twitter of communication, where each new member of the series requires more elaborate technology to communicate less. In fact, with Twitter we must have arrived somewhere in the inane quarters (I’m just queuing for a coffee, btw, and they’re playing an interesting CD, must remember) and – just as with Keane – the scary question is of course what will come next? [I suspect the answer should be Hot or Not, but that has been around for years and cleverly reduced user interaction to a yes/no decision, can we beat that?]

But before I could elaborate on that, I found myself in kernel panic land and my text gone. At first I hoped chances to recover the text aren’t too bad. After all that study that RAM isn’t completely erased when a machine restarts or is shut down made the rounds recently. The question was just whether the crucial bit of RAM would be overwritten by the time I could access it. It was, which is why you have to make to with this text.

Thus, I restarted the system taking the 1:8 (256MB:2GB) chance of OS X overwriting my text just to boot. I’m fairly sure that my machine’s memory had been shaken through well at the time of the panic (PIDs in the 40000 range, 10days of uptime, 5GB of swap files, WTF ‽), so stuff could have been anywhere. But the next problem was to actually access that darn RAM. Let’s just say that OS X doesn’t come with a convenient way to do that and – naturally – nobody quickly replied to the question I asked on the topic on Twitter, because that might have been useful.

And the web wasn’t too useful either as most search queries with what looked like relevant terms on this issue to me returned regurgitated versions of the story of those geeks managing to read the RAM and encryption keys of a machine they quickly turned off. As web sites, and particularly computer web sites, go not a single one of them did any original research on this or even contained any clue that the writers tried to reproduce this on their own machines. Naturally none of them contained a clue on how to read out the machine’s memory – all that while reading web pages in Safari ate up my precious RAM.

At some stage I had ‘lucky’ search terms which led me to the site of the inimitable Amit Singh – a site that from my point of view suffers from the problem many others should envy it for: it has so much good content that it’s difficult to find the bits that are relevant for you – who mentions the problem in a sidenote. To quote:

As a trivial alternative to the kernel extension described in this document, you can try using the kmem=1 boot-time argument. If your kernel supports this argument (the Apple kernels at the time of this writing do), setting it will reenable the kernel memory device.

Now I wonder how many of the people writing mouthfuls about hacking computers by reading out their RAM would know this trivial bit of information? Anyway, the upshot is that Apple decided that their users ‘don’t need’ to be able to easily access their very own machine’s very own RAM if they want to and simply turned off the /dev/mem file people know an love from other systems. But running a command like sudo nvram boot-args="kmem=1" will enable the /dev/mem file again after the next restart [and delete other settings you may have had for boot arguments].

The rest was an exercise in copying a file and looking at it. Searching for some rare words from my text (Starsailor!) in both ASCII and UTF-16 encodings didn’t find it, which as far as I can tell suggests that the text had been overwritten already. This is a good point to laud the HexFiend tool. While it could do with a better search feature (e.g. Unicode Text Entry, NSStrings love UTF-16 if I’m not mistaken), it has amazing performance. Even on my slow laptop drive it gets through 2GB in around a minute, reading almost 30MB/s. I have never seen other applications achieve this. Even better, all this is done without discernible CPU usage or performance degradation.

So in the end I lost, but I came out of it with another story to tell.

Homework: Inspect your swap files with HexFiend to see whether they really are encrypted when you’re using that option of the OS. Also find out whether your system will display the contents of the swap files to you or whether you have to forcefully shut it down to look at them.

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

while current ones read like this:

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

It doesn’t look like this difference is of any practical relevance as both the old and new style properly lists work just fine on my Mac. But seeing the difference made me wonder whether it’s like this ‘by design’ or because Apple parse the files sloppily. If what’s up there in XML files really serves as an identifier, it shouldn’t change or Apple would have to ‘register’ the same format under two names. Which’d seem a bit sloppy.

Would a strict parser bark on this? Unfortunately I couldn’t find a clear answer to that question with a bit of googling. As far as I understand the space between the first ‘//’ and the second ‘//’ is used for the name of the format’s owner. Is that the current owner or rather the owner at the time the format was specified?

On the upside: 9 bytes saved per file! OMG! LOL!

Just look at this little example:

The problem we see here is that WebKit anti-aliases its rounded borders. A nice idea, if it were taking the background into account. However, WebKit prefers to anti-alias the background against colour of the inside of the element in question rather than what's actually visible behind it. To make this clear, perhaps this example with a background image is helpful:

If you look closely, you'll notice that the portion of the background image that would be shown at the corner is displayed there. Resizing the browser window's width while watching the right corners may make this more obvious. I'd say this shouldn't happen.

Amusingly they don't have this problem in Firefox because they decided they'd be happy without anti-aliasing and thus avoided this opportunity for sloppy implementation.

Another thing that's rather unsatisfying about rounded corners is the way they are handled by img elements: A rounded corner is drawn but it is drawn beneath the image. So instead of cropping the image in a nice and round way, it gives something ugly. This is so obvious that I'd guess it's deliberate. But I wonder what the rationale behind it could be.

Mozilla (as of Firefox 2) actually outdoes WebKit in this respect as it doesn't only not crop img elements but also lets an element's background image 'underlap' beyond the rounded corners – and occasionally even outside the border!

Look at these issues on a separate page.

Like the fact that some complete frigtard managed to produce a TeX file which contained Roman text along with cyrillic characters. Well, that shouldn’t be a big problem. However, it is a problem if - and that’s how we reconstructed things - the document was created in the following way:

• The document was first written as a TeX document in Russian in the 1990s. It was written on a Mac and saved using the Mac Cyrillic encoding.
• Cyrillic lookalike characters were used for Roman ones in a number of places. For example Н (Cyrillic capital letter EN) instead of H (Latin capital letter H).
• Then someone (else) created an English translation of the document and didn’t re-type all of the formulas but simply copy and pasted them from the Russian version.

This is hard to notice when looking at the text file in the right encoding and it’s rather tricky to find out what exactly happened there as well. (Just try to find out the exact encoding of a file in a Linux GUI if you don’t really know what you’re doing… and who’d guess Mac-friggin-Cyrillic for it?) But it certainly leaves us with a document containing Cyrillic characters where they shouldn’t be.

The next problems were to find all the Cyrillic characters in the document and to replace them. That should be fairly trivial but with the tools I have at hand I found it quite complicated. [read: if you know a one line regular expression to achieve the same thing, please leave a comment!] A straightforward change of file encoding didn’t do the trick as this replacement of characters is no such thing. So after a bit of back and forth I ended up doing the following: Open the file in a text editor as Mac Cyrillic. This made sure the wrong characters are correctly interpreted; Copy the file’s text to the clipboard. Hack together the following PyObjC script to replace characters in the clipboard and write them to a file - printing out the conversions done and the potentially remaining problems to the console:

#!/usr/bin/env python
#coding=utf-8
from AppKit import *

pb = NSPasteboard.generalPasteboard()
input = pb.stringForType_(NSStringPboardType).mutableCopy()

originalstring = u'ЗЃгНМЕКаСТ•А†бä'
newstring =  u'3oyHMEKaCTeAacä'
l = len(originalstring)

for i in range(0, l-1):
    a = originalstring[i]
    b = newstring[i]
    count = input.replaceOccurrencesOfString_withString_options_range_(a, b, NSLiteralSearch, NSMakeRange(0, input.length()))
    print a + "->" + b
    print count

a = input.rangeOfCharacterFromSet_( NSCharacterSet.characterSetWithRange_(NSMakeRange(0,127)).invertedSet())

print input[a.location-100:a.location+10]
print input.writeToFile_atomically_encoding_error_("/Users/ssp/Desktop/test.tex", 0, NSASCIIStringEncoding, None)

This still feels like it is a bit too complicated for the simple problem at hand. But it did the job. I think I’m starting to like PyObjC. To begin with, python as a language seems quite nice and intuitive. I haven’t read a manual but just from seeing a few examples I could deduce enough to get a working script. I wouldn’t say that this is necessarily a technically good thing for a language, but for a scripting language used for off-the-cuff hackish stuff like this it’s brilliant. [This certainly beats the atrocity known as perl or the hideousness of shell scripts.]

Then there’s Objective-C and the Cocoa frameworks. As I am familiar with them, having direct access is rather good and gives me the ability to do many things right away without needing to re-learn everything. Again, perfect for hacks like this. And it’s better than the ‘real thing’ because I don’t have the overhead of creating an XCode project, compiling and so on when doing this. A nice thing about Cocoa is its fault tolerance. You can just get away with passing zero pointers in many situations, leaving you with a working script even though things didn’t go perfectly. [That certainly beats AppleScript; As AppleScript is probably the worst language ever for string manipulation I wanted to avoid it here.]

Extra kudos go to the PyObjC implementors for making a bit of an effort in their error messages. Compared to other languages, these were actually helpful. There’s nothing as bad as starting a hack like this and running into a cryptic error message which halts progress. At that point you start losing loads of time. For some things - as the inclusion of non-ASCII characters in the script, an issue which I was really scared about considering the general Unicode incompetence in scripting languages - PyObjC simply spat out a message pointing right to a web page discussing the issue and telling me I want to write #coding=utf-8 at the top of my script. Another Google search made clear that I want to add a u in front of my string constants and things worked from there. That’s excellent.

Of course this script is still imperfect. It’s off-the-cuff by someone who doesn’t know what he’s doing. And I failed to do everything I wanted to achieve. A few questions that stuck follow. Any insight on the issues they present will be appreciated.

• Is there a really simple way to get a collection of all ‘strange’ characters in a document? Just a list of all non-ASCII characters without duplicates in a line of Cocoa or a magic regular expression? That would have made it easier to gauge the size of the problem before starting.
• I managed to find the ‘wrong’ characters one-by-one but I would only get their offset from the beginning of the string easily. When looking at things in a text editor at the same time you usually just have a command to jump to a certain line but not to a certain character in the file. What’s the easiest way to solve this?
• It seems that the last character in my strings is ignored. (That’s why I added trivial replacement at the very end.)
• python strings and NSStrings don’t seem to be exactly identical in PyObjC. For some Objective-C’s -length method works, for others I had to use Python’s len() function.
• I couldn’t write to the clipboard. When doing so in NSPasteboard you need to pass an ‘owner’ to the method you are calling. Usually that is self. I tried entering self but PyObjC just gave an error. I tried passing other things like 0 or a string instead and that led to a rather unfortunate situation where OS X.5’s whole clipboard infrastructure was broken. pboard needed to be killed and any running application which tried to use the clipboard froze and needed to be killed when doing so. Hence I just wrote the results to a file…