Dependencies on Cursor

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

On 26-06-2013, at 2:49 PM, Chris Muller <[hidden email]> wrote:
> 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?

Easy; for something like that you might want a simple UI element that flashes on/off as appropriate. For a slightly more sophisticated feedback, perhaps something that glows brighter or more intense colours as the rate changes, or even a good old VU meter style widget? Even more info needed? How about a rate-sensitive meter and an associated actual log view that can be checked, reviewed, saved to file, whatever?

I've been trying to keep the idea of a faintly exception related mechanism separate from whatever UI widget is best for any particular use; I hope that particular tree hasn't got lost in the woods of this long list of messages. A pop-up progress bar is only one of many options that would be useful.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: NNI: Neglect Next Instruction

On 26 June 2013 22:58, tim Rowledge <[hidden email]> wrote:
I as yet still have a hand on Ariadne's thread. It sounds like the
general consensus is that
* low level code like Files has no business monkeying with Cursor,
* using Notifications allows us to have a pluggable feedback notification.

For now that might well mean that we have something (UIManager?) that
handles those messages and implements the current Cursor behaviour. Or
something could supply custom UI feedback, for applications that
needed something special.

frank

> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Strange OpCodes: NNI: Neglect Next Instruction
>
>
>

- Bert -

Hmmm, a simple UI element like the busy-Cursor?!   :)  Again, by the
time you ask yourself the question, "What is the system doing?" it's
too late to go back and open some external widget and "hook it up".
There is where the cursor's ubiquity and global-availability for UI
process serves well.  If it is not currently accepting input, then it
must indicate so to avoid user confusion and frustration -- but if it
must do THAT, why not let it provide a little bit more feedback about
what's going on by letting it be any of a number shapes?

>For a slightly more sophisticated feedback, perhaps something that glows brighter or more intense colours as the rate changes, or even a good old VU meter style widget? Even more info needed? How about a rate-sensitive meter and an associated actual log view that can be checked, reviewed, saved to file, whatever?
>
> I've been trying to keep the idea of a faintly exception related mechanism separate from whatever UI widget is best for any particular use; I hope that particular tree hasn't got lost in the woods of this long list of messages. A pop-up progress bar is only one of many options that would be useful.

You should have a look at my "MaClientProcess", which handles
everything you said (graceful pause and resume, graceful cancel,
calculation of rate and time remaining for the progress reporting) and
can even use resumable Notifications for control.  You'd probably like
it, but I never proposed putting it into Squeak because I see it as an
"app-level" thing where I see Squeak as general-purpose, not
necessarily an "app builder".

On 06/26/2013 05:49 PM, Chris Muller wrote:
> 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?

Some on-screen widget. Perhaps a little counter, "12345 Hz" in the
corner of the screen or spatially localised to whereever the user
interface representing the rest of the metainformation about the
database is.

Using Cursor is fine up until you consider that there may be more than
one subsystem that wants to use Cursor at once. Perhaps there's one
process reifying proxies as you describe, at the same time another is
downloading a webpage. Which one should get to change the Cursor?

My answer to that question is "mu."

Cheers,
   Tony

> Using Cursor is fine up until you consider that there may be more than one
> subsystem that wants to use Cursor at once. Perhaps there's one process
> reifying proxies as you describe, at the same time another is downloading a
> webpage. Which one should get to change the Cursor?

The one which is running in the UI process.

> I as yet still have a hand on Ariadne's thread. It sounds like the
> general consensus is that
> * low level code like Files has no business monkeying with Cursor,
> * using Notifications allows us to have a pluggable feedback notification.
>
> For now that might well mean that we have something (UIManager?) that
> handles those messages and implements the current Cursor behaviour. Or
> something could supply custom UI feedback, for applications that
> needed something special.

Yes, that sounds reasonable.