Actually I would like a kind of milky overlay for a busy window with a big "startup spinner" or whatever that new busy symbol is called. Have that symbol sit over the window since it's useless while it's busy.
But leave the cursor an arrow. It would really help avoid that "I lost control of my computer" feeling that the rainbow cursor creates.
The "other OSes have busy cursors too" argument sucks since I want Mac OS X to be better than the rest, not the same.
So, just as sheets are a nice new addition, avoiding the modalness of the old error dialogs, we could have a window/app specific busy sign without affecting the actual cursor.
Perhaps current technology wont allow this, but it would be nice if OS X could recognize the difference between a process that has become "stuck" and a process that is momentarily busy. If it could, then the current (or modified) beach ball could be used for the "momentarily busy" situations and a force quit dialogue box option could come up if the process was stuck. I realize this is probably what happens what an application crashes, but still it would be nice if OS X could better determine this.
Today I had an issue where Final Cut stood busy for almost a minute when opening a project file and updating it to the latest version. The beach ball is typical for a second or two, its only when it lasts longer that I begin to wonder it the program has "effectively" crashed. In this case I simply force quit the program and opened the project again and problem solved.
What I am frustrated with is the fact that this same thing can happen when opening windows. Why? You would think that a DP2.5 G5 with 2GB RAM would have the processing power to open ANY window instantaneously at any point in time, but especially one with only a few files in it. Yes, this happenes in Windows occasionally. But, being someone who uses my Mac and PC about equally, I would say that it does happen more on my Mac (and my Mac is faster than my PC).
At any rate, no one has answered the original poster's question... Does Tiger (at least the beta) help this situation at all? I would definately say things have improved since 10.1 (when I started using OS X), so hopefully Tiger (and other future versions) will continue on with this trend.
the finder has slightly better threading in tiger, but otherwise no. rainbows are everywhere :P
Agreed, I installed the latest seed that I acquired questionably through those Internets and I?m still seeing the, ?I'm stuck on stupid syndrome, spinney rainbow wheel of death?. I?m not talking about normal, wait I?m loading something, it?s more of a, ?I?m out to lunch, be with you an hour? like I got in Panther?. So the problem is still there, for me anyway, but we got a lot more features to play with though.
Actually I would like a kind of milky overlay for a busy window with a big "startup spinner" or whatever that new busy symbol is called. Have that symbol sit over the window since it's useless while it's busy.
That's a really good idea. It will really help the newcomers know what's going on, as well as advanced users. However, if it's only a few secs it should be the rainbow!
Perhaps current technology wont allow this, but it would be nice if OS X could recognize the difference between a process that has become "stuck" and a process that is momentarily busy. If it could, then the current (or modified) beach ball could be used for the "momentarily busy" situations and a force quit dialogue box option could come up if the process was stuck. I realize this is probably what happens what an application crashes, but still it would be nice if OS X could better determine this.
Not for nuthin', but there is a proof in computer science that such a thing can never be programmed. It's called the Halting Problem.
I'm still trying to get to the bottom of this beachball problem. I don't think most apps are really "busy" when that happens; I think, since this is a kernel-level cursor, that the app is waiting for something and isn't responding to the window manager. Apple never addresses it at WWDC.
The beachball means the app hasn't come up for air for 5 consecutive seconds. It's nearly impossible for the OS to tell for sure if an app is in a buggy loop or making progress on a legitimate, lengthy task.
My two experiences with the beach ball both arise from the app waiting on the OS for something.
By far the most common for me is when an app hits swap hard ( omniweb does this a lot, I think it keeps a window open for every web page tab - uses a heap of memory ). When Im running omniweb I can easily have it take a minute to swap in after Ive been working in another app - beach ball all the way. Then as you use it, all of the menus and things get swapped in on demand - more beach ball.
The second is when an app is trying to perform some network activity. Im not sure what the timeouts for networks are in OS X, but it is certainly in the minutes. The Finder in particular, can take ages to deal with network timeouts.
Both of these situations can provide better user feedback. In the first case the OS can inform the user that their machine is running slowly because they dont have enough memory ( and give an option not to show the warning again ). It could also use a different cursor ( or at least provide the ability to use a different cursor ). Menu Meters is a life saver, if I get the spinning beach ball and MM is showing lots of disk IO I know its typically swap activity.
In the second case the OS knows that the program is blocked waiting on some IO that is taking a long time with little activity. It could alert the program, letting it provide an option to cancel, or a timeout indicator. The idea of putting a dialoge on the window is great - a big gray mask, saying "Finder is currently accessing the network. This will automatically end in 2:36 minutes if no response is received, or you can [cancel] now."
Kickaha, yes the SBB is feedback, but it is typically insufficient. Its like telling a user that "An error has occured." Its a last ditch fall back position, only to be used in rare cases, so that at least the user knows that their computer is still working. 4fx's issue with Final Cut Pro is a good example. FCP should provide a progress bar for opening a file, not the SBB. Using the SBB might be easy for the developer, but it isnt user friendly. This is the sort of thing that experienced users ( aka developers ) ignore, because they know the system too well.
4fx's issue with Final Cut Pro is a good example. FCP should provide a progress bar for opening a file, not the SBB. Using the SBB might be easy for the developer, but it isnt user friendly. This is the sort of thing that experienced users ( aka developers ) ignore, because they know the system too well.
FCP actually does have a progress bar for updating files like this, the beach ball typically only comes up when the program has hung during this process (which is too often). Its strange really. But typically force quitting and repeating the process is successful.
I like your idea of a using a processor monitor for this. In my case, I already know that this process doesnt take much processing power, so if the beach ball comes up I immediately know that something has gone wrong.
Just had an idea... someone (if Apple hasnt already done it) should make a widget for a processor monitor and other system monitors. For me I dont like having things like that open all the time and cluttering up my desktop realestate, but using dashboard for it would be perfect!
Just had an idea... someone (if Apple hasnt already done it) should make a widget for a processor monitor and other system monitors. For me I dont like having things like that open all the time and cluttering up my desktop realestate, but using dashboard for it would be perfect!
Got to be careful here, as there is an element of "be careful what you ask for". Sometimes the computer just can't tell why something is stalled up fatally or just stalled up momentarily. Just keep an eye on the processes in your Activity Monitor when you got the computer running hard with "stuff" next time. A lot of times you will see it report something is "hung" (like Safari, to take an example), when you most certainly know it is not hung. It is just taking its own sweet time on something. This does not dismiss that there are also times where it really is hung. Then Safari may finally finish its task, and the Activity Monitor revises it as "running" again (Well, which was it??? Was it really hung or not?). The point is, many times the state of being hung indefinitely or just a few microsec (or anywhere in between) is utterly indeterminant to the computer. The user has an idea, but only because being an organic sentient with relatively unlimited "TFLOPs", fuzzy logic, and intuition to bear on the matter does have a "few" perks.
So what good will a "different" kind of spinning ball really do? Sometimes it may be indicating something is really messed up, and just as easily, may be reporting something entirely erroneously. So the user has yet one more source of confusion or possibly bad information to form an assessment of what is really going on. You can bet they will conjure up various false conclusions, subsequentally. ...like they may conclude that OSX is very buggy and crashy because they get the "hanging man" icon all the time, but actually they are running far too little memory for the way they use their computer. It's just a single example, but you can see how the notion of a "more descriptive" icon can easily result in more misinformation, ironically.
You could go a step further and do like Windows did for a while. It tried to be "smarter" and happily "force-quit" all those processes it thought was hung-up, instead of burdening you with this management chore. What happened? It ended up aggressively flushing a lot of perfectly fine processes (albeit, momentarily delayed, but certainly still "running") along with the ones that were really crashed. So the user gets the impression that either much Windows software is hopelessly buggy or the OS itself is ridiculously flakey. This is no small matter when Windows decides to flush out your app that you had some important stuff running (that also "looked" like it was hung to the computer). Your app didn't really crash, Windows just "thought it did", and took the liberty of flushing it out for you. Nice, right? What all this means is that making the system more "pre-emptive" about things can just as easily end up biting you as it can help you. Sometimes it is better to just let it handle things on its own terms and "appear dumber".
OmniOutliner (and perhaps 'Graffle too?) have a nice feature that pops up a nice little busy dial thingy and a status message over the window's contents.
Now, if Apple could de-couple the busy indicator from the actual cursor, it would go a long way in making the user feel like they have not lost control of the entire computer. (Mind you, OmniOutliner also will put up a spinning beachball, but that's the OS's fault).
Apple pioneered tying the busy status feedback to the cursor but I feel that that is antiquated now.
A per-window, or per-application (if the former is impossible) overlay indicating busy-ness would be great, similar to how sheets free us from modal dialog boxes.
Simply have the cursor remain the arrow no matter how busy or frozen the app is. Let its status be known from some other context.
Spin Control is an application that helps you identify why an application might display the spinning rainbow wait cursor. It automatically samples any application which appears unresponsive to the Window Server.
Now if we just knew precisely what "unresponsive to the Window Server" meant, we'd have a better understanding. When CoreGraphics puts up the spinning cursor, the cursor is usually tied to one app; you can still switch to other apps and the cursor only changes to spinning when over a window or menu bar belonging to the "unresponsive" app. Of course, Mach continues to time-slice all of the processes just fine, as expected with a preemptively multitasked system. It seems to me that if an app would dedicate a thread to doing whatever it is that the window server wants, it would always appear to be responsive. Mail.app, for example, almost never appears hung - you can always click something else no matter what it is currently trying to do or waiting for.
Comments
But leave the cursor an arrow. It would really help avoid that "I lost control of my computer" feeling that the rainbow cursor creates.
The "other OSes have busy cursors too" argument sucks since I want Mac OS X to be better than the rest, not the same.
So, just as sheets are a nice new addition, avoiding the modalness of the old error dialogs, we could have a window/app specific busy sign without affecting the actual cursor.
Today I had an issue where Final Cut stood busy for almost a minute when opening a project file and updating it to the latest version. The beach ball is typical for a second or two, its only when it lasts longer that I begin to wonder it the program has "effectively" crashed. In this case I simply force quit the program and opened the project again and problem solved.
What I am frustrated with is the fact that this same thing can happen when opening windows. Why? You would think that a DP2.5 G5 with 2GB RAM would have the processing power to open ANY window instantaneously at any point in time, but especially one with only a few files in it. Yes, this happenes in Windows occasionally. But, being someone who uses my Mac and PC about equally, I would say that it does happen more on my Mac (and my Mac is faster than my PC).
At any rate, no one has answered the original poster's question... Does Tiger (at least the beta) help this situation at all? I would definately say things have improved since 10.1 (when I started using OS X), so hopefully Tiger (and other future versions) will continue on with this trend.
Originally posted by webmail
the finder has slightly better threading in tiger, but otherwise no. rainbows are everywhere :P
Agreed, I installed the latest seed that I acquired questionably through those Internets and I?m still seeing the, ?I'm stuck on stupid syndrome, spinney rainbow wheel of death?. I?m not talking about normal, wait I?m loading something, it?s more of a, ?I?m out to lunch, be with you an hour? like I got in Panther?. So the problem is still there, for me anyway, but we got a lot more features to play with though.
Originally posted by johnq
Actually I would like a kind of milky overlay for a busy window with a big "startup spinner" or whatever that new busy symbol is called. Have that symbol sit over the window since it's useless while it's busy.
That's a really good idea. It will really help the newcomers know what's going on, as well as advanced users. However, if it's only a few secs it should be the rainbow!
Originally posted by 4fx
Perhaps current technology wont allow this, but it would be nice if OS X could recognize the difference between a process that has become "stuck" and a process that is momentarily busy. If it could, then the current (or modified) beach ball could be used for the "momentarily busy" situations and a force quit dialogue box option could come up if the process was stuck. I realize this is probably what happens what an application crashes, but still it would be nice if OS X could better determine this.
Not for nuthin', but there is a proof in computer science that such a thing can never be programmed. It's called the Halting Problem.
I'm still trying to get to the bottom of this beachball problem. I don't think most apps are really "busy" when that happens; I think, since this is a kernel-level cursor, that the app is waiting for something and isn't responding to the window manager. Apple never addresses it at WWDC.
By far the most common for me is when an app hits swap hard ( omniweb does this a lot, I think it keeps a window open for every web page tab - uses a heap of memory ). When Im running omniweb I can easily have it take a minute to swap in after Ive been working in another app - beach ball all the way. Then as you use it, all of the menus and things get swapped in on demand - more beach ball.
The second is when an app is trying to perform some network activity. Im not sure what the timeouts for networks are in OS X, but it is certainly in the minutes. The Finder in particular, can take ages to deal with network timeouts.
Both of these situations can provide better user feedback. In the first case the OS can inform the user that their machine is running slowly because they dont have enough memory ( and give an option not to show the warning again ). It could also use a different cursor ( or at least provide the ability to use a different cursor ). Menu Meters is a life saver, if I get the spinning beach ball and MM is showing lots of disk IO I know its typically swap activity.
In the second case the OS knows that the program is blocked waiting on some IO that is taking a long time with little activity. It could alert the program, letting it provide an option to cancel, or a timeout indicator. The idea of putting a dialoge on the window is great - a big gray mask, saying "Finder is currently accessing the network. This will automatically end in 2:36 minutes if no response is received, or you can [cancel] now."
Kickaha, yes the SBB is feedback, but it is typically insufficient. Its like telling a user that "An error has occured." Its a last ditch fall back position, only to be used in rare cases, so that at least the user knows that their computer is still working. 4fx's issue with Final Cut Pro is a good example. FCP should provide a progress bar for opening a file, not the SBB. Using the SBB might be easy for the developer, but it isnt user friendly. This is the sort of thing that experienced users ( aka developers ) ignore, because they know the system too well.
Originally posted by mmmpie
4fx's issue with Final Cut Pro is a good example. FCP should provide a progress bar for opening a file, not the SBB. Using the SBB might be easy for the developer, but it isnt user friendly. This is the sort of thing that experienced users ( aka developers ) ignore, because they know the system too well.
FCP actually does have a progress bar for updating files like this, the beach ball typically only comes up when the program has hung during this process (which is too often). Its strange really. But typically force quitting and repeating the process is successful.
I like your idea of a using a processor monitor for this. In my case, I already know that this process doesnt take much processing power, so if the beach ball comes up I immediately know that something has gone wrong.
Just had an idea... someone (if Apple hasnt already done it) should make a widget for a processor monitor and other system monitors. For me I dont like having things like that open all the time and cluttering up my desktop realestate, but using dashboard for it would be perfect!
Originally posted by 4fx
Just had an idea... someone (if Apple hasnt already done it) should make a widget for a processor monitor and other system monitors. For me I dont like having things like that open all the time and cluttering up my desktop realestate, but using dashboard for it would be perfect!
Try MenuMeter http://www.versiontracker.com/dyn/mo.../macosx/17713. You'll likes...... I'm still partial to "top".
So what good will a "different" kind of spinning ball really do? Sometimes it may be indicating something is really messed up, and just as easily, may be reporting something entirely erroneously. So the user has yet one more source of confusion or possibly bad information to form an assessment of what is really going on. You can bet they will conjure up various false conclusions, subsequentally. ...like they may conclude that OSX is very buggy and crashy because they get the "hanging man" icon all the time, but actually they are running far too little memory for the way they use their computer. It's just a single example, but you can see how the notion of a "more descriptive" icon can easily result in more misinformation, ironically.
You could go a step further and do like Windows did for a while. It tried to be "smarter" and happily "force-quit" all those processes it thought was hung-up, instead of burdening you with this management chore. What happened? It ended up aggressively flushing a lot of perfectly fine processes (albeit, momentarily delayed, but certainly still "running") along with the ones that were really crashed. So the user gets the impression that either much Windows software is hopelessly buggy or the OS itself is ridiculously flakey. This is no small matter when Windows decides to flush out your app that you had some important stuff running (that also "looked" like it was hung to the computer). Your app didn't really crash, Windows just "thought it did", and took the liberty of flushing it out for you. Nice, right? What all this means is that making the system more "pre-emptive" about things can just as easily end up biting you as it can help you. Sometimes it is better to just let it handle things on its own terms and "appear dumber".
Now, if Apple could de-couple the busy indicator from the actual cursor, it would go a long way in making the user feel like they have not lost control of the entire computer. (Mind you, OmniOutliner also will put up a spinning beachball, but that's the OS's fault).
Apple pioneered tying the busy status feedback to the cursor but I feel that that is antiquated now.
A per-window, or per-application (if the former is impossible) overlay indicating busy-ness would be great, similar to how sheets free us from modal dialog boxes.
Simply have the cursor remain the arrow no matter how busy or frozen the app is. Let its status be known from some other context.
Spin Control is an application that helps you identify why an application might display the spinning rainbow wait cursor. It automatically samples any application which appears unresponsive to the Window Server.
Now if we just knew precisely what "unresponsive to the Window Server" meant, we'd have a better understanding. When CoreGraphics puts up the spinning cursor, the cursor is usually tied to one app; you can still switch to other apps and the cursor only changes to spinning when over a window or menu bar belonging to the "unresponsive" app. Of course, Mach continues to time-slice all of the processes just fine, as expected with a preemptively multitasked system. It seems to me that if an app would dedicate a thread to doing whatever it is that the window server wants, it would always appear to be responsive. Mail.app, for example, almost never appears hung - you can always click something else no matter what it is currently trying to do or waiting for.