Dependencies on Cursor
Locked
 
|
Lots of code (174 senders) use something like:
Cursor wait showWhile: ["stuff"] That's great, and neat, and causes a dependency on the entire Graphics package. I propose breaking this dependency by extending UIManager's protocol. You would then write: UIManager default showCursor: #wait during: ["stuff"] I use a Symbol to identify the cursor because that doesn't require depending on any particular classes. Perhaps UIManager >> #showCursor:during: can lay out the minimum expected set of labels (whatever Cursor currently lists). Then MorphicUIManager and MVCUIManager can implement this method in the existing way, with ^ Cursor foo showWhile: aBlock One other change is needed, and that's to handle mistakes. So I propose Cursor class >> #named: aSymbol ^ (self respondsTo: #named) ifTrue: [self perform: aSymbol] ifFalse: [self normal]. The reason for the icky reflection is to fit in with the existing way cursors are used. I'd be happy to unroll the #perform: into a #caseOf: mapping explicitly to the existing cursors. Thoughts? frank |
Re: Dependencies on Cursor
|
|
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 . Cheers, Juan Vuletich Quoting Frank Shearar <[hidden email]>: > Lots of code (174 senders) use something like: > > Cursor wait showWhile: ["stuff"] > > That's great, and neat, and causes a dependency on the entire Graphics > package. I propose breaking this dependency by extending UIManager's > protocol. You would then write: > > UIManager default showCursor: #wait during: ["stuff"] > > I use a Symbol to identify the cursor because that doesn't require > depending on any particular classes. Perhaps UIManager >> > #showCursor:during: can lay out the minimum expected set of labels > (whatever Cursor currently lists). Then MorphicUIManager and > MVCUIManager can implement this method in the existing way, with ^ > Cursor foo showWhile: aBlock > > One other change is needed, and that's to handle mistakes. So I propose > > Cursor class >> #named: aSymbol > ^ (self respondsTo: #named) > ifTrue: [self perform: aSymbol] > ifFalse: [self normal]. > > The reason for the icky reflection is to fit in with the existing way > cursors are used. I'd be happy to unroll the #perform: into a #caseOf: > mapping explicitly to the existing cursors. > > Thoughts? > > frank > > Cheers, Juan Vuletich |
Re: Dependencies on Cursor
|
|
On 06/24/2013 09:28 AM, 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. Does this work also for long-running primitives? I think the #showWhile: approach works in that situation. Tony |
Re: Dependencies on Cursor
|
|
It should work if you use the MT Cog VM, that allows Squeak to
continue running alongside primitives. Never tested it, though. Quoting Tony Garnock-Jones <[hidden email]>: > On 06/24/2013 09:28 AM, 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. > > Does this work also for long-running primitives? I think the > #showWhile: approach works in that situation. > > Tony Cheers, Juan Vuletich |
|
|
On 24-06-2013, at 7:57 AM, "Juan Vuletich (mail lists)" <[hidden email]> wrote: > It should work if you use the MT Cog VM, that allows Squeak to continue running alongside primitives. Never tested it, though. Given that you are deliberately doing things different in Cuis, perhaps you might consider a new prim to do this even without multi-threading support. The Stack/Cog VMs use a heartbeat timer and it would be pretty simple to add a primitiveLongWaitCursor that took a suitable cursor and a time delay, and after said delay, swapped the cursor. The tricky part would be making it cleanly work in the tick interrupt so that long running primitives don't block it. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim An algorithm must be seen to be believed. |
|
|
In reply to this post by Frank Shearar-3
On 24-06-2013, at 5:31 AM, Frank Shearar <[hidden email]> wrote: > You would then write: > > UIManager default showCursor: #wait during: ["stuff"] > snip] > The reason for the icky reflection is to fit in with the existing way > cursors are used. I'd be happy to unroll the #perform: into a #caseOf: > mapping explicitly to the existing cursors. > > Thoughts Well I really dislike seeing #respondsTo: et al in general code so I'd propose something along the lines of a list of known cursors (it's reasonable in my opinion to make that list using reflection at either startup or add-new-cursor time) and then Cursor class >> #named: aSymbol ^ cursorList at: aSymbol ifAbsent:[self normal] tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: CCC: Crash if Carry Clear |
Re: Dependencies on Cursor
|
|
In reply to this post by timrowledge
Quoting tim Rowledge <[hidden email]>:
> > On 24-06-2013, at 7:57 AM, "Juan Vuletich (mail lists)" > <[hidden email]> wrote: > >> It should work if you use the MT Cog VM, that allows Squeak to >> continue running alongside primitives. Never tested it, though. > > > Given that you are deliberately doing things different in Cuis, > perhaps you might consider a new prim to do this even without > multi-threading support. The Stack/Cog VMs use a heartbeat timer and > it would be pretty simple to add a primitiveLongWaitCursor that took > a suitable cursor and a time delay, and after said delay, swapped > the cursor. The tricky part would be making it cleanly work in the > tick interrupt so that long running primitives don't block it. Yes, good idea. But I'm trying not to modify the VM, and to always use the current Squeak VMs. I'm already short of time, and I try to focus on the image side of things. If some kind soul would do it, I'd adopt it for sure. > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > An algorithm must be seen to be believed. > Cheers, Juan Vuletich |
|
|
In reply to this post by timrowledge
On 24 June 2013 18:30, tim Rowledge <[hidden email]> wrote:
> > On 24-06-2013, at 5:31 AM, Frank Shearar <[hidden email]> wrote: >> You would then write: >> >> UIManager default showCursor: #wait during: ["stuff"] > >> snip] > >> The reason for the icky reflection is to fit in with the existing way >> cursors are used. I'd be happy to unroll the #perform: into a #caseOf: >> mapping explicitly to the existing cursors. >> >> Thoughts > > Well I really dislike seeing #respondsTo: et al in general code so I'd propose something along the lines of a list of known cursors (it's reasonable in my opinion to make that list using reflection at either startup or add-new-cursor time) and then > > Cursor class >> #named: aSymbol > ^ cursorList at: aSymbol ifAbsent:[self normal] Yep, reflection hides the actual API, and makes things slow as well. So in Cursor's particular case, it has loads of classvars with names of the form FooCursor, Foo naturally corresponding to the selector #foo. So there's CrossHairCursor, BlankCursor, etc. That means you end up duplicating the list of cursors (between the set of class vars and cursorList), or you make a rather invasive change of ripping out all the class vars. A middle ground might be this: Cursor >> named: aSymbol ^ aSymbol caseOf: { [#down] -> [self down]. [#wait] -> [self wait]. } otherwise: [self normal]. frank > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: CCC: Crash if Carry Clear > > > |
|
|
My requirements are that control needs to remain with applications to
provide feedback about any of a _variety_ of actions a program may be *doing* -- not simply how long a user has been waiting. Changing the cursor form is already process-intensive enough without needing to endure any more performance degradation, please. I struggle to understand why, for any package that thinks it wants to do something graphical like operate on a Cursor, should not depend on the Graphics package anyway? Why so worried to the point of getting away from simple OO sending a message to the Form object and moving to some kind of relational lookup simply because of a valid package dependency..? If we MUST sterilize the system, Frank seems to have the best compromise with performance so far with the CASE statement. Unfortunately it still chips away at the simplicity and also functionality we have now, such as the ability for an application to conveniently extend with its own cursor forms. Is it about "feeling squeaky clean," or is there some bigger payoff I'm missing? Is this about getting to a smaller core? On Mon, Jun 24, 2013 at 12:43 PM, Frank Shearar <[hidden email]> wrote: > On 24 June 2013 18:30, tim Rowledge <[hidden email]> wrote: >> >> On 24-06-2013, at 5:31 AM, Frank Shearar <[hidden email]> wrote: >>> You would then write: >>> >>> UIManager default showCursor: #wait during: ["stuff"] >> >>> snip] >> >>> The reason for the icky reflection is to fit in with the existing way >>> cursors are used. I'd be happy to unroll the #perform: into a #caseOf: >>> mapping explicitly to the existing cursors. >>> >>> Thoughts >> >> Well I really dislike seeing #respondsTo: et al in general code so I'd propose something along the lines of a list of known cursors (it's reasonable in my opinion to make that list using reflection at either startup or add-new-cursor time) and then >> >> Cursor class >> #named: aSymbol >> ^ cursorList at: aSymbol ifAbsent:[self normal] > > Yep, reflection hides the actual API, and makes things slow as well. > So in Cursor's particular case, it has loads of classvars with names > of the form FooCursor, Foo naturally corresponding to the selector > #foo. So there's CrossHairCursor, BlankCursor, etc. That means you end > up duplicating the list of cursors (between the set of class vars and > cursorList), or you make a rather invasive change of ripping out all > the class vars. A middle ground might be this: > > Cursor >> named: aSymbol > ^ aSymbol caseOf: { > [#down] -> [self down]. > [#wait] -> [self wait]. > } otherwise: [self normal]. > > frank > >> tim >> -- >> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >> Strange OpCodes: CCC: Crash if Carry Clear >> >> >> > |
|
|
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. I don't need to be concerned about performance since a hard dependency to Cursor showWhile: can be maintained. But at least the in-image "apps" like the Browsers and stuff, performance should not be noticably affected by their occasional flipping of the cursor, and so Tims idea of a Dictionary of forms / form names should be plenty fast enough for that and with ability to extend without changing code by apps putting into that Dictionary.. On Mon, Jun 24, 2013 at 3:50 PM, Chris Muller <[hidden email]> wrote: > My requirements are that control needs to remain with applications to > provide feedback about any of a _variety_ of actions a program may be > *doing* -- not simply how long a user has been waiting. Changing the > cursor form is already process-intensive enough without needing to > endure any more performance degradation, please. > > I struggle to understand why, for any package that thinks it wants to > do something graphical like operate on a Cursor, should not depend on > the Graphics package anyway? Why so worried to the point of getting > away from simple OO sending a message to the Form object and moving to > some kind of relational lookup simply because of a valid package > dependency..? > > If we MUST sterilize the system, Frank seems to have the best > compromise with performance so far with the CASE statement. > Unfortunately it still chips away at the simplicity and also > functionality we have now, such as the ability for an application to > conveniently extend with its own cursor forms. Is it about "feeling > squeaky clean," or is there some bigger payoff I'm missing? Is this > about getting to a smaller core? > > > On Mon, Jun 24, 2013 at 12:43 PM, Frank Shearar <[hidden email]> wrote: >> On 24 June 2013 18:30, tim Rowledge <[hidden email]> wrote: >>> >>> On 24-06-2013, at 5:31 AM, Frank Shearar <[hidden email]> wrote: >>>> You would then write: >>>> >>>> UIManager default showCursor: #wait during: ["stuff"] >>> >>>> snip] >>> >>>> The reason for the icky reflection is to fit in with the existing way >>>> cursors are used. I'd be happy to unroll the #perform: into a #caseOf: >>>> mapping explicitly to the existing cursors. >>>> >>>> Thoughts >>> >>> Well I really dislike seeing #respondsTo: et al in general code so I'd propose something along the lines of a list of known cursors (it's reasonable in my opinion to make that list using reflection at either startup or add-new-cursor time) and then >>> >>> Cursor class >> #named: aSymbol >>> ^ cursorList at: aSymbol ifAbsent:[self normal] >> >> Yep, reflection hides the actual API, and makes things slow as well. >> So in Cursor's particular case, it has loads of classvars with names >> of the form FooCursor, Foo naturally corresponding to the selector >> #foo. So there's CrossHairCursor, BlankCursor, etc. That means you end >> up duplicating the list of cursors (between the set of class vars and >> cursorList), or you make a rather invasive change of ripping out all >> the class vars. A middle ground might be this: >> >> Cursor >> named: aSymbol >> ^ aSymbol caseOf: { >> [#down] -> [self down]. >> [#wait] -> [self wait]. >> } otherwise: [self normal]. >> >> frank >> >>> tim >>> -- >>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >>> Strange OpCodes: CCC: Crash if Carry Clear >>> >>> >>> >> |
|
|
On 25 June 2013 03:12, Chris Muller <[hidden email]> 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. File depends on Graphics solely through Cursor, while Compression depends on Graphics through Cursor, BitBlt and Form. As it happens, this gigantically invasive change would remove exactly one dependency. I'm thus tempted to ignore this apparently low-hanging but rather unripe fruit, at least for the nonce. > 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. That's a good idea. It communicates the intent, rather than the mechanism. > I don't need to be concerned about performance since a hard dependency > to Cursor showWhile: can be maintained. But at least the in-image > "apps" like the Browsers and stuff, performance should not be > noticably affected by their occasional flipping of the cursor, and so > Tims idea of a Dictionary of forms / form names should be plenty fast > enough for that and with ability to extend without changing code by > apps putting into that Dictionary.. I don't mind applications loaded into an image having a dependency on Graphics. What I'm trying to do with #showCursor:during: is avoid unnecessary entanglements in the _base_ image. I see no reason at all why Files or Collections or Compression should depend on Graphics. None of these packages require a UI element. (Compression uses BitBlt, I think, to make use of BitBlt's primitives.) I'm trying to introduce a strictly layered set of packages in the base image, with as few cyclic dependencies (ideally none) as possible. 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. Since Cursor is effectively a(n undelimited) dynamic variable it occurs to me we could signal the start and end of some busy block with Notifications, but Notifications are relatively expensive - linear in the depth of the call stack. In fact I'd _prefer_ to use delimited dynamic variables (through resumable exceptions), because that's friendly to stack slicing. But to make the massive use of delimited dynamic variables performant would probably require VM level changes. So in summary this is kinda-sorta a nice idea, except at the moment it doesn't buy us particularly much. It looked like an easy way to decouple parts of the system, but it isn't. Let's shelve it for now. frank > On Mon, Jun 24, 2013 at 3:50 PM, Chris Muller <[hidden email]> wrote: >> My requirements are that control needs to remain with applications to >> provide feedback about any of a _variety_ of actions a program may be >> *doing* -- not simply how long a user has been waiting. Changing the >> cursor form is already process-intensive enough without needing to >> endure any more performance degradation, please. >> >> I struggle to understand why, for any package that thinks it wants to >> do something graphical like operate on a Cursor, should not depend on >> the Graphics package anyway? Why so worried to the point of getting >> away from simple OO sending a message to the Form object and moving to >> some kind of relational lookup simply because of a valid package >> dependency..? >> >> If we MUST sterilize the system, Frank seems to have the best >> compromise with performance so far with the CASE statement. >> Unfortunately it still chips away at the simplicity and also >> functionality we have now, such as the ability for an application to >> conveniently extend with its own cursor forms. Is it about "feeling >> squeaky clean," or is there some bigger payoff I'm missing? Is this >> about getting to a smaller core? >> >> >> On Mon, Jun 24, 2013 at 12:43 PM, Frank Shearar <[hidden email]> wrote: >>> On 24 June 2013 18:30, tim Rowledge <[hidden email]> wrote: >>>> >>>> On 24-06-2013, at 5:31 AM, Frank Shearar <[hidden email]> wrote: >>>>> You would then write: >>>>> >>>>> UIManager default showCursor: #wait during: ["stuff"] >>>> >>>>> snip] >>>> >>>>> The reason for the icky reflection is to fit in with the existing way >>>>> cursors are used. I'd be happy to unroll the #perform: into a #caseOf: >>>>> mapping explicitly to the existing cursors. >>>>> >>>>> Thoughts >>>> >>>> Well I really dislike seeing #respondsTo: et al in general code so I'd propose something along the lines of a list of known cursors (it's reasonable in my opinion to make that list using reflection at either startup or add-new-cursor time) and then >>>> >>>> Cursor class >> #named: aSymbol >>>> ^ cursorList at: aSymbol ifAbsent:[self normal] >>> >>> Yep, reflection hides the actual API, and makes things slow as well. >>> So in Cursor's particular case, it has loads of classvars with names >>> of the form FooCursor, Foo naturally corresponding to the selector >>> #foo. So there's CrossHairCursor, BlankCursor, etc. That means you end >>> up duplicating the list of cursors (between the set of class vars and >>> cursorList), or you make a rather invasive change of ripping out all >>> the class vars. A middle ground might be this: >>> >>> Cursor >> named: aSymbol >>> ^ aSymbol caseOf: { >>> [#down] -> [self down]. >>> [#wait] -> [self wait]. >>> } otherwise: [self normal]. >>> >>> frank >>> >>>> tim >>>> -- >>>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim >>>> Strange OpCodes: CCC: Crash if Carry Clear >>>> >>>> >>>> >>> > |
Re: Dependencies on Cursor
|
|
Quoting Frank Shearar <[hidden email]>:
> ... > 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? Cheers, Juan Vuletich |
|
|
On Tue, Jun 25, 2013 at 07:16:03AM -0300, Juan Vuletich (mail lists) wrote:
> Quoting Frank Shearar <[hidden email]>: > > >... > >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 |
|
|
On 6/25/13, David T. Lewis <[hidden email]> wrote:
> On Tue, Jun 25, 2013 at 07:16:03AM -0300, Juan Vuletich (mail lists) wrote: >> Quoting Frank Shearar <[hidden email]>: >> >> >... >> >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 > > |
|
|
That reminds me the post from Travis Griggs, citing ideas from Vassili Bykov And I think that Juan's implementation is clearly in this spirit, so +1http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&printTitle=Cursor_consider_showWhile:_[Harmful]&entry=3432339015 2013/6/25 H. Hirzel <[hidden email]>
|
|
|
On 25 June 2013 16:35, Nicolas Cellier
<[hidden email]> 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 <[hidden email]> > >> On 6/25/13, David T. Lewis <[hidden email]> wrote: >> > On Tue, Jun 25, 2013 at 07:16:03AM -0300, Juan Vuletich (mail lists) >> > wrote: >> >> Quoting Frank Shearar <[hidden email]>: >> >> >> >> >... >> >> >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 |
|
|
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 <[hidden email]> On 25 June 2013 16:35, Nicolas Cellier |
|
|
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 <[hidden email]> wrote:
|
|
|
In reply to this post by Nicolas Cellier
On 25-06-2013, at 8:52 AM, Nicolas Cellier <[hidden email]> 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 <[hidden email]> > On 25 June 2013 16:35, Nicolas Cellier > <[hidden email]> wrote: > > That reminds me the post from Travis Griggs, citing ideas from Vassili Bykov That's a pile of good comment right there. Using the cursor all the time was easy and effective when you had very little other choice. We had some discussions a while back about making buttons provide some 'temporarily busy' feedback and part of that was about avoiding cursor changing even within UI code. Non-UI code really ought not ever make cursor changes. The best thing to do in my experience is to use a signal of some variety; an actual Exception might be suited to many cases but other notification mechanisms are possible. Why, we even have some good uses as examples - ProgressMorph, which appears to be unused String>displayProgress*, which is doing the right kind of thing whilst still being overly tied to UI details ProgressInitiationException, which is used by String>displayProgress It seems to me that a slightly more abstract exception would be sensible, so that code might read a bit like this:- foo: thing "do something that might take a while; alert the UI stuff and keep letting the user know things are ok" self prepareForArmageddon. ProgressNotificationAlert initialNotification. "this part is done in discrete steps" listOfStuff do:[wotsit| wotsit thungummy. ProgressNotificationAlert notifiyStepPercentage: wotsit size]. "this bit may take any amount of time, so use a generic beachball/spinner/ticker thing" ProgressNotificationAlert notifyLongJob. thing peformMagicTricks. ProgressNotificationAlert terminateAlert There's plenty of scope for debating the details of whether we ought to put the code in handler block like constructs or whatever. How little code could we make the user have to write? Maybe it could work as simply as the current Cursor message:- foo: thing ProgressNotificationAlert while:[ self prepareForArmageddon. listOfStuff do:[wotsit| wotsit thungummy]. thing peformMagicTricks] tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: NNI: Neglect Next Instruction |
|
|
On 25 June 2013 18:42, tim Rowledge <[hidden email]> wrote:
> > On 25-06-2013, at 8:52 AM, Nicolas Cellier <[hidden email]> 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 <[hidden email]> >> On 25 June 2013 16:35, Nicolas Cellier >> <[hidden email]> wrote: >> > That reminds me the post from Travis Griggs, citing ideas from Vassili Bykov > > That's a pile of good comment right there. Using the cursor all the time was easy and effective when you had very little other choice. We had some discussions a while back about making buttons provide some 'temporarily busy' feedback and part of that was about avoiding cursor changing even within UI code. Non-UI code really ought not ever make cursor changes. The best thing to do in my experience is to use a signal of some variety; an actual Exception might be suited to many cases but other notification mechanisms are possible. Why, we even have some good uses as examples - > ProgressMorph, which appears to be unused > String>displayProgress*, which is doing the right kind of thing whilst still being overly tied to UI details > ProgressInitiationException, which is used by String>displayProgress > > It seems to me that a slightly more abstract exception would be sensible, so that code might read a bit like this:- > > > foo: thing > "do something that might take a while; alert the UI stuff and keep letting the user know things are ok" > self prepareForArmageddon. > ProgressNotificationAlert initialNotification. > "this part is done in discrete steps" > listOfStuff do:[wotsit| > wotsit thungummy. > ProgressNotificationAlert notifiyStepPercentage: wotsit size]. > "this bit may take any amount of time, so use a generic beachball/spinner/ticker thing" > ProgressNotificationAlert notifyLongJob. > thing peformMagicTricks. > ProgressNotificationAlert terminateAlert This is kind've what I was thinking when nattering about Cursor being like an undelimited dynamic variable. Using resumable exceptions could conceivably let the code above respond to the UI, not just notify the UI of changes. I just worry about performance, but maybe I should worry about that when it's a problem. Or: there's plenty of scope for improving Morphic performance _anyway_, so don't worry about this hit. frank > There's plenty of scope for debating the details of whether we ought to put the code in handler block like constructs or whatever. How little code could we make the user have to write? Maybe it could work as simply as the current Cursor message:- > > foo: thing > ProgressNotificationAlert while:[ > self prepareForArmageddon. > listOfStuff do:[wotsit| > wotsit thungummy]. > thing peformMagicTricks] > > > > > tim > -- > tim Rowledge; [hidden email]; http://www.rowledge.org/tim > Strange OpCodes: NNI: Neglect Next Instruction > > > |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |