Tor

[Tor]

Hi. The error printed by the client is misleading, it should have stated clearly that there is a problem with the proxy configuration. We’ve documented this wrong error reporting here:

https://www.nomachine.com/TR07S10321

As for the reason why the proxy configuration is wrong, this is not clear yet. Can you try to select “Use system proxy setting” instead of “Automatic proxy configuration”? Is your system actually configured to use a proxy?
If you’re not sure about it but you know proxy parameters, you can select the manual configuration and fill it with the correct proxy host and port.

[Tor]

Hi. Qt is using the X server properties and system environment to determine how to paint widgets, so we could compare the two different working environments to understand how to fix your issue.
Are you connecting to a virtual or to a physical desktop? What is the server operating system version?
You can run the commands xdpyinfo and env in your local or SSH terminal (where the application has the correct style) and in the remote NoMachine desktop, then attach the outputs here or to an email to forum[at]nomachine[dot]com. I’ll gladly check them to answer your doubts.

[Tor]

Hi! All settings you change while connected to the remote desktop are saved and automatically applied when you connect again.
What is the distribution of the server? Are you connecting to a physical or virtual desktop?
Can you describe what you see exactly? For example, the session starts in fullscreen then goes back to window mode?
Did you try to change other settings, like a checkbox in Input or Display settings, in order to verify if those preferences are correctly saved?
Are you connecting to a server configured manually, or to a server automatically discovered in your LAN?
Thanks.

[Tor]

Hi!
You can press Control + Alt + ID to switch monitor, where ID is 1, 2, etc. If you want to know the ID of each monitor, press Control + Alt + I. You can also configure these key bindings from menu Input, Shortcuts.

[Tor]

Hi Martin.
You can open the Display menu by pressing Control + Alt + 0 and by clicking the Display item.
In order to know if your window manager can be configured to show thick window borders we’d need to know the operating system version running on the server, as this is a system configuration.

[Tor]

Hi. We have a similar issue documented here:

https://www.nomachine.com/TR10Q09439

During our tests we’ve found this issue occurs when Sticky Keys are enabled on Windows, could you please verify if that is your case? The configuration can be checked in Settings, Ease of Access, Keyboard, Use Sticky Keys.

[Tor]

Hi. Is the ‘Scale to window’ option enabled in the Display menu? If the remote desktop is being shrinked in the window, grabbing a window edge could be difficult if the remote window manager has a tiny sensitive area since it’ll be reduced even more by the scaling down effect. If this is the case you could disable the scaling mode, or configure the window manager to show bigger window frames.

[Tor]

Nothing changed between my initial report and now.

So far we could not reproduce the issue you’re describing, with the Gnome configuration I’ve suggested above. Could you contact us at forum[at]nomachine[dot]com, so we could send you a client automatically dealing with the compositor requests in order to exclude some trivial problems?

[Tor]

Thank you for your feedback. Would you like to tell us the name of the Antivirus and the version, so we can contact them to discuss the issue? If you can’t publish the name here feel free to contact us to forum[at]nomachine[dot]com.

[Tor]

Hi. Open the Display menu bar and verify that “Scale to window” is NOT selected, because that is generally the reason why you see some stretching. You should select “Enable viewport mode” and choose in Display settings the same resolution of your client display, so when going fullscreen you’ll have a perfect 1:1 ratio. Let us know if this helps.

[Tor]

Hi. Please open the Console application from Utilities menu, select “User Reports” on the left column and click on the most recent file in the list on the right that has prefix “nxplayer_”. Right click the selected file, choose “Reveal in Finder” in the context menu, then send that file to forum[at]nomachine[dot]com.
Confirm here if there are no files with that prefix, so we’ll discuss another way to debug your issue.

[Tor]

Hi. Could you send here the output of the command xrandr -q executed in a terminal on the virtual desktop?

[Tor]

The client is not swapping keys between Linux and macOS, so if you want to send Command + C you’ll have to press the keyboard button corresponding to “Command” on Mac (for example on a Windows keyboard it would be the Windows button). Can you confirm you’ve used shortcuts in this way?

[Tor]

I tried it in fullscreen, windowed, another monitor, virtual desktop, with grab and without grab.

You NEED keyboard grabbing if those shortcuts are being used by the local system. 🙂
You’re probably using Wayland, this is the reason why it is not working. The problem is documented here:

https://www.nomachine.com/TR10P08952

Since you’re using GNOME you can try the following workaround:

1. Enable input grabbing in Wayland

gsettings set org.gnome.mutter.wayland xwayland-allow-grabs true

2. Print the whitelisted applications

gsettings get org.gnome.mutter.wayland xwayland-grab-access-rules

3. Append ‘nxplayer.bin’ to the existing application classes. “App A” is an example, your whitelist could be empty so you just need to add the player

gsettings set org.gnome.mutter.wayland xwayland-grab-access-rules "['App A', 'nxplayer.bin']"

4. Launch the player by enabling the active window grabbing

/usr/NX/bin/nxplayer --activegrab

[Tor]

Hi. Can you please verify if shortcuts are correctly forwarded when NoMachine client window is fullscreen? Don’t forget to enable keyboard grab option, it is required to catch also shortcuts used by your Linux system.

[Author]

Posts