Instrument sim for PhET-iO

[ariel-phet]

This sim is scheduled to be outfitted for PhET-iO by @jbphet after his work with States of Matter is finishing up.

@samreid will be available when @jbphet works on the sim and work through the instructions contained in the following file:

https://github.com/phetsims/phet-io/blob/master/doc/how-to-instrument-a-phet-simulation-for-phet-io.md

Part of the goal will be to refine this documentation

[samreid]

@jbphet can you speculate when we may begin working on this?

[jbphet]

We discussed my priorities in the 11/3/2016 status meeting, and once States of Matter is in RC phase I will start spending ~1day/week on this, so I suspect there will be some action on it next week or the week after.

[samreid]

On Thursday's status meeting, I suggested working on instrumenting Balloons and Static Electricity with @jbphet instead of Gravity Force Lab, in order to address phetsims/a11y-research#2 and get "2 birds with one stone", but after review in phetsims/balloons-and-static-electricity#201 I discovered there is a lot of new code related to accessibility that would complicate the task, and that @jbphet and I should actually start with Gravity Force Lab, as originally planned.

So I'll create a new issue for step 1 of instrumentation, which is for code review.

[jbphet]

Below is the checklist of items that must be completed in order to implement the instrumention, extracted from https://github.com/phetsims/phet-io/blob/master/doc/how-to-instrument-a-phet-simulation-for-phet-io.md. Refer back to the original document for explanations of the checklist items if needed.

• Understand the goal
• Code review
• Import Tandem to main.js
• Create root tandem
• Pass tandems to sim screens
• Pass tandems to model and view
• Pass tandems to all constructors
  • See also Testing while adding Tandem instances. Test with ?phet-io.validateTandems=false since common code components don't yet have tandems.
• Pass tandem instances to common code components
  • See also Testing while adding Tandem instances.
• Replace types with tandemized equivalents
• Instrument any Uninstrumented Common Code Components Used by the Sim
• Instrument new component types defined by the sim
• Add simulation specific support
• Are random numbers using phet.joist.random, and all doing so after modules are declared (non-statically)? For
  instance, the following methods (and perhaps others) should not be used: Math.random, _.shuffle, _.sample, _.random
• undefined values cannot be saved from the phet-io state save, sims should be written to use null instead.
• Update these instructions if you find them to be incomplete, inconsistent or incorrect.

[samreid]

@jbphet is taking the lead on this, I'll be supporting him with scheduled meetings.

[jbphet]

A test task has been created to test the result of this instrumentation effort, see phetsims/tasks#743. I'm going to unassign myself from this issue and link it to the test task.

[jbphet]

@samreid - this issue is old, but is assigned to me, and I'm not at all sure if this is done, still needed, or in general where it's at. Do you have a sense, or can you assign to someone who does? I'm certainly not spending any time on it at the moment and it's not on my radar for working on it anytime soon.

[zepumph]

@kathy-phet and I continued going through Studio together.

• Investigate (22 minutes or less), hiding the dashed line when the forceDisplayNode is made invisible.
• Add a PhET-iO derived property for the distance between the two masses. This would have units. @arouinfar does distanceProperty sound alright with you?
• (see Recenter NumberControl title when changed with PhET-iO? scenery-phet#526) massControl1.titleNode should center better.
• revisit scientific notation checkbox and how it has a custom enabledProperty (which is the showForceValuesProperty). Do we really need that to be linked? @kathy-phet was interested in @arouinfar's opinion on that.

[zepumph]

Investigate (22 minutes or less), hiding the dashed line when the forceDisplayNode is made invisible.

I think I will be able to do this by uninstrumenting ISLCForceArrowNode as the forceDisplayNode, and instead instrumented a new composite Node in ISLCObjectNode as forceDisplayNode that has ISLCForceArrowNode and the dashes as the child. This doesn't seem too bad to me.

[zepumph]

Investigate (22 minutes or less), hiding the dashed line when the forceDisplayNode is made invisible.

It has been 20 minutes, and I found that things are further complicated because ISLCObjectNode.arrowNode isn't added as a child, but instead stored as a field, and added directly to the screen view (parent of the ISLCObjectNode). I am giving up on this. Sorry! Let me know if we want to investigate. I think I could make it work, but it would involve a fair bit of layout change.

[zepumph]

Add a PhET-iO derived property for the distance between the two masses. This would have units. @arouinfar does distanceProperty sound alright with you?

How about "separationProperty" instead. Added above.

[zepumph]

More design meeting:

revisit scientific notation checkbox and how it has a custom enabledProperty (which is the showForceValuesProperty). Do we really need that to be linked? @kathy-phet was interested in @arouinfar's opinion on that.

• showForceValues checkbox is no longer the scientificNotationCheckbox's enabledProperty

• instrument the vertical dashed line, to be able to be toggled, called centerOfMassLineNode

[zepumph]

Everything here has been completed. Now we will finish up over in #174. Closing