Convert editor dark mode to presets - #1805

Note that I moved the dark loading screen from dark-www because it's a part of the project player, see #1606 (comment).

I renamed Experimental Dark to make it clear that it isn't experimental.

Note that I moved the dark loading screen from dark-www because it's a part of the project player, see #1606 (comment).

I renamed Experimental Dark to make it clear that it isn't experimental.

Can you rephrase? I forgot what theme makes loading screens dark at the moment.

Merging this will probably take some time.
Some comments:

1. We need to make sure all presets look pretty much the same than they did when they were not presets (except making cancel buttons red, etc.)
2. This does not affect "join scratch" modal, epic!
3. I'd prefer having less colors. Honestly I don't have the time and patience to check what every color does, not sure if anyone else will. I guess some UI colors could be based on other ones automatically (like the color of the scrollbar). Not sure
4. It won't be very easy to get good UI/UX out of this, at the cost of personalization. Specially because now "default" can mean default Scratch colors, or the default dark mode (3.Darker)

Can you remind me why 3.Darker couldn't be the default, and vanilla Scratch a preset? I'm thinking we maybe should make 3.Darker colors default, as well as making 3.Darker a preset (yes, duplicated), with vanilla Scratch also as a preset. Adding a way to reset a single color to any preset would allow this, I think?

Note that I moved the dark loading screen from dark-www because it's a part of the project player, see #1606 (comment)

Can you rephrase? I forgot what theme makes loading screens dark at the moment.

Currently loading screens are affected by website dark mode, but this doesn't make sense because otherwise the editor dark mode controls the project player.

1. We need to make sure all presets look pretty much the same than they did when they were not presets (except making cancel buttons red, etc.)

I'll try to make a list of all changes this makes to the existing dark mode versions (most of them are minor).

3. I'd prefer having less colors. Honestly I don't have the time and patience to check what every color does, not sure if anyone else will. I guess some UI colors could be based on other ones automatically (like the color of the scrollbar). Not sure

I think it's already obvious what most colors do, except primary, secondary and accent which change lots of things. Reducing the number of colors without changing the appearance of presets too much is hard, but I think the following changes could be made:

• The scrollbar could be a transparent overlay, I'd just have to make sure it still looks the same with the default Scratch colors and with Experimental Dark (where it needs to be the same color as borders;. 3.Darker and 3.Dark don't currently make the scrollbar dark.)
• The selected category background could be an overlay too: it already is in 3.Dark(er) and this wouldn't change the other dark modes too much.
• Instead of separate primary and secondary color settings, there could be just one named "highlight color" and the secondary color would be a darker variant of it.

Can you remind me why 3.Darker couldn't be the default, and vanilla Scratch a preset? I'm thinking we maybe should make 3.Darker colors default, as well as making 3.Darker a preset (yes, duplicated), with vanilla Scratch also as a preset. Adding a way to reset a single color to any preset would allow this, I think?

It's more intuitive if clicking the reset icon, or choosing "default" in a reset menu, resets to a Scratch color and not a dark mode, but the way you suggested where the default settings are duplicated as a preset would work too, the only problem(?) would be that 3.Darker would be called "Default" in the reset menu.

The only problem(?) would be that 3.Darker would be called "Default" in the reset menu.

The addon will still be called "Editor dark mode [...]" so I don't think that's a problem, tbh.
We can work around this and make it so it says "3.Darker" instead of "Default", somehow

The only problem(?) would be that 3.Darker would be called "Default" in the reset menu.

The addon will still be called "Editor dark mode [...]" so I don't think that's a problem, tbh.
We can work around this and make it so it says "3.Darker" instead of "Default", somehow

It depends on how the dropdown menu would work. In cases like this, a way to tell that default settings have a name in addon.json (maybe a property called defaultPresetName) so they would appear with that name in the reset menu would be useful.

1. We need to make sure all presets look pretty much the same than they did when they were not presets (except making cancel buttons red, etc.)

I'll try to make a list of all changes this makes to the existing dark mode versions (most of them are minor).

All presets:

• scratch-blocks inputs are now dark. Removed, see Convert editor dark mode to presets #1805 (comment). I think adding a block input background setting to the custom block colors addon is a better idea.
• Improved block context menu appearance: it now uses the same colors as the scratch-gui context menus and separators added by some other addons are now clearly visible.
• Input placeholders are now transparent instead of using the browser default (which is typically gray).
• Text on unselected tabs is now transparent white (it used to be gray in Dark Editor and white in other dark modes).

3.Darker:

• I changed the border color from transparent black to transparent white to make borders of some elements, such as backpack items, more visible.

Both 3.Darker and 3.Dark:

• Stage monitors are now dark.
• scratch-blocks scrollbars are now dark.
• Block comments are now dark.
• Icons on dark backgrounds are now white.
• Previously the background of a selector item used two different colors when not hovered, one behind the icon and the other behind the name of the item. Because Scratch doesn't do this, it would require an additional setting, so I removed it.
• The body of the stage selector now has the same background color as its header, for the same reason.
• The backpack header has a different color too for this reason.
• Borders in the paint editor are now transparent.
• Slightly different modal background to avoid adding a separate setting for it.
• Modal headers use the primary color as their background instead of the same color as the modal itself. I think I'm going to change that to the menu bar color. Fixed, now they're the same color as the menu bar.
• Buttons in the block palette now change background on hover.
• Cancel buttons are no longer red.

Dark Editor:

• All elements now have the same border color, #111111.
• Tabs now change color on hover.
• I removed the font weight change from tabs. It affects layout, which dark mode shouldn't. Instead I made the text color more visible (see "All presets").
• The background of the paint and sound editors is now the same as that of the sprite selector header, again to avoid adding too many settings.
• Removed the changed background color and font weight of paint editor buttons: another thing dark mode shouldn't do.
• Modals are now dark. As I mentioned already, I'm going to change their header to use the menu bar background which will otherwise make them almost the same as before. Now they use the menu bar background. I also changed the highlight color which affects the overlay behind them to be the same as the menu bar background.
• Dark Editor used to change the color of some blue buttons to gray to make using dark mode more comfortable - see [ENA-235] Light/Dark modes scratchfoundation/scratch-gui#59 for interesting discussion about this. I removed this for now, but I want to add an option called something like "unobtrusive highlights" that would reduce the overall use of the primary color, probably replacing it with the either a transparent/darker version of it or the input background. Now I made them dark blue instead, like the navigation bar.

Experimental Dark:

• I made scratch-blocks zoom icons dark. There are no other changes other than bug fixes and the ones mentioned under "All presets": Experimental Dark is essentially just a dark version of Scratch's color scheme so converting it to a preset was easy.

@WorldLanguages I removed a few settings and changed the Dark Editor highlight color to a darker blue.

Waiting for #1832 for the reset dropdown.

I fixed the full screen button. The stage border didn't look very good either when website dark mode was disabled so I did the same thing to it.

Now that I made this change I'm no longer sure if making the project player always styled by editor dark mode is a good idea. I want to add a similar color customization system to website dark mode and I think it doesn't make sense if the player is controlled by one addon but everything else on the same page is controlled by a different addon.

@mxmou IMO anything above the canvas (monitors etc.) should be styled by editor dark mode, even on player mode, for consistency

Merge this when we're ready

Btw Blockly.Colours exists and does a lot of the things that this PR is doing for editor-darkmode

Btw Blockly.Colours exists and does a lot of the things that this PR is doing for editor-darkmode

You mean the workspace, scrollbar etc. colors? Those (at least some of them) are overridden by the scratch-blocks css.js.

@mxmou IMO anything above the canvas (monitors etc.) should be styled by editor dark mode, even on player mode, for consistency

Depending on what we want, consistency across pages or consistency between different elements on the same page.

Maybe styled by editor DM on the editor page and by website DM on the project, fullscreen, and embed pages?

Currently it works like this:

• project page is styled by website dark mode, except any elements on the stage (monitors, ask prompts), which are styled by editor dark mode
• editor and full screen modes are styled by editor dark mode - I don't think this should be changed
• embed is styled by website dark mode (Dark embedded projects #2042), elements that would normally be styled by editor dark mode are not dark there

I think it would be better if the project and embed pages were only affected by website dark mode and the other two only by editor dark mode.

I think it would be better if the project and embed pages were only affected by website dark mode and the other two only by editor dark mode.

Smh that was hard to read
That would mean the monitors would look different depending if the project is in player mode or editor/fullscreen mode right?

@WorldLanguages It would. But it would also mean that if one set the website highlight color to red and the editor highlight color to green, the monitor background would be red in player mode, not green.

can we merge pls

can we merge pls

Probably, other changes could be made when the website dark mode is rewritten.

@mxmou I noticed editor dark mode + colored context menus means highlight color is not used. May be what we want but just making sure you're aware

@WorldLanguages This is intended.

Feedback:

There isnt an option to change the variable background color, it always uses the page bg, I don't like the look of the dark variables when using the dark editor mode

Possible solution: a boolean settings on whether monitors (AKA anything above the canvas) should be affected (defaults to true)?

There isnt an option to change the variable background color, it always uses the page bg, I don't like the look of the dark variables when using the dark editor mode

I just made this issue from feedback we got from the fan server... #2239

@TheColaber Oh is this a bug?

Feedback:

You should add an "Active Tab Text (Color, Costumes, Sound, Variables)" color option to Costumizable Editor Theme settings because it can't be changed. It's always blue. If you make Active Tab Background color to blue the text becomes impossible to read. Or if you just want to make a different color themed editor it just looks bad.

@WorldLanguages I already thought about this. The setting could be called "highlight text" because there are a few other places that use blue text. I don't think each of them should have a separate setting, especially because no preset would need to change it.