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.
|
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. |
- Add comprehensive docstring - Replace log.error with log.exception for better error tracking - Move keyConnector cleanup to finally block to ensure proper resource handling - Remove unused exception variable from catch clause
Add explicit parameter name 'backlog' and explanatory comment to the socket.listen() call to improve code readability and make the purpose of the value 5 more obvious to future maintainers.
- Standardize parameter naming from snake_case to camelCase (bind_host → bindHost) - Add docstrings to key classes and methods in server.py - Use more specific is_file() check instead of exists() for certificate fingerprint - Clean up parameter naming across secureDesktop.py and server.py
|
Just checking, we will still be able to do that, right? I have a relay server running and on the same machine I have another port to control NVDA but not through the relay server. |
# Conflicts: # source/config/configSpec.py # source/config/profileUpgradeSteps.py
|
@coderabbitai resolve |
|
@amirmahdifard @Aarushb @valiant8086 |
|
Very nice work @SaschaCowley and @ctoth |
|
This is amazing! Unfortunately self-hosted servers fail in this implementation, so I'm keeping my add-on copy around for just a bit longer, but am glad to see this become part of core. Error log: For non-self-hosted server connections (as to a remote URL), it works without this error popping up, though. |
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