Re: Mutable NSColor?
Re: Mutable NSColor?
- Subject: Re: Mutable NSColor?
- From: Ali Ozer <email@hidden>
- Date: Mon, 24 Sep 2001 09:18:57 -0700
From the NSColor.h header file: "Subclassers of NSColor need to
implement the methods colorSpaceName, set, the various methods which
return the components for that color space, and the NSCoding protocol.
Some other methods such as colorWithAlphaComponent:, isEqual:,
colorUsingColorSpaceName:device: may also be implemented if they make
sense for the colorspace. Mutable subclassers (if any) should also
implement copyWithZone: to a true copy."
So as long as you've done this stuff, you should be fine. You also need
an initializer that makes sense to you. Either
"initWithRed:green:blue:alpha:", or, given you're mutable, just init
might be fine.
One way to implement some of this stuff is to keep r, g, b, a as floats
like you say; implement the primitives mentioned above; return the r, g,
etc when asked for redComponent, etc; and when you're sent a method you
can't answer easily (for instance, colorUsingColorSpaceName:device:),
simply (lazily) create an NSColor with your r, g, b, a, ask it the
question. You can also cache that most recently created NSColor for
performance reasons. If and when your color is mutated, throw the cached
color away.
Ali
On Monday, September 24, 2001, at 06:33 AM, Rob Rix wrote:
>
... I ended up just making a really simple (five-minute code, like)
>
class which manages four floats (r, g, b, a) and can translate to and
>
from NSColor. Only real difference is that mine isn't as versatile (no
>
CMYK, et cetera), and mine is mutable.