95: Fix light/dark mode mismatch causes preset to not load #124

2026-06-14T01:17:41+02:00

AramJonghu commented

2026-06-14 01:17:41 +02:00

Closes #95.

Changes

Now a check if variant has the mode user is already on.
Temp writes to config file for the scheme change to register in config file and settingswindow.

What does this fix

Variant check will not error out the colorscheme preset selection in cli if user is not on the same mode as user. Say user is on dark mode, but wants to select a preset that only has light mode, now does not error.
Temp write so that the colorscheme change shows correctly in settingswindow.

Caveats

QML file watcher seems to read mid write, which is the reason for a temp write. Without a temp write, you get a JSON parse error. It does not affect usability, but not a pretty look. I am sure this can be resolved on the qml side as the current solution is a bit ugly.
In the future, an enhancement would be that a preset scheme can be better integrated with the light/dark mode scheduler. I will create an issue on this and propose two suggestions (at least what I think is possible). Now at #125.

Closes #95. ## Changes - Now a check if variant has the mode user is already on. - Temp writes to config file for the scheme change to register in config file and settingswindow. ## What does this fix - Variant check will not error out the colorscheme preset selection in cli if user is not on the same mode as user. Say user is on dark mode, but wants to select a preset that only has light mode, now does not error. - Temp write so that the colorscheme change shows correctly in settingswindow. ## Caveats - QML file watcher seems to read mid write, which is the reason for a temp write. Without a temp write, you get a JSON parse error. It does not affect usability, but not a pretty look. I am sure this can be resolved on the qml side as the current solution is a bit ugly. - In the future, an enhancement would be that a preset scheme can be better integrated with the light/dark mode scheduler. I will create an issue on this and propose two suggestions (at least what I think is possible). Now at #125.

AramJonghu added the bug label 2026-06-14 01:17:41 +02:00

AramJonghu self-assigned this 2026-06-14 01:17:41 +02:00

AramJonghu added 2 commits 2026-06-14 01:17:41 +02:00

added auto-resolve preset mode (light/dark mode conflict) fecf8a886f

Not using direct write, but tmp write to avoid JSON parse error

Lint & Format (JS/TS) / lint-format (pull_request) Successful in 12s

Details

Python / lint-format (pull_request) Successful in 17s

Details

Python / test (pull_request) Successful in 31s

Details

Lint & Format (Rust) / lint-format (pull_request) Successful in 1m9s

Details

f31a1e224b

AramJonghu requested review from Inorishio 2026-06-14 01:17:41 +02:00

AramJonghu requested review from zach 2026-06-14 01:17:41 +02:00

AramJonghu commented

2026-06-14 01:40:06 +02:00

Note: I found a bug where if user selects light mode in the settingswindow, but uses dark scheme preset, other UI does not follow. Would have to investigate further on this specific issue.

zach commented

2026-06-14 12:57:11 +02:00

Note: I found a bug where if user selects light mode in the settingswindow, but uses dark scheme preset, other UI does not follow. Would have to investigate further on this specific issue.

Probably has to do with how I normally call generate from QML. I usually write:

Quickshell.execDetached(["zshell-cli", "scheme", "generate", "--mode", `${Config.general.color.mode}`]);

Which means the flag is explicitly set to the mode the user currently has selected. I think this should stay the way it is because even if the user doesn't enable scheduled dark mode, the toggle for dark mode should still be functional (once implemented for presets.)

> Note: I found a bug where if user selects light mode in the settingswindow, but uses dark scheme preset, other UI does not follow. Would have to investigate further on this specific issue. Probably has to do with how I normally call `generate` from QML. I usually write: ```qml Quickshell.execDetached(["zshell-cli", "scheme", "generate", "--mode", `${Config.general.color.mode}`]); ``` Which means the flag is explicitly set to the mode the user currently has selected. I think this should stay the way it is because even if the user doesn't enable scheduled dark mode, the toggle for dark mode should still be functional (once implemented for presets.)

👍 1

zach requested changes 2026-06-14 13:02:59 +02:00

cli/src/zshell/subcommands/scheme.py

						
				@@ -593,0 +599,4 @@

				                    (vari for vari in meta.variants if vari.id == p_variant), None

				                )

				                if variant and requested_mode not in variant.modes and variant.modes:

				                    resolved_mode = sorted(variant.modes)[0]

zach commented

2026-06-14 13:02:03 +02:00

I personally think we shouldn't default to something here. Raising an exception would be better if the requested scheme is not found, maybe write exception trace to log file too. This is because the condition on line 601 should never return true and if it does then it means we are calling it incorrectly from QML/CLI.

AramJonghu commented

2026-06-14 17:33:44 +02:00

The reason it is there is because the current implementation usually only has a single mode per colorscheme preset. rosepine:dawn only has light mode for example. The current implementation allows less friction when selecting a preset that is not aligning to the mode you are at currently.

resolved_mode can only be light or dark (I am pretty sure).

We can think of a different solution, but that would be a more complex solution that'd be more dynamic (a possible consequence of the implementation of #125). Lets say user is on rosepine:main, which is a dark preset. If user switches to light, it could dynamically understand to move to rosepine:dawn. The current implementation does not do this.

I agree with error/exception trace to log file, good idea.

The reason it is there is because the current implementation usually only has a single mode per colorscheme preset. `rosepine:dawn` only has light mode for example. The current implementation allows less friction when selecting a preset that is not aligning to the mode you are at currently. `resolved_mode` can only be light or dark (I am pretty sure). We can think of a different solution, but that would be a more complex solution that'd be more dynamic (a possible consequence of the implementation of #125). Lets say user is on `rosepine:main`, which is a dark preset. If user switches to light, it could dynamically understand to move to `rosepine:dawn`. The current implementation does not do this. I agree with error/exception trace to log file, good idea.

zach marked this conversation as resolved

zach merged commit 7cf6e5f8a5 into main

2026-06-14 21:27:27 +02:00

zach deleted branch 95-fix-light-mode-scheme-mismatch

2026-06-14 21:27:33 +02:00

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: zach/z-bar-qt#124