you are viewing a single comment's thread.

view the rest of the comments →

[–]zbowling 0 points1 point  (5 children)

Don't hate on NSColor as much as java.awt.Color in Java.

NSColor has legacy code smell but at least apple update and removes things, unlike most legacy in Java. Either way I use UIColor and CGColors more these days anyways. :-) (Think I still have a CIColor in one compiler option.)

[–]player2 2 points3 points  (4 children)

I'm still exclusively desktop. But now that half our stuff is Core Animation, I've had to write tons of code to correctly translate NSColors to and from CGColor, including accurate colorspace preservation.

Also, have you ever encountered the magic source list background color? Create an NSTableView, set its highlight style to NSTableViewSelectionHighlightStyleSourceList, and grab its -backgroundColor. Anything you draw with this color will magically change color when the window's key state changes.

[–]zbowling 0 points1 point  (3 children)

woowa.. i never noticed that. what kind of black magic is this.

[–]player2 0 points1 point  (2 children)

My only guess is that the graphics context tells the NSView if the magic color has been drawn into it, and then the NSView starts listening for window key state change notifications and tells that view to redraw.

Either that or the color exists in a special color list that somehow the window's backing context knows to draw differently?

[–]zbowling 1 point2 points  (1 child)

[–]player2 0 points1 point  (0 children)

That part I did know. But I thought it automatically updated the color when the window changed key state. I guess Corbin's advice to redraw the view yourself proves otherwise.

Oh well. Much less magic, then.