Why the heck can't I download drivers?
Plus: why Finder needs Carbon, and synching Palms
Learning to live with Mac OS X Epson went down in my estimation this past weekend for not posting OS X printer drivers on its Web site. They're all there on the Mac OS X 10.0.0. CD for you, warbles the cheery Read Me page, to make installation easier for you.
Oh no it doesn't. The OS X 10.0.0 CD won't let you install the printer drivers without also installing the OS. Just go to the Customise Installation panel and see what I mean - the base Mac OS X system checkbox is disabled. Now, Apple may have written the new OS X software installer to detect that I'm running OS X 10.0.4 and so not overwrite any essential files with the older, potentially incompatible 10.0.0 versions that it knows about, but I don't want to risk it. I've zapped too many systems in the past by making that mistake.
To be fair, the fault here is really Apple's for preventing you from running the OS X installer at a later date to add printer drivers or the OS' BSD sub-system that you didn't think you needed first time round.
I can easily imagine Apple's response to that: just install the drivers anyway, since you never know when you're going to need them.
Sorry, but that argument is akin to that old claim that it doesn't matter how big your operating system and applications code is, since hard disks have more capacity than you'll ever need. Apple used to grumble enough about Microsoft using that line, so there's really no excuse for using itself now. However capacious my hard drive, I don't want it filled up with files I don't need - even if I might do one day.
Which is why I look to the printer manufacturer's Web site - just as I would if I were looking for driver updates. There's no reason whatsoever Epson shouldn't offer existing drivers for download apart from ducking the responsibility for support. Either way, it's pretty lame behaviour.
Epson's excuse: "By providing the printer drivers in the CD-ROM we made sure that only the latest drivers are available to our customers."
Hang on a minute, Epson, isn't that THE WHOLE POINT OF WEB DOWNLOADS?
Still, Epson isn't alone here: Canon doesn't offer downloads either.
Hewlett-Packard is the very honourable exception, providing not only driver downloads of existing but a notification service that promises to email you when updated software is posted.
So how, then, can you install a new Epson printer on an existing, updated OS X system? Actually, it's quite easy. I used Marcel Bresink's excellent TinkerTool, which among other Finder and Dock enhancements, will also force Finder to display hidden system files. Then, it's just a matter of locating and launching the appropriate .pkg file off the CD, doing the driver install, and plugging in your printer.
The files are in System/Installation/Packages directory on the Mac OS X Install CD.
Incidentally, the installer also installs lots of Hewlett-Packard and Canon printer drivers. They all end up in Library/Printers/ where they can be dragged to the trash and removed.
Palm Syncing sorted
I moved another step closer to running an OS X-only system this weekend having figured out how to synchronise my Palm Vx without having to reboot into OS 9.
I'd been dreading trying this out after the number of problems other users seem to have had, according to old MacFixIt postings, at any rate. In the end it proved a fairly straightforward process - not as simple as OS 9, but by no means complicated either.
Run Classic, keeping your extensions on. Next, run Conduit Manager (the version that comes with Palm Desktop 2.6.1 - the upgrade is on the Mac OS 9.1 CD) then press the Hotsync button on the Palm cradle. Your data will be synchronised and backed up, and any apps earmarked for installation on your Palm will be. Don't just hit the Hotsync button - it'll activate Conduit Manager but the two will drop the connection before the sync is complete.
OK, I admit it, I was wrong when I said you can't drag apps, AppleScripts and folders into the Finder's toolbar - you can. I'd tried to do so while running the Customise Finder Toolbar command, which only lets you drag tools from the palette provided. As a number of Register readers pointed out, though, you can drag files into the toolbar when you're viewing a regular Finder window.
Both methods make sense, but they really should be better integrated. Two separate approaches - one for standard toolbar elements, another for adding other elements - is just plain confusing, as my own error shows.
Light is green, screen is clean
I got some complaints for my suggestion that Aqua's green 'traffic light' button should expand windows to fill the entire screen as per Windows' Maximise button. I damned the green button for only growing windows to some "arbitrary" size.
Back in your box, laddie, said my more irate correspondents. The new window size isn't arbitrary. Click on the button and windows expand as much as they need to show as much of the contents as they can.
A fair point, perhaps, if the green button's behaviour were consistent. It isn't. Sometimes apps remain hidden, and it always fails to deal with toolbars that are wider than a window maximised to show all the icons (having to click on little arrows to get the missing toolbar buttons is just so Windows). And few programs - including many of Apple's own - take into account the Dock when maximising their windows, making it difficult to access Dock-blocked widgets and content.
I suggest a compromise: Option-Click for full-screen expansion, mouse-only for tradition Mac OS 'maximisation'. All we have to do now is figure out how to persuade Apple to add the compromise to its human interface design regulations.
Certainly Apple seems more on my side on this one. Says Inside Mac OS X: System Overview: "Mac OS X eliminates the problem of proliferating windows by focusing the activities of an application in a single window." In other words, it's all about eliminating screen clutter, which is exactly why I'd like to see full-screen Window maximisation. Each to his or her own, and Aqua should be capable of working with everyone's preferred modus operandi.
Finder needs Carbon?
Now here's a thing. Apple's Mac OS X documentation states that when the Finder copies a UFS [ie. native Unix] file to an HFS or HFS+ [ie. native Mac OS] volume, it ensures the integrity of the Mac file's resource information.
Essentially, HFS/HFS+ stores file information such as icons, pictures and data - in a separate unit called a 'fork'. Unix doesn't support forks, so when you copy a Mac OS file to a UFS-formatted disk, Finder creates a separate file to hold that data. Copy the file back and Finder reintegrates the two files into a single one containing two forks.
Now here's the really interesting bit from Inside Mac OS X: System Overview: "Note that the Finder accomplishes these operations through the Carbon APIs on which it is based".
Is this the reason Finder was coded in Carbon not Cocoa? Does Cocoa not support forked files, since it expects application resources to be bundled up as discrete files in a folder?
I think we should be told...
To be continued...
You can download TinkerTool 1.32b here