Closed KatieWoe closed 1 year ago
This is another one of those cases where we need to use IndexedNodeIO. Similar to https://github.com/phetsims/molecule-polarity/issues/157.
I also just noticed that what the point tool is locking onto is different.
@KatieWoe said:
I also just noticed that what the point tool is locking onto is different.
I don't understand. Can you elaborate? Steps to reproduce?
In the image above, the top sim has the point tool as grey, and the bottom sim has it as orange. Same steps as before, but put a point tool on the grey line before moving the orange line back into position.
The point tool color in the downstream sim will be incorrect any time it is on a line that intersects the orange curve when the state is set.
Steps:
There's a similar problem with rendering order of the point tools, see screenshot below. When you grab a point tool, it moves to the front. That does not occur in the downstream sim.
The take-away here is that if the developer uses moveToFront
and moveToBack
to change the rendering order of Nodes, then those Nodes need to have these options in order to make that rendering order stateful:
phetioType: IndexedNodeIO,
phetioState: true
In the above commits, I fixed the rendering order issue for curves and point tools, in master and 1.3 branches.
The problem demonstrated by @Nancy-Salpepi in https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1632498402 is not fixed yet.
The problem with point-tool color reported in https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1632498402 is due to the implementation of getQuadraticNear
in PointTool, see relevant doc below. It prefers the curve that it's already on. And that presents an ordering problem when restoring state. So we may need to remove that feature, which was requested by @kathy-phet in https://github.com/phetsims/graphing-quadratics/issues/47.
/**
* Gets the quadratic that is close to a specified position, within a specified distance.
* This algorithm prefers to return the quadratic that the point tool is already on.
...
public getQuadraticNear( position: Vector2, offDistance: number, onDistance: number ): Quadratic | null {
The problem with point-tool color reported in https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1632498402 was fixed in the above commits, for master and 1.3 branches. And I was able to keep the "prefer the quadratic that the point tool is already on" behavior.
@KatieWoe and/or @Nancy-Salpepi please verify in master. If it looks OK, please change the label to "fixed-awaiting-deploy".
I was catching up - but its already fixed. Thanks @pixelzoom.
The grey line being on top of the orange line as described in the first part of the issue still occurs on master.
This mismatch occurs if:
Due to https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1634518466 and https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1634523189 this doesn't seem fixed on master
@pixelzoom what I originally reported in https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1632498402 doesn't seem to be fixed either.
Reproduced - thanks QA.
Very weird, I could have sworn this was fixed... Part of what threw me is that https://github.com/phetsims/graphing-quadratics/issues/202#issue-1799724568 says "Go to the second screen" but shows visuals for the first screen.
Also noting that @KatieWoe's report in https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1634523189 is a different use case than what was previously reported.
I found some other PhET-iO hackery that is probably interacting badly with the changes that I made above in https://github.com/phetsims/graphing-quadratics/commit/801b2e1929c36d2a3f72c0222ce515587f384ee0 and https://github.com/phetsims/graphing-quadratics/commit/1cce96283d52a577c104bfc1223947bc6d79a70c. It references #165 and #36, so this is a problem that has come up before.
In GQGraphNode.ts:
// When restoring state, if savedQuadratic is identical to quadraticProperty, then leave it in front, so
// the user can see it. Otherwise, move it to the back. Note that this does not address the corner case where
// the instructional designer has changed quadraticProperty, then changed it back to match savedQuadratic.
// We decided not to address that case, see https://github.com/phetsims/graphing-quadratics/issues/165.
if ( isSettingPhetioStateProperty.value && !savedQuadratic.hasSameCoefficients( model.quadraticProperty.value ) ) {
savedQuadraticNode.moveToBack();
}
}
} );
// When a quadratic is saved, it is initially in front of quadraticProperty. Otherwise it wouldn't be visible
// because they are identical. When quadraticProperty is changed BY THE USER, move the saved quadratic to the back.
// If it's changed by restoring PhET-iO state, do nothing, because savedQuadraticProperty listener above will
// handle it. See https://github.com/phetsims/graphing-quadratics/issues/36 and
// https://github.com/phetsims/graphing-quadratics/issues/165.
model.quadraticProperty.link( quadratic => {
if ( !isSettingPhetioStateProperty.value ) {
savedQuadraticNode && savedQuadraticNode.moveToBack();
}
It occurs on any screen with the camera button. I found it easiest to reproduce on the second screen, but took a picture on the first.
This approach to making z-order stateful:
phetioType: IndexedNodeIO,
phetioState: true
... only works if the Nodes are instrumented. Which they were not. So I instrumented them.
But in order to instrument them, I had to instrument graphNode
, their parent Node. That changed the structure of the scenegraph, changed the API, and required several new migration rules. Changes were pushed to master and 1.3 branches in the above commits.
@arouinfar please verify that the introduction of graphNode
is OK, as described below. Leave this assigned to me, because I still need to resolve the problems reported in https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1632498402 and https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1634523189.
These were the old phetioIDs:
These are the new phetioIDs. "view" was changed to "view.graphNode":
These new elements were added to make z-order stateful. There is a set of these for each screen. None of them are featured, and their visibleProperty is not instrumented.
I noticed that it was possible to change the indices for the "new element" Nodes listed in https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1635059920, by using the "Move Up" and "Move Down" buttons in Studio. So I made them read-only in the above commits to master and 1.3 branches. For example:
The remaining problems with the point tool color are due to this bit of code in GQModel.ts:
const pointToolQuadraticsProperty = new DerivedProperty(
[ this.quadraticProperty, this.quadraticTermsProperty, this.savedQuadraticProperty ],
( quadratic, quadraticTerms, savedQuadratic ) => {
// order is important! compact to remove nulls
return _.compact( [ quadratic, ...quadraticTerms, savedQuadratic ] );
} );
When the saveQuadraticNode
is in the foreground, the savedQuadratic
model element is still at the end of the list, and therefore chosen last by the point tool. Getting the model and view orders to match is going to require big changes.
I tried this workaround. But it's too clever and has ordering problems when state is restored, so does not resolve the problems.
The changes to the tree all look good @pixelzoom. However, I had to change a few phetioIDs
in examples.md to include graphNode
in the path. Commit is referenced above. This is another example of why https://github.com/phetsims/phet-io-sim-specific/issues/21 would be a really nice feature to have.
I discussed this issue with @arouinfar. Summary:
Feature request #47 (make point tool stay on line that you're currently on) would be better if it was only applicable while dragging. This might warrant a new issue, or might be handled as part of this issue. I need to think about it.
The remaining problems with the point tool color in this issue feel like corner cases, where the interactive and saved curves are identical. They are not pedagogically useful, and we should keep that in mind in deciding how much time to devote to this.
In th long run, it would be better to have the model be responsible for the z-order of curves, and fore the view to use the model when ordering Nodes. This is the bit that's going to be a big change.
Note to self... The relevant files are:
function getQuadraticNear
PointToolDragListener
pointToolQuadraticsProperty
model.savedQuadraticProperty
and model.quadraticProperty
listenersAnother failed attempt... The patch below worked correctly in the standalone sim, but the point tool color is incorrect in the State Wrapper due to the order that GQModel pointToolQuadraticsProperty
dependencies are restored.
I finally worked out a resonable solution in the above commit, which resolves the order dependences involved in restoring state. The API changed, but no migration rules were needed.
The important changes are:
(1) GQModel isSavedQuadraticInFrontProperty
is a new instrument Property that determines whether the saved quadratic is in front of the interactive quadratic. isSavedQuadraticInFrontProperty
is not featured, and it is read-only. GQGraphNode observes isSavedQuadraticInFrontProperty
, and handles moving the saved quadratic to the front/back of the scenegraph.
// Whether the saved quadratic should be displayed in front of the other interactive quadratic. This is true
// immediately after saving a quadratic because it is identical to the interactive quadratic, and would therefore
// be hidden behind the interactive quadratic. This Property was needed to properly restore z-order of curves
// and association of point tools to curves. See https://github.com/phetsims/graphing-quadratics/issues/202
public readonly isSavedQuadraticInFrontProperty: Property<boolean>;
(2) PointTool's quadraticProperty
(the quadratic that the point tool is on) is now a Property<Quadratic|null>
instead of a DerivedProperty<Quadratic|null>
. It is phetioReadOnly: true
, and it is still featured. It is updated (based on its dependencies, via a Multilink) only when we are NOT restoring state. Otherwise its statefulness results in the correct value being restored.
(3) Point tools now prefers to stay associated with a curve only while they are being dragged. This was the request in https://github.com/phetsims/graphing-quadratics/issues/47, and we went a little too far by applying that behavior to all situations. So the behavior is now less confusing when you are not dragging a point tool -- the curve the point tool appears to be "on" will determine its color. For example, if you have a point tool on the interactive curve, then save a curve (via the camera button), the point tool will now change to the color (gray) of the saved curve.
@KatieWoe and/or @Nancy-Salpepi please review in master. If it looks OK, change the label to "fixed-awaiting-deploy" for verification in the next RC.
Things are looking ok in the state wrapper on master from what I can tell.
@Nancy-Salpepi would you like to have a look too, or shall I proceed with the next RC?
I was going to take a look during the spot check, unless you rather I looked now?
Given the number of times that I've unsuccessfully tried to address this issue 🙄, I think it would be better if @Nancy-Salpepi had a look before I publish the next RC.
looking now
I am seeing one odd thing with the pointer color in state and in the standalone. Steps:
https://github.com/phetsims/graphing-quadratics/assets/87318828/a5e05974-7c95-4a5b-9727-ad7522e9f25f
I discussed the behavor in https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1648460255 with @Nancy-Salpepi . When you stop dragging the point tool, its color remains the same as whatever curve it had been attached to -- in this case, the pink curve. When any curve changes (in this case, the gray curve was saved), all curves must be considered as possible candidates, because the point tool doesn't know what changed, how close the curves are to it, etc. The candidates are considered in foreground-to-background order. So in this case, it finds the green curve, which is in front of the pink curve, and the color changes to green. And yes, I agree that it feels a little weird and unexpected.
I'll ruminate some more, and discuss with @arouinfar. But my first reaction is that this is a corner case that we should probably just live with.
I met with @arouinfar.
The first thing we agreed on was... nice job @Nancy-Salpepi at finding this edge case! 😬
The second thing that we agreed on is that this edge case is not worth addressing. If we revert to the previous (published) behavior, that is significantly worse, especially when the interactive and saved curves overlap. Trying to address this edge case would definitely be a complicated/convoluted implementation. The average user is unlikely to have the attention to detail that QA has, so probably won't even notice. And while the behavior is a bit unexpected, it's actually logical when considering the implementation (which admittedly benefits the developer more than user, but c'est la vie).
So... We're willing to live with the behavior reported in https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1648460255, and will label this as ready for RC testing.
Ready for testing in 1.3.0-rc.2. Please close if this issue verifies OK.
Test these scenarios reported above:
... and any other scenarios that occur to you.
All of scenarios in https://github.com/phetsims/graphing-quadratics/issues/202#issuecomment-1648577744 look good to me in rc.2.
Closing (and hopefully never reopening!).
Device Samsung OS Win 11 Browser Chrome Problem Description For https://github.com/phetsims/qa/issues/962 When you first take a "picture" with the picture button a grey line sits on top of the orange line. If you move the orange line, it passes over the gray line where they overlap. The orange line is on top and covers the grey line if you move it back to it's original position, the same as the grey line. However, this last situation is not stateful. If you move the orange line fully over the grey line, and look at the bottom sim in the state wrapper, the grey line will instead sit on top of the orange line, as if just created.
Steps to Reproduce
Visuals