Progress cursor

It would be nice if the cursor could indicate the progress being made. VW has progress dialogs but sometimes you want something that is window or application specific (like a cursor that is for the window it is over). If showing a wait cursor, and 0-1 progress complete value is given, then show a pie around the cursor to indicate the percentage complete. Note that this is different than typical spinner or flasher type cursors that suggest activity but not progress.

Hopefully somebody will have fun implementing it. Probably only a day or two of work to implement this in VW. Probably a dozen ways it could be implemented too. The cursor object (or your wrapper of a cursor) should probably hold the progress value so that something like "CurrentCursor progressValue: 5/100" can be sent from nested contexts and the cursor active for that context will get the progress value.

Paul Baumann

Hi Andres,

I prefer the "progress notification area" (PNA) style over a progress dialog. A dialog only has an advantage in that screen space is reclaimed once the dialog closes; however, modal dialogs are a workaround to a problem that a PNA avoids entirely. There were problems with how VW originally implemented the PNA shown on the transcript window (that have hopefully been fixed by now). PNA is nice for displaying a message along with progress.

Changing the cursor takes no additional window space and is not obscured by other windows. A progress cursor only makes sense for the cursors that emphasize activity over position (like #wait, #database, #write, #quickGarbage, #compactMemory, #bull, #read, #blank, etc.). I wouldn't want  a pointer cursor to have a pie around it either.

I'd be interested in a framework that does as I've described.

Several years ago I'd reported problems with the PNA in the VW transcript window. It was slowness caused by an accumulation of deferred UI work. I recall Travis was able to reproduce it to confirm it using an example that loaded code from store. Your *Notification framework seems like it might be intended as an alternative to #uiEvent for forked processes that would normally be used to avoid problems like these. Too often application code fails to coordinate UI events that originate from background processing. For example, the VW cursor gets stuck when a background process attempts to do cursor changes and it is not the windowProcess (the correction being code like "[Cursor normal show] fork"). Some code wants to show a cursor for every single thing it does (often in place of just tuning the slowness away), and all those cursor changes start to cause a problem when work is later refactored to be done in a background process.

The solution for cursor changes is more simple than a notification framework, (in methods like #showProgressWhile:) if activeProcess is not the windowProcess then skip the cursor display. All the overhead of events and notifications can be skipped when this ui activity is clearly not being under control of the windowProcess. The windowProcess may be busy or waiting for a long time and a background process intended to run independent of it. This trick is better than accumulating deferred work or acting as the windowProcess when it is not. Ignore cursor changes that are not done as the windowProcess; it is more practical than an error and more efficient (and useful) than deferring the work. If anything is done, it would only be to invalidate a region or update data which the windowProcess would cleanup later.

Paul Baumann