• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: What paradigm behind NSColor's drawing methods?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What paradigm behind NSColor's drawing methods?


  • Subject: Re: What paradigm behind NSColor's drawing methods?
  • From: glenn andreas <email@hidden>
  • Date: Fri, 1 Feb 2008 14:47:17 -0600


On Feb 1, 2008, at 1:41 PM, Jerry Krinock wrote:

I've always been amazed by -[NSColor set], which "Sets the color of subsequent drawing to the color that the receiver represents".

This seems absurd. Instead of affecting the receiver, the receiver is affecting some other object, and the identify of the affected object is not even hinted at.

Instead, I would expect there to be a method like like:

   -[NSGraphicsContext setColor:(NSColor*)]

and then you could also have a getter (and I cannot find a real-life equivalent of this),

   -(NSColor*)[NSGraphicsContext color]

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?


Pretty much none of the drawing operations take a context - you don't do "[[[NSGraphicsContext] currentContext] fillPath: aBezierPath]" nor is there "[[[NSGraphicsContext currentContext] drawImage: anImage atPoint: aPoint fromRect: aRect ...]" nor similar for string drawing. Also, none of the "procedural" drawing routines (NSFillRect, etc...) take a graphics context.

Basically, anything that draws effects the the current context, and if you want to change that for setting color, you'd want to do it everywhere, and adding an explicit context to every single drawing related operation would be a major pain.

The paradigm behind NSColor is no different than any of the other ones. It doesn't seem absurd, or even out of line for how other graphics based APIs work (after all, glSetColor() doesn't take a glContext either, nor did Quickdraw SetColor(), etc...). You could wonder if (fill and stroke) color should be an attribute of the bezier path instead, like line width is (or like it was on QuickdrawGX), but that's a different philosophy.

And in reality, it works well as is - I've never had a problem where I set the color of the wrong drawing context (the only problem I've ever has was not remembering to set it appropriately beforehand). What circumstances are you running into that not having an explicit drawing context parameter is a problem?


Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium | prime : build, mutate, evolve, animate : the next generation of fractal art




_______________________________________________

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


  • Follow-Ups:
    • Re: What paradigm behind NSColor's drawing methods?
      • From: Jerry Krinock <email@hidden>
References: 
 >What paradigm behind NSColor's drawing methods? (From: Jerry Krinock <email@hidden>)

  • Prev by Date: Re: Need some help with fetch requests
  • Next by Date: Setting to not open document at startup?
  • Previous by thread: What paradigm behind NSColor's drawing methods?
  • Next by thread: Re: What paradigm behind NSColor's drawing methods?
  • Index(es):
    • Date
    • Thread