On 25 June 2013 03:12, Chris Muller <asqueaker at gmail.com> 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 <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
>>>>
>>>>
>>>>
>>>
>