[MCP] [Q] Color change notification
Ned Konz
ned at bike-nomad.com
Tue Mar 18 17:01:18 UTC 2003
On Tuesday 18 March 2003 08:35 am, Bill Spight wrote:
> Dear Ned,
>
> > Of course, in Morph all changed does is invalidate the rectangle.
> > It's not the same as Object>>changed (i.e. it's not a change
> > notification).
>
> Then why in the world should Morph>>color: invalidate the
> rectangle?????
Because invalidating the rectangle will eventually force a redraw,
which is necessary because the Morph may have changed color. Same
reason that extent: (eventually) calls #changed.
> How about this? Change Morph>>color: to
>
> color: aColor
> "Change the receiver's color. Directly set the color if
> appropriate, else go by way of fillStyle. Notify of color change.
> (To set the color initially, use #defaultColor.)"
>
> (aColor isColor or: [aColor isKindOf: InfiniteForm]) ifFalse:[^
> self fillStyle: aColor].
> color = aColor ifFalse:
> [self removeProperty: #fillStyle.
> color _ aColor.
> self colorChanged]
> ^^^^^^^^^^^^
> (Note also changes to comment.)
>
> Calling the new method "colorChanged" is consistent with other
> usage, such as "layoutChanged".
And it would mean that color had been set to either a Color or
InfiniteForm? Would there be a similar notification for
fillStyleChanged?
I really don't like the distinction between Color, InfiniteForm, and
FillStyle. I'd much rather see the instvar "color" become
"fillStyle", ditching the fillStyle property. It would be easy to
convert Morphs on filein or in the image.
And then color: would set fillStyle to a SolidFillStyle, etc., and
color would be defined as:
color
^fillStyle asColor
--
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE
More information about the Squeak-dev
mailing list
|