Re: Progress Indicators Spin vs Bar
Re: Progress Indicators Spin vs Bar
- Subject: Re: Progress Indicators Spin vs Bar
- From: James Merkel <email@hidden>
- Date: Mon, 20 Jun 2011 13:16:33 -0700
On Jun 20, 2011, at 12:05 PM, Conrad Shultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 6/20/11 11:47 AM, James Merkel wrote:
On Jun 20, 2011, at 2:01 AM, Mike Abdullah wrote:
On 20 Jun 2011, at 09:31, James Merkel wrote:
Yeah, I just kind of avoided the basic problem. The app isn't
receiving at least some events -- for example the menus can't be
pulled down. On the other hand, the spinning beach ball doesn't
appear, and I can drag the progress window around.
Window dragging is handled by the window server so that an
unresponsive app can't affect it.
Upon further investigation I see that the beach ball does finally
appear.
I guess the question is, what is the definition of unresponsive? An
app
will always have short unresponsive periods when it is doing
something.
Disclosure: I haven't really been following this thread (no pun
intended) so I apologize if some of this has been said or is not
applicable.
"Unresponsive" means the main thread is blocked, i.e. it's not able to
process events (e.g. keystrokes, clicks), update the UI, or even
respond
to a SIGTERM (hence the "Force Quit" - SIGKILL).
Of course every action on the main thread takes SOME finite amount of
time, but the idea is that a well designed program offloads any tasks
that could potentially take a perceptible amount of time onto a
secondary thread so that the main thread can proceed, the run loop
turns
over, etc.
There are certain situations where either processing must occur on the
main thread (classes in AppKit or UIKit that are designated
non-thread-safe come to mind) or where a task cannot logically proceed
until a task is completed (for example, if a data model needs to be
loaded in order for the app to be useful). In such cases, at a
minimum
you want to have a progress indicator so that user doesn't think the
app
has crashed. You should also go to great lengths to try to still
offload such activity so that you can have the main thread handle some
UI to allow the operation to be canceled if it's taking longer than
the
user wants (think of the "Stop" button omnipresent in every web
browser).
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.
I would say that if a procedure can potentially take a perceptible
amount of time, go ahead and display a progress indicator. If it's so
quick that the user doesn't even see it, so be it. Check out how web
browsers do it... even going to http://localhost in Safari or Firefox
shows a progress indicator for a fleeting moment.
I don't really understand what you mean by "a waste." It would be
_more_ code to conditionally display an indicator, and in the case
where
you would consider not putting one up it follows that you can't be
taxing the processor too much, so it's not like you're going to be
slowing things down appreciably.
- --
Conrad Shultz
Synthetiq Solutions
www.synthetiqsolutions.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk3/mewACgkQaOlrz5+0JdV9BwCcCv7VwQkBf3/TJO+rMVh/hbW7
IKgAoIiyiflPyQ2DL/GPzgwXP2IK58iA
=Z5g/
-----END PGP SIGNATURE-----
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.
Thanks,
Jim Merkel
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden