[Codex] microsoft/pxt#11292 — add a new color picker block - #43
Conversation
This is cool! I needed this earlier |
I think the circle is enough to tell you which color I chose. I think the colored square on the left is unnecessary... |
@THEb0nny i'm just copying what most color pickers do for the preview! plus i think having a nice big square makes it way easier to see changes take effect |
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 78ff0724d5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (target?.type === "text" || target?.type === COLOR_STRING_BLOCK_TYPE) { | ||
| const field = target.getField("TEXT"); | ||
| field.setValue(color); | ||
| } | ||
| return; |
There was a problem hiding this comment.
Store HSV updates for hex picker edits
When the user changes a color through the popup while the block is in hex format, this branch updates the text field and then returns before assigning this.colorHSV. If they then switch the dropdown back to RGB/HSL/HSV/CMYK or rely on the mutation state, the block converts from the old HSV value and shows the wrong color channels. Update the stored HSV state before returning from the hex branch.
Useful? React with 👍 / 👎.
| if (colorPickerBlock?.type === COLOR_PICKER_BLOCK_TYPE) { | ||
| colorHSV = colorPickerBlock.colorHSV; | ||
| } |
There was a problem hiding this comment.
Initialize the hex picker from its text field
For a hex color block loaded from TypeScript such as colorHelpers.hex("#FFFF00"), or after the user manually edits the hex string, colorHSV can still be the default/previous value. This editor opens the widget from colorPickerBlock.colorHSV without first reading the connected text field, so the popup displays the wrong color and the first drag can overwrite the intended hex value. Mirror the number field path by calling readColorFromInputs() before creating the widget.
Useful? React with 👍 / 👎.
| const shadow = document.createElement("shadow"); | ||
| shadow.setAttribute("type", "makecode_color_picker_number"); |
There was a problem hiding this comment.
Add RGB format mutations to toolbox shadows
When the built-in RGB picker is inserted from the toolbox, these explicit makecode_color_picker_number shadows are created without the format mutation that the number block uses to switch from its default Degrees mode. The initial RGB fields therefore accept 0–360 until the user changes formats, so values like 300 can be displayed in Blocks even though colorHelpers.rgb clamps them to 255 at runtime. Generate the same RGB-format mutation used by generateColorPickerNumberShadowDom.
Useful? React with 👍 / 👎.
adds a new color picker block! the motivation here is that we've always had a lot of targets/extensions that define multiple blocks for getting colors in various color spaces. for example, the neopixel extension in micro:bit, the circuit playground editor, pxt-ev3 (for the home button color), some of the boards in pxt-maker, the color fading extension in arcade, etc.
as a result, we have a lot of duplicated color space conversion code in our many repos. given how universal this is to all of our targets, this PR aims to create one color picker block to rule them all!
the new block natively supports all of the usual color formats:
internally, the color is stored as HSV in a mutation on the block. the reason for this is that the HSV and HSL color spaces have a lot of points that map to the same color in the RGB derived color spaces, so if you compile down to RGB then you get a lot of jumping around for the various HSV and HSL channel values as the hue changes.
on hardware the colors are all actually stored as 24 bit RGB numbers which i believe is universally how we do it in all of our targets. there are new functions on the
colorHelpersnamespace for converting the various formats to 24 bit RGB.the UI for the fields is a barebones HSV color picker:
like pauseuntil, this block is optional. unlike pauseuntil, we have a lot of targets where this block probably won't need to be in the default categories that come with the editor. for this reason, i had to a add a new scheme that allows extensions to contribute builtin blocks to the toolbox. in order to have this block appear in the toolbox, you simply need to define a function that has the
builtinBlockId="makecode_color_picker"comment annotation like so:the color parameter is also necessary to make the block match the color of whatever category contains it. adding this will also add monaco toolbox entries for all the various colorHelper functions.
right now the
builtinBlockIdannotation only supports the color picker, but i plan to add support for pause until and other blocks in the future. the first place this block is going to be used is in the color fading extension in arcade (i have some devious plans to completely overhaul the APIs in that extension)Mirrored from upstream PR:
https://github.com/microsoft/pxt/pull/11292Created automatically by pr-sxs-human-evals for code-review agent comparison.
(URL wrapped in a code span so GitHub does not create a cross-reference on the upstream timeline.)