X.5 Tidbits 2¶
3785 words on Mac OS X 10.5 Leopard
Another collection of small points regarding Mac OS X.5. See the first installment for more tidbits.
I love it because it’s Trash
No, Oscar isn’t back. But for some reason the Dock’s Trash can is spring-loaded now. I really like spring-loadedness, but for the Trash it just doesn’t make sense. Who’d carefully arrange items in there?
Double Sheeted
For reasons that I never really understood, Apple didn’t want people to use multiple sheets on a single window. Sure, having those won’t be the prettiest thing ever, but it surely beats an application modal dialogue and its locking up of things. Apple took care to make sure that they present you with a modal dialogue instead of a sheet when such a double-sheet situation could occur. But if you’ve been a careless programmer, you may have noticed that the system was fully capable of opening multiple sheets on a single window. You just needed to do it.
Luckily, Apple changed their mind now and multiple sheets on a window are allowed and used in X.5:
This still seems to be a little buggy (e.g. when using F11-Exposé just the window and the lower sheet will slide out of the screen but the upper sheet will remain in place), but generally it’s a good development.
SystemUIServer
The previously noted ability to set a keyboard equivalent for Finder contextual menu items raised the hope that Apple finally fixed their SystemUIServer, the application which displays all the system-owned menus at the right hand side of the menu bar (except for the Spotlight menu), as well. But no, keyboard equivalents can be assigned to menu items in SystemUIServer and they will also be displayed. But they still won’t work.
Which seems rather odd as SystemUIServer is definitely keen on watching your keyboard input otherwise - being the application to invoke the screencapture tool, for example. So there remains some work to do for Apple. Particularly so, as having keyboard equivalent support for SystemUIServer items would kill the last excuse people have for their ill-advised per-application script menus. Apple’s ScriptMenu could then fully handle all those jobs with all the bells and whistles.
And while Apple are at it, they should also make SystemUIServer less likely to stall (attaching my FireWire iPod to the machine the second time, has been doing that quite reliably for years), as nothing, nothing, NOTHING should be able to stall the application which displays the clock in your menu bar.
Furthermore, Apple should clean up with the royal mess they turned the menu bar into over the years. As far as I can tell there are four to five different areas of the menu bar. The proper menu bar of an application at the left, possibly including the new Help Menu which is a bit different (see below), then the Spotlight menu at the very right of the menu bar which is owned by the separate Spotlight application, then the SystemUIServer area with all the menu extras and then - potentially - the area of application owned status items which are displayed to the left of SystemUIServer.
Unfortunately, Apple didn’t implement their menu bar well enough to make the transitions between the various types of items smooth. Just try dragging around your clicked (and held) mouse in the menu bar: it’s insane. You can start in an application’s menu and all other menus of the application will naturally open, the menus of status items won’t open, but the menus of SystemUIServer items will, while the Spotlight menu remains closed as well. Dragging the mouse back into the application’s menus after this will leave you with the puzzling effect that those won’t open now either. Quite odd, if you ask me.
And while it may be rare that people click in an application’s main menu and then go over to the Spotlight menu in a single move, it’s extremely likely that people will click in SystemUIServer before opening the Spotlight menu. Particularly if the top right corner of the screen is a ‘hot’ corner that invokes some Exposé action, it seems likely that you aim for the left hand side of the Spotlight menu to avoid that hot spot. But then you’ll be stuck in SystemUIServer and will have to click again to be able to use the Spotlight menu. Quite a nuisance. CAN I HAS SINGLE MENUBAR PLZ?!
Help
The new Help menu is amusing because it contains a search field. And that search field makes it a bit strange. Try the following: Select some text in an application and open a normal menu: The menu will open but nothing else will happen. Then move the mouse cursor over to the Help menu. As keyboard focus is now moved to the Help menu’s search field, the selection colour in your document switches to the inactive selection colour. Which, I think, makes perfect sense logically, but is extremely irritating to those of us who actually use menus as it can cause areas of the screen to ‘flicker’ for no good reason.
Following this a bit, you will notice that the same is true for every other action that involves an UI element which formally - but in my opinion not from its appearance - belongs to another application. All the ‘other’ menu items at the right hand side of the menu bar will change your selection colour for example. As will opening a stack. While I do get the logic of that, I think it ruins the illusion of a unified user experience.
A bonus bit about the help menu which doesn’t hurt but does defy logic is that it has full copy and paste support via keyboard equivalents. So you can hit Command-V while the Help menu’s text field is active and see the Edit menu highlight and text being pasted. That’s useful but not exactly the behaviour you have learned to expect from menus with at most a single menu being highlighted and used at any given time. Makes me wonder with what kind of hack this was implemented.
Another, if not the main, fun bit about the Help menu is of course that it doesn’t just try to find you matching help topics from the indexed help file but it also lists all matching menu items. And hovering the mouse over one of the matches will open the corresponding menu and hover an amusingly dancing and pulsing arrow next to it. Sounds silly, but can be quite useful. That said, I’m not sure whether all aspects of this fully make sense.
Hiding the ‘normal’ Help menu items when displaying the search results? This punishes people who don’t find what they’re looking for with the search field and who want to open the normal help in the end, just to not find the menu item. Not including the menu items from SystemUIServer? Makes sense in a way, but this moves them even further from applications. Displaying inactive menu items in the same way as the active ones in search results? Quite possibly leads to disappointment when the actual menu item turns out to be disabled. Having a rather wide and mostly empty left ‘column’ in that menu? Defeats me. Truncating the titles of some search results without offering tooltips when overing over them? Not that helpful.
It seems that the Help search will also search the global Help to a certain extent. Which probably makes a bit of sense if you expect people to just type anything that comes to their mind into the first help search field they find (which is probably a realistic thing to expect). But which I also find a bit confusing. And if the help menu has such a wide left hand column, they should perhaps use that to somehow mark found items if they are not from the current application’s help.
FInally, the Help Viewer. One of the more annoying things in X.5 The fact that it now hovers over and covers up the windows it is supposed to explain doesn’t make it any better. The few times I felt the need to use it, I invariably had to move it around on screen. Hovering windows are fickle. You can’t easily get them out of your way. The only options you have is to move them off screen which isn’t very elegant or to minimise them which is a rather slow and clumsy approach. Perhaps this problem isn’t as bad if you’re using a 30 inch screen and can reserve some empty space for the Help Viewer. But that’s not my usage situation. The floating Help menu makes it much less likely that I’ll even bother to use help. The sheer annoyingness of that window just puts me off.
For those of us who like our Classic nostalgia, the new help menu is even worse. Of course we know that floating help windows can be great. We had Apple Guide to prove that. Floating help windows which are totally aware of the application they are helping you on. Which would locate windows for you, which would circle the places you had to click and so on. That was great help. But none of it is present in X.5. You just get the ‘I’m in your way’ aspect of a floating window combined with the dumbness of HTML help. Bliss.
Unix Executables
While Apple are always keen to advertise their new or not-so-new features for a new release of their software, that list isn’t a true list of changes. For example, it completely lacks a list of things that stop working in the new release because Apple preferred to stop supporting them. That, of course, is a rather important list. For example, in Mac OS X.4, the support for AppleTalk based file sharing was dropped, thus making connecting a MacOS X machine to old Macs running System 7 or so extremely inconvenient, if not impossible. But dropping a major and decade old feature of the OS wasn’t worth mentioning.
I supposed the biggest dropped feature in X.5 is Classic. There’s no doubt about that. As Apple already dropped that feature on Intel in X.4 that doesn’t come as a surprise. At a much smaller scale we also find changes. Most annoyingly from my point of view is what Apple did to the way old files are displayed: Most of them are supposedly of type ‘Unix Executable’ and carry an icon to support that. Usually these are files for which I currently don’t have matching application on my machine. And they are files with properly defined file type and creator metadata. The sheer existence of the latter should give a strong hint about them not being Unix executables. But rather they are things like Maple files from when I was a fresher or - most enragingly - System 7 sound files.
I have a treasured collection of silly System 7 sound files which I collected over the years and always took with me. They always worked and have always been a pleasure. (One time I freaked out a colleague because I had put HAL saying I’m sorry Dave, I’m afraid I can’t do that
in the Shutdown Items folder of my computer at work. He needed to use it over the weekend without knowing about that… and thus had a memorable experience.) And in friggin’ X.5 they have suddenly been degraded to ‘Unix Executable’ status. Argh! Even worse, not only did Apple stop displaying proper icons for files of their very own file format, they also removed the ability to play these files easily despite the functions for that still being in the OS.
I’m annoyed. Now I’ll have to convert them to AIFFs or something. Just that the system doesn’t give me a simple way to do that. (File Juicer seems to be able to the necessary conversions.)
Don’t get me wrong. If it’s old technology and they think the OS is better off without it, fine. Then they should drop it from their code base (which they didn’t). But they should be upfront about it. They should make a list of things that used to work but won’t work in the new release. And, for good style, they should offer pointers at how to resolve the newly introduced incompatibilities. (No, I don’t care how well that would go down with marketing, thanks.) In fact, that list could easily be more relevant for people wanting to actually use the new software than the list of newly introduced features is.
Spelling
It appears that Apple’s spell checker still dislikes non-trivial strings. At least I can get it - and the applications using it to stall by editing those. Amusing. Particularly as Safari tends to stall for a minute or so and then tells me that it couldn’t find the spell checker. Which is neither user friendly nor correct.
Admittedly it’s like shooting fish in a barrel, but obviously the grammar checker is good for laughs as well. Particularly in the way it comments your mistakes via non-localised tool tips.
Not only is this particular message quite silly. ‘Sentence fragment’, WTF? I also quite dislike the ‘this may be’ part. The software is so unsure of what it’s seeing here that it can’t give any definite answers. Usually if computers can’t give definite answers, it tends to mean that they are wrong or will at least look stupid in a large number of cases. They’d be better off shutting up or admitting they don’t know anything in those cases. But - huh! - This may be a screen with some text on it.
In fact this reminds me quite a bit of notifications as you see them in Windows. And even when they are bad, Apple do better than Microsoft: Apple use ‘may’ where Microsoft use ‘might’.
iChat Agent
I shall write a more detailed entry on iChat and all its cool new features as well as missed opportunities soon, but this is more of a tidbit. Somehow iChat’s background helper application, iChatAgent, has a severe form of memory incontinence. After a week or so it will have gobbled up loads of memory. I had cases with hundreds of MB of ‘real’ memory and more common cases with a few GB of ‘virtual’ memory. That can be solved by quitting the application using Activity Monitor. Which at least in the ‘real’ memory cases is advisable as it may reduce the degree of swapping hell that OS X presents.
A less amusing fact can be observed by curiously running the leaks tool on the iChatAgent process. In most cases you will be able to find your AIM password in the leaked memory blocks. Looking it up like that might be faster than opening the Keychain Access application to find it there. How convenient!
Memory
All through the history of OS X we have been told that it comes with this magic memory management which solves all the problems we had with memory in older system versions. Most notably because of memory protection which keeps applications from screwing up the whole system.
And while that may be true technically, I keep finding that OS X memory handling isn’t particularly good. Perhaps I had good karma going with OS 9 in the old days, but I didn’t have excessively bad problems with applications crashing the whole machine - even though that was technically possible. In fact, after trying to write my first own Toolbox based application (to make things worse I tried this at a time when I didn’t even know that pointers existed) and noticing how extremely easy it was to crash the whole machine just because you didn’t check a return value, I started to have great respect for real programmers. Because of the conceptually weak memory management of the classic Mac OS, application programmers had a huge responsibility to carry because their applications had to be really careful when handling memory. And most of the programmers made an effort to take that responsibility seriously.
Then came OS X. It changed the game completely. Even complete programming klutz like myself could now easily fiddle around and program stuff. Because no matter how stupid our programs were, the system’s ‘space age’ memory management would ensure they didn’t do any worse than killing themselves. As a consequence - this is my conjecture anyway - people don’t program as carefully anymore. The punishment for being more sloppy is negligible while programming and much lower when the application is running on a user’s machine that it used to be. Sure, crashes aren’t nice but they’re not as bad as hosing the whole machine.
Furthermore, application memory usage exploded in OS X. Or rather, thanks to Unixy memory management you (or at least I) can only guess how much memory an application uses - and in whichever way you look at it, the numbers are enormous. You get a number for ‘real’ memory used and one for ‘virtual’ memory used. Then there’s also a number for ‘private’ memory. Common wisdom seems to be that the ‘real’ number is the one to look for. But somehow that number can also change thanks to swapping while the application doesn’t do anything.
Because of OS X’s unixy side being all virtual memory happy, there seem to be very few efforts made to even control memory management from the side of programmers. I know I don’t. And in many places it’s not even clear to me how that would be done realistically. As a consequence, any application thanks to errors in the software can gobble up around 4GB (actually more like 3,4GB) of ‘virtual’ memory. Personally I have seen that both Sandvox (seems to be solved since version 1.2) and versions of Coda (most likely a leak coming via WebKit via Quartz Composer) and in both cases the applications’ authors tried to be helpful but ended up not being able to help or fully understand the problem because they didn’t even have full knowledge or control of the memory used by their application. Such is the beauty of complex frameworks.
Interesting question to ask: What does happen when an application runs out of virtual memory space? How well does it handle the situation? Can it recover from it? Well, I usually had to force quit the applications in that situation.
But in a way that wasn’t the worst thing. Because the dirty secret hiding here is that an application gobbling up that much RAM totally imbalances OS X’s fragile memory system. Even after killing the offending application, things will be so sluggish thanks to swapping that most likely a fresh restart will be less painful than all those moments where you have to wait five seconds for a menu to open or the Dock to magnify. That really is an ugly side of OS X. And it should be improved. For example, my system had been running for a week or two recently and it just became to sluggish overall to be fun anymore. Even quitting applications didn’t help. And a look at my memory stats and swapfile folder gave this:
Let’s just say that I thought this was a bit too much. If the OS really were half way as magic as people claim it is, it would just do a better job of cleaning up its swap files after itself, it’d also make an effort to keep all code that’s essential for the system’s responsiveness at hand. Particularly when there is a lot of free memory around. And at that stage I also start thinking about the space on my hard drive. Why is that much of it used for swap files and that sleep image thing? Couldn’t all of that be handled somewhat more cleverly?
Even if that is considered ‘stone age’ technology by many these days, the fact that you had to ‘reserve’ a certain amount of memory for applications in the classic Mac OS had the advantage that a clear limit of memory usage was imposed and that programmers had to worry about the available memory. I didn’t see hard drive thrashing as I regularly have it today back then. If memory was becoming scarce, I was just told I have to quit some applications. Of course we won’t get that simplicity back today, particularly as the engineers decided that it’s more efficient to throw dozens of extra megabytes per process at the programmers’ convenience and pretty much every Mac application is a memory hog these days as a consequence. I wonder how many GB of RAM I need to not suffer from these problems.
And why TF are my swapfiles claimed to be of a ‘plain text’ type?
Dictionary
The Mac’s included Dictionary application saw a nice update with X.5. Not only is it now officially documented how to make dictionaries of your own and how to access the system’s dictionaries from your applications, some people published examples for home-made dictionaries already.
Even more interesting: X.5 also ships with a Wikipedia dictionary built it. It defaults to use Wikipedia in your preferred language but you can activate other languages as well in the preferences. Unlike many other parts of Mac OS X.5 which ruthlessly establish connections to the internet without even letting you know, the Wikipedia dictionary plug-in shows enough respect to the user to warn him that the internet will be accessed when using the Wikipedia dictionary.
An opportunity that Apple missed with this is to include Wikipedia’s nice feature to quickly switch between entries in different languages for the same term. I frequently find this helpful. Both as a mock dictionary and because there can be considerable differences between the entries in different languages. Getting that right might be hard to implement, but it’s just the difference between ‘well done’ and ‘great’.
Another addition to the Dictionary is a Japanese dictionary and an English-Japanese one. Which is great. However, it emphasises even more the fact that Apple just ignores all the other languages their system pretends to support. They kind of localise it for a number of other languages. They even charge higher prices for it outside the US, yet they don’t even fully support the languages. That much about illusions of every supported language being a first class citizen in OS X. The fact that Apple decided to localise the file name of the Dictionary application in German X.5 to be Lexikon
(encyclopædia) rather than ‘Wörterbuch’ suggests that there aren’t any plans to add a German dictionary later on either (or that Apple’s planning skills are bad).
Finally, it appears that the image files in the built-in English dictionary still exhibit encoding problems in this version:
