Case Study 2 - Mac OS 9 page 2
Part of the file system viewers case study.
Small icons view in classic Mac OS is very strange. In Windows, the column with adapts to the longest icon name, and subsequent longer names are visibly truncated with an ellipsis until a refresh calculates a new column width.
In classic Mac OS, any time a name doesn’t fit, that space is simply skipped, leaving a very untidy arrangement:
Now, Mac OS Save dialogs do not let you click an existing file to capture its name for re-use, so I would often save a file to disc with a generic filename and rename it later. First, the new file:
Next, I would paste in the name of an existing file which I want to use as the basis for my new name:
But lo! When you paste in a new name, if it is longer than the available space permits, the icon that wants that space is drawn back over the top! If you click anywhere within the text field, the selection changes, except for if you click on the obtrusive icon, which terminates the rename process. Not only does it look like the icon is inside the rename field, the Mac even believes that it is.
Once you are done renaming, the same problem repeats itself:
Note that while in an alphabetically-sorted list view, renaming a file causes it to move to its new place in the list, regardless of whether that causes to disappear off the top or bottom of the window. In an alphabetically-sorted icon view, the icon sits resolutely at its original location and the name is not truncated. Mac OS provides no means to refresh the window so that the list order is reapplied. By comparison, Windows XP provides two methods: refresh (which does nothing if Windows thinks you’ve manually arranged the files, even if the folder is set to auto-arrange) and re-applying the sort order, which simply sorts the folder in the opposite direction.
My story gets better. Here, I have just duplicated the selected file with command-D; notice now there is now no icon immediately to its right, since there is no longer space for it:
If I rename it to a shorter name, the gap does not close back up again.
I wonder if I could make an entire column go blank …
I love the Finder. The Finder loves error -110.
Apparently it means “Address was odd, or out of range” but that sounds more like a processor exception than a filing error. I was not sure whether or not to include this screenshot, but while working on the files, the Finder got stuck in an endless loop of these and had to be killed and then the system rebooted. (“Does not compute!”)
The way the Finder handles long file comments with forced word wrap, such as addresses (very common on the Macintosh: many programs store the addresses of downloaded files into their comments) is inconsistent. Here, I have selected the entire address with the mouse, but the Finder seems to think that the comment is only on two rows:
If I click where I think the end of the text is, and press backspace, the text is visually corrupted:
Using Select All (command-A) to select the text triggers a redraw showing how the Finder believes the text is laid out:
Not quite the same.
Sorting out that third image caused GraphicConverter to crash the system. I have had more system crashes working on these pages than ever, and the culprit seems to be GraphicConverter.