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

Measuring Tape gets stuck under Fast/Normal/Slow buttons #361

Closed
brooklynlash opened this issue Oct 9, 2020 · 5 comments
Closed

Measuring Tape gets stuck under Fast/Normal/Slow buttons #361

brooklynlash opened this issue Oct 9, 2020 · 5 comments
Assignees

Comments

@brooklynlash
Copy link

Test device
Lenovo ThinkPad

Operating System
Windows 10

Browser
Chrome and Firefox

Problem description
This is for phetsims/qa#519
When on the To Scale sim, you can move the measuring tape under the Fast/Normal/Slow buttons and it can get stuck under them. Can be fixed by resetting the sim or zooming in/out. Can reproduce on published sim as well.

Steps to reproduce

  1. Click To Scale section.
  2. Click the check mark on the measuring tape.
  3. Move the measuring tape under the Fast/Normal/Slow buttons (under Normal is best area)

Visuals
gravmeasuretape

Troubleshooting information:
!!!!! DO NOT EDIT !!!!!
Name: ‪Gravity and Orbits‬
URL: https://phet-dev.colorado.edu/html/gravity-and-orbits/1.2.0-dev.16/phet/gravity-and-orbits_all_phet.html
Version: 1.2.0-dev.16 2020-09-15 16:33:11 UTC
Features missing: applicationcache, applicationcache, touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36
Language: en-US
Window: 1707x818
Pixel Ratio: 2.25/1
WebGL: WebGL 1.0 (OpenGL ES 2.0 Chromium)
GLSL: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 30 uniform: 4095
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 32767x32767
OES_texture_float: true
Dependencies JSON: {}

@arouinfar
Copy link
Contributor

Nice find @brooklynlash. We generally try to layer the MeasuringTapeNode on top of everything else. For example:
image
image

@samreid let's change the z-order of the MeasuringTapeNode so that it's on top of the TimeControlNode.

@samreid
Copy link
Member

samreid commented Oct 16, 2020

In this simulation, there are 2 competing nodes:

  1. The scene, which contains the planets and measuring tape and grid
  2. The screen, which contains the control panels, reset all button & time controls

These are currently not interleaved.

Putting the Scene first (as in master now) means the measuring tape goes behind all screen things.
Putting the Screen first would work well for the measuring tape, but puts the grid in front of the control panels.

image

@samreid
Copy link
Member

samreid commented Oct 16, 2020

@arouinfar do you want the planets and other bodies to also go in front of the "Fast/Normal/Slow" buttons etc? Is the grid the only thing that should be in the back? Will we need to interleave the nodes or split into more than 2 layers? The measuring tape body is constrained to the play area, but should the tip be in front or behind the control panel (or doesn't matter one way or the other?)

@samreid samreid assigned arouinfar and unassigned samreid Oct 16, 2020
@arouinfar
Copy link
Contributor

Oh, that is more complicated than I realized @samreid. I think this issue is relatively minor, and I don't know that it warrants interleaving the nodes or a more complicated layering approach.

It's not ideal that the MeasuringTapeNode can get (temporarily) trapped behind the radio buttons, but I don't think it's a terribly realistic use case.

I'm fine with closing this as wont-fix @samreid. If you agree, please close. If you'd rather adjust the layering, let me know and I'll make a recommendation.

@arouinfar arouinfar assigned samreid and unassigned arouinfar Oct 21, 2020
@samreid
Copy link
Member

samreid commented Oct 26, 2020

I don't believe we should try to fix this before the upcoming dev "rc-lite" release. I don't feel strongly one way or the other about whether this is fixed for the next main release. Based on the preceding remark, I'm inclined to close, but anyone please reopen if you disagree.

@samreid samreid closed this as completed Oct 26, 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