Switching Theme deletes all Alternative Highlight Colors

[Truncated]

I can't save the Alternate Highlight Colors to the default theme, but if they are switched it simply drops any alternative colors you have.

This may be by design (due to not changing the themes). If so, it would be good to force a custom theme with prompting if alternative highlight colors are added. It's counter-intuitive to allow custom highlight colors that can't be retained. Maybe greying it out the alternative highlight colors section with a note that says "create your own theme to make and save alternate highlight colors" or something?

My take is that Alternative highlight colors should be able to be auto saved on creation to the Obsidian and Solarized options if they are active, so this would be a bug.

[mugiwara85]

The README clearly says: "How the themes work:

Every setting and color is saved in the theme, except the excluded languages. You can't modify or delete the default themes. When you switch themes, all unsaved changes are lost. Therefore it is recommended to create your own theme (unless you are happy with the default settings and will never change the theme), and always save your changes. If you made a change, and did not save it, the theme will not include it! Each theme has its own light and dark colors. To customize the light/dark colors, just switch Obsidian to light/dark mode, and you can change the colors for that mode. When creating a new theme the currently selected theme will be taken as a template for the new theme. After saving changes in a theme, these become the new default values. Example: You select a color (red) and save the theme. Now, this color is the default value. This means, that if you click the "restore default color" icon next to the color picker the color red will be restored."

But I agree, it is not the best solution now. I was already considering making the default themes modifiable, and also automatically saving changes when the user changes something. This way you shouldn't have to save the themes. I just didn't had time to implement this in the current release.

[Truncated]

Mea culpa on the reading of the README - I did not have the time to dive into that nuance before I accidently deleted all of the alternative colors I had. Here were my thoughts as I evaluated it as a user:

• I could make them and they persisted between openings / setting page opening and closing or being switched. That form of auto-save is common so it's certainly not unreasonable to assume that they are "saved" at that point.
• I can change all of the values of all of the settings and they persist without clicking save on the Theme. This alone logically contradicts the readme statement.

My recommendation would be to implement two simple changes:

1. Add a warning box with sub-text size font under every settings subpage header that is only visible when a default theme is selected. "Warning: Changes cannot be written to default themes and will be lost if the theme is changed by add-on update or selection of a different theme. To ensure any setting changes are persisted and can be returned to, create a custom theme above. Additional details for light/dark mode can be found in the README"
2. Grey-out the floppy disk save button when default themes are enabled. In general for UX, it's much better to show whether a button can be used proactively by the :disabled class than to allow the click and tell them no afterwards. The latter sets an unspoken assumption that it CAN be saved.

This approach communicates what you need right at the place you need it and should be generally less to implement.

[mugiwara85]

Ooooor as I said ealier:

• Default themes would also be modifiable (I could add a button or something where the default themes could be reset to their original state)
• and everything will be saved automatically when something changes

[Truncated]

Ooooor as I said ealier:

Dude, you don't have to be an arse about it. I was a shitty user who didn't read the instructions first - I copped to that.

It's also super common. If that's going to piss you off, then you're gonna be pissed a lot and probably end up being a hypocrite eventually. :)

What I was trying to suggest was an option that literally should be only a few lines of text rather than changing the behavior of your themes code. A quick, simple, low-impact, viable option that could address the issue right away while you work out... whatever it was you were saying earlier, tldr. ;)

[mugiwara85]

Sorry, I wasn't trying to be an arse at all, and I am not pissed at all. It wasn't meant to be negative in any way. I was just saying, because maybe you didn't read it what I wrote :)

I agree that your solution would be simpler (less code to do), but I think it would be better, for better user experience if the default themes could also be modified. That's it. Nothing negative here.

[mugiwara85]

Hi @Truncated I just pushed some changed which should fix the problem you described. I added two options:

• under Basic settings - here you can restore every default theme
• and another next to the dropdown where you can select the theme, to restore only that specific theme to its original state.

I didn't do the autosaving because if every setting is saved immediately, you could not revert the color pickers anymore to the original colors. So, you still have to save your settings, because if you switch themes, and they are not saved, they will be lost.

You can just take the main.js and the styles.css files and replace yours with it, in your VaultFolder\.obsidian\plugins\codeblock-customizer\.

Since you are good at finding bugs, I would really appreciate if you could test it, and give me feedback.