In addition to what is already done here:

• Context help is not working in "Remote" settings panel, in new connection dialog; I did not test elsewhere.
• The connection dialog layout is lacking spaces between its controls; this makes it more difficult to see for visually impaired people and is not consistent with other dialogs of NVDA's GUI. NVDA's GUI helpers should be used so that the dialog has a standard look.
• The code of the connection dialog is not in the gui subfolder; it would be nice to move it there.

Will you take care to fix this in this PR or should new issues be opened?

Regarding the removal of radio buttons, I do not understand it. Even rare, they are present in NVDA's interface: profile dialog, new dic entry dialog, NVDA+F7 dialog, and maybe others. They are also quite common in standard Windows GUI and on the web. I found that they were rather a nice experience and would have kept them, grouping them in a group though, so that the context to what they apply be known. Just my opinion though; it's not an imperative change request.

I also wonder:
The integration of NVDA remote's code was a big PR. Maybe the remote code package should be made private, as it was done for add-on store at the beginning, because I expect this code to be polished or modified a bit in the future.

What do you think?

@CyrilleB79 thanks for the feedback!

• Context help is not working in "Remote" settings panel, in new connection dialog; I did not test elsewhere.

Yep, this is being worked on in this PR

• The connection dialog layout is lacking spaces between its controls; this makes it more difficult to see for visually impaired people and is not consistent with other dialogs of NVDA's GUI. NVDA's GUI helpers should be used so that the dialog has a standard look.

This was a big part of this PR. I think all of the work should be done, so if you want to give it a spin and let me know what you think, feel free.

• The code of the connection dialog is not in the gui subfolder; it would be nice to move it there.

I'm a little unsure about this myself.

• Keeping this code in the remoteClient package keeps remote very self-contained, which means if, for example, a security-conscious person wanted to contain a build of Remote without any Remote code in it at all, they could fairly easily do so.
• On the other hand, it would be more internally consistent to keep this code in the gui subpackage, probably in its own module.

Regarding the removal of radio buttons, I do not understand it. Even rare, they are present in NVDA's interface: profile dialog, new dic entry dialog, NVDA+F7 dialog, and maybe others. They are also quite common in standard Windows GUI and on the web. I found that they were rather a nice experience and would have kept them, grouping them in a group though, so that the context to what they apply be known.

Thanks for those examples. Have a play with the redesigned dialogs and let me know what you think. The change between dropdowns and radio buttons is fairly easy to make.

I did experiment with keeping the radio buttons, but I found that having grouped radio buttons contained within another grouping was not verbalised very well. I can do more experimentation if we think that it's worthwhile.

The integration of NVDA remote's code was a big PR. Maybe the remote code package should be made private, as it was done for add-on store at the beginning, because I expect this code to be polished or modified a bit in the future.

I'll have a chat with the rest of the team about that. Thanks for the suggestion.

I just had a look at the new dialogs (Connect and settings). With the little that I am able to see, the layout seems ok.

I still have questions and remarks:

1. Title of the Connect dialog (NVDA+alt+pgUp): could it be renamed to "Connect to another machine" or "Connect with another machine"? or "a remote machine"
2. In the Connect dialog, if you click "Get External IP", a message could pop up about 5 seconds later to say that the port is probably not forwarded. There is no waiting dialog/progress bar after you click on "Get External IP" and this may be confusing if you have continued navigating in the time between. There are even bugs if you have already validated the OK button of the connect dialog because after you validate the no port forwarded error message, you turn back to navigate in the Connect dialog again (which should have been closed), but it is visually not visible anymore.
3. When you configure auto-connect in the settings, if you use an existing server (default case), you can specify the host, but not the port that is greyed out. What does it mean? What if the chosen existing server uses another port than Port : édition non disponible Alt+ p sélectionné 6837?
4. And is this port information required to be known at all in this use case? If yes, why isn't it present in the Connect dialog for the same use case?
5. When pressing NVDA+alt+pgUp, the Connect dialog is opened in background; it is not set as foreground window and it does not automatically take the focus; I need to alt+shift+Tab to focus it.

Also:
6. You have removed the notion of "Relay server" from the GUI. IMO, using this term in the suitable situation would help. E.g., if I have understood correctly: Use the following values for "Server:": "Use an existing relay server" / "Set up a server locally"

1. Title of the Connect dialog (NVDA+alt+pgUp): could it be renamed to "Connect to another machine" or "Connect with another machine"? or "a remote machine"

Yes, I agree with this.

2. In the Connect dialog, if you click "Get External IP", a message could pop up about 5 seconds later to say that the port is probably not forwarded. There is no waiting dialog/progress bar after you click on "Get External IP" and this may be confusing if you have continued navigating in the time between.

My bad, it looks like I marked this as ready to review but hadn't pushed my changes! There is now a progress dialog while attempting to get the external IP.

There are even bugs if you have already validated the OK button of the connect dialog because after you validate the no port forwarded error message, you turn back to navigate in the Connect dialog again (which should have been closed), but it is visually not visible anymore.

I don't quite follow, but I think this should have been fixed by adding the progress dialog.

3. When you configure auto-connect in the settings, if you use an existing server (default case), you can specify the host, but not the port that is greyed out. What does it mean? What if the chosen existing server uses another port than Port : édition non disponible Alt+ p sélectionné 6837?

If using a remote relay server and port other than 6837, you can append a colon and the port number (ex. example.com:1234). This could definitely be clarified in the UI.

4. And is this port information required to be known at all in this use case? If yes, why isn't it present in the Connect dialog for the same use case?

Most users should not need to specify the port to use when using a relay server, but may do so by appending a colon and the port number (ex. example.com:1234) if this is needed. I have noted this in the user guide.

5. When pressing NVDA+alt+pgUp, the Connect dialog is opened in background; it is not set as foreground window and it does not automatically take the focus; I need to alt+shift+Tab to focus it.

I'm not experiencing that here, but I can have a look at explicitly focusing it if that isn't being done already.

6. You have removed the notion of "Relay server" from the GUI. IMO, using this term in the suitable situation would help. E.g., if I have understood correctly: Use the following values for "Server:": "Use an existing relay server" / "Set up a server locally"

I was personally a little torn about the terminology to use here. I think calling it a "remote relay server" is a bit confusing, as we're using the word "remote" as an adjective, but it is in a context where "remote" could be interpreted as the name of the feature. This is something that I want to discuss with the team when they return from CSUN, and possibly tackle along with your issue #17815 about using a consistent name.