uuUndo/uuUndo & NewsWatcher.TXT

1 line
3.9 KiB
Plaintext
Raw Normal View History

2015-02-06 08:56:41 +00:00
>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