[squeak-dev] Dependencies on Cursor

Bert Freudenberg bert at freudenbergs.de
Tue Jun 25 17:06:18 UTC 2013


Well, there needs to be *some* mechanism for communication from low-level code to the UI. A direct dependency is bad, obviously.

Juan's suggestion works for any long-running operation, without the need to code anything. That's great. But it wouldn't let us distinguish what the cause of it is - showing the read cursor or write cursor did that.

Maybe the two should be combined? For example, there could be a ResourceAccessProgressNotification that knew about read/write/network access. This combined with Juan's "watchdog" would let the UI indicate more specifically what the cause of the delay is.

- Bert -

On 25.06.2013, at 08:52, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:

> But can we agree that File should not bother with UI things, it's not it's business, be it by direct access to Cursor, or indirect access thru a UIManager?
> 
> 
> 2013/6/25 Frank Shearar <frank.shearar at gmail.com>
> On 25 June 2013 16:35, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
> > 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
> 
> There's nothing wrong with Juan's code. It just doesn't have much to
> do with the problem that spawned this thread.
> 
> The link is, however: Vassili and Travis are saying "remove Cursor
> showWhile:". And that _would_ solve my problem. Removing these senders
> would make Files no longer depend on Graphics.
> 
> (Juan's suggestion would address the second half of the linked
> article. Again, it's great, and maybe we should port that to Trunk
> ASAP, but it's not what I was posting about.)
> 
> frank
> 
> > 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/b26a9e85/attachment.htm


More information about the Squeak-dev mailing list