Fix logic error in display tracking

[codeofdusk]

Link to issue number:

None

Summary of the issue:

On my machine (set to 1080p), after a while, NVDA repeatedly says "lanscape". In the Python console, I get:

>>> _displayTracking.getPrimaryDisplayOrientation()
OrientationState(width=1920, height=1080, style=<Orientation.PORTRAIT: 1>)

However, since 1920 is greater than 1080, getPrimaryDisplayOrientation().style should be Orientation.LANDSCAPE.

Description of how this pull request fixes the issue:

Declare parameter names in the call to _getOrientationStyle.

Testing strategy:

Alpha testing

Known issues with pull request:

None known

Change log entry:

None needed

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

[codeofdusk]

@seanbudd I'm getting several display orientation change notifications per minute on my machine, making NVDA unusable until I restart (at which point they stop for a while). Why do we want to report state changes when heightAndWidthUnchanged is True (in _getNewOrientationStyle)?

[seanbudd]

@codeofdusk

This event is only meant to fire if your display changes (either in orientation or connecting to a new display).
https://learn.microsoft.com/en-us/windows/win32/gdi/wm-displaychange

As per the code comment if the height and width are the same, it's a screen flip and the orientation state has changed.
Otherwise, it may be a change of display (e.g. monitor disconnected).

Is it possible your device is connected to a display with a faulty connection? I am curious as to what is firing the WM_DISPLAYCHANGE events.

[codeofdusk]

@seanbudd I usually have no display connected, but connecting one (even for a few minutes) seems to solve it.

[codeofdusk]

That said, assuming the original behaviour of getPrimaryDisplayOrientation isn't intended, I'll mark this PR as ready for review.

[seanbudd]

Thanks yes this is a great catch, does it also fix the issue for you without changing _getNewOrientationStyle?

[seanbudd]

Can you please add a change log entry

[codeofdusk]

It doesn't fix the issue for me, but it does fix a logic error, so hopefully it fixes something else somewhere. No what's new entry added since no apparent user impact.

[seanbudd]

Perhaps we could create a toggle to disable these notifications in general? Might be worth creating an option for power status change notifications too?

[wmhn1872265132]

If this is done, it seems that notifications such as adjusting the volume through the volume keys should not be restricted to the Explorer process.