Re: Progress Indicators Spin vs Bar
Re: Progress Indicators Spin vs Bar
- Subject: Re: Progress Indicators Spin vs Bar
- From: Conrad Shultz <email@hidden>
- Date: Mon, 20 Jun 2011 12:05:16 -0700
-----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-----
_______________________________________________
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