On 26-06-2013, at 9:31 AM, Tony Garnock-Jones <tonyg at ccs.neu.edu> wrote:

> On 06/25/2013 03:04 PM, Chris Muller wrote:
>> 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.


I agree here. Feedback ought to be via some affordance within the application doing the work; hence my suggestions a while back about perhaps making buttons act as an 'in-place' progress bar. Apple does a moderately ok but not really adequate job of application feedback in a number of places, with the Safari URL/progressbar and the Finder whirly thing - though they ought to be much more prominent.

From the depths of the application/system, we should use something akin to exceptions (probably starting with actual Exceptions would be smart) that can be raised without having to know any details about how the information will be used. The UI or other front-end would handle the notification as it chooses (including optionally whacking the cursor) and carry on, calmly.

Another thing to consider is whether to, and how to, handle having a progress UI widget that has a 'cancel/quit' button to abort too-long running operations. I can see how using the bones of the Exception resume mechanism might provide some help here, though there is potential for a lot of tidy-up work when cancelling a partially complete job. There's obvious tie-ins with handling errors.



tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Any Sufficiently Advanced Incompetence Is Indistinguishable From Malice