Re: What paradigm behind NSColor's drawing methods?
Re: What paradigm behind NSColor's drawing methods?
- Subject: Re: What paradigm behind NSColor's drawing methods?
- From: Peter Ammon <email@hidden>
- Date: Fri, 1 Feb 2008 16:23:29 -0800
On Feb 1, 2008, at 11:41 AM, Jerry Krinock wrote:
I've just re-read the Cocoa Drawing Guide but still can't
comprehend the paradigm behind NSColor's -set, -setFill, -setStroke
etc. Can someone please straighten me out? Or are these methods
the unfortunate legacy of some bad decision made 15 years ago?
Unlike some other frameworks, NSColor can be subclassed, and
NSGraphicsContext cannot know how to handle arbitrary NSColor
subclasses.
For example, [[NSColor selectedMenuItemColor] set] sets a pattern
color into the context, with the actual pattern depending on several
factors, including whether Aqua or Graphite is chosen in System
Prefs. It also modifies the pattern phase of the context. There's
no way for NSGraphicsContext to know it needed to do those things for
an arbitrary NSColor.
"Dumb" value-type colors could be set directly on the graphics
context (which is more or less what Quartz does). If you have
"smart" object colors, that can do arbitrarily sophisticated things
to the graphics context, then those smarts need to live in the color
class itself.
-Peter
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden