Dark mode

[Commanderk3]

Dark Mode

I just want to make sure that whether this approach is good or not. Many of the colors in MB are derived from platformstyle.js
Modifying this file will require less hardcoding to change the theme to dark mode. When you toggle to dark mode the user has to reload the website to observe the changes. This is similar to how changing of languages works. With this PR, the isDarkModeON is stored locally (like beginnerMode). When the website starts it checks if isDarkModeON is true, if yes then it initializes a different set of colors (in platformstyle.js)
Of course there are some elements whose color is not defined by platformstyle.js . For them I guess we can define there color specifically.

@walterbender What do you think ?

The colors for dark mode can be better I guess.....

[walterbender]

Mostly kind of works. The palette buttons should prob. not change to black on blue. The palette background should not be white. The block colors themselves should probably be adjusted, esp. if the label text is now white.

[Commanderk3]

Mostly kind of works. The palette buttons should prob. not change to black on blue. The palette background should not be white. The block colors themselves should probably be adjusted, esp. if the label text is now white.

Noted 👍

[justin212407]

Hi @Commanderk3 , I find the working and implementation of this feature really intriguing. I’d love the opportunity to collaborate with you on it.

[Commanderk3]

Sure, contact me in Matrix

[justin212407]

Sure I'll do that would like to know about all the updates there too

[Commanderk3]

My work on dark mode so far.....
@walterbender

[Commanderk3]

@walterbender Sir please review the latest update. The colors for blocks are darker now and redability is much better.

[walterbender]

Should these values be defined in platformColor?

[Commanderk3]

Yes, irrespective of light or dark mode, the stroke color is same for both. And I also created paletteLabelBackgroung because of its unique dark theme color.

[walterbender]

Should this be defined in platformColor?

[walterbender]

Looks really nice. My only doubt, aside from the few comments above, is whether or not we could generalize this in some way, to facilitate the user in generating their own custom themes. (I am not thinking of adding a theme editing interface so much as making it clear in the code and in perhaps a README how one would go about doing it.)

[Commanderk3]

In Music Blocks, elements are colored mainly in two ways. One is internal CSS where colors are derived from platformstyle.js and the other is through external CSS files. Block colors, pie menu, canvas, etc. are in platformstyle.js
Elements like the navbar and dropdown menu are defined through external CSS.
I believe internal and external CSS are both important. Perhaps we can mention the boundaries of platformstyle and external CSS in a README file.

[Commanderk3]

@walterbender

In Music Blocks, elements are colored mainly in two ways. One is internal CSS, where colors are derived from platformstyle.js, and the other is through external CSS files. Block colors, pie menu, canvas, etc., are in platformstyle.js. Elements like the navbar and dropdown menu are defined through external CSS. I believe internal and external CSS are both important. Perhaps we can mention the boundaries of platformstyle and external CSS in a README file.

@walterbender Should I edit the README about how a user can customize theme?

[arjunjayan999]

Looks really nice. My only doubt, aside from the few comments above, is whether or not we could generalize this in some way, to facilitate the user in generating their own custom themes. (I am not thinking of adding a theme editing interface so much as making it clear in the code and in perhaps a README how one would go about doing it.)

I think, from a developer perspective, we should also add some common themes ourselves, like Solarized Dark, Solarized Light, Minimalist Theme, Neon Theme, Pastel Theme, Retro Theme, and Glass-morphism for visual appeal, as well as themes like High-Contrast Theme, Grayscale Theme, Protanopia/Deuteranopia-Friendly Theme, and Tritanopia-Friendly Theme for color-blind people.

To achieve this,
We should make relevant classes and add their hex codes in a CSS file (probably change the existing dark-mode.css to include all themes i.e. make relative classes for other themes using the original as a template) , and then, depending on the user's choice, we can add the chosen classes using JS(the theme creator will also need to make a string of classes in a particular order, then we can split the classes in an array, then generalize the addition of classes to a tag based on user choice), this will handle the external CSS.
Then in platformStyle.js, we should assign the platformColor to an object named userTheme(made by the creator of the theme with a themeID to include his pallet, the creator can look at the current platformColor object as a template) which will be declared separately in platformStyle.js, instead of hardcoding them into the platformColor object like we do now for each theme. Then we can assign based on user choice which will need to be logged in as a themeID in storage.
Finally we need to change the functionality specific to dark mode and generalize it to a color theme mode like:-
-activity.js 1102 pallete.js 166 167 176 177 (these have hex values hard-coded into them, may cause issue with other themes)
-actvity.js 6569 (this renders a dark mode icon) 7133 (save locally as dark mode) (change both to general color theme function)
-check if dark mode is on and toggle dark mode (both of them can be generalized)
-toggle button will become a menu with registered themes but for automatic addition to the list we can use JS append the option from userTheme object.
-toolbar.js and script.js also have specific dark mode (generalize to color theme)

In the end,
-Developers would only need to add the classes to the CSS file (for their particular theme using the current dark-mode.css as a template) and create the string of those class names in a particular order in JS for external CSS and
-create an object userTheme(using the current platformColor object as a template) and it will be assigned to the platformColor in platformStyle.js if the user chooses it. [which will need to be logged in as the user’s choice into storage, like @Commanderk3 has already done for dark mode]. A simple two step process which can explained and given the template for in a readme.md file.

From a purely user perspective, providing a color picker option in the pie menu (and other relevant areas) and then the input value event can be logged into storage and then changed in userTheme to assign it to the platformColor object would be nice. It can be downloaded locally and shared in JSON format if needed. It has its shares of problem which need to issued first like how we will need two different modules to handle internal CSS and external CSS, or keep only one kind of styling in JS increasing the JavaScript overhead. We can do something simple like hard-coding the user's choice into the DOM, but to tackle text and background differently, we will need two different options in the pie menu. These are some issues which come to the top of my mind as of now. But with this feature, we can also apply a gradient theme and a colored glassmorphism effect.

This approach ensures modularity, making it easier for other developers to add and manage themes effectively. @walterbender and @Commanderk3, please share your thoughts on this.

[Commanderk3]

@arjunjayan999
That will be awesome for Music Blocks. A dynamic color theme is surely something which we can implement for users. That said, I believe @walterbender would know MB at a higher level. If it is a good idea or not.

[walterbender]

I think a readme would be very useful to someone trying to develop their own theme.

I don't think we want to go overboard with too many new themes. But if there is a high-contrast theme? I don't think we need Protanopia/Deuteranopia- and Tritanopia-friendly themes as there is built in value contrast as well as chromatic contrast in all of the palette color choices.

[walterbender]

If we do add more themes, we will prob. need to add a pie menu for theme selection. At that point, we'll want to explicitly add a custom theme. All of these ideas should come in a separate PR.

[arjunjayan999]

Seems logical about the choice for color-blind options. A pie menu for theme selection and a custom theme option sound like valuable additions, after that it will be very easy to add custom themes which are approved of. I agree these changes should be handled in a separate PR to keep things organized.

[Commanderk3]

I think a readme would be very useful to someone trying to develop their own theme.

I don't think we want to go overboard with too many new themes. But if there is a high-contrast theme? I don't think we need Protanopia/Deuteranopia- and Tritanopia-friendly themes as there is built in value contrast as well as chromatic contrast in all of the palette color choices.

@walterbender I will make a commit for it. The README file will be beneficial.

[Commanderk3]

@walterbender I am a bit confused. Exactly where should I edit the README?

[walterbender]

Since most of the changes would be in platform.js, make a README.md file in js/utils.

[Commanderk3]

@walterbender README file added

[walterbender]

Still a few hardcoded color values. Any reason not to move these to platformColor?

[Commanderk3]

Irrespective of dark or light mode the color will be the same. But now we are talking about multiple themes so it makes sense to not hardcode them.

[walterbender]

maybe this should be a theme name (so the same storage value can be used for any theme)?

[walterbender]

I did find one other issue that needs to be addressed:

[walterbender]

Maybe we can land this and sort out the grid in a separate MR.

[walterbender]

There is, however, a conflict in Phrasemaker that needs to be sorted before I can merge.

[Commanderk3]

@walterbender What conflict sir ?

[walterbender]

[Commanderk3]

@walterbender Sir why did the conflict occur? It usually does not happen.

[walterbender]

Something changed on the master branch since you made your PR branch that is incompatible with one of your changes. But it seems to be resolved.

[justin212407]

@walterbender I'll try and sort out the grid issue in the pr i will be creating which is going to add on onto the features diwangshu implemented in this pr. So basically this feature will be implemented in 2 prs ro completion.