Re: Work on NSColor

[Fred Kiefer]

> I would like to discuss some changes on NSColor. 
> 
> NSColor is currently a concrete class capable to store all the possible
> values for all different NSColor types. I would like to change NSColor
> into an abstract class with one concrete subclass per colour space. So
> we would have calibrated RGB colours and device specific RGB colours and
> all the other types each coming from a different class (all inheriting
> from NSColor).
> 
> What would be the benefit of this? The structure of those classes would
> be closer to the documentation, all objects would be smaller and
> additional colour classes would fit in easier (Including named colours,
> which are currently not supported). NSColor objects would really be
> immutable. But the biggest benefit would be that colours for different
> devices would later on really be specific for that device.
> 
> On the other hand there are of course some drawbacks:
> Converting a colour to a different colour space would cost each time not
> just once. (Or we have to implement some kind of conversion caching)
> 
> The changes in more detail: We will have different concrete classes for 
> - calibrated RGB 
> - device specific RGB
> - calibrated Grey
> - device specific Gary
> - device specific CMYB
> - named colours
> 
> RGB colours would include the corresponding HSB values.
> The [set] method would convert a calibrated or named colour to the
> corresponding device specific colour for the current output device and
> [set] that.
> Converting a named colour (and thereby also setting) a named colour
> would involve a lookup at the corresponding colour list.
> 

I finally did do those changes I announced on the first day of this
year. All colours are now much smaller in memory usage and all methods
on them should be much faster. The only exception being multiple calls
to the same colour conversion, as those are no longer cached.
The concrete subclasses of NSColor now archive themselves, this is done
to allow NSColor to still load the old archives. We could as well decide
not to use these classes in archives and do all the coding in NSColor,
but than it will be harder to keep compatibility with old archives and
still use an efficient format for new ones.

I did not do the second recommend change, to return named colours from
the colour list "System" for the system colours. I am not sure, where
these colours would/should be converted to device colours.