Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

App module handler: handle executable names with dots as part of the file name #5323

nvaccessAuto opened this issue Aug 29, 2015 · 1 comment


Copy link

Reported by nvdakor on 2015-08-29 02:29
Consider the following scenario: an app module writer will write support for an app that contains dots as part of the executable image name. However, due to Python's way of searching for paths, the new app module will not be loaded. For example, suppose if one needs to support an app named "", Python will fail to locate "" - assuming "foo" is a package and "bar" as one of its modules.
To handle this case, add a checking routine in app module handler's app module fetch routine to see if an executable name has dots, and if so, replace dots with underscores. This allows app modules for apps with dots as part of the executable name to replace the offending dots with underscores (which will not confuse Python). With this change, app module handler will be able to handle apps such as Microsoft Photos ( with the app module of, Universal Windows App (UWA) version of Twitter ( and so on and allows add-on writers to write app modules for these apps (until app developers utilize UIA for the benefit of screen reader users; this last point is crucial now that UWA is here, and these apps are UIA heaven).

Copy link

Comment 1 by Joseph Lee <joseph.lee22590@... on 2015-08-29 02:36
In [3c876e7]:

App module handler: Executables with dots as file name are now loaded by replacing dots with underscores. re #5323.

Because of Python's way of importing modules, an executable name such as would be interpreted as bar module in foo package. To handle this case, underscores will be used. This may also mean how app module is reported to users (Control+NVDA+F1) may have to be modified somehow. For now, each dots will be replaced bd a single underscore.

josephsl added a commit to josephsl/nvda that referenced this issue Aug 22, 2016
…utable name. re nvaccess#5323

To avoid module lookup issue, a 'dot' (.) is replaced by an underscore (_).
@nvaccessAuto nvaccessAuto added this to the 2016.4 milestone Sep 16, 2016
jcsteh pushed a commit that referenced this issue Sep 16, 2016
…a dot (.) in their names. Dots are replaced with underscores (_).

Issue #5323. PR #6286.
seanbudd pushed a commit that referenced this issue Apr 26, 2022
…ary appModule to a given executable. (#13366)

Related to #13364

Summary of the issue:
Currently when NVDA tries to load an appModule for a given program it just looks for a Python module of the same name as the program's executable. This has its limitations in particular:

Some names are incompatible with the Python's import system (for example see App module handler: handle executable names with dots as part of the file name #5323 where we resorted to replacing dots with underscores before attempting the import).
When a single apModule should be used for a multiple executable's we need as many appModules as there are executable's (this also often causes linter failures as these alias modules just star imports everything from the main module).
Even if the given module name does not contain symbols which are incompatible with importlib they may contain characters which are invalid in ordinary import statements (for one example see Fix crashes in 64-bit builds of Notepad++ 8.3 and later #13364 where the apModule is called "notepad++"). Since "+" is invalid in Python's import statement add-on developers cannot import this module from nvdaBuiltin which means that it cannot be extended in an add-on.
Description of how this pull request fixes the issue:
This PR introduces a mapping of executable names to appModules which is consulted before the given module is imported. It also adds a convenience functions for add-on developers which can be used to register or unregister a specific module for a given program. All alias apModules currently present in the source are marked as deprecated and application's for which they were loaded are mapped to the right appModule using the new map.
Since we cannot remove the old alias app modules care has been taken not to use them - they' re kept only for add-ons developers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

1 participant