tedd wrote:
> What you describe, or rather what you are doing, is fine the way you're
> doing it if it rings your bell. However, if I were the user, I would want
> an application that wouldn't tie my machine up so that I couldn't do
> anything else. I would want a multi-task application.
> 
> I think the term "prettier" is in the eye of the beholder. Prettier to me
> means that the user is allowed to do anything he/she is accustomed to do
> with my program as with any other program; and that my program functions
> under the normal and customary user interface guidelines. I don't want my
> program to be the exception.
> 
> When I see special Macintosh applications that don't follow the normal user
> guidelines, then they don't seem pretty to me. In fact, I become very
> critical in reviewing other programs, which some on this list can testify.
> 
> If your program serves its purpose and your client is satisfied with the
> results, then fine. But, I claim that every Macintosh program can do that
> and still adhere to the Macintosh way of doing things.

Hmmm...I must have given you the wrong impression of what my program's
doing.  As far as I can tell, it _does_ adhere to normal user guidelines
and to the Macintosh way of doing things.  It's a bit unusual in that it
can take several hours to complete its processing, but it does _not_ tie
up the Mac while that's going on.  Once you've supplied the parameters
to get it started, it puts up a progress window.  You can then, if you
like, switch to another app and do other stuff while my program
continues processing in the background.  You can switch it back to the
front occasionally, if you want to check its progress (or cancel it). 
If my app finishes while it's in the background, it beeps and displays a
flashing icon on the menu bar, to notify you.

It would be even nicer if it could process two or more sets of files
simultaneously; but, for reasons which I won't go into, these particular
files need to be processed sequentially.

My point was not about the _user's_ experience--I certainly wouldn't
sacrifice the UIF guidelines to make my life as a programmer easier
(unless I was hitting a deadline :-)).  My point was about the
_programmer's_ experience--that the
"single-event-loop-that-calls-everything-else" model is not _always_ the
best way to implement a standard, event-driven, Macintosh-style program.

- Rick