[fix] Cursor>>showWhile: race conditions and crosstalk.

In our IDE we created a window that polls the store database every 20
seconds.
As a result we get a database cursor every twenty seconds, even when
working in other windows.
This is particularly annoying when selecting text: the sharp arrow
cursor changes int a blunt disk stack cursor.

Furthermore we sometimes see the wrong cursor 'stick'. Most often that
will be the cursor from a widget resizer that has been captured by the
store monitoring application and then being incorrectly 'restored' after
a db read.

So I published a package in the open repository that maintains the
cursor state on a per-windowmanager basis, package 'Cursor per
WindowManager patches' - this was coded on vw771.




Here is a rundown of its implementation:

The Cursor class maintains the cursor state on its class side, that code
is patched to delegate it to the active process:

Cursor class>>currentCursor
     ^Processor activeProcess currentCursor

Cursor class>>currentCursor: aCursor
     Processor activeProcess currentCursor: aCursor


Process delegates these methods to the associated windowmanager, if no
windowmanager it drops the info:

Process>>currentCursor
     ^self windowManager
         ifNil: [Cursor normal]
         ifNotNil: [:wm | wm currentCursor]

Process>>currentCursor: aCursor
     self windowManager
         ifNotNil: [:wm | wm currentCursor: aCursor fromProcess: self]


The window manager actually stores the current cursor and shows it when
it is changed by the correct process. Two ivars have been added to
WindowManager: 'currentCursor' and 'hasMouseOver'.

WindowManager>>currentCursor
     ^currentCursor ifNil: [currentCursor:=Cursor normal]

WindowManager>>currentCursor: aCursor fromProcess: aProcess
     aProcess = baseProcess
         ifTrue:
             [currentCursor = aCursor
                 ifFalse:
                     [currentCursor := aCursor.
                     self updateVisibleCursor]]

Windowmanager>>updateVisibleCursor
     self hasMouseOver ifTrue: [self currentCursor beCursor]

The code so far handles cursor changes from within a windowmanager's
process. We also need code to react to the user moving the mouse over
various windows. Since such motion can happen while the windowmanager is
busy with a long operation it cannot be handled by the window manager's
thread.
Instead we patch two methods on window that are called by the
InputState's process, we insert a line to notify the window manager:

ScheduledWindow>>addMouseEnterEvent
     windowManager ifNotNil: [:wm | wm hasMouseOver: true].
     sensor ifNotNil: [sensor eventMouseEnter: self]

ScheduledWindow>>addMouseExitEvent
     windowManager ifNotNil: [:wm | wm hasMouseOver: false].
     sensor ifNotNil: [sensor eventMouseExit: self]

Windowmanager>>hasMouseOver: aBoolean
     "Called from the InputState process"
     hasMouseOver := aBoolean.
     self updateVisibleCursor

Note that #hasMouseOver: and #updateVisibleCursor have no multithreading
protections, they are written such that it 'just works' without the
possibility of accidentally blocking the InputState thread.


I would appreciate it if others here could review this code for
potential race conditions etc.
We have been using it for a while now at Soops and have encountered no
issues so far.

My hope is that it will end up in the base image, as a small step in
polishing the multi-threaded UI.



TIA!

Reinout
-------

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Reinout

Unless you are working with a system that can have 2 mice I don't see a race
problem.

But, with respect to preventing a background process from changing the
cursor, I think
it needs to be dealt with in a different manner. For example, if the you
have a background
process running that has an object allocation failure which falls over to
doing a data compaction,
you may want to see the compact cursor. I think there needs to be some of
facility to control
what background generated cursors a window may allow to appear.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
===========================================================
will
> be the cursor from a widget resizer that has been captured by the store
> monitoring application and then being incorrectly 'restored' after a db
read. is without
> the possibility of accidentally blocking the InputState thread.
>
>
> I would appreciate it if others here could review this code for potential
race
> conditions etc.
> We have been using it for a while now at Soops and have encountered no
> issues so far.
>
> My hope is that it will end up in the base image, as a small step in
polishing


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Terry!


On 5/29/2012 9:29 PM, Terry Raymond wrote:
> Unless you are working with a system that can have 2 mice I don't see a race
> problem.
I'm not sure what your are getting at here, my machine has two mice (but
only one pointer/mouse position).
I'm not aware that VW can handle multiple pointers....

I see your point, but don't know yet how to navigate the problems it
entails, unless I re-introduce the race conditions in #showWhile:.

Would it suffice to only make exceptions for the GC cursors or would we
want a generic mechanism?




Thanks,

Reinout
-------

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

> On 5/29/2012 9:29 PM, Terry Raymond wrote:
> > If you have a background process running that has an object
> > allocation failure which falls over to doing a data compaction,
> > you may want to see the compact cursor.

Reinout Heeck wrote:
> Would it suffice to only make exceptions for the GC cursors or would
we
> want a generic mechanism?

I think we want a generic mechanism. For instance, execute, wait, read
and write cursors are all used in our application to indicate blocking.
In some cases that blocking is global, in others (e.g. in the
development environment) it is specific to a window manager (or actually
an application, which in the past has sometimes had more than one window
manager, but now is always in one window manager).

I don't think the globality of a cursor is a feature of the image used
for the cursor, but of the semantics at the point the cursor is asked
for. Sometimes a cursor is only for a widget, sometimes a window,
sometimes a window manager, sometimes an application, and sometimes
global.

I remember Reinout (?) also working earlier on a hierarchy of cursor
semantics, so that a 'more powerful' cursor would override a 'less
powerful' cursor. E.g. if I have a database commit operation, which does
several reads and writes, I might want an outer block that shows the
wait cursor, while the reads and writes each try to show their own
cursor. The hierarchy could say that the wait cursor overrides the read
and write cursors, so the latter would not be shown, and the user would
have a calm wait cursor rather than flashing read/write/wait cursors.

Does anyone have suggestions of other languages and/or UI frameworks
that have a better functioning cursor system than VW? It may be easier
to copy something that works rather than figure it out abstractly and
hope the result is good for all kinds of different apps.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 30.05.2012 um 10:52 schrieb Steven Kelly:

> I remember Reinout (?) also working earlier on a hierarchy of cursor
> semantics, so that a 'more powerful' cursor would override a 'less
> powerful' cursor. E.g.

IMHO, the mouse pointer should not be abused for indications like this at all. Its purpose is to indicate what the user can DO, rather than what is currently happening. Keeping track of the what-can-i-do-status is already a challenge enough.

As seen on most Mac apps, a small status bar at the bottom of the window, often even with a progress bar, is great for indicating the progress of running actions. Possibly along with a spinning wheel or something. When the action is done, the widgets just disappear again.

Global actions could go to the VisualLauncher.

Andre


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 5/30/2012 10:52 AM, Steven Kelly wrote:

Ok, this smells a lot like the exception model, #showWhile: raises a
'hint' and the calling code can decide what to do with it. See the
UserNotification hierarchy for an analogue.

Still don't see how to handle the multithreaded cases...


>
> I remember Reinout (?) also working earlier on a hierarchy of cursor
> semantics, so that a 'more powerful' cursor would override a 'less
> powerful' cursor. E.g. if I have a database commit operation, which does
> several reads and writes, I might want an outer block that shows the
> wait cursor, while the reads and writes each try to show their own
> cursor. The hierarchy could say that the wait cursor overrides the read
> and write cursors, so the latter would not be shown, and the user would
> have a calm wait cursor rather than flashing read/write/wait cursors.

This part might be nicely feasible using an exception based model (and
we also loose the need to declare the 'strength' of a cursor....)

>
> Does anyone have suggestions of other languages and/or UI frameworks
> that have a better functioning cursor system than VW? It may be easier
> to copy something that works rather than figure it out abstractly and
> hope the result is good for all kinds of different apps.

Yes please!




Thanks,

Reinout
-------

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

andre [[hidden email]] wrote:
I agree with your sentiments, but we're not always free to choose. On
Windows the convention is to use the hourglass/rotating circle cursor to
indicate the system is busy, and the hourglass/rotating circle + arrow
cursor to indicate the system is working in the background:

http://msdn.microsoft.com/en-us/library/windows/desktop/bb545459.aspx#bu
sy
(see also "Activity pointers" section later on the page)

For many years in our app we've mapped all 'state' cursors (execute,
wait, gc, read, write, ...) to true Windows cursors, either busy or
working, and that helps keep the cursors calmer.

For operations longer than a second or two, we open a progress gauge as
a dialog. We used to have the progress gauge in the main window (from
which most of the long operations are started), but found that For a
multi-window app, placing global progress indicators in one launcher
window isn't a good idea, since it may well be obscured, and other
windows look like they would still be active. A dialog also prevents
attempts to perform operations in other windows during the long
operation - handy, since such attempts can lead to errors as the models
are in a transitional state e.g. during transaction abandon.

Steve

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

A while ago I looked at this problem and found that distinguishing
between a foreground and a background cursor was helpful.  Although the
meaning of foreground and background cursors is not what you'd expect
when thinking about foreground and background graphics, please allow me
the use of the terms until I find better ones :).

Foreground (or application? user?) cursors are what happens as a direct
result of the user doing stuff.  For example, you mouse over somewhere
and instead of the arrow you see a horizontal slider icon indicating you
can now drag some vertical edge horizontally.

Background (or system?) cursors are what happens as a result of some
activity that is only indirectly caused by the user.  The GC cursors are
examples of this, and so is GemStone's diamond cursor.  They appear for
a bit, and then they go away resetting whatever foreground cursor was
active.

If you separate the cursors by purposes (layers? levels in a stack?),
then a lot of the crosstalk is eliminated.  For example, if an app sets
the horizontal slider cursor and then a GC comes in, when the GC is done
the cursor goes back *not* to the horizontal slider cursor but to
whatever is the foreground cursor at the moment.  So if the user moved
the mouse and after the GC the foreground cursor has to be the arrow,
then awesome when the GC cursor goes away then the cursor will be the
arrow.  Or the slider if the GUI thread didn't get to it yet, in which
case the arrow will appear at some point in the future.

In short, the distinction between cursor purposes allows the user
interface to treat them independently of each other, and so there are no
race conditions.  Requests for cursor changes are simply that,
*requests*, which may or may not be honored depending on which request
is given priority by the cursor management mechanism.

One more thing you can do with this is also decimating the number of
cursor changes, which is nice if you're working on an image remotely.  I
remember being at a customer and getting significant performance
improvement from doing that.

Anyway, that's just my opinion.

On 5/30/2012 1:52 AM, Steven Kelly wrote: _______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Andres, thanks for sharing this.

The old cursor throttling implementations are referenced here:
http://www.cincomsmalltalk.com/CincomSmalltalkWiki/ThrottledCursor


I'll mull over the various comments a bit.

Thinking out loud:

Layering of cursor types:
--affordance helpers (like resize cursors)
--User activity feedback (Cursor busy)
--'background' (GC, gemstone diamond)

Layering of cursor uses dependent on the context (elsethread I likened
that to the way exception handlers can subsume exception types in the
case of user activity feedback cursors).
As Steven said one may want to subsume several Cursor read/ Cursor write
alternations by a more stable Cursor busy evocation.



R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Nice to see you back, Travis - I knew you couldn't stay away long ;). More seriously, I'm truly sad to see you go, but wish you every success and happiness. And now back on topic...

> The problem with the VW cursor system is this addictive method
> called showWhile:. What you'll find, is that no UI Framework
> out there has this idiom. Spinny balls and hourglasses are
> usually handled by the system, out of the developers hands.
> Developers just do spatial response cursor manipulation.

That's true for Mac, but not for Windows, X, Qt, Gdk (as far as I can tell)

> I think the idea that "we should copy something that works
> rather than figure it out abstractly and hope the result is
> good for all kinds of different apps" is incompatible with
> VW programmers...

You could have stopped there :).

> ...who demand to be able do things like Cursor db showWhile: [...].

Actually, I think programmers using VW aren't the problem. They're not responsible for the facilities offered by VW, and they don't really have a choice but to use showWhile:. It's either that or build their own cursor mechanism, but we pay Cincom precisely so we wouldn't have to build our own UI library (graphics library, network library...).

It would be nice to see Reinout's or Andre's solution in VW. I doubt there's a perfect solution, and they both improve behavior without requiring changes to existing customer code. Offering an optional, better abstraction too (as Andre's seems to) would be even better: developers could move their code to the new, better calls in their own time.

Steve


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Travis,

I have been reading that, and when I saw Store arriving with a new showWhile:[ .. Store ..  ] interface I naively thought that this was the way it should be done ....

I then proceeded in a total copyright infringement (Sorry Sam) by cloning the whole thing and refactoring it until nothing was left but a new showWhile interface.

I use it for XML importing exporting, BLOB operations, database table recreations etc. It has a nice interface to update the messaging and  is published under a totally uninspired name WaitForVisual on the public store.

Am I doing wrong ??

@+Maarten,

 

Here's one example:

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

The problem with the VW cursor system is this addictive method called showWhile:. What you'll find, is that no UI Framework out there has this idiom. Spinny balls and hourglasses are usually handled by the system, out of the developers hands. Developers just do spatial response cursor manipulation.

I think the idea that "we should copy something that works rather than figure it out abstractly and hope the result is good for all kinds of different apps" is incompatible with VW programmers who demand they be able to do things like Cursor db showWhile: […]. Show me another app in the wild that has app wide global cursors that show specific (e.g. something more refined than an hourglass/spinnyball, such as read, db, or write) cursors… I'll be waiting in the wings. Well, actually, I won't. :)

--

Travis Griggs

Objologist

10 2 letter words: "If it is to be, it is up to me"

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Maarten,



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Haven't seen the worm, but without doubt the best ever remains with Oracle:

 

http://screencast.com/t/7edzn4TeZUC

 

 

-----Original Message-----
From: "Kooyman, Les" <[hidden email]>
Sent: Friday, 1 June, 2012 20:32
To: "Samuel S. Shuster" <[hidden email]>, [hidden email]
Cc: "VWNC list" <[hidden email]>, "Travis Griggs" <[hidden email]>
Subject: RE: [vwnc] [fix] Cursor>>showWhile: race conditions and crosstalk.

Hey, I liked the red worm.

---

From: Samuel S. Shuster
Sent: Fri 6/1/2012 11:26 AM
To: [hidden email]
Cc: VWNC list; Travis Griggs
Subject: Re: [vwnc] [fix] Cursor>>showWhile: race conditions and crosstalk.

Maarten,

I then proceeded in a total copyright infringement (Sorry Sam)

FWIW, Travis wrote it. He wanted, but never got around to getting higher priority, to generalize it and move it out of Store.

If it is worth anything, you had to see my original "Red Worm" horror to see how I, in effect, forced him to come up with something better.

And So It Goes

Sames

______________________________________________________________________

Samuel S. Shuster [|]

VisualWorks Engineering, Store Project

Smalltalk Enables Success -- What Are YOU Using?

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi all,

   I spent part of the weekend searching the web for cursor management
idioms and discovered that every widget framework introduces its own
abstraction for manipulating visible cursor state.

Most of these seem to classify the busy cursor as a special case and I
often saw stipulations that calls to showbusyCursor() and
unshowBusyCursor() have to be balanced (the #showWhile: idiom)  while
they need not be balanced for other cursor types.

Some frameworks allow static prioritizing of cursors, others ad-hoc
prioritizing of cursors.

Talking to the VW developers here at Soops I find some do want to see GC
cursors and some don't....

And then there's the Mac OS X spinning beach ball automatic cursor.... I
use Mac at home and can simply state that I hate the spinning beach
ball: it only tells me I have to wait (something I usually know both
without and before that hint) and does not tell me whether the
application is making progress (which lively read/write/database/busy
cursor changes or perhaps a disk activity light do convey).


So if I spend more time on this code I will probably extract cursor
visibility management into a global policy object and let all cursor
change messages go through there.  This way developers can plug in their
own policies if they want...

Travis' blog post notes one important thing I did not realize: the
usages of Cursor>>show (by Trackers etc) and Cursor>showWhile: (used
inline as busy/progress indicator) can be used as a classification.
So in the -auto-busy policy the sends of #showWhile: could be ignored,
so it seems a policy object would have to receive these messages in a
distinguishable way.


I don't know if I'll do further work on this code, but for the moment it
does fix two problems we had in the IDE :-)

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc