njr 3.0

A Mac OS X Hints article points to Still Life, which creates movies by panning, zooming, and fading between images. All of Granted Software's products are donationware, and the few I've tried so far (Still Life, USBMonitor and iMIDI) are amazing and truly useful. iMIDI uses TCP/IP as a MIDI transport and supports Rendezvous; USBMonitor pops up a translucent window when you plug in a USB device.

12:10 PM | Radio
No Comments

A few tips for dealing with broken Installer VISE installers, which
I discovered this weekend while upgrading my PowerBook to Jaguar:

Does the installer require you to authenticate? Delete the contents
of /var/root/.Trash to reclaim space on your hard drive after
the installer has finished. Installer VISE correctly moves files to
the Trash instead of deleting them outright, but unfortunately it's
root's Trash. My PowerBook had 85 MB of files in
there, primarily old copies of Office X components.

Does the installer quit all open applications for you? The FaxSTF
10.0.8 and Office X 10.1.2 updaters want to, but there's no point
doing so under OS X, as you can relaunch applications as the installer
is working and create the same problems that this action is designed
to work around. Instead of clicking Install, open Script Editor and
type this script:

tell application "Office X 10.1.2 Update" to DoAutoInstall

Replace “Office X 10.1.2 Update” with the name of the broken
installer. Then click Run, and the installer will execute without
quitting any applications. Make sure you quit the applications you're
upgrading, however. [This tip courtesy Rosyna].

4:32 PM | Radio
No Comments

I've been looking for a good-quality 2D graphing engine for my instrumentation results that, uh, isn't Gnuplot. Moth looks very promising; I'm going to play with it tonight.

3:22 PM | Radio
No Comments

I've been incredibly busy recently, and my workload shows no signs of lessening until after my medical genetics final on the 15th. Thanksgiving break was wonderful, though too short as usual.

In the last few weeks I've been porting my instrumentation overhead analysis code from C++ to Python and MetaKit. The Carbon ports of Tk/Tkinter and especially GNU Emacs have improved to the point of usability, so in the last week I've moved my primary working environment from one of our group's Linux clusters to my PowerBook and desktop G4. I still need to use Linux for testing, but being able to do development in a Mac environment without needing X11 is great.

MetaKit, with its Python binding Mk4py, is a flexible, simple and easy to use embedded database. There's even a SQL implementation implemented on top of it. The other database I considered was SQLite, which is a lot more featureful, but I dismissed it because it stores numbers as strings. The one problem I've run into with MetaKit has been its lack of support for Unicode strings—which I luckily don't need but which the xml.dom.minidom parser loves to return.

From a mailing list post today I discovered pyrepl, which provides some very useful enhancements to command-line editing in the Python interpreter.

11:24 AM | Radio
No Comments

Last Thursday's post complaining about the Mac OS X Finder attracted a bit of attention. At the time I had been sufficiently delayed in my work by Finder failings already, so I took the screenshot and posted a teaser regarding the problems I noticed. The message appeared as I was trying to move applications from my tiny, supposed-to-be-temporary-pending-reinstall-which-I-still-haven't-done Jaguar startup disk to another disk in order to make more room for swap files (currently occupying 547 MB in size on the 2 GB volume; despite having 896 MB RAM, I think I need more).

Here is my list:

1. The alert message is poorly written. To use Apple's own interface guidelines on the subject, it doesn't use the user's vocabulary (what are “special permissions”?), and doesn't mention what the user can do to get ouf of the situation (what if the user really wants to move the item?).
2. The message doesn't mention which items have the permissions in question, or even how many items have those permissions, when the Finder is obviously aware of which items are problematic, and the user probably has better things to do than check every single one (especially when application packages are involved).
3. Moving items across disks/volumes consists of two phases: first the items are copied, potentially overwriting files in the target; then the items are removed from the source. The user is not necessarily aware of this, and referring to the operation as a “copy” (in the window title, and the alert message) is confusing.
4. It's unclear whether the items with the special permissions are located at the source or destination: the message should be specific: “cannot be read”, “cannot be moved/removed from X”, “cannot be overwritten”. The answer can be inferred from the “copy” terminology used in the message, but again, you need to understand the mechanics of how a cross-volume move is performed.
5. The alert message asks a yes or no question (buttons should be “Skip” and “Cancel”), yet provides only one option (the ever-helpful “OK”), which doesn't give any indication of what will happen.
6. Assuming you consider “OK” to be the equivalent of “Skip”, the Finder doesn't skip the item: it moves nothing instead. This makes it very difficult to isolate the item, because you need to move each item in turn until you find the one with the message, instead of all but the problematic item being successfully moved.
7. Various visual anomalies: extra space below inactive scroll bar, progress bar and alert icon bizarrely positioned, button and text spacing apparently random.

Some examples of moving and privilege conflicts, including reproduction recipes as requested:

% mkdir test test/from test/to test/from/a test/from/b
% chmod 700 test/from/b ; sudo chown root test/from/b
Password:
% open test

Move (Command-drag) the contents of “from” into “to”. You'll get a message that reads “Preparing move to 'to': The operation cannot be completed because you do not have sufficient privileges for some of the items.”

Note that the folder “a” has already been moved to the “to” folder. This is inconsistent with the status message “Preparing move to 'to'”: obviously if items have already been successfully moved, the Finder is not preparing at all, it's actually performing the move. A preparation/preflight pass is useful, and I'm glad the Finder still performs it, so such confusing situations as half-completed copies can be avoided in most cases. Preexisting permissions which will unambiguously cause an operation to fail should be caught at preflight time.

Here's a better (though still imperfect) replacement error message:

“The folder 'b' could not be moved from “from” because you do not have sufficient privileges to read its contents.”

Ideally, the user should be given choices to (a) take ownership of the file, (b) authenticate and move the file preserving privileges, (c) don't touch the file and continue with the move, and (d) get help on the problem.

% sudo rm -rf test
% mkdir test test/from test/to test/from/a test/from/b
% chmod 755 test/from ; sudo chown root test/from
% open test

Perform the same procedure as described above. This works well: “You cannot move the selected items because you do not have the privileges to remove them from 'from'. Would you like to copy these items instead?”

% sudo rm -rf test
% mkdir test test/from test/from/a ; touch test/from/b
% sudo chown root test/from/b ; sudo chmod 4755 test/from/b
% open test

There's only one folder now; Command-drag it to another disk, and you'll see Thursday's message. Unlike in the earlier example, the “preparing” status is correct: nothing has been moved by the time you receive the message.

To people who say I should report these bugs: yes I should, but more importantly, Apple should fix this stuff internally before it ever reaches beta. There are systemic issues at Apple causing these kinds of UI disasters to happen, and identifying such problems one at a time is an inefficient way of dealing with them. Mac OS 8.5 was the last version of the OS to have any kind of consistent UI quality. The line can be drawn rather clearly: the “Index selection…” contextual menu item, one of the few visible additions in 8.6, managed to violate a bunch of guidelines (capitalization and wording) in just two words. New UI in OS 9, of which the most egregious example was Multiple Users, was no improvement. And here we are, four years later, with Jaguar continuing the downward spiral (an “Enable journaling” button in 10.2.2's Disk Utility, anyone?)

Someone should be sitting down with the OS 9 and OS X Finders, trying everything they can think of, comparing behavior, and keeping consistency where appropriate, and filing bugs. Better yet, that someone should have been the programmers implementing the OS X Finder in the first place.

For example, that it took until Mac OS X 10.2 for “replace all” to be an option in the Finder, though still not keyboard-accessible, when it was both easily keyboard-accessible and the default in Mac OS 9, is inexcusable. Who do they think has the patience to sit and click “Replace” repeatedly as the progress window resizes itself over and over again?

Similarly, the dialog box you receive when attempting to unmount a disk with files in use is completely useless, simply stating that the disk is in use. The OS is entirely aware of which application has a file open on the disk, and the name of that file nothing but some thoughtful programming stops the OS X Finder from giving the important and useful information that a user needs to fix the problem (and which OS 9 provided perfectly well). Not everyone has the knowledge to run 'lsof', and if it turns out no applications have files open, then quit the Finder as a workaround for a known bug, as I do several times a week. What do they do? Quit every open application in turn, and finally log out or reboot in desperation when it turns out that it's a DiskArbitration bug causing the problem?

That's the essence of my complaint: either the people who write the Finder at Apple have an incredibly high tolerance for flaky software, they don't use it at all, or are placed under pressure from management such that they don't have a chance to deliver quality software. Anything I write – for my own use, even – I would fix if it were as broken as the Finder is, and if it were heading for use by potentially millions of users, I'd feel incredibly guilty to subject them to such garbage.

This will be my last “OS X sucks” rant for the year. Time to affect what I can really affect instead: my own software.

11:48 PM | Radio
No Comments