-
-
Notifications
You must be signed in to change notification settings - Fork 579
MVP eyedropper tool for fill colors #300
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
Conversation
Tasks from upcoming sprints are always on the table! I was also debating with myself if we should even include it in 6 or 7. Thanks for grabbing it. |
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.
LGTM
Deploying with
|
Latest commit: |
fb878bd
|
Status: | ✅ Deploy successful! |
Preview URL: | https://a38ba3b3.graphite-master.pages.dev |
Can you please add right click mapping to the secondary color? So left click samples into the primary color while right click samples into the secondary color. |
* Implement eyedropper for layer fill colors * Add shortcut for eyedropper * Add right mouse sampling for secondary color
* Implement eyedropper for layer fill colors * Add shortcut for eyedropper * Add right mouse sampling for secondary color
Closes #303.
This was marked for Sprint 7, but I realized this MVP would be a quick and useful addition.
Fill
andStroke
Lmb => MouseDown
input mapping for the eyedropper toolCaveat: The color update is implemented using
FrontendMessage::UpdateWorkingColors
as opposed toSelectPrimaryColor
. That is because using the former doesn't update colors on the frontend. AddingUpdateWorkingColors
to the handler forSelectPrimaryColor
causes an unresponsive infinite-loop on the frontend. This is becauseSwatchPairInput
registers a response handler forResponseType.UpdateWorkingColors
but alsowatch
esprimaryColor
andsecondaryColor
, mapping changes toSwatchPairInput.update{Primary | Secondary}Color
. Those two functions each the respective WASM functions, which in turn dispatch the color selection messages, causing an infinite loop.In the future, I think this infinite loop should be avoided by removing the
watch
es and instead add callbacks toColorPicker
. We should only be dispatching theSelect...Color
messages when the frontend (i.e. the user) updates the colors. In fact, as it currently is, the response handler forUpdateWorkingColors
always dispatches redundant calls toSelectPrimaryColor
andSelectSecondaryColor
.I could implement that fix, but I think we should leave it for another PR to work out details.
This change is