Config tiddler title for default light & dark palette (e.g. $:/config/palette/default-dark)

#1

I’m adding a feature that switch tw palette based on browser color mode.

So it would be more helpful if tw can store result of “Set dark and light palettes” to two config tiddlers. So not only @Mohammad 's shiraz’s $:/plugins/kookma/shiraz/ui/Buttons/SwitchPalette can use it, other plugins or userscripts can use it too, to auto switch palette.

I would suggest using $:/palette/dark and $:/palette/light for this config for interoperability, what do you think?

Maybe use $:/config/palette/default-dark and $:/config/palette/default-light

User script to switch theme
#2

Hi @linonetwo

There actually is already such a feature

When I’m at home I show you

1 Like
#3

Look at the $:/info/darkmode tiddler
It should change when you change the operating system design from light to dark

#4

but maybe the issue is it can’t trigger automatically so far? there was a thread about it

<$action-setfield $tiddler="$:/palette" $value={{{ [{$:/info/darkmode}match[yes]then[$:/palettes/makiaeadark]else[$:/palettes/makiaea]] }}}/>
to activate, set tag $:/tags/StartupAction/Browser
currently also recognises system darkmode and matches it
#5

Hi @makiaea

Some time ago I modified the colour macro for that purpose but it didn’t make it in the core because of performance concerns

But anyhow, the core colour macro looks like this:

\define colour(name)
<$transclude tiddler={{$:/palette}} index="$name$"><$transclude tiddler="$:/palettes/Vanilla" index="$name$"><$transclude tiddler="$:/config/DefaultColourMappings/$name$"/></$transclude></$transclude>
\end

and we could create a new colour macro

\define colour(name)
<$transclude tiddler={{{ [{$:/info/darkmode}match[yes]then{$:/palette/dark}else{$:/palette/light}] }}} index="$name$"><$transclude tiddler="$:/palettes/Vanilla" index="$name$"><$transclude tiddler="$:/config/DefaultColourMappings/$name$"/></$transclude></$transclude>
\end

Then we’d only have to create the two tiddlers $:/palette/dark and $:/palette/light containing the title of the palettes we want to use

2 Likes
#6

Thanks, I find it

截屏2023-09-22 00.14.01
截屏2023-09-22 00.14.01804×258 7.4 KB

But in this thread, I actually mean if we should storing $:/palettes/Nord in the $:/palette/dark, and $:/palettes/SnowWhite in the $:/palette/light (or some other names).

#7

Glad to see we are using the same name without even talk about this before! So I think this is the correct name to use.

Maybe we can PR it to the core, to add a config for it.

#8

I can trigger that from the host app, like TidGi-Desktop or TidGi-mobile. And on the browser, maybe using a userscript (So I can even automatically adjust other people’s wiki, for example, official tw wiki).

#9

There is an $:/info/darkmode info-tiddler, that is set by the browser.

Typically modern browsers automatically use the OS setting. But it’s possible to set the prefers-color-scheme CSS media-query variable also in the browser settings.

So it can be different to the default setting of the browser. There could be a startup-action, that detects the content of the info-tiddler and switches the $:/palette tiddler accordingly.

  • $:/config/palette/prefers-dark and $:/config/palette/prefers-light will need to be tiddlers that contain the name of the palette, that users want to use. eg:
    • $:/palettes/Vanilla for prefers-light and
    • $:/palettes/GruvboxDark for prefers-dark

IMO we will need a new setting in the ControlPanel → Appearance → Palette tab, that lets us set the values of $:/config/palette/prefers-dark and $:/config/palette/prefers-light

Edit: may be $:/config/palette/default-dark and $:/config/palette/default-light are better names

Additionally all the palettes need to be fixed. Most if not all of them have severe problems at the moment.

The Palette Manager Edition can help to fix them, because every colour setting has previews, that lets us spot the problems.

Just some thoughts

1 Like
#10

In your macro definition you use the deprecated text-substitution. This should easily be fixable if \procedure and index=`$(name)$` is used

But as I wrote we will need some new settings in the ControlPanel too.

#11

I wonder if we could ever use;

In functions / filters defined there in?

  • I wonder if its feasable?
#12

See: https://tiddlywiki.com/#substitute%20Operator:[[substitute%20Operator]]%20[[substitute%20Operator%20(Examples)]]

#13

Yes, I think they are good. Starting by $:/config/palette is better than $:/palette/

I’m surveying for this tiddler name in this thread, updated the title to reflect that.

#14

@pmario

I didn’t catch up with the latest tw developments
I’m not using functions and procedures at the moment because I don’t know how to handle them

#15

The main info about procedures is this:

  • Procedures can be used as a “drop-in replacement” for macros – following the main rules below
  • Procedures will replace Macros in the TW core (over time)
    • Macros will not go away soon – But whenever you need text substitution you should use procedures

Procedures

  • Local variables are used using the standard variable notation <<myVariable>>
    • Local variables do not need the double underlines anymore __
  • Text substitutions like $someText$ are not evaluated
    • They caused caching / performance problems
    • core macros using that syntax will be rewritten over time
\procedure test(myVariable) The value of myVariable is: <<myVariable>>

or

\procedure test(myVariable)
The value of myVariable is: <<myVariable>>
\end

New Text Substitution

more to come
-m

2 Likes
#16

I’m preparing a PR at the moment.

2 Likes
#17

I do have a working prototype that is part of the ControlPanel → Appearence → Palette settings tab

  • It allows users to enable / disable the “detection” setting
  • What should be the default ?

image
image1920×858 69.8 KB

I had to change quite a bit of palette switcher UI code, to be able to reuse the dropdown.

At the moment a browser reload is needed, since TW misses an “actionable” notification that the browser changed the setting.

The $:/info/darkmode is updated, but no action can be triggered yes.

#18

Why not wrap an action widget in the reveal or list widget, so they are triggered when a filter changed?

Could you add a picker for them? Shiraz have an example

截屏2023-09-23 00.31.42
截屏2023-09-23 00.31.421460×1310 46.8 KB

#19

Because they are not triggered. Action widgets can only be triggered with user interaction or js event-handlers

#20

I think that makes no sense.

The tiddler $:/plugins/kookma/shiraz/ui/Buttons/SwitchPalette is a UI tiddler that contains some default values in fields.

The dropdown from your screenshot seems to modify this UI code tiddler, which moves the code-tiddler from shadow into the user-space. This will prevent future plugin code updates. We want to avoid that behaviour in the core.

If the $:/config/palette/default-light and $:/config/palette/default-dark tiddlers are merged the shiraz-plugin can use those new config tiddlers and work with them.