Re: [SOLVED, with reservations] Re: Turn off menu highlight in outline view?
Re: [SOLVED, with reservations] Re: Turn off menu highlight in outline view?
- Subject: Re: [SOLVED, with reservations] Re: Turn off menu highlight in outline view?
- From: Corbin Dunn <email@hidden>
- Date: Tue, 18 Aug 2009 07:15:22 -0700
On Aug 17, 2009, at 7:22 PM, Adam R. Maxwell wrote:
On Aug 17, 2009, at 11:54 AM, Quincey Morris wrote:
On Aug 17, 2009, at 11:14, I. Savant wrote:
I'm not sure what you mean here, but I'm fairly sure I disagree. :-D
This is one step in the right direction. One. At least, insofar as
"we heard a very common request and, in the interests of
consistency and promoting good-looking apps on our platform, we
will address it."
OK, source lists were a fairly weak example. I guess what I meant
was -- in API terms -- source lists are "just" a stylistic variant,
whereas in fact they likely have behavioral differences too, in a
lot of scenarios. But there are no source list APIs, just indirect
sort-of customizations (like outlineView:isGroupItem:).
I like the source list example, having tried to use it with a
subclass of NSTextFieldCell. NSTableView evidently uses SPI to get
the proper bold and shadow attributes on the text; even with the new
background style API, you still can't make it draw text correctly
with a subclass [1].
That is a good point. FWIW, it doesn't use any SPI -- it just turns
the standard "string value" into an "attributed string value". The
attributes are defined by our design team, and may change at any time.
Currently, they are:
1. Appropriate NSForegroundColorAttributeName color:
Normal: [NSColor colorWithCalibratedRed:96.0/255.0 green:
110.0/255.0 blue:128.0/255.0 alpha:1.0];
Inactive: [NSColor colorWithCalibratedWhite:0 alpha:0.6];
2. Bold NSFontAttributeName, ie:
[[NSFontManager sharedFontManager] convertFont:font
toHaveTrait:NSBoldFontMask];
or
[NSFont boldSystemFontOfSize:pointSize];
(Converting a font is slower than using the system bold font).
3. The kerning is changed to make it tighter:
[result setObject:[NSNumber numberWithDouble:0.2]
forKey:NSKernAttributeName];
But, as I said, they may change at anytime. Using a standard
NSTextCell (for the group headers in a source list), is the best
solution.
-- Cells. Using cells to encapsulate drawing and interaction is
fine as an implementation detail, but exposing cells as a technique
of class customization is a real PITA. Cell programming, beyond the
simplest of overrides, is no fun at all (cells are on my short list
of cliff-ready experiments too), and there just isn't a wide enough
range of standard cells to meet the demand for customizations.
Yes! I loathe working with NSCell. If you want variable height
rows and an ImageAndTextCell, you have to subclass NSTextFieldCell
to make it draw vertically centered...and then fix the same problem
for editing. And fix your expansion cell rects. And the focus
ring. And probably a few other things that I'm too lazy to look up
right now :).
Unfortunately, trying to figure out which NSCell methods to override
is almost impossible, since so many of them seem redundant (how many
people understand how cellSize, cellSizeForBounds,
imageRectForBounds, titleRectForBounds, and drawingRectForBounds are
related? or calcSize and calcDrawInfo:?). For additional
confusion, lots of NSImageCell and NSTextFieldCell-specific methods
are in NSCell...but which ones? I don't think documentation can
even help at this point; I just keep hoping NSCell will be pushed
over the cliff and replaced by something "very simple and light
weight" [2].
Your comments, and what everyone else has said, is great information.
I still encourage people to log their requests into our bug tracking
system, Radar.
--corbin
_______________________________________________
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