- outlineView:willDisplayCell:forTableColumn:item: and selected item
-
In my outline view, I'm using an NSTextFieldCell and setting the item's
color via setTextColor:.
This works fine, but for some colors, it's almost impossible to see when
the item is selected. I'd like to always make the text white if the item
is selected.
In Leopard, I know I can use [cell backgroundStyle] ==
NSBackgroundStyleDark to check this, but I was wondering if there is any
easy check for Tiger and below. I can actually go through the
machinations of asking the outline view if the item is selected, but it
seems a lot more heavyweight. You have to do:
[[outlineView selectedRowIndexes] containsIndex:[outlineView
rowForItem:item]]
And I'm not sure just how fast that is, but it can't be as fast as just
asking the cell "are you selected" :) -
The pre-leopard code isn't pretty. The AppKit relnotes give the old
path while motivating the backgroundStyle API. I'm not sure if this
is 100% complete..> Prior to Leopard, you may have noticed that text turns white in selected table view rows. The
> mechanism that controlled this behavior, unfortunately, was arcane. The table would set the
> highlight color of the cell to the alternateSelectedControlColor and set the cell to be highlighted.
> The cell would then introspect its highlight color, and use white text if the color was the
> alternateSelectedControlColor.
You probably have a constrained case, so it may suffice to check
-isHighlighted.
It'd be nice if you could use the Leopard API on Leopard or later, as
we might try to be a little bit more clever about when the text
actually turns white. Ideally the text wouldn't turn white if the
user's chosen selection color was sufficiently light. There's scope
for making that work in the backgroundStyle API.
-Ken
On Mon, Feb 25, 2008 at 5:12 PM, John Stiles <JStiles...> wrote:> In my outline view, I'm using an NSTextFieldCell and setting the item's
> color via setTextColor:.
>
> This works fine, but for some colors, it's almost impossible to see when
> the item is selected. I'd like to always make the text white if the item
> is selected.
>
> In Leopard, I know I can use [cell backgroundStyle] ==
> NSBackgroundStyleDark to check this, but I was wondering if there is any
> easy check for Tiger and below. I can actually go through the
> machinations of asking the outline view if the item is selected, but it
> seems a lot more heavyweight. You have to do:
>
> [[outlineView selectedRowIndexes] containsIndex:[outlineView
> rowForItem:item]]
>
> And I'm not sure just how fast that is, but it can't be as fast as just
> asking the cell "are you selected" :)
> -
Also, I'd be pretty surprised if this actually showed up in perf
profiling. Do you mean 'heavyweight', or annoying? :-)>> but it seems a lot more heavyweight. You have to do:
>>
>> [[outlineView selectedRowIndexes] containsIndex:[outlineView rowForItem:item]]
-Ken
On Mon, Feb 25, 2008 at 6:26 PM, Ken Ferry <kenferry...> wrote:> The pre-leopard code isn't pretty. The AppKit relnotes give the old
> path while motivating the backgroundStyle API. I'm not sure if this
> is 100% complete..
>
>> Prior to Leopard, you may have noticed that text turns white in selected table view rows. The
>> mechanism that controlled this behavior, unfortunately, was arcane. The table would set the
>> highlight color of the cell to the alternateSelectedControlColor and set the cell to be highlighted.
>> The cell would then introspect its highlight color, and use white text if the color was the
>> alternateSelectedControlColor.
>
> You probably have a constrained case, so it may suffice to check
> -isHighlighted.
>
> It'd be nice if you could use the Leopard API on Leopard or later, as
> we might try to be a little bit more clever about when the text
> actually turns white. Ideally the text wouldn't turn white if the
> user's chosen selection color was sufficiently light. There's scope
> for making that work in the backgroundStyle API.
>
> -Ken
>
>
>
>
> On Mon, Feb 25, 2008 at 5:12 PM, John Stiles <JStiles...> wrote:
>> In my outline view, I'm using an NSTextFieldCell and setting the item's
>> color via setTextColor:.
>>
>> This works fine, but for some colors, it's almost impossible to see when
>> the item is selected. I'd like to always make the text white if the item
>> is selected.
>>
>> In Leopard, I know I can use [cell backgroundStyle] ==
>> NSBackgroundStyleDark to check this, but I was wondering if there is any
>> easy check for Tiger and below. I can actually go through the
>> machinations of asking the outline view if the item is selected, but it
>> seems a lot more heavyweight. You have to do:
>>
>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
>> rowForItem:item]]
>>
>> And I'm not sure just how fast that is, but it can't be as fast as just
>> asking the cell "are you selected" :)
>>
> -
Six of one and a half dozen of the other? :)
Anyway, it looks like this does the trick:
([cell isHighlighted] && [[outlineView window] isKeyWindow] &&
[[outlineView window] firstResponder] == outlineView)
Not quite as clean and nice as "backgroundStyle" but it will have to do
for now :)
Ken Ferry wrote:> Also, I'd be pretty surprised if this actually showed up in perf
> profiling. Do you mean 'heavyweight', or annoying? :-)
>
>
>>> but it seems a lot more heavyweight. You have to do:
>>>
>>> [[outlineView selectedRowIndexes] containsIndex:[outlineView rowForItem:item]]
>>
>
> -Ken
>
> On Mon, Feb 25, 2008 at 6:26 PM, Ken Ferry <kenferry...> wrote:
>
>> The pre-leopard code isn't pretty. The AppKit relnotes give the old
>> path while motivating the backgroundStyle API. I'm not sure if this
>> is 100% complete..
>>
>>> Prior to Leopard, you may have noticed that text turns white in selected table view rows. The
>>> mechanism that controlled this behavior, unfortunately, was arcane. The table would set the
>>> highlight color of the cell to the alternateSelectedControlColor and set the cell to be highlighted.
>>> The cell would then introspect its highlight color, and use white text if the color was the
>>> alternateSelectedControlColor.
>>
>> You probably have a constrained case, so it may suffice to check
>> -isHighlighted.
>>
>> It'd be nice if you could use the Leopard API on Leopard or later, as
>> we might try to be a little bit more clever about when the text
>> actually turns white. Ideally the text wouldn't turn white if the
>> user's chosen selection color was sufficiently light. There's scope
>> for making that work in the backgroundStyle API.
>>
>> -Ken
>>
>>
>>
>>
>> On Mon, Feb 25, 2008 at 5:12 PM, John Stiles <JStiles...> wrote:
>>> In my outline view, I'm using an NSTextFieldCell and setting the item's
>>> color via setTextColor:.
>>>
>>> This works fine, but for some colors, it's almost impossible to see when
>>> the item is selected. I'd like to always make the text white if the item
>>> is selected.
>>>
>>> In Leopard, I know I can use [cell backgroundStyle] ==
>>> NSBackgroundStyleDark to check this, but I was wondering if there is any
>>> easy check for Tiger and below. I can actually go through the
>>> machinations of asking the outline view if the item is selected, but it
>>> seems a lot more heavyweight. You have to do:
>>>
>>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
>>> rowForItem:item]]
>>>
>>> And I'm not sure just how fast that is, but it can't be as fast as just
>>> asking the cell "are you selected" :)
>>>
>>
>> -
Actually, for what it's worth, I did just hit one snag. If you attempt
to edit the cell, the field editor inherits the white color! This makes
it pretty difficult to see what you're doing ;)
I have a custom field editor anyway and have lots of control over how
the edit process gets started, so it was no problem to force the field
editor to use the actual item color, but I figured this was worth
mentioning, for the archives if nothing else.
John Stiles wrote:> Six of one and a half dozen of the other? :)
> Anyway, it looks like this does the trick:
> ([cell isHighlighted] && [[outlineView window] isKeyWindow] &&
> [[outlineView window] firstResponder] == outlineView)
>
> Not quite as clean and nice as "backgroundStyle" but it will have to
> do for now :)
>
> Ken Ferry wrote:
>> Also, I'd be pretty surprised if this actually showed up in perf
>> profiling. Do you mean 'heavyweight', or annoying? :-)
>>
>>
>>>> but it seems a lot more heavyweight. You have to do:
>>>>
>>>> [[outlineView selectedRowIndexes] containsIndex:[outlineView rowForItem:item]]
>>>
>>
>> -Ken
>>
>> On Mon, Feb 25, 2008 at 6:26 PM, Ken Ferry <kenferry...> wrote:
>>
>>> The pre-leopard code isn't pretty. The AppKit relnotes give the old
>>> path while motivating the backgroundStyle API. I'm not sure if this
>>> is 100% complete..
>>>
>>>> Prior to Leopard, you may have noticed that text turns white in selected table view rows. The
>>>> mechanism that controlled this behavior, unfortunately, was arcane. The table would set the
>>>> highlight color of the cell to the alternateSelectedControlColor and set the cell to be highlighted.
>>>> The cell would then introspect its highlight color, and use white text if the color was the
>>>> alternateSelectedControlColor.
>>>
>>> You probably have a constrained case, so it may suffice to check
>>> -isHighlighted.
>>>
>>> It'd be nice if you could use the Leopard API on Leopard or later, as
>>> we might try to be a little bit more clever about when the text
>>> actually turns white. Ideally the text wouldn't turn white if the
>>> user's chosen selection color was sufficiently light. There's scope
>>> for making that work in the backgroundStyle API.
>>>
>>> -Ken
>>>
>>>
>>>
>>>
>>> On Mon, Feb 25, 2008 at 5:12 PM, John Stiles <JStiles...> wrote:
>>>> In my outline view, I'm using an NSTextFieldCell and setting the item's
>>>> color via setTextColor:.
>>>>
>>>> This works fine, but for some colors, it's almost impossible to see when
>>>> the item is selected. I'd like to always make the text white if the item
>>>> is selected.
>>>>
>>>> In Leopard, I know I can use [cell backgroundStyle] ==
>>>> NSBackgroundStyleDark to check this, but I was wondering if there is any
>>>> easy check for Tiger and below. I can actually go through the
>>>> machinations of asking the outline view if the item is selected, but it
>>>> seems a lot more heavyweight. You have to do:
>>>>
>>>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
>>>> rowForItem:item]]
>>>>
>>>> And I'm not sure just how fast that is, but it can't be as fast as just
>>>> asking the cell "are you selected" :)
>>>>
>>>
>>> -
The way NSCell deals with this is that the white color is never part
of the value data itself, it's thought of as a draw-time visual
effect.
That is, rather than calling setTextColor, you could override
-drawInteriorWithFrame:inView:.
-Ken
On Tue, Feb 26, 2008 at 11:35 AM, John Stiles <JStiles...> wrote:>
> Actually, for what it's worth, I did just hit one snag. If you attempt to
> edit the cell, the field editor inherits the white color! This makes it
> pretty difficult to see what you're doing ;)
>
> I have a custom field editor anyway and have lots of control over how the
> edit process gets started, so it was no problem to force the field editor to
> use the actual item color, but I figured this was worth mentioning, for the
> archives if nothing else.
>
>
>
>
> John Stiles wrote:
> Six of one and a half dozen of the other? :)
> Anyway, it looks like this does the trick:
> ([cell isHighlighted] && [[outlineView window] isKeyWindow] &&
> [[outlineView window] firstResponder] == outlineView)
>
> Not quite as clean and nice as "backgroundStyle" but it will have to do for
> now :)
>
> Ken Ferry wrote:
> Also, I'd be pretty surprised if this actually showed up in perf
> profiling. Do you mean 'heavyweight', or annoying? :-)
>
>
>
>> but it seems a lot more heavyweight. You have to do:
>>
>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
> rowForItem:item]]
>
> -Ken
>
> On Mon, Feb 25, 2008 at 6:26 PM, Ken Ferry <kenferry...> wrote:
>
>
> The pre-leopard code isn't pretty. The AppKit relnotes give the old
> path while motivating the backgroundStyle API. I'm not sure if this
> is 100% complete..
>
>> Prior to Leopard, you may have noticed that text turns white in selected
> table view rows. The
>> mechanism that controlled this behavior, unfortunately, was arcane. The
> table would set the
>> highlight color of the cell to the alternateSelectedControlColor and set
> the cell to be highlighted.
>> The cell would then introspect its highlight color, and use white text if
> the color was the
>> alternateSelectedControlColor.
>
> You probably have a constrained case, so it may suffice to check
> -isHighlighted.
>
> It'd be nice if you could use the Leopard API on Leopard or later, as
> we might try to be a little bit more clever about when the text
> actually turns white. Ideally the text wouldn't turn white if the
> user's chosen selection color was sufficiently light. There's scope
> for making that work in the backgroundStyle API.
>
> -Ken
>
>
>
>
> On Mon, Feb 25, 2008 at 5:12 PM, John Stiles <JStiles...> wrote:
>> In my outline view, I'm using an NSTextFieldCell and setting the item's
>> color via setTextColor:.
>>
>> This works fine, but for some colors, it's almost impossible to see when
>> the item is selected. I'd like to always make the text white if the item
>> is selected.
>>
>> In Leopard, I know I can use [cell backgroundStyle] ==
>> NSBackgroundStyleDark to check this, but I was wondering if there is any
>> easy check for Tiger and below. I can actually go through the
>> machinations of asking the outline view if the item is selected, but it
>> seems a lot more heavyweight. You have to do:
>>
>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
>> rowForItem:item]]
>>
>> And I'm not sure just how fast that is, but it can't be as fast as just
>> asking the cell "are you selected" :)
>>
>
>
> -
What would I do in my override? Temporarily set the text color, call
super, and then revert it back?
Ken Ferry wrote:> The way NSCell deals with this is that the white color is never part
> of the value data itself, it's thought of as a draw-time visual
> effect.
>
> That is, rather than calling setTextColor, you could override
> -drawInteriorWithFrame:inView:.
>
> -Ken
>
> On Tue, Feb 26, 2008 at 11:35 AM, John Stiles <JStiles...> wrote:
>
>> Actually, for what it's worth, I did just hit one snag. If you attempt to
>> edit the cell, the field editor inherits the white color! This makes it
>> pretty difficult to see what you're doing ;)
>>
>> I have a custom field editor anyway and have lots of control over how the
>> edit process gets started, so it was no problem to force the field editor to
>> use the actual item color, but I figured this was worth mentioning, for the
>> archives if nothing else.
>>
>>
>>
>>
>> John Stiles wrote:
>> Six of one and a half dozen of the other? :)
>> Anyway, it looks like this does the trick:
>> ([cell isHighlighted] && [[outlineView window] isKeyWindow] &&
>> [[outlineView window] firstResponder] == outlineView)
>>
>> Not quite as clean and nice as "backgroundStyle" but it will have to do for
>> now :)
>>
>> Ken Ferry wrote:
>> Also, I'd be pretty surprised if this actually showed up in perf
>> profiling. Do you mean 'heavyweight', or annoying? :-)
>>
>>
>>
>>> but it seems a lot more heavyweight. You have to do:
>>>
>>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
>> rowForItem:item]]
>>
>> -Ken
>>
>> On Mon, Feb 25, 2008 at 6:26 PM, Ken Ferry <kenferry...> wrote:
>>
>>
>> The pre-leopard code isn't pretty. The AppKit relnotes give the old
>> path while motivating the backgroundStyle API. I'm not sure if this
>> is 100% complete..
>>
>>> Prior to Leopard, you may have noticed that text turns white in selected
>> table view rows. The
>>> mechanism that controlled this behavior, unfortunately, was arcane. The
>> table would set the
>>> highlight color of the cell to the alternateSelectedControlColor and set
>> the cell to be highlighted.
>>> The cell would then introspect its highlight color, and use white text if
>> the color was the
>>> alternateSelectedControlColor.
>>
>> You probably have a constrained case, so it may suffice to check
>> -isHighlighted.
>>
>> It'd be nice if you could use the Leopard API on Leopard or later, as
>> we might try to be a little bit more clever about when the text
>> actually turns white. Ideally the text wouldn't turn white if the
>> user's chosen selection color was sufficiently light. There's scope
>> for making that work in the backgroundStyle API.
>>
>> -Ken
>>
>>
>>
>>
>> On Mon, Feb 25, 2008 at 5:12 PM, John Stiles <JStiles...> wrote:
>>> In my outline view, I'm using an NSTextFieldCell and setting the item's
>>> color via setTextColor:.
>>>
>>> This works fine, but for some colors, it's almost impossible to see when
>>> the item is selected. I'd like to always make the text white if the item
>>> is selected.
>>>
>>> In Leopard, I know I can use [cell backgroundStyle] ==
>>> NSBackgroundStyleDark to check this, but I was wondering if there is any
>>> easy check for Tiger and below. I can actually go through the
>>> machinations of asking the outline view if the item is selected, but it
>>> seems a lot more heavyweight. You have to do:
>>>
>>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
>>> rowForItem:item]]
>>>
>>> And I'm not sure just how fast that is, but it can't be as fast as just
>>> asking the cell "are you selected" :)
>>>
>>
>>
>>
>> -
No, you'd draw whatever you feel like drawing, possibly after
processing it. You'd use methods from NSStringDrawing. It's also
sometimes convenient to delegate drawing to what you think of as a
subcell - I'd try to do that before pulling tricks like temporarily
modifying self across a call to a superclass method.
This would opt you out of NSCell's built-in processing, so you'd at
least want to limit it to older OSes, and may have other bad aspects
to it. I'm not really advocating this path, this is more or less just
an FYI as to how the framework works.
-Ken
On Tue, Feb 26, 2008 at 1:26 PM, John Stiles <JStiles...> wrote:> What would I do in my override? Temporarily set the text color, call
> super, and then revert it back?
>
>
>
>
> Ken Ferry wrote:
>> The way NSCell deals with this is that the white color is never part
>> of the value data itself, it's thought of as a draw-time visual
>> effect.
>>
>> That is, rather than calling setTextColor, you could override
>> -drawInteriorWithFrame:inView:.
>>
>> -Ken
>>
>> On Tue, Feb 26, 2008 at 11:35 AM, John Stiles <JStiles...> wrote:
>>
>>> Actually, for what it's worth, I did just hit one snag. If you attempt to
>>> edit the cell, the field editor inherits the white color! This makes it
>>> pretty difficult to see what you're doing ;)
>>>
>>> I have a custom field editor anyway and have lots of control over how the
>>> edit process gets started, so it was no problem to force the field editor to
>>> use the actual item color, but I figured this was worth mentioning, for the
>>> archives if nothing else.
>>>
>>>
>>>
>>>
>>> John Stiles wrote:
>>> Six of one and a half dozen of the other? :)
>>> Anyway, it looks like this does the trick:
>>> ([cell isHighlighted] && [[outlineView window] isKeyWindow] &&
>>> [[outlineView window] firstResponder] == outlineView)
>>>
>>> Not quite as clean and nice as "backgroundStyle" but it will have to do for
>>> now :)
>>>
>>> Ken Ferry wrote:
>>> Also, I'd be pretty surprised if this actually showed up in perf
>>> profiling. Do you mean 'heavyweight', or annoying? :-)
>>>
>>>
>>>
>>>> but it seems a lot more heavyweight. You have to do:
>>>>
>>>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
>>> rowForItem:item]]
>>>
>>> -Ken
>>>
>>> On Mon, Feb 25, 2008 at 6:26 PM, Ken Ferry <kenferry...> wrote:
>>>
>>>
>>> The pre-leopard code isn't pretty. The AppKit relnotes give the old
>>> path while motivating the backgroundStyle API. I'm not sure if this
>>> is 100% complete..
>>>
>>>> Prior to Leopard, you may have noticed that text turns white in selected
>>> table view rows. The
>>>> mechanism that controlled this behavior, unfortunately, was arcane. The
>>> table would set the
>>>> highlight color of the cell to the alternateSelectedControlColor and set
>>> the cell to be highlighted.
>>>> The cell would then introspect its highlight color, and use white text if
>>> the color was the
>>>> alternateSelectedControlColor.
>>>
>>> You probably have a constrained case, so it may suffice to check
>>> -isHighlighted.
>>>
>>> It'd be nice if you could use the Leopard API on Leopard or later, as
>>> we might try to be a little bit more clever about when the text
>>> actually turns white. Ideally the text wouldn't turn white if the
>>> user's chosen selection color was sufficiently light. There's scope
>>> for making that work in the backgroundStyle API.
>>>
>>> -Ken
>>>
>>>
>>>
>>>
>>> On Mon, Feb 25, 2008 at 5:12 PM, John Stiles <JStiles...> wrote:
>>>> In my outline view, I'm using an NSTextFieldCell and setting the item's
>>>> color via setTextColor:.
>>>>
>>>> This works fine, but for some colors, it's almost impossible to see when
>>>> the item is selected. I'd like to always make the text white if the item
>>>> is selected.
>>>>
>>>> In Leopard, I know I can use [cell backgroundStyle] ==
>>>> NSBackgroundStyleDark to check this, but I was wondering if there is any
>>>> easy check for Tiger and below. I can actually go through the
>>>> machinations of asking the outline view if the item is selected, but it
>>>> seems a lot more heavyweight. You have to do:
>>>>
>>>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
>>>> rowForItem:item]]
>>>>
>>>> And I'm not sure just how fast that is, but it can't be as fast as just
>>>> asking the cell "are you selected" :)
>>>>
>>>
>>>
>>>
>>>
> -
Trying to simulate the drawing behavior of NSCell seems error-prone to
me. Since I don't have access to the original code, it would be hard to
match its behavior. I'd much rather inherit as much as I can and only
customize around the edges.
Ken Ferry wrote:> No, you'd draw whatever you feel like drawing, possibly after
> processing it. You'd use methods from NSStringDrawing. It's also
> sometimes convenient to delegate drawing to what you think of as a
> subcell - I'd try to do that before pulling tricks like temporarily
> modifying self across a call to a superclass method.
>
> This would opt you out of NSCell's built-in processing, so you'd at
> least want to limit it to older OSes, and may have other bad aspects
> to it. I'm not really advocating this path, this is more or less just
> an FYI as to how the framework works.
>
> -Ken
>
> On Tue, Feb 26, 2008 at 1:26 PM, John Stiles <JStiles...> wrote:
>
>> What would I do in my override? Temporarily set the text color, call
>> super, and then revert it back?
>>
>>
>>
>>
>> Ken Ferry wrote:
>>> The way NSCell deals with this is that the white color is never part
>>> of the value data itself, it's thought of as a draw-time visual
>>> effect.
>>>
>>> That is, rather than calling setTextColor, you could override
>>> -drawInteriorWithFrame:inView:.
>>>
>>> -Ken
>>>
>>> On Tue, Feb 26, 2008 at 11:35 AM, John Stiles <JStiles...> wrote:
>>>
>>>> Actually, for what it's worth, I did just hit one snag. If you attempt to
>>>> edit the cell, the field editor inherits the white color! This makes it
>>>> pretty difficult to see what you're doing ;)
>>>>
>>>> I have a custom field editor anyway and have lots of control over how the
>>>> edit process gets started, so it was no problem to force the field editor to
>>>> use the actual item color, but I figured this was worth mentioning, for the
>>>> archives if nothing else.
>>>>
>>>>
>>>>
>>>>
>>>> John Stiles wrote:
>>>> Six of one and a half dozen of the other? :)
>>>> Anyway, it looks like this does the trick:
>>>> ([cell isHighlighted] && [[outlineView window] isKeyWindow] &&
>>>> [[outlineView window] firstResponder] == outlineView)
>>>>
>>>> Not quite as clean and nice as "backgroundStyle" but it will have to do for
>>>> now :)
>>>>
>>>> Ken Ferry wrote:
>>>> Also, I'd be pretty surprised if this actually showed up in perf
>>>> profiling. Do you mean 'heavyweight', or annoying? :-)
>>>>
>>>>
>>>>
>>>>> but it seems a lot more heavyweight. You have to do:
>>>>>
>>>>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
>>>> rowForItem:item]]
>>>>
>>>> -Ken
>>>>
>>>> On Mon, Feb 25, 2008 at 6:26 PM, Ken Ferry <kenferry...> wrote:
>>>>
>>>>
>>>> The pre-leopard code isn't pretty. The AppKit relnotes give the old
>>>> path while motivating the backgroundStyle API. I'm not sure if this
>>>> is 100% complete..
>>>>
>>>>> Prior to Leopard, you may have noticed that text turns white in selected
>>>> table view rows. The
>>>>> mechanism that controlled this behavior, unfortunately, was arcane. The
>>>> table would set the
>>>>> highlight color of the cell to the alternateSelectedControlColor and set
>>>> the cell to be highlighted.
>>>>> The cell would then introspect its highlight color, and use white text if
>>>> the color was the
>>>>> alternateSelectedControlColor.
>>>>
>>>> You probably have a constrained case, so it may suffice to check
>>>> -isHighlighted.
>>>>
>>>> It'd be nice if you could use the Leopard API on Leopard or later, as
>>>> we might try to be a little bit more clever about when the text
>>>> actually turns white. Ideally the text wouldn't turn white if the
>>>> user's chosen selection color was sufficiently light. There's scope
>>>> for making that work in the backgroundStyle API.
>>>>
>>>> -Ken
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Feb 25, 2008 at 5:12 PM, John Stiles <JStiles...> wrote:
>>>>> In my outline view, I'm using an NSTextFieldCell and setting the item's
>>>>> color via setTextColor:.
>>>>>
>>>>> This works fine, but for some colors, it's almost impossible to see when
>>>>> the item is selected. I'd like to always make the text white if the item
>>>>> is selected.
>>>>>
>>>>> In Leopard, I know I can use [cell backgroundStyle] ==
>>>>> NSBackgroundStyleDark to check this, but I was wondering if there is any
>>>>> easy check for Tiger and below. I can actually go through the
>>>>> machinations of asking the outline view if the item is selected, but it
>>>>> seems a lot more heavyweight. You have to do:
>>>>>
>>>>> [[outlineView selectedRowIndexes] containsIndex:[outlineView
>>>>> rowForItem:item]]
>>>>>
>>>>> And I'm not sure just how fast that is, but it can't be as fast as just
>>>>> asking the cell "are you selected" :)
>>>>>
>>>>
>>>>
>>>>
>>>>
>>
>> -
On Feb 26, 2008, at 3:13 PM, John Stiles wrote:> Trying to simulate the drawing behavior of NSCell seems error-prone
> to me. Since I don't have access to the original code, it would be
> hard to match its behavior. I'd much rather inherit as much as I can
> and only customize around the edges.
You're not replicating a whole lot here, however. If you're already
setting the multi-colored text color in willDisplayCell: for every
cell, then the minimal amount of work you need should be to call
setTextColor before calling the super class's implementation of
drawInteriorWithFrame if the cell is highlighted and active.
- (void)drawInteriorWithFrame:(NSRect)cellFrame inView:(NSView
*)controlView;
{
BOOL isWindowActive = [[[self controlView] window] isKeyWindow] &&
[[NSApplication sharedApplication] isActive];
BOOL isControlActive = isWindowActive && ([[[self controlView]
window] firstResponder] == [self controlView]);
if (isControlActive && [self isHighlighted]) {
[self setTextColor:[NSColor whiteColor]];
}
[super drawInteriorWithFrame:cellFrame inView:controlView];
}
You can of course get more involved, but this as a minimum should
work. The only thing happening here is what you want: to override the
higlight color.
--
Seth Willits -
Right, agreed. Ken's idea was that I would implement my own
-drawInteriorWithFrame:inView:, which is what I was saying I didn't want
to do.
Seth Willits wrote:> On Feb 26, 2008, at 3:13 PM, John Stiles wrote:
>
>> Trying to simulate the drawing behavior of NSCell seems error-prone
>> to me. Since I don't have access to the original code, it would be
>> hard to match its behavior. I'd much rather inherit as much as I can
>> and only customize around the edges.
>
> You're not replicating a whole lot here, however. If you're already
> setting the multi-colored text color in willDisplayCell: for every
> cell, then the minimal amount of work you need should be to call
> setTextColor before calling the super class's implementation of
> drawInteriorWithFrame if the cell is highlighted and active.
>
>
> - (void)drawInteriorWithFrame:(NSRect)cellFrame inView:(NSView
> *)controlView;
> {
> BOOL isWindowActive = [[[self controlView] window] isKeyWindow] &&
> [[NSApplication sharedApplication] isActive];
> BOOL isControlActive = isWindowActive && ([[[self controlView]
> window] firstResponder] == [self controlView]);
>
> if (isControlActive && [self isHighlighted]) {
> [self setTextColor:[NSColor whiteColor]];
> }
>
> [super drawInteriorWithFrame:cellFrame inView:controlView];
> }
>
>
> You can of course get more involved, but this as a minimum should
> work. The only thing happening here is what you want: to override the
> higlight color.
>
>
> --
> Seth Willits -
On Feb 26, 2008, at 10:21 PM, Seth Willits wrote:> On Feb 26, 2008, at 3:13 PM, John Stiles wrote:
>
>> Trying to simulate the drawing behavior of NSCell seems error-prone
>> to me. Since I don't have access to the original code, it would be
>> hard to match its behavior. I'd much rather inherit as much as I
>> can and only customize around the edges.
>
> You're not replicating a whole lot here, however. If you're already
> setting the multi-colored text color in willDisplayCell: for every
> cell, then the minimal amount of work you need should be to call
> setTextColor before calling the super class's implementation of
> drawInteriorWithFrame if the cell is highlighted and active.
>
>
> - (void)drawInteriorWithFrame:(NSRect)cellFrame inView:(NSView
> *)controlView;
> {
> BOOL isWindowActive = [[[self controlView] window] isKeyWindow] &&
> [[NSApplication sharedApplication] isActive];
> BOOL isControlActive = isWindowActive && ([[[self controlView]
> window] firstResponder] == [self controlView]);
>
> if (isControlActive && [self isHighlighted]) {
> [self setTextColor:[NSColor whiteColor]];
> }
>
> [super drawInteriorWithFrame:cellFrame inView:controlView];
> }
I should mention a few things about this snippet of code. Under
leopard, the "isKeyWindow/isActive" stuff isn't required; you can just
use something like this:
BOOL isControlActive = [self interiorBackgroundStyle] ==
NSBackgroundStyleLight;
...
This will be correct in more places than the above example (which
would be wrong for edited text).
Also, if you call setTextColor for one case, you should call
setTextColor for the other 'else' clause too. Otherwise, any drawings
with the same cell will use the last color set (white), unless your
willDisplayCell resets it.
corbin
