add a new color picker block#11294
Closed
IanMatthewHuff wants to merge 7 commits into
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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)