>
> Date: Thu, 01 Jan 2015 22:51:06 +0000
> From: Quincey Morris <quinceymor...@rivergatesoftware.com>
>
> On Jan 1, 2015, at 13:25 , Eden Smallwood <zeppenw...@lafn.org> wrote:
>>
>> How does Apple know to make the text white in one place and black in
>> the other?
>
> How are you choosing the color for your text? Have you tried [NSColor
> textColor] or perhaps [NSColor controlTextColor]?
Quincey, that was clever of you, I think, so thanks for that. It
didn’t work tho. I tried a myriad of those *special* colors, and while some of
them come up white... No matter what color they come up as, they are the same
in both windows, so there’s no dynamism there for me to take advantage of.
From a Big Picture perspective, it seems likely that, even if we were
to assume that controlTextColor() is sometimes dynamic, the reason it doesn’t
work in my situation is for the same reason that none of the blend modes work.
What that reason is exactly might be hard to express in words, but... well.
For a moment, I got very hopeful about [NSColor
windowBackgroundColor]... That would have solved my problem in an instant, if
it returned translucentBlack or opaqueWhite depending... If NSColor somehow
knew the status of the underlying window, despite the fact that the QL API gave
me no pointer to the window. Alas, printing the function returns this
recursive gibberish: NSNamedColorSpace System windowBackgroundColor,and my
attempts to extract color info from that jibber jabber just crash.
> Date: Thu, 01 Jan 2015 14:12:47 -0800
> From: Jens Alfke <j...@mooseyard.com>
>
>
>> On Jan 1, 2015, at 1:25 PM, Eden Smallwood <zeppenw...@lafn.org> wrote:
>>
>> If you’re thinking "Wh on Bk and Bk on Wh, therefore XOR to the
>> rescue", I’ve tried every conceivable setting of cgBlendMode and
>> nsCompositingMode and nothing has any effect whatsoever on the text color
>> which results in the window.
>
> XOR-based drawing modes are pretty much useless in anything other than 1-bit
> (b/w) graphics. I don't think CG even supports them.
Jens, I googled this issue quite a bit, and from what I read the
proposition that “CG supports / doesn’t support XOR” seems to depend on what
you mean exactly. No, it doesn’t support XOR in the classic sense, and in fact
the headers mention that "Note that the Porter-Duff "XOR" mode is only
titularly related to the classical bitmap XOR operation” whatever the heck that
means.
Not that it matters, really-- the issue is really that no matter what
mode I choose, it has absolutely no effect whatsoever.
>> Or perhaps it’s possible to detect the “background color” of the
>> current CGContext or NSContext? But this notion doesn’t seem to exist.
>
> I don't think so. The individual calls don't draw both foreground and
> background, so the background is simply the color of the pixels that already
> exist in the buffer at the time you're drawing. Or of the pixels your pixmap
> will be composited onto when it's drawn, if it's transparent.
>
> I don't know much about QuickLook generators, but it looks like there are a
> lot of possible data types that the generator can return the preview as,
> including textual ones like RTF. If so, it's possible the preview you saw is
> textual and the Finder is overriding its text styling to force a contrasting
> color.
>
> —Jens
I’m sorry but can I ask for clarification on what you’re saying there--
you seem to be suggesting that there might be an avenue towards solving the
issue if I rewrote my generator to return an RTF file as opposed to drawing
“directly”, so to speak? But that seems somewhat backwards to me. Why would
an RTF data representation be more amenable to blend modes than when I’m
directly calling [<NSString*> drawInRect:sasdf withAttributes:asdfasd] ?
Truth be told, my generator is done except for this one aggravating
bug. If solving the problem requires rewriting my schlock into an RTF file,
then I’m going to admit defeat and just use some arbitrary non-white and
non-black color on X.6, and shame on Apple for not even mentioning this absurd
situation in the documentation.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
