TextColor when switching between color schemes

I am a bit stuck. Sometimes I wish to set my Mac to work in Light Mode, and sometimes in Dark Mode. When I switch between the Tinderbox 7 color scheme and the Dark Coral color scheme to match, the TextColor of the text in my notes does not change. Everything else changes over correctly, except for the text color.

I have read the TB Ref page on TextColor, and see that inheritance breaks once there is text in the Text pane.

I have tried selecting the text and applying the ‘default’ text format from the Ruler bar above the text pane.

Is there a way to have the text change automatically, so as not to go note-by-note every time I wish to switch from Light Mode to Dark Mode or back?

Or, alternatively, can someone explain how $TextColor and the Text Inspector and ‘Default style’ all interact?

I’m not sure what changes happened post-v6 (other than more RTF richness) but my understanding is all $Text-related attributes are inherited in a not until any styling, even be it a bit of bolding is applied. At that point all $Text hard-encodes its values, even for runs of text that the user would presume as 'default styling. Why? I don’t know but I’m sure it seemed—some years pre OS light/dark mode—a sensible approach. Anyway, even if the ‘default’ text toggle text/background colours, what about the bold purple text on a lime green background you set in a moment of hilarity? Even if we don’t care about those edge cases, the developer has to - even if only to pragmatically ignore them. If tempted to say “But, Apple apps…” see Howard Oakley’s blog for even Apple can’t properly handle its own invention.

I too tend to switch, with the result I gave up on dark mode. Sure, it looks cools, but I don’t have the 20/20 vision of my youth and everything reversed out is either too contrasting or has not enough contrast. I found I’d run in dark OS mode ‘chrome’ but choosing to have a ‘light-style’ view and text background—pity the poor dev. So, I’m back in light mode. Meh.

I agree things could be better for (colour) swingers. So the question is, what do we expect to happen to the $Text pane on mode switch. My thinking is, if we users can’t easily describe it (in terms of current settings/attributes) it might just harder than we imagine. :slight_smile:

This is the point (and this isn’t a come-on) where @eastgate de-cloaks and points out my reasoning is flawed and this is easy to do. :thinking: (thuogh possibly ont in a tist of global pestilence).

These are all good points, Mark. As usual, I enquire because there is often a way to do things of which I am unaware.

In regards to your final question: what I expected to happen was that the text colour in the document would respect the text colour determined in the chosen color scheme. Upon exporting the default dark theme in order to make my own, I saw that it has values for textcolor. I expected this to (re-)set the color of $TextColor, upon switching to a different color scheme.

Personally, I would expect this to overwrite any existing colours in Text. I can, of course, see how this could be problematic to many other use cases, and I do understand the considerations raised above. If there is a way to do what I am looking for, however, I would be grateful to hear it.

Imagine having notes in which you have set text colors carefully — perhaps you’re a judge and use red for arguments from the prosecution and green for arguments from the defense.

Now, you apply a color theme and all your colors are gone.

But I agree that text in the old default $TextColor should change to the new default $TextColor, and I don’t believe this is done consistently.

1 Like

Yep, I get it. To be more precise, I think what I was expecting is that whatever was in the default old color swaps over to the new default TextColor as determined by the color scheme. Thinking about this more, if anything had its color changed, that color should be preserved, since it is not the default.

If some text had been put into green for defence argument, that would stay green whatever is happening with the default text. If judge can’t read the dark blue in a Dark Mode-friendly color scheme, they can just switch back to another light scheme, and the green stays the same.

But perhaps that is what you meant, more concisely, in your last line there.

1 Like

Is there some simple and straightforward way of reapplying the default text color from the color scheme to $TextColor, as an inherited value so I’m not hard-coding text color but making every note consistently inherit it from the document? This has to be possible because changing to the Dark Coral color scheme changed my notes with formatting from black text to white text, but changing the color scheme back to Coral did not undo this change. So there has to be an asymmetry here somewhere. Like a Stamp?

I’m sorry to hear you’re having a problem. I can’t replicate this in the current v8.7.1 (I’m working on 10.14.6 in OS light mode—though I’m not presuming those to be a factor, yet!

Assuming a new TBX and a note with some text, can you list the steps needed to produce the effect? IOW, the customisations needed in the $Text from default and the exact names of the colour schemes to use and in which order (and any further text edits when in a given scheme), etc. This should enable us to more closely follow your process; the cause of some effects can be extremely narrow, so hard to test without an exact model.

My experiments show that $Text in default $TextFont/Size changes from black, to white, etc., as I switch colour schemes. Text where I have set a colour for some words, this doesn’t change. That should be expected and is a weakness of Apple’s design in this regard (Google and you’ll find expert Mac users critiquing this).

Ok. I’m going to try to be clear here.

You can replicate this easily without changing any text color anywhere.

  1. Open a new fresh document.
  2. Create two notes, A and B.
  3. In A, type “test body A”.
  4. In B, type “test body B”.

  1. Hit CMD-8, go to color, apply “Dark Coral.”
  2. Observe that the body text is now white.
  3. Apply “Coral.”
  4. Observe that the body text is still white.

There is no change to the RTF representation of colors, not even formatting or linking.

I do not apply colors. I don’t care about specific color representation. Semantic demarkations such as italics, bold, underline, strikethrough, and highlight should be preserved. But I do not care about specific colors. I want my notes to be easily perceptible in dark mode. This app has a dark mode. I should be able to use the dark mode. I should be able to change color schemes without this kind of mutable asymmetry affecting my notes.

To be clear: this is a bug from whatever angle you look at it. This is not some artifact of RTF representation, or of color schemes, or whatever. The bug probably has to do with inheriting differences in default values from the default color scheme. I should be able to transparently switch between color schemes without adding or removing semantic information to my notes, and right now I can’t.

This also works the exact same if you use the “Fresh” color scheme, which I just noticed exists.

Thanks. this is really helpful! Ok, at step #8 I get:

So, I don’t get the same but that doesn’t imply (lest I appear to do so) that your report above is wrong. So we need to think about other factors. Here I’m using v8.7.1b467 on macOS 10.14.6 (because … reasons) and using OS ‘light’ mode. Are you using macOS 10.15.x (or 11.0beta)? That might be a factor but the difference isn’t necessarily causation just because its different.

If using an older version of Tinderbox, this might be a cause. During the life of v8, the arrival of OS dark/light mode introduced some issues requiring the existing colour palettes to be updated (with some user-unseen settings) to deal with this.

So, to triage a bit further, what app version and macOS are you using? I ask even if only to discount these as factors.

HTH :slight_smile:

I am using the latest stable macOS (10.15.5) and the latest public stable Tinderbox (8.7.1). The bug is also replicable on Big Sur exactly as I described it.

Thanks. Given that, I think this is one to call in to formal Tech Support (info@eastgate.com) as, given the information at hand and your test case, I don’t think fellow users can dissect this further. IOW, I wish we could help here, but this probably needs some under-the-hood work that other users can’t do.

Sorry, it’s frustrating. You kindly gave a really useful description of steps to take and sorry there is no clear answer.

We’re on it!

1 Like