uuUndo/uuUndo & NewsWatcher.TXT

1 line
3.9 KiB
Plaintext

>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