-
Notifications
You must be signed in to change notification settings - Fork 3.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: store color theme in state #8753
feat: store color theme in state #8753
Conversation
const themeMap = { | ||
'dark-mode': mergeWithDefaults(darkMode), | ||
'high-contrast': mergeWithDefaults(highContrast), | ||
'standard': defaultColors | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to better names for our themes (ex standard / original / default / ???). This is easy to modify later too.
Right now the color data structure match the payload that is passed to scratch-blocks
. I could see this being augmented later if we have some properties that are part of the editor but not in the blocks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these names are fine for now, until/unless we settle on different user-facing names later.
I could see this being augmented later if we have some properties that are part of the editor but not in the blocks.
Makes sense! Seems like it would be pretty easy to turn it into theme = { blocksColors: {}, otherStuff: {} }
if necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good so far! I have some questions, but as far as overall structure & strategy, this makes sense to me.
colours: { | ||
workspace: '#F9F9F9', | ||
flyout: '#F9F9F9', | ||
toolbox: '#FFFFFF', | ||
toolboxSelected: '#E9EEF2', | ||
scrollbar: '#CECDCE', | ||
scrollbarHover: '#CECDCE', | ||
insertionMarker: '#000000', | ||
insertionMarkerOpacity: 0.2, | ||
fieldShadow: 'rgba(255, 255, 255, 0.3)', | ||
dragShadowOpacity: 0.6 | ||
}, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does removing this mean there should be a .isRequired
on Blocks.propTypes.options.colours
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point... Technically if it is left off the default scratch-blocks
colors are used, which is nice. But make-toolbox-xml now expects certain colors to be provided. I've gone a different direction that I think accomplishes the same goal. I've passed the theme name to <Blocks />
, including a default if it is not provided. This should ensure all of the colors the editor uses will be available to this component. See the latest commit.
const themeMap = { | ||
'dark-mode': mergeWithDefaults(darkMode), | ||
'high-contrast': mergeWithDefaults(highContrast), | ||
'standard': defaultColors | ||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these names are fine for now, until/unless we settle on different user-facing names later.
I could see this being augmented later if we have some properties that are part of the editor but not in the blocks.
Makes sense! Seems like it would be pretty easy to turn it into theme = { blocksColors: {}, otherStuff: {} }
if necessary.
const stageSelected = ScratchBlocks.ScratchMsgs.translate( | ||
'MOTION_STAGE_SELECTED', | ||
'Stage selected: no motion blocks' | ||
); | ||
return ` | ||
<category name="%{BKY_CATEGORY_MOTION}" id="motion" colour="#4C97FF" secondaryColour="#3373CC"> | ||
<category name="%{BKY_CATEGORY_MOTION}" id="motion" colour="${colors.primary}" secondaryColour="${colors.tertiary}"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is colors.tertiary
always used to fill in a "secondary" color?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the category styling, yes.
These aren't all of the uses, but for the block colors, scratch-blocks
uses:
- primary for the block background color
- secondary for the dropdown background color
- tertiary for the border color
These categories only have two colors for the circle icon: background (primary) and border (secondary). It is a bit unfortunate that the block's tertiary matches up to the category's secondary. Any suggestions to make this less confusing?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha, that makes sense. I probably knew that at some point in the past...
I think it could make sense to add a comment about this if you see a good place for it, but once it's established it'll go from "hmm, I wonder if this is a mistake" to "hmm, it's a bit odd that it worked out this way" -- less of a concern :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Added some comments to the code.
4b4db60
to
b2d4021
Compare
How does the mergewithdeafault work in a way it can process the dark mode code? |
|
Alright tak!
…On Thu, Mar 2, 2023, 9:06 AM aoneill01 ***@***.***> wrote:
mergeWithDefaults allows you to define just the colors that are different
from the default theme, using defaultsDeep
<https://lodash.com/docs/4.17.15#defaultsDeep>. My assumption is that
some themes will share a lot of settings with the default theme. We'll see
if that holds true. 🤞
—
Reply to this email directly, view it on GitHub
<#8753 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A3IHPMGGOWUZ2FNRSJ5BJ7TW2CSNFANCNFSM6AAAAAAUX7WHLU>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
🎉 This PR is included in version 2.0.0-beta.1 🎉 The release is available on: Your semantic-release bot 📦🚀 |
🎉 This PR is included in version 2.0.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
I think this is will be a great feature! |
Note that this is not merging into
develop
. Instead we will likely have a long-running feature branch for the color theme epic.Resolves
Proposed Changes
scratch-blocks
Reason for Changes
This is a first step towards the larger epic of creating high contrast and dark mode color themes for the editor. Eventually the user will be able to choose the color theme through the UI and see all of the editor components correctly themed. This change keeps the selected theme name in memory and converts it to a set of colors that will later be used to change styling.
Test Coverage
scratch-gui/src/reducers/theme.js
.)Browser Coverage
Check the OS/browser combinations tested (At least 2)
Mac
Windows
Chromebook
iPad
Android Tablet