nvda

bd9bb487 - Made portable creation through the installer or tools menu more flexible, by allowing system variables in paths (#14681)

Made portable creation through the installer or tools menu more flexible, by allowing system variables in paths (#14681) Fixes #14680 Summary of the issue: While it is possible to use system variables (%appdata%, %userprofile%, %temp%, etc.) in the create portable dialog's "browse" sub-dialog, it was not possible to use them in the Create Portable dialog itself. Therefore, when using the installer or the tools menu portable option, one either had to enter full paths, or use the browse dialog to utilize system variables to minimize typing. For people who create many portables, that can be unnecessary overhead. Description of user facing changes It is now possible to use system variables (such as %tmp% or %homepath%) in the path specification while creating portable copies of NVDA. Additionally, it is no longer necessary to include a drive letter when entering the absolute path to a portable target. Description of development approach In gui.installerGUI, there is a method of PortableCreaterDialog class, called onCreatePortable: The path, as entered in the dialog (self.portableDirectoryEdit.Value), was used in this method three times. Created a local variable, expandedPortableDirectory, containing that value, processed through os.path.expandvars(). Used that local value throughout the remainder of the method. Added a note to the error which appears if the user doesn't specify an absolute path, stating that system variables may be used. Rephrased the messages asking for the path, and removed the mention of the required drive letter, per NV Access review comments. Replaced a % substitution with a .format() string formatter, in an error dialog. Edited, reformatted, and added missing translator comments. Miscellaneous linting. Additional: In gui.installerGUI.doCreatePortable(): Linting, spelling, added translation comments, replaced substitutions with calls to format A note regarding no longer checking for drive letter in entered absolute path: While creating a portable copy, we ask the user for an absolute path. In the os.path module's opinion, a path can be absolute without having a drive letter. Therefore, we previously checked and threw an error if the drive letter was missing. When @seanbudd suggested removing the drive letter notation from absolute path messages, testing without entering one revealed errors that occurred if there was no drive letter, even though it shouldn't technically matter. Instead, since os.path.isabs has already determined that the path is absolute, we can just add the drive letter if it's missing. We can do that by calling os.path.abspath, which absolutizes the (probably mostly) already absolute path, by adding a drive letter if it was missing, and any other path components necessary to have a fully qualified path. --- Commits: * Made portable creation through the installer or tools menu more flexible, by allowing system variables in paths. (#14681) In the method PortableCreaterDialog.onCreatePortable: The path, as entered in the dialog (`self.portableDirectoryEdit.Value`), was used in this method three times. - Created a local variable, `expandedPortableDirectory`, containing that value, processed through `os.path.expandvars()`. - Used that local value throughout the remainder of the method. - Removed the mention of drive letter in absolute path messages, per NV Access suggestion. - Added a note to the error which appears if the user doesn't specify an absolute path, stating that system variables may be used, and giving examples. - Reformatted a translation comment for the title of that error dialog. - Replaced a % substitution with a .format() string formatter, in an error dialog. - Miscellaneous linting. - Added a few missing translator comments. * gui.installerGUI.doCreatePortable(): Linting, spelling, added translation comments, replaced substitutions with calls to format * Stop trying to check for drive letter in entered absolute path. When creating a portable copy, we ask the user for an absolute path. Since technically a path can be absolute without having a drive letter, we previously checked and threw an error if the drive letter was missing, even though Windows doesn't require one to be absolute about the path. Instead, since os.path.isabs has already determined that the path is absolute, all that remains is to add the drive letter if it's missing. We can do that by calling os.path.abspath, which absolutizes the (probably mostly) already absolute path, by adding a drive letter if it was missing, and any other path components necessary to have a pedantically correct path. * Added a blank line (linting) * Incomplete review suggestion Co-authored-by: Sean Budd <seanbudd123@gmail.com> * Explain where the os.path.abspath drive letter comes from. * update changes * update changes --------- Co-authored-by: Luke Davis <XLTechie+github@newanswertech.com> Co-authored-by: Sean Budd <seanbudd123@gmail.com> Co-authored-by: Sean Budd <sean@nvaccess.org>