Skip to content

Status bar handling: allow app modules to define their own routines to fetch status bar and use it in status bar command in global commands #4640

@nvaccessAuto

Description

@nvaccessAuto

Reported by nvdakor on 2014-11-21 19:15
Hi,
Some developers at NVDA development list proposes the following:
As there are situations where one may wish to emulate a status bar and/or read a particular status bar when an app has more than one status bar, let NVDA query the app module for a routine for fetching the desired status bar object before resorting to using status bar routine defined in API module. If this is implemented, it would open new possibilities for app modules to specify which status is which or provde a "fake" status bar. Some of the possibilities are:

  • If an app has two or more status bar objects, let the app choose which one to indicate as a status bar.
  • If an app doesn't have a status bar yet if the user wishes to hear status information, then allow NvDA to announce the "fake" status bar i.e. the status information.
    This second scenario would allow an app module like that of Vim to let the user hear important status information using a familiar command.
    Implementation strategies and current situation:
  • If one wishes to modify how the status bar is returned, one needs to modify NVDA core. This isn't ideal for add-on writers.
  • For some apps, NVDA returns "no status bar found" when there is info displayed somewhere (Vim is a good example).
  • One way to get around this issue is to introduce a routine in base app module that can be overwritten in subclasses to return the desired status object, or if one desires, a routine that simulates a status bar. Then in global commands, have NvDA check to see if the app module for the object has this new routine, and if not, resort to using the core routine for fetching status bar objects.
  • For consistency, the app module routine should set navigator object to the desired status object. A major issue is if we have no status bar objects and if the app module simulates a status bar. Thus the base app module should take care of setting navigator object to the desired status object, with subclasses doing their work and optionally would call the super method if need to.
    Thanks.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions