>A uudecode utility must have the following attributes to be usable with
>NewsWatcher:

Sounds like I already got most of them last night!  I'll mail you an alpha
version later today for your preliminary evaluation.

>No splash screen or registration dialog or other display that the user must
>dismiss, at least not when launched with an ODOC event.

Check.

>No standard file prompt for destination file name and location. Use the
>file name from the uuencode header line, and put the decoded result file in
>the same folder as the input file.

Check.

>Append digits or something if necessary to guarantee unique destination
>file name.

Check.

>Launchable in background. Do not assume you start out in the foreground.

Check.

>Use Notification Manager properly if you are in the background before
>presenting error alerts or other dialogs.

Check -- right now there *are* no error alerts or dialogs. (This may change, of
course :-)

>Must be drag-and-drop, of course: Drop a text file on the utility, and it
>decodes.

Check.

>Must be able to accept additional ODOC events while busy, and queue them.
>In NewsWatcher, if the helper app is already running, I just send it an
>ODOC event. I don't queue them up at my end. This is important, for
>example, if a user extracts binaries from several articles at once in a
>subject window. In this case, I will likely be creating temp.n.uu files and
>firing ODOC events at you faster than you can process them.

I think this works, but will check it.  All WaitNextEvent() calls during the
processing have an event filter of (everyEvent - highLevelEventMask), so things
should queue up in the OSEvent queue until I get back to the main event loop.

>Must delete input file after successful decode, or at least offer this as a
>configurable option. If any kind of error occurs during decoding, however,
>the input file must not be deleted.

Not done yet, but planned as an option.

>Must be able to handle multiple-part uuencoded text with intermixed headers
>and other junk, with or without the special "flag lines" indicating where
>the parts begin and end. You can, however, assume that parts are in the
>correct order.

Check.  (This was one of the really cool features of my unix version :-)


>The following attributes are highly desirable:

>Should quit when finished if launched with ODOC event.

Check.

>Should have configurable preferences for file name suffix -> file type and
>creator mapping. (I did manage to convince Leonard to make JPEGView the
>default for gif and jpeg files in Expander, by the way. With Expander, you
>have to attack StuffIt Engine with ResEdit to change this mapping.)

Not yet, but planned.  At first, I'll probably just do something similar to the
Stuffit Engine until I have time for going all out.

>Should run like a bat out of Hell in native mode, of course. :-)

Check -- faster than Leonard's, even :-)

>Should call WaitNextEvent every 4-6 ticks while busy, no more and no less,
>to cooperate well with other apps.

I'm using a sleep time of 3 ticks while busy, and making sure I don't call
WaitNextEvent any more often than every 2 ticks.  It *still* runs like a bat out
of hell, though.

>Should *not* slow down when run in the background.

Check.

>A progress dialog is fine, but handle update events properly and reasonably
>quickly. Movable modal progress dialogs are best.

Check.

>Should move the decoded result file to the same location in the Finder
>window as the input file after deleting the input file. This makes dragging
>and dropping from NewsWatcher to a Finder window nicer, because the final
>decoded file ends up where you dropped it.

Hadn't thought of that, but it's a good idea.  I'll put it in.

Thanks for the checklist -- it makes my job a lot easier.  Maybe you can even
distribute my app with NewsWatcher if you like it enough.  I don't really care
what you do with it; I'm writing it for my own reasons, anyway :-)

Aaron