A PR might be submitted after backlog phase is done:
Is your feature request related to a problem? Please describe.
Thanks to #9792, app modules can define _get_statusBar method to tell NVDA how to obtain status bar for a given program. It turns out there is already a way to do this: overlay classes, as evidenced by base NVDAObject defining _get_statusBar method. This presents a dilemma for NVDA: whose opinion should it follow: overlay class or app module? Besides, current implementation ignores status bar method defined in overlay classes.
Describe the solution you'd like
As overlay classes are more contextual (that is, it represents a graphical element a user is dealing with), let NVDA ask for opinion from overlay classes in addition to app modules. This is useful for a scenario where app module scripts must parse status bar information from everywhere (Foobar2000, for example), with the correct status bar being cached. Another scenario is with apps where two or more status bars are present (GoldWave, for example) and the actual status bar is located somewhere other than bottom of the screen. A third scenario is apps where status bar is located at the bottom of the screen but indented slightly (File Explorer, for example). Although app module version of _get_statusBar may help out in these cases, overlay classes for these apps know better about context.
Describe alternatives you've considered
Either:
Tweak #9792 where either the app module or overlay class status bar method can be consulted.
Remove _get_statusBar from base NVDA object.
Additional context
See #2125 and #4640 about the debate surrounding this issue.
Hi,
A PR might be submitted after backlog phase is done:
Is your feature request related to a problem? Please describe.
Thanks to #9792, app modules can define _get_statusBar method to tell NVDA how to obtain status bar for a given program. It turns out there is already a way to do this: overlay classes, as evidenced by base NVDAObject defining _get_statusBar method. This presents a dilemma for NVDA: whose opinion should it follow: overlay class or app module? Besides, current implementation ignores status bar method defined in overlay classes.
Describe the solution you'd like
As overlay classes are more contextual (that is, it represents a graphical element a user is dealing with), let NVDA ask for opinion from overlay classes in addition to app modules. This is useful for a scenario where app module scripts must parse status bar information from everywhere (Foobar2000, for example), with the correct status bar being cached. Another scenario is with apps where two or more status bars are present (GoldWave, for example) and the actual status bar is located somewhere other than bottom of the screen. A third scenario is apps where status bar is located at the bottom of the screen but indented slightly (File Explorer, for example). Although app module version of _get_statusBar may help out in these cases, overlay classes for these apps know better about context.
Describe alternatives you've considered
Either:
Additional context
See #2125 and #4640 about the debate surrounding this issue.
Thanks.