That's another point, I remember when using ST80, the cursor was blinking fast between these states read/write/hour glass/normal, and this particular feedback did not add much value.

2013/6/25 Frank Shearar frank.shearar@gmail.com

On 25 June 2013 16:41, Ken Dickey Ken.Dickey@whidbey.com wrote:

...

I think Juan's point may have been missed, but shows up in his change

notes:

...

• Automatic hourglass mouse pointer when Morphic is busy
• Removed about 80 calls like 'Cursor wait showWhile: []', as they are

no longer needed!

I hadn't missed this particular point. But then, the #showWhile: calls usually show _kinds_ of busy-ness: reading, writing, etc.

frank

...

$0.02

-KenD

Ken [dot] Dickey [at] whidbey [dot] com

Ah yes, maybe it's some sort of useful warning: "beware of epileptic crisis" or something like that...

2013/6/25 Chris Muller asqueaker@gmail.com

That's a somewhat self contradicting statement -- because:

"the cursor was blinking fast between these states read/write/hour glass/normal"

is chock full of information about the running program. First, and foremost, one would know the system is not locked up. Indicating reading vs. writing vs. processing is very useful with applications that involve a lot of I/O, such as database or network applications. By relating input actions to cursor status, the system can impart a lot information about what it's doing.

By contrast, the Cuis approach of indicating busy on a timer confirms to the waiting user something they already know -- that they're waiting. It tells them that the built-in timer to switch the cursor is working, but nothing else about what the system is or isn't doing.

This should not be taken as a criticism of Cuis itself. There's a lot to like about Cuis.

On Tue, Jun 25, 2013 at 10:55 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:

...

That's another point, I remember when using ST80, the cursor was blinking fast between these states read/write/hour glass/normal, and this

particular

...

feedback did not add much value.

2013/6/25 Frank Shearar frank.shearar@gmail.com

...

On 25 June 2013 16:41, Ken Dickey Ken.Dickey@whidbey.com wrote:

...

I think Juan's point may have been missed, but shows up in his change notes:

• Automatic hourglass mouse pointer when Morphic is busy
• Removed about 80 calls like 'Cursor wait showWhile: []', as they are

no longer needed!

I hadn't missed this particular point. But then, the #showWhile: calls usually show _kinds_ of busy-ness: reading, writing, etc.

frank

...

$0.02

-KenD

Ken [dot] Dickey [at] whidbey [dot] com

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.

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.

Cheers, Tony

[1] http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&a...

Hi,

WorldState>>activeHand and friends still exist. Never made use of that but I assumed every hand is / has a separate cursor?

Cheers

Herbert

Am 26.06.2013 18:31, schrieb Tony Garnock-Jones:

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.

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.

Cheers, Tony

[1] http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&a...

On 26.06.2013, at 10:04, Herbert König herbertkoenig@gmx.net wrote:

Hi,

WorldState>>activeHand and friends still exist. Never made use of that but I assumed every hand is / has a separate cursor?

Indeed. The primary hand is mapped to the system pointer ("hardware cursor") and every other hand is drawn by Morphic.

My multi-touch implementation for the iPad maps each finger to a separate hand. This lets you drag around multiple morphs at the same time without any special coding effort, it just works.

Also, a long time ago (around Squeak 2.8) I published a neat Linux hack where every mouse you plugged into the system would show up as a separate hand.

The original use case was within Nebraska though, were every remote participant got their own hand (see RemoteHandMorph).

There is also the event recorder and playback which uses a secondary hand.

- Bert -

On 06/26/2013 01:33 PM, Bert Freudenberg wrote:

My multi-touch implementation for the iPad maps each finger to a separate hand.

Perfect. Could your implementation be adapted to e.g. CogDroid, do you think? (I have a new Android tablet specifically for such experimentation.)

Tony

On 06/26/2013 02:04 PM, Bert Freudenberg wrote:

Certainly, you just need to somehow get the events from the VM into the image. If CogDroid could use the same event format then the image code should just work. The current format is based on Apple's, so I'm not sure how simple the mapping would be. If it's not easy, then now might be a good time to create a generic format. All platforms (except Mac OS?) now have support for multi-touch so making it general would be nice.

I haven't looked too far into the Android NDK's event formats, but from what I can gather they are closely based on the underlying Linux /dev/input events.

If it were possible on Unix machines to read from /dev/input/* without blocking when there is no pending data, we'd be more-or-less at the point where we could avoid VM modifications entirely for Android multitouch.

Tony

Mac OS X supports multi-touch (i.e. MacBook touch pads and the Apple Magic Mouse)

Isn't this what you're talking about?

http://developer.apple.com/library/mac/#documentation/cocoa/conceptual/Event... Touch Events Represent Fingers on the Trackpad

Instead of handling a gesture, you could choose to track and handle the “raw” touches that make up the gesture. But why might you make such a choice? One obvious reason is that OS X does not recognize the particular gesture you are interested in—that is, something other than magnify (pinch in and out), rotate, or swipe. Or you want your view to respond to a system-supported gesture, but you want more information about the gesture than the AppKit framework currently provides; for example, you would like to have anchor points for a zooming operation. Unless you have reasons such as these, you should prefer gestures to raw touch events.

The following sections discuss the multi-touch sequence that delimits a touch event in an abstract sense, point out important touch-event attributes, and show you how to handle touch events. A Multi-Touch Sequence

When a user touches a trackpad with one or more fingers and moves those fingers over the trackpad, the hardware generates low-level events that represent each of those fingers on the trackpad. The stream of events, as with all type of events, is continuous. However, there is a logical unit of touches that together, represent a *multi-touch sequence*. A multi-touch sequence begins when the user puts one or more fingers on the trackpad. The finger can move in various directions over the trackpad, and additional fingers may touch the trackpad. The multi-touch sequence doesn’t end until all of those fingers are lifted from the trackpad.

Within a multi-touch sequence, a finger on the trackpad typically goes through distinct phases:

-

It touches down on the trackpad. -

It can move in various directions at various speeds. -

It can remain stationary. -

It lifts from the trackpad.

The AppKit framework uses objects of the NSTouch class to represent touches through the various phases of a multi-touch sequence. That is, an NSTouch object is a snapshot of a particular finger—a touch—on the trackpad in a particular phase. For example, when a touch moves in a certain direction, the AppKit represents it with an NSTouchinstance; it uses another NSTouch object to represent the same finger when it lifts from the trackpad.

On Wed, Jun 26, 2013 at 2:08 PM, Bert Freudenberg bert@freudenbergs.dewrote:

On 26.06.2013, at 13:53, Darius Clarke socinian@gmail.com wrote:

...

Mac OS X supports multi-touch (i.e. MacBook touch pads and the Apple

Magic Mouse)

Nah, you cannot independently access the finger positions. We're really talking about touchscreen support.

• Bert -

Glad to help. You're probably right.

At least OS X wouldn't be a limiting factor for making a multi-platform library.

""LightTable" demo and it just feels terrible""

Sometimes something is terrible until someone has that spark of insight into a new way of using it with something familiar.

- Darius

...

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&a...

On 26 June 2013 22:58, tim Rowledge tim@rowledge.org wrote:

On 26-06-2013, at 2:49 PM, Chris Muller asqueaker@gmail.com 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.

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; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: NNI: Neglect Next Instruction

On 26-06-2013, at 2:49 PM, Chris Muller asqueaker@gmail.com 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.

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

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.