-----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 (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
