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
Milestone
Comments
Comment 1 by Joseph Lee <joseph.lee22590@... on 2015-08-29 02:36
|
Closed
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 (_).
5 tasks
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
Reported by nvdakor on 2015-08-29 02:29
Hi,
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 "foo.bar.exe", Python will fail to locate "foo.bar.py" - 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 (Microsoft.photos.exe with the app module of Microsoft_photos.py), Universal Windows App (UWA) version of Twitter (twitter.windows.exe) 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).
Thanks.
The text was updated successfully, but these errors were encountered: