On Tue, Jun 25, 2013 at 07:16:03AM -0300, Juan Vuletich (mail lists) wrote:
> Quoting Frank Shearar <frank.shearar at gmail.com>:
> 
> >...
> >I realise that I'm advocating the removal of a host of Graphics
> >dependencies only to replace them with ToolBuilder-Kernel
> >dependencies. I'd prefer to not have the latter either, but it's a
> >lesser of two evils.
> >
> >...
> >frank
> 
> What about my suggestion? I mean, doesn't it deserve a comment?
> 

Yes indeed it does. I have not been following this discussion closely, but
I'll comment anyway :-)

On Mon, Jun 24, 2013 at 10:28:31AM -0300, Juan Vuletich (mail lists) wrote:
> I recently did something better fo Cuis. The idea is to let Morphic
> handle that. If Morphic frame rate drops below some threshold, show
> the wait cursor. This way, there are no 'bad' references to UI from
> non-UI code, and you only get the wait cursor if appropriate (for
> instance, not if the very same code is run on a forked process). It is
> trivial to add protocol to set the "wait cursor" to be used. This
> allowed me to clean a lot of methods.
>
> It is in update #1704 at https://github.com/jvuletich/Cuis .

This sounds like like a really elegant approach, because it does not
require advance knowledge that some operation is likely to take a long
time, and it will do the right thing on both slow and fast hardware.

It does however seem to depend on the Morphic update mechanism, so it
may not translate well to other UI styles. (I look to MVC to keep us
honest in these matters, but you can imagine a SeasideProject in addition
to MorphicProject and MVCProject, and the same principle applies.)

On Mon, Jun 24, 2013 at 09:12:08PM -0500, Chris Muller wrote:
> After more thought, I should rebut myself for sounding so harsh.
> Frank, are Cursor showWhile:, et al. the _sole_ cause of dependency on
> Graphics from many packages?  If so, then I do understand the interest
> in wanting to soften those dependencies.  If we're going to extend
> "UIManager" I think we should call it something generic to a UI that
> may not even support a cursor:
>
>   UIManager default indicateBusyWhile: [ ... ]
>   UIManager default indicateReadingWhile: [ ... ]
>   etc.
>

This sounds like a promising approach. It is easy to read and the intent
is clear. It seems like it would provide a mechinism for using an optimal
implementation for various types of projects. For example, an MVCProject
might use the traditional "Cursor wait showWhile:" idiom, and a MorphicProject
could use the new Cuis approach. Meanwhile if someone was (finally!)
implementing SeasideProject, they could figure out an implementation that
makes sense for a web app.

Dave