[squeak-dev] Dependencies on Cursor

Frank Shearar frank.shearar at gmail.com
Tue Jun 25 15:41:42 UTC 2013


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


More information about the Squeak-dev mailing list