Skip to content
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

ZoomButtonGroup pointer areas should support an arbitrary spacing #650

Closed
samreid opened this issue Dec 15, 2020 · 3 comments
Closed

ZoomButtonGroup pointer areas should support an arbitrary spacing #650

samreid opened this issue Dec 15, 2020 · 3 comments

Comments

@samreid
Copy link
Member

samreid commented Dec 15, 2020

From a discussion in phetsims/circuit-construction-kit-common#620, @pixelzoom and I discussed that ZoomButtonGroup pointer areas should support an arbitrary spacing. At the moment, it looks like it assumes the spacing is 0.

@ariel-phet can you please recommend a priority and developer?

@pixelzoom
Copy link
Contributor

pixelzoom commented Dec 15, 2020

I'll take care of this one. Should be quick.

@pixelzoom
Copy link
Contributor

pixelzoom commented Dec 16, 2020

Implemented in the above commits, with a demo in scenery-phet Components screen for PlusMinusZoomButtonGroup. Run with ?screens=3&component=PlusMinusZoomButtonGroup&showPointerAreas and change the value of const spacing to reproduce these tests:

spacing = 0, pointer areas are fully shifted:

screenshot_760

spacing = 10, partial shift needed:

screenshot_759

spacing = 30, no shift needed:

screenshot_761

@samreid want to take a look?

@samreid
Copy link
Member Author

samreid commented Dec 18, 2020

Here are the pointer areas without the shift:

image

Here are the pointer areas with the shift:

image

It seems like the intention is to keep the same shape and just move them, but in some cases it may be desirable to truncate the overlap instead of shifting the entire areas. I'm not recommending a change for this, just wanted to bring it up for the record. It seems reasonable to shift the entire areas so they have the same "footprint". And the effect I described could be achieved by changing the dilations.

I also considered factoring out a function that computes the touch area at once instead of mutating it, but the given implementation seems clearer.

In short, nice work! Closing.

@samreid samreid closed this as completed Dec 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants