Remote Access #17580
Remote Access #17580
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
See test results for failed build of commit 460a4efb7f |
|
hi, great! but if this will be implimented, tele nvda addon's features should be ported hear because that addon has several features that we need, that nvdaremote doesn't have them. great! |
|
@jmdaweb may be you have something hear |
|
Sorry, but I have nothing to say. An issue was opened in the NVDA Remote repo requesting integration of TeleNVDA features while code refactor was in progress and it was completely ignored. Given our interactions in the past, I prefer waiting for NV Access. For now, I think TeleNVDA will probably reach its end of life and all additional features will be lost. However, seems this pr will have a long discussion and more commits before it's merged, so it's impossible to predict the result. |
|
@jmdaweb what! why tele nvda will be discontinued? the features was the best and it's impossible to work with nvda remote with out tele nvda's features. This is not good at all. someone who could, later dipending on nvaccess opinion, could develop the tele nvda's code in to nvda. |
|
Cc: @LeonarddeR |
|
To be honest, that is exactly what I was thinking: the tell NVDA assistance addon features. While this itself is a great step, I've migrated to tell for a good while now because it allows for features such as file sharing. I will not derail any further however given that this is pr for remote and not tell, neither is this an issue. I just mentioned it since apparently an issue was opened previously but not responded to. Just having remote itself is also really fantastic, and the features from tell could always be merged in at a later time with proper credit. |
|
I guess it makes sense to port whatever is relevant in tele nvda to NVDA core after this pr is merged. |
|
@LeonarddeR We would love feedback! I'm heading to CES this week and so may not be able to address reviews until next week, but absolutely reviews are welcome. We want to make this the best-possible experience for users and devs alike. |
There was a problem hiding this comment.
Here are some initial thoughts:
* The URL handler has not yet been hooked up, disabling nvdaremote:// link functionality. We should discuss if we want to embed it as a stand-alone executable or port the functionality to another executable in NVDA. See also [NVDA Remote dependency: Bundle url_handler.exe in NVDA #16714](https://github.com/nvaccess/nvda/issues/16714)
I guess this can be added to nvda_slave, which also deals with the nvda-addon file extension handling.
The rationale for leaving everything self-contained is it makes it very easy to completely remove the functionality if desired in a corporate setting.
I think having a super toggle somewhere that indeed allows you to disable the functionality completely makes sense here.
Regarding the code, I'm noticing several snake cased attribute names here and there, particularly in the gui parts. I'm pretty sure something like code rabbit should be able to list them all, then renaming them with an intelligent IDE shouldn't be to difficult.
source/remoteClient/beepSequence.py
Outdated
| BeepSequence = collections.abc.Iterable[BeepElement] | ||
|
|
||
|
|
||
| def beepSequence(*sequence: BeepElement) -> None: |
There was a problem hiding this comment.
I guess this can safely go into the tones module.
|
I can see that #43900 has not yet been triaged; maybe, I hope for you, you have discussed it in an alternative way with NV Access so that this almost 5000 LOC work was not submitted in vain. I'll wait for NV Access labelling (triaged or concept-approved) before commenting this PR. |
|
also, if this will be merged, it should become like nvda it self as wel. In nvda, in addon stor for example, when we press actions button for an addon or press application, all context menu options are toggle options, which is really great. But in nvdaremote, we always have connect and disconnect options, and when connected, the connect option is disabled and disconnect is enabled and vice vercer. This should be a toggle option in core. Tele nvda already done this but not like it should. It used removed and inserted options instead of disabling and enabling. But hear, one of the options connect or disconnect should be completely removed from the code, and only the other be inuse, exactly like the mute option. That is, when we press that option, an if check should be in it's def to check if the remote is connected, it will disconnect and the option name will be changed to connect..., and vice vercer. And also, like tele nvda, the mute option should change it's lable between mute remote and unmute remote. This way, the code is much cleaner and clearer because one of the defs will be removed and the checks will all be aplyed on one def, and also, as we talked before in tele nvda repo, this is more wanted user interface and less confusing. Now that this is coming in to nvda it self, people should have it in the improvements as now this is in the core, and users should not replace it with anything else, like, oh nvdaremote is not good, lets switch to tele nvda because of, 1: user interface. 2: alert before disconnecting the controled computer checkbox to prevent so many problems developed by @cary-rowen in tele nvda repo. 3: the new mute remote computer when controling local computer that if checked, when you switch back to local computer, the remote computer will be muted automaticly. This is useful for many cases but all of these are optional and no body is forced to use or not use them, developed by my self in tele nvda repo. 3: a fue unassighned shortcuts, such as. Send ctrl alt del, open addon options, developed by my self in tele nvda repo. So, please consider everything befor this addition. As always, Thanks! |
SaschaCowley
added
the
conceptApproved
ctoth
force-pushed
the
remote
branch
2 times, most recently
from
cacbbbf to
90471a6
Compare
|
Here are the existing add-on translations: |
|
about unmuting remote computer when controling it commit, it should folow tele nvda's code because that is optional checkbox that if checked, controling local computer will mute the remote automaticly and when controling remote, it will unmute the remote automaticly. And if this option is not checked, non of these happen. It is a lot better and useful for many things |
|
@jmdaweb hello, I have a question. If this gets merged in nvda, will it be stil compatable with the nvda remote server relay implimentation made by you? because we and so many people are using that nice server to host their own remote servers. Whel it was compatible with nvda remote and tele nvda, so i just wanted to make sure it is also compatible with this core remote feature as wel. |
|
@ctoth you mentioned:
Could you elaborate on this? In what sense do you want to improve the braille experience? |
I am not personally a Braille user but I have heard reports of issues where the master and slave displays conflict or both try and show information, or the Master blinks between its own text and the other text with the default 2.6.4 add-on. I don't know if anything at all is wrong, or if something is wrong and it is specific to certain models, or if nothing is wrong and the current Remote works fine. I do know that we tested this implementation from both connection types, with and without the UAC transition, etc. and it seems to work well. |
|
If braille is on par with current remote, I guess we can leave it as is and then improve it if need be. |
source/utils/alwaysCallAfter.py
Outdated
| import wx | ||
|
|
||
|
|
||
| def alwaysCallAfter(func): |
There was a problem hiding this comment.
Can type hints be added please? This will need typing.ParamSpec and collections.abc.Callable
| @@ -221,6 +221,8 @@ def _genManifestTemplate(shouldHaveUIAccess: bool) -> tuple[int, int, bytes]: | |||
| # multiprocessing isn't going to work in a frozen environment | |||
| "multiprocessing", | |||
| "concurrent.futures.process", | |||
| # Tomli is part of Python 3.11 as Tomlib and causes an infinite loop now. | |||
There was a problem hiding this comment.
What is the meaning of this comment? Why is tomllib not satisfactory?
There was a problem hiding this comment.
The Cryptography package tries to import Tomli, which makes it get picked up by Py2exe. We don't need it for the functionality we use Cryptography for, and if we don't exclude it from the build Py2exe gets confused and stuck in an infinite circular import loop, which results in a RecursionError.
Improve code clarity by renaming the global client variable to a more descriptive name 'remoteClient' across the codebase. This change: - Renames the global variable in remoteClient/__init__.py from 'client' to 'remoteClient' - Updates all references in globalCommands.py to use the new variable name - Adds explicit cleanup in terminate() by setting remoteClient to None - Preserves type hints and existing functionality
Change ConnectionMode and ConnectionState from Enum to StrEnum for more straightforward string handling. This allows direct use of enum members as strings without accessing the .value property.
…nd is disconnected. Also fix logging
Co-authored-by: Cyrille Bougot <[email protected]>
Co-authored-by: Leonard de Ruijter <[email protected]>
Co-authored-by: Leonard de Ruijter <[email protected]>
Changes how nvdaremote:// URLs are processed by: - Adding a new nvdaControllerInternal RPC method handleRemoteURL - Updating URL handler registration to invoke nvda_slave.exe directly - Updating the slave to pass the URL to the running NVDA This simplifies the URL handling by: 1. Using existing NVDA helper infrastructure instead of custom window messaging 2. Eliminating need for WM_COPYDATA IPC and associated complexity 3. Providing more direct and reliable URL processing path sans url_handler.exe
Added new interface function handleRemoteURL to enable remote URL handling capabilities in NVDA: - Added fault_status/comm_status interface definition in nvdaControllerInternal.acf - Added corresponding function exports in both local and remote helper DLLs
Use config migration system to move remote control settings from separate remote.ini into NVDA's main configuration: - Add "remote" section to base configuration spec - Increase schema version from 15 to 16 - Add migration code to automatically move settings from remote.ini to main config - Update remote client to use main config instead of separate file - Create backup of old remote.ini after migration - Remove standalone remote config handling code
There was a problem hiding this comment.
Please update the copyright header
There was a problem hiding this comment.
Please update copyright headers
There was a problem hiding this comment.
Please update copyright header
There was a problem hiding this comment.
Can you please add a copyright header?
| """Handles a remote URL request from the slave process. | ||
| @param url: The nvdaremote:// URL to process | ||
| @return: 0 on success, -1 on failure | ||
| """ |
There was a problem hiding this comment.
Could you please update this docstring to use Sphinx style docstrings per our coding standards?
| """Handles a remote URL request from the slave process. | |
| @param url: The nvdaremote:// URL to process | |
| @return: 0 on success, -1 on failure | |
| """ | |
| """Handles a remote URL request from the slave process. | |
| :param url: The nvdaremote:// URL to process | |
| :return: 0 on success, -1 on failure | |
| """ |
Resources:
| @@ -9,6 +9,7 @@ | |||
| * Support for math in PDFs has been added. | |||
| This works for formulas with associated MathML, such as some files generated by newer versions of TeX/LaTeX. | |||
| Currently this is only supported in Foxit Reader & Foxit Editor. (#9288, @NSoiffer) | |||
| * Full remote access functionality based on the NVDA Remote add-on has been integrated into core, allowing users to control another computer running NVDA or allow their computer to be controlled remotely for assistance and collaboration. Previously available only as an add-on, this functionality is now built into NVDA with improved security, better integration with NVDA's systems, and enhanced maintainability. (#4390, #17580, @ctoth, @tspivey, @daiverd, NVDA Remote Contributors and funders) | |||
| [[controlserver]] | ||
| autoconnect = boolean(default=False) | ||
| self_hosted = boolean(default=False) | ||
| connection_type = integer(default=0) |
There was a problem hiding this comment.
Please add a comment explaining the meaning of the integer values.
| [[seen_motds]] | ||
| __many__ = string(default="") |
There was a problem hiding this comment.
My feeling is that we will ask for MOTD functionality to be removed, but I haven't review that part of the code yet, nor asked the team.
There was a problem hiding this comment.
Can you please update the copyright header?
| @@ -529,3 +530,19 @@ def functionWrapper(): | |||
| raise exception | |||
| else: | |||
| return result | |||
|
|
|||
|
|
|||
| def alwaysCallAfter(func: Callable[..., None]) -> Callable[..., None]: | |||
There was a problem hiding this comment.
Can you please fix the type hinting here, probably with a typing.Paramspec?
Link to issue number:
#4390 - The initial request for "NVDA Remote functionality
Summary of the issue:
This PR integrates NVDA Remote functionality into core with significant
architectural improvements and modernization. While maintaining protocol compatibility with the existing add-on, it introduces cleaner architecture, type safety, proper event handling, and improved maintainability.
Description of user facing changes
Description of development approach
The implementation follows a modular architecture:
Core Components:
Integration Points:
Security Considerations:
The code has been ported from the nvdaremote/nvdaremote repository and significantly improved from the version most-recently deployed.
Testing strategy:
We have performed extensive manual testing of the feature both with versions of itself as well as the older add-on.
We have some examples of unit tests hooked up with NVDA's testing infrastructure testing some components which will be supplied, , though we as the community need to write more unit and system tests.
It has been tested with Braille, though we would greatly-appreciate if more Braille and Braille-only users could test it strongly. We wish to improve the Braille experience from the existing baseline in the 2.6.4 add-on.
Known issues with pull request:
remoteClientpackage, but we may want to move things like theRemoteMenuout into theGUIpackage. The rationale for leaving everything self-contained is it makes it very easy to completely remove the functionality if desired in a corporate setting.Code Review Checklist:
Summary by CodeRabbit
Release Notes: NVDA Remote Access Feature
New Features
Key Capabilities
User Interface
nvdaremote://URL handling