<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>Well, there needs to be *some* mechanism for communication from low-level code to the UI. A direct dependency is bad, obviously.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><div><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px; font-family: 'Lucida Grande'; font-size: 12px; "><div style="font-family: Helvetica; ">- Bert -</div></span></div></div><div><br></div><div>On 25.06.2013, at 08:52, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">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?<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2013/6/25 Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; ">
On 25 June 2013 16:35, Nicolas Cellier<br>
<div class="im"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> That reminds me the post from Travis Griggs, citing ideas from Vassili Bykov<br>
><br>
> <a href="http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Cursor_consider_showWhile:_[Harmful]&entry=3432339015" target="_blank">http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Cursor_consider_showWhile:_[Harmful]&entry=3432339015</a><br>
><br>
> And I think that Juan's implementation is clearly in this spirit, so +1<br>
<br>
</div>There's nothing wrong with Juan's code. It just doesn't have much to<br>
do with the problem that spawned this thread.<br>
<br>
The link is, however: Vassili and Travis are saying "remove Cursor<br>
showWhile:". And that _would_ solve my problem. Removing these senders<br>
would make Files no longer depend on Graphics.<br>
<br>
(Juan's suggestion would address the second half of the linked<br>
article. Again, it's great, and maybe we should port that to Trunk<br>
ASAP, but it's not what I was posting about.)<br>
<span class="HOEnZb"><font color="#888888"><br>
frank<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> 2013/6/25 H. Hirzel <<a href="mailto:hannes.hirzel@gmail.com">hannes.hirzel@gmail.com</a>><br>
><br>
>> On 6/25/13, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
>> > On Tue, Jun 25, 2013 at 07:16:03AM -0300, Juan Vuletich (mail lists)<br>
>> > wrote:<br>
>> >> Quoting Frank Shearar <<a href="mailto:frank.shearar@gmail.com">frank.shearar@gmail.com</a>>:<br>
>> >><br>
>> >> >...<br>
>> >> >I realise that I'm advocating the removal of a host of Graphics<br>
>> >> >dependencies only to replace them with ToolBuilder-Kernel<br>
>> >> >dependencies. I'd prefer to not have the latter either, but it's a<br>
>> >> >lesser of two evils.<br>
>> >> ><br>
>> >> >...<br>
>> >> >frank<br>
>> >><br>
>> >> What about my suggestion? I mean, doesn't it deserve a comment?<br>
>> >><br>
>> ><br>
>> > Yes indeed it does. I have not been following this discussion closely,<br>
>> > but<br>
>> > I'll comment anyway :-)<br>
>> ><br>
>> > On Mon, Jun 24, 2013 at 10:28:31AM -0300, Juan Vuletich (mail lists)<br>
>> > wrote:<br>
>> >> I recently did something better fo Cuis. The idea is to let Morphic<br>
>> >> handle that. If Morphic frame rate drops below some threshold, show<br>
>> >> the wait cursor. This way, there are no 'bad' references to UI from<br>
>> >> non-UI code, and you only get the wait cursor if appropriate (for<br>
>> >> instance, not if the very same code is run on a forked process). It is<br>
>> >> trivial to add protocol to set the "wait cursor" to be used. This<br>
>> >> allowed me to clean a lot of methods.<br>
>> >><br>
>> >> It is in update #1704 at <a href="https://github.com/jvuletich/Cuis" target="_blank">https://github.com/jvuletich/Cuis</a> .<br>
>> ><br>
>> > This sounds like like a really elegant approach, because it does not<br>
>> > require advance knowledge that some operation is likely to take a long<br>
>> > time, and it will do the right thing on both slow and fast hardware.<br>
>> ><br>
>> > It does however seem to depend on the Morphic update mechanism, so it<br>
>> > may not translate well to other UI styles. (I look to MVC to keep us<br>
>> > honest in these matters, but you can imagine a SeasideProject in<br>
>> > addition<br>
>> > to MorphicProject and MVCProject, and the same principle applies.)<br>
>> ><br>
>> > On Mon, Jun 24, 2013 at 09:12:08PM -0500, Chris Muller wrote:<br>
>> >> After more thought, I should rebut myself for sounding so harsh.<br>
>> >> Frank, are Cursor showWhile:, et al. the _sole_ cause of dependency on<br>
>> >> Graphics from many packages? If so, then I do understand the interest<br>
>> >> in wanting to soften those dependencies. If we're going to extend<br>
>> >> "UIManager" I think we should call it something generic to a UI that<br>
>> >> may not even support a cursor:<br>
>> >><br>
>> >> UIManager default indicateBusyWhile: [ ... ]<br>
>> >> UIManager default indicateReadingWhile: [ ... ]<br>
>> >> etc.<br>
>> >><br>
>> ><br>
>> > This sounds like a promising approach. It is easy to read and the intent<br>
>> > is clear. It seems like it would provide a mechinism for using an<br>
>> > optimal<br>
>> > implementation for various types of projects. For example, an MVCProject<br>
>> > might use the traditional "Cursor wait showWhile:" idiom, and a<br>
>> > MorphicProject<br>
>> > could use the new Cuis approach. Meanwhile if someone was (finally!)<br>
>> > implementing SeasideProject, they could figure out an implementation<br>
>> > that<br>
>> > makes sense for a web app.<br>
>> ><br>
>> > Dave<br>
>><br>
>> + 1<br>
<br>
</div></div></blockquote></div><br></div>
<br></blockquote></div><br></body></html>