[IDEA] Automatically Switch Between Dark / Light Palette Depending on Browser Setting about tiddlywiki5

[pmario]

How to set :/palettes/Notion using UI?

[pmario]

I'm preparing a PR atm

[linonetwo]

How to set $:/config/palette/default-light to $:/palettes/Notion using UI?

Some people in QQ group say its annoying to customize wiki when there is no build-in config form for them. (When talk about sidebar position)

[Jermolene]

Thanks @pmario – how would backwards compatibility be handled? I think it's problematic to migrate from a single configuration tiddler to two interrelated ones.

One could imagine an arrangement such as "Use the palette titles from $:/config/palette/default-dark and $:/config/palette/default-light if they exist, otherwise use the title from $:/palette" but this would break any existing code using the $:/palette tiddler.

[pmario]

Thanks @pmario – how would backwards compatibility be handled?

$:/palette will be untouched.

The $:/config/palette/default-dark - light tiddlers are only used if the
$:/config/palette/enable-light-dark-detection is set to yes.

The enable tiddler does not exist by default. (Except we decide to enable that setting by default)

[Jermolene]

Wouldn't it be a lot simpler if the $:/palette tiddler was extended with "dark" and "light" fields. If they are present, then their values would be used in place of the "text" field.

On a separate note, I think the UI is too complex. Being able to select different palettes for light and dark mode is I think a minority requirement, and I'm uncomfortable if we make using palettes more complicated for the majority of people who don't care about light and dark mode.

[pmario]

Being able to select different palettes for light and dark mode is I think a minority requirement, and I'm uncomfortable if we make using palettes more complicated for the majority of people who don't care about light and dark mode.

Dark palettes are a "must have" in the web at the moment.

IMO this PR is a big "quality of live" improvement.

If the setting is on by default, the user switches the browser UI to "Dark Mode" and the TW Palette also changes. ->
No user intervention needed. That's what users expect today.

---

On a separate note, I think the UI is too complex.

I did try it with a "select-wdiget" and "text only dropdown". It looks absolutely alien in that context.

There is nothing new. It's the same experience in the Right Sidebar -> Tools -> palette button. All the symbols and the visual UI is the same.

[Jermolene]

Dark palettes are a "must have" in the web at the moment.

I am not disputing the demand for automatic dark/light mode switching. The complexity I am talking about is having to manage two separate palette settings. Dark mode should be automatic, and users shouldn't have to configure it unless they've got unusual needs.

There is nothing new. It's the same experience in the Right Sidebar -> Tools -> palette button. All the symbols and the visual UI is the same.

The part that is new is having to separately select two palettes, one for dark mode and one for light mode. Even if the user doesn't change the default, presenting it as two separate choices is unnecessary additional cognitive load on the user.

[pmario]

Wouldn't it be a lot simpler if the $:/palette tiddler was extended with "dark" and "light" fields. If they are present, then their values would be used in place of the "text" field.

IMO that's a backwards compatibility problem. Every existing plugin and hand-crafted UI will overwrite those fields because they do not have them. This will cause a lot of bug reports that will be hard to find, because fields are invisible by default

[Jermolene]

IMO that's a backwards compatibility problem. Every existing plugin and hand-crafted UI will overwrite those fields because they do not have them. This will cause a lot of bug reports that will be hard to find, because fields are invisible by default

I think the backwards compatibility situation is much simpler. Existing code that writes to $:/palette will still change the palette. With the $:/config/palette/enable-light-dark-detection tiddler set to yes then legacy code writing to $:/palette won't have any visual effect.

[pmario]

The part that is new is having to separately select two palettes, one for dark mode and one for light mode. Even if the user doesn't change the default, presenting it as two separate choices is unnecessary additional cognitive load on the user.

The user only has to change the setting if they want settings that are different to the default.

As a user --

1. I want to use the current "switcher" setting as it is now, which overwrites $:/palette
2. I want to be able to Enable / Disable the detection
3. I want to define a light and a dark palette that is activated according to the browser UI setting

[pmario]

I think the backwards compatibility situation is much simpler. Existing code that writes to $:/palette will still change the palette.

Yes and that's a problem. If I define the new dark and light fields in my $:/palette to use them for auto-switching.
Then I do install an "old" plugin which overwrites $:/palette -> My fields are gone. -> IMO that's a hard to find problem.

[pmario]

I am not disputing the demand for automatic dark/light mode switching. The complexity I am talking about is having to manage two separate palette settings. Dark mode should be automatic, and users shouldn't have to configure it unless they've got unusual needs.

As I wrote. There are defaults, that can be changed if needed.

If we enable auto detection by default -> No user intervention is needed.

[Jermolene]

Hi @pmario the UI here directly exposes your proposed arrangement of configuration tiddlers. That means that in order to see what palette they are using, or to change that palette, the user must understand the relationship between the two mutually exclusive sections of the user interface, and understand the significance of the checkbox. Compared to the present arrangement, this is enormously more complicated.

[Jermolene]

Yes and that's a problem. If I define the new dark and light fields in my $:/palette to use them for auto-switching. Then I do install an "old" plugin which overwrites $:/palette -> My fields are gone. -> IMO that's a hard to find problem.

@pmario if we are trying to preserve the behaviour of the existing plugin then it is correct that $:/palette gets overwritten.

[pmario]

I am not disputing the demand for automatic dark/light mode switching.

Does this mean, that the automatic dark/light mode switching should be ON by default?

[linonetwo]

Dark mode should be automatic, and users shouldn't have to configure it unless they've got unusual needs.

The switching is automatic, but I want to switch to Nord theme by default automatically, someone might not. But we can preconfigure this in a Release like TidGi or TiddlywikiXP, so end-user don't need to config it.

We have at least 4 levels of user: core js dev - wikitext dev - Release assemblers - end users

[linonetwo]

Existing code that writes to $:/palette will still change the palette.

I understand what you mean now.

I have a proposal, When changing palette from UI, we set palette-light/dark together based on color-scheme field on the palette.

(I also agree to use a field for palette-light/dark!)

And we can leave palette-light empty in the core, because in the empty.html, the palette is light. And if it is empty, this config is fallback to use $:/palette 's text field.

If user is already using another light palette (or palette don't have a color-scheme field, default to light), this also works fine.

If user is using a dark palette, when auto switch, use Vanilla for light, and use text field of $:/palette for dark.

---

In conclusion:

conditions	$:/palette and $:/palette!!light or !!dark (the one currently using in env) mismatch	$:/palette === $:/palette!!light or !!dark (the one currently using in env)
[{$:/palette}get[color-scheme]] === current env	use $:/palette!!text (fallback to old configs)	use $:/palette
[{$:/palette}get[color-scheme]] !== current env	use $:/palette!!light or !!dark (based on env)	use $:/palette!!light or !!dark (based on env)

| conditions                                      | $:/palette and $:/palette!!light or !!dark (the one currently using in env) mismatch | $:/palette === $:/palette!!light or !!dark (the one currently using in env) |
|-------------------------------------------------|--------------------------------------------------------------------------------------|-----------------------------------------------------------------------------|
| [{$:/palette}get[color-scheme]] === current env | use $:/palette!!text (fallback to old configs)                                       | use $:/palette                                                              |
| [{$:/palette}get[color-scheme]] !== current env | use $:/palette!!light or !!dark (based on env)                                       | use $:/palette!!light or !!dark (based on env)                              |

anyway, VSCode have this feature too, you can look at its logic:

[Jermolene]

Thanks @pmario. I have two concerns about this PR:

• That the data model of having multiple conflicting configuration tiddlers is confusing and error prone, and will lead to behaviour that is hard to understand for end users
• That the proposed new control panel user interface is unwieldy and too complex to be universal

Earlier today @CrossEye came up with an excellent reference that covered "multipurpose fields". I think that we are facing a similarly venerable anti-pattern here.

[pmario]

Sorry for wasting everyone's time. I'll close this UI centric issue and the related PR.

I'll create a new proposal related to the core function that detects the browser "preferes-color-scheme" setting.

[linonetwo]

Not wasting time, I didn't realize these issues until this discussion.

And I didn't realize vscode already have this feature too. It's this feature is off by default, and I was manually switching theme every time.