[squeak-dev] Dependencies on Cursor

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Tue Jun 25 15:35:30 UTC 2013


That reminds me the post from Travis Griggs, citing ideas from Vassili Bykov

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

And I think that Juan's implementation is clearly in this spirit, so +1


2013/6/25 H. Hirzel <hannes.hirzel at gmail.com>

> On 6/25/13, David T. Lewis <lewis at mail.msen.com> wrote:
> > 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
>
> + 1
>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20130625/aec731eb/attachment.htm


More information about the Squeak-dev mailing list