[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