On Jun 20, 2011, at 2:05 PM, Greg Parker wrote:
On Jun 20, 2011, at 11:47 AM, James Merkel wrote:
Another question -- when should a progress indicator be put up? The
length of time in my processing loop can very greatly. I could be
processing 3 files or 300 files. It seems a waste to flash a
progress indicator for very short processing cases. On the other
hand I can't just set a threshold for putting up a progress
indicator, since the processing period can very from one machine to
another. Also the processing period varies for different file types
and even varies on the same machine from run to run. No obvious
answers to some of these questions.
One solution is to simply start the operation with no displayed
progress, then later show the progress if it has not finished in X
seconds.
(Programmatically: schedule a one-shot NSTimer for X seconds later
that starts showing progress when it fires. When the operation
finishes, cancel the timer if it has not fired already. Do this both
of these on the main thread to avoid thread-safety problems.)
Your app will feel faster if short operations appear to finish
"instantly" instead of briefly flashing a progress bar. File
operations in the Finder do something like this.
On the other hand, you should always show progress if the operation
has no user-visible side effects. Nothing is worse than displaying
nothing and leaving the user to wonder whether it did anything at
all. In this case you want the finished progress bar to appear as a
confirmation to the user for at least some minimum length of time.
True it's extra code to conditionally display an indicator, so I
may as well always display it.
The bigger problem is putting the long process into another thread.
Need to delve into that.
Yes, the work thread will be the hard part. Polishing the progress
UI should be straightforward after that.
--
Greg Parker gpar...@apple.com Runtime Wrangler
I hadn't thought of that -- putting up a progress indicator after a
short passage of time. Sounds like a better way to go.
I am trying to come up with a way of not using threads (because of the
potential problems). All I really want to do is give the user a way of
canceling the long process. I was thinking of just sampling a cancel
state variable every time through the loop. Of course that introduces
overhead, and there's the possibility the user cancels on a
particularly long duration loop cycle and wouldn't quickly see a
response to his cancel. I would think there is some simpler method
than using threads for handling this fairly common situation of a
handling a long process.
Jim Merkel
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
