Short max widths for game answers

[KatieWoe]

For phetsims/qa#277 and phetsims/qa#278
When the correct answer is given on a game level and it says "your line" (the one written in black) in the bottom box, the answer string is very short. This can be noticeable without string Tests if the string is long enough. easiest to see with stringTest=long.

[pixelzoom]

EquationBoxNode is used for both the guess and answer boxes, where the equation's maxWidth is set like so:

60 equationNode.maxWidth = boxSize.width - ( 2 * X_MARGIN ); // constrain width for i18n

So I can't immediately speculate on why the answer equation would be smaller.

[pixelzoom]

Cleanup and fix in the above commits.

This was a problem with 'Graph The Line' type challenge, as identified in the upper-left corner of the screen when running with ?showAnwers. E.g.:

It now behaves properly with stringTest=long, e.g.:

A subclass of 'Graph The Line' challenge is 'Place The Point' challenge. If the placement of the 3 points doesn't make a line, you'll see something like this:

For reasons that I won't try to explain... With stringTest=long, the '... is not a line.' text will not fill the full width of the box, like this:

In practice, this will not be an issue, so I'm not going to go through the gyrations required to make it the full width of the box with stringTest=long.

@KatieWoe please verify in master. If it looks OK, leave the issue open for regression testing in the next RC.

[KatieWoe]

Looks good on master

[pixelzoom]

Pending regression testing in 1.3.0-rc.2.

[KatieWoe]

There still seems to be a problem when the slope is undefined (seen in Graphing Lines level 1).

[pixelzoom]

Thanks @KatieWoe. Fixed in master and 1.3 in the above commits. Please verify in master. If all looks well, leaves this issue open for regression testing in 1.3.0-rc.3.

[KatieWoe]

Doesn't happen in the first screens, but still happens on game screens. @pixelzoom

[pixelzoom]

@KatieWoe can you please elaborate? What problem are you still seeing related to this issue? Below are screenshots for all of the cases that you've identified so far, and text in the bottom box is the full width of the box in all cases.

Screenshots of master with ?ea&stringTest=long&showAnswers.

Similar to screenshot in #117 (comment):

Similar to screenshot in #117 (comment), with undefined slope:

Similar to screenshot in #117 (comment), but with defined slope:

[KatieWoe]

Seen here:

1. stringTest=double
2. Find a challenge where you control the slope
3. Get problem wrong and observe the length of the equation in the Your Line box.
4. Swing the line around as you would in the other screens
5. Observe changed size

[pixelzoom]

OK thanks. This is a new problem, created by the fix for the reported problem.

[pixelzoom]

@KatieWoe The problem reported in #117 (comment) is fixed, please verify in master. Also verify that this doesn't break #114.

[KatieWoe]

All looks good from what I can see

[pixelzoom]

Pending regression testing in 1.3.0-rc.4.

[KatieWoe]

I did have a quick question for GL though. I noticed that "not a line" change size depending on what happened before it. I think this was known (#117 (comment)) but I wanted to make sure before I oked the issue.

Will also be seen with stringTest=long

[pixelzoom]

So here's the dilemma... For "Place the Point" challenges, there are 3 things that can be displayed in the bottom box (the "guess box"):

• an equation (e.g. y = 2x + 3)
• "x = N (undefined slope)"
• "... is not a line"

Only one of these is displayed depending on where the 3 points are placed, and the other 2 are invisible. All 3 share a common parent (the box's content), and maxWidth is set on that common parent. But whether they are visible or not, all 3 contribute to the bounds of the content.

The problem only occurs when transitioning from "x = N (undefined slope)" to "... is not a line" because the former is a longer string. When transitioning from an equation to "... is not a line", there's no problem. This recording demonstrates that:

A few things to consider:

• This is unlikely to occur in practice (with typical strings).
• If it does occur, there's no significant affect on usability.
• Fixing this is likely to take several more hours and require another RC.

So my recommendation is that we do not address this for the current release, or possibly at all. @amanda-phet are you OK with that?

[amanda-phet]

I agree with @pixelzoom that we should not address this. I'm not sure it is worth it ever, because of the considerations you listed (unlikely to occur, and no effect on usability).

[pixelzoom]

Thanks @amanda-phet.

@KatieWoe anything else to do here, or OK to close?

[KatieWoe]

Should be ok to close. Closing