Skip to content

Few color picker changes to propose - #11616

Open
Joey Wunderlich (jwunderl) wants to merge 7 commits into
masterfrom
dev/jwunderl/color-picker
Open

Joey Wunderlich (jwunderl) wants to merge 7 commits into
masterfrom
dev/jwunderl/color-picker

Conversation

@jwunderl

Copy link
Copy Markdown
Member

few changes to suggest:

ability to specify which format to start with via block attribute (in this case, hex b/c that's what simulator theming shows / takes in

image

a square at the front that evals out when possible, ? when not

image

ability to apply defaults to the shadow you're puttin in category, including e.g. wanted duplicateOnDrag for these blocks, color to match, etc.

do these sorts of changes make sense with what you had in mind for the builtinblockids behavior or nah / things to trim out richard?

@aznhassan

Copy link
Copy Markdown
Member

Can we get an Arcade upload target to try out the new blocks?

@jwunderl

Copy link
Copy Markdown
Member Author

ah the arcade side of pr had em, here's a build with a very simple project https://arcade.makecode.com/app/590bd0d230b87b393be2ea5905452f455f73966f-ef652ebaad#pub:S43701-26279-46872-67107

@aznhassan

Copy link
Copy Markdown
Member

Switching back and forth between blocks/javascript/blocks again causes the square to just display a black block:
Image

Recompute the derived color preview before rendering so workspace loads with disabled Blockly events still reflect reconstructed literal inputs.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@aznhassan

Copy link
Copy Markdown
Member

If you use a variable to store the color, then switch to javascript and make any change (such as addding a comment), when you switch back to blocks and remove the variable, the background of the color picker will now be brown:

Image

Recompute the derived color preview before rendering so workspace loads with disabled Blockly events still reflect reconstructed literal inputs.
@jwunderl

Copy link
Copy Markdown
Member Author

fix for decomp (it was reading values that were replaced later in decompilation pass) https://arcade.makecode.com/app/d151c4577c684b9c7a93cfb1fa84c770dc21ab6a-310979b002

@aznhassan

Copy link
Copy Markdown
Member

It's no longer brown, but now you get this instead:
Image

@jwunderl

Copy link
Copy Markdown
Member Author

ah i see i'm dumb, i saw a different minor issue in screenshot and misread it as that -- fix 2.0 https://arcade.makecode.com/app/384d26ca1019facdcb6c58fdd8d4071150a1654a-6d485d983c (will have to make a new block for it b/c old one got swapped in too far)

@aznhassan

Copy link
Copy Markdown
Member

Okay, let me know when the new block has been pulled through. Still seeing it in the recent build:

Image

@jwunderl

Copy link
Copy Markdown
Member Author

Okay, let me know when the new block has been pulled through. Still seeing it in the recent build:

Image

Ah meant new blocks as in from toolbox, the old one compiled to a function it shouldn't have basically so the project javascript itself wrong now - dragging out new one, ->Javascript, >blocks works as expected as far as i can tell

@riknoll

Copy link
Copy Markdown
Member

definitely get rid of the question mark, it looks like an error. in that case i would just kill the box entirely

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants