>> By relating input actions to cursor status, the system can impart a
>> lot information about what it's doing.
>
> I think one important point worth stressing is that there's only one Cursor
> - it's a global ambient resource.
>
> Concurrency is much more common these days than in it was in the time of
> ST80, so we should be moving toward being able to report on multiple ongoing
> activities at once. Cursor doesn't cut it here at all.

No one ever suggested using the Cursor to report on background process
activity.  Background process reporting is a totally separate issue
from what we're talking about, letting the UI process indicating
busy-activity via the cursor.  I guess Travis' blog states as much
too...?

> Seen from this perspective, the only remaining use for a real busy cursor is
> exactly the "beachball" case, similar to what Juan has implemented for Cuis.
> Travis and Vassili's remarks [1] are dead on.

Travis' proposal was to keep a "busy cursor" and augment it with an
"immediate cursor", so for you to say like "the only use" followed by
"dead on" is contradictory.  I agree with Travis' blog except at one
part where he said, "...never immediately at the beginning of a
computation."  One should never say never.  :)

Let me offer another cold, hard example.  Maybe you can tell me here
what alternative will "cut it" over the Cursor?  The case of reifying
a proxy in a Smalltalk image to its real-object counterpart in a DB.
This is something that happens about 100 times per minute depending on
many factors.  Flipping the cursor provides a visual, real-time way to
understand, not only the frequency of proxy hits, but also the rate
which each hit is reifying.  A progress would not provide this
information, nor would it be appropriate to popping up 100 progress
bars per minute..  What else, then?


>
> Cheers,
>   Tony
>
> [1]
> http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Cursor_consider_showWhile:_[Harmful]&entry=3432339015
>