[squeak-dev] Dependencies on Cursor

Chris Muller asqueaker at gmail.com
Tue Jun 25 02:12:08 UTC 2013


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 <asqueaker at gmail.com> 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 <frank.shearar at gmail.com> wrote:
>> On 24 June 2013 18:30, tim Rowledge <tim at rowledge.org> wrote:
>>>
>>> On 24-06-2013, at 5:31 AM, Frank Shearar <frank.shearar at gmail.com> 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; tim at rowledge.org; http://www.rowledge.org/tim
>>> Strange OpCodes: CCC: Crash if Carry Clear
>>>
>>>
>>>
>>


More information about the Squeak-dev mailing list