Physical monitor limitations for virtual sessions w/ floating window

[NicolasRouquette]

I work with an Amazon VM running CentOS7 & the NX Workstation server (5.1.26) to which I connect from a MacBookPro (2880×1800) running Mac OS X 10.11.5 with two external Apple Thunderbolt displays (2560×1440) using the NX client (5.1.26).

This setup has been working for me for about a year since I discovered NX and I love the performance, reliability and connectivity options. I’ve observed some rather peculiar aspects of the NX client behavior w.r.t. multi-monitor setup that I’d like to know whether these are intended “features” of the product or something else and would be interested in usability improvements in this area.

Running a virtual desktop is limited to one physical display regardless of whether the laptop is open (3 monitors) or closed (2 external monitors). With the external displays arranged in a row, I would like to have a virtual desktop shown over both displays (i.e., (2×2560) x 1440 = 5120×1440). Unfortunately, that does not work. This would be a really uber cool capability.

Running a custom session (e.g., gnome-terminal) as a floating window is a problem depending on whether I have the laptop open or not. In this mode, I understand that the NoMachine client automatically starts an XQuartz server on the mac to display the floating X windows from the NX server, which runs a virtual X display server unique for that session (e.g., :1001).

With the laptop open, “xwininfo -root” tells me the geometry of the X display server is 7040×1779.
This suggests that one could use all three monitors. However, that’s not the case.

• Maximize the gnome-terminal X window; then “xwininfo” says the geometry is 1919×1143. This behavior would be consistent with an X display server geometry of 1920×1200; not 7040×1779!
• I can’t resize the window any larger either. In fact, all X events outside a top-left 1920×1200 rectangle are ignored altogether.
• I can’t move the window to any other physical monitor.

What’s really annoying here is that I can’t work with the laptop open (i.e. 3 monitors) and custom sessions displayed as floating windows.

With the laptop closed, “xwininfo -root” tells me the geometry of the X display server is 5120×1418.
Again, this suggests that one could use both monitors.

• Maximize the gnome-terminal X window; this time, xwininfo gives 1919×1141. This behavior would be consistent with an X display server geometry of 1920×1200; not  5120×1418!
• I can manually resize the window to use all of 1 monitor (great!)
• I move an X window wholly displayed on one monitor to be wholly displayed on another monitor (great!) If an X window is positioned such that it should be displayed in part on both monitors, then only the top left side is displayed on one monitor; the other side isn’t visible even though the monitors are logically arranged side-to-side without any gap.
• The caveat in this configuration comes from tools that pop up new windows (e.g. modal dialogs). Sometimes, these can show up in a place that would straddle monitors and be partially visible or not at all. I found the following tools to be useful to move around X windows whose top isn’t accessible via the mouse:
  • https://github.com/dancor/wmctrl
  • https://github.com/fikovnik/ShiftIt
  • https://www.semicomplete.com/projects/xdotool/xdotool.xhtml

I would like to know if this behavior is reproducible, whether it is normal and whether there are any planned improvements in this area.

 

 

[graywolf]

Hello

With the external displays arranged in a row, I would like to have a virtual desktop shown over both displays (i.e., (2×2560) x 1440 = 5120×1440). Unfortunately, that does not work. This would be a really uber cool capability.

NoMachine allows user to chose “Fullscreen” (in that case the remote session covers one monitor) or “Fullscreen on all screens” (covering all monitors). Actually, the case you describe is different as you’d like to span the remote session over two monitors of three.

A feature request describes how the layout of multiple monitors should be exported to the remote session, so they could be treated as separate entities. An additional specification fitting your case could be the ability of chosing which monitors must be assigned to the session and organising them in a custom layout.

I can’t resize the window any larger either. In fact, all X events outside a top-left 1920×1200 rectangle are ignored altogether.

If an X window is positioned such that it should be displayed in part on both monitors, then only the top left side is displayed on one monitor; the other side isn’t visible even though the monitors are logically arranged side-to-side without any gap.

This behavior looks strange. We are going to reproduce and fix it.

The caveat in this configuration comes from tools that pop up new windows (e.g. modal dialogs). Sometimes, these can show up in a place that would straddle monitors and be partially visible or not at all.

This occurs because the set of monitors is treated as a whole. The mentioned feature request would help in this case too. The dialogs should be displayed in the centre of one monitor, but now the edges of the monitors are not known to the remote applications.

[graywolf]

It is possible that many of the issue you reported are related to the way OS X handles “spaces” and “screens”

https://xquartz.macosforge.org/trac/ticket/796
https://support.apple.com/en-us/HT202780

“If you need an app window to span multiple displays, deselect the option ‘Displays have separate Spaces’ in the Mission Control pane of System Preferences.”

[NicolasRouquette]

Thanks for the comments/suggestions. I experimented with Displays have separate Spaces turned off. Interestingly, I get the same results with the laptop open or closed & two external monitors:

Moving virtual desktops & floating windows

Moving NoMachine virtual desktops & floating windows across physical displays works and there are no problems if the window is displayed across multiple monitors. This seems to match the feature request for floating windows.

Resizing floating windows

Maximizing a floating window only stretches it to span only one monitor. However, I can stretch a floating window to span multiple monitors (2 or 3). Except for the limitation of the maximize behavior, this seems to match the feature request for floating windows.

Resizing virtual desktops

Maximizing a virtual desktop only stretches it to span only one monitor. I think there is a separate issue with resizing virtual desktops with the NoMachine client for MacOSX. For several 5.1.x versions, there is odd behavior that resizing the virtual display window depends on what kind of X display manager is running on the NoMachine server.

– With KDE, I can manually resize a virtual display by grabbing the window edge/corner; however, I never use this because the ‘/’ character in terminal windows (gnome-terminal, konsole, xterm) is displayed with the background color (i.e., it’s invisible!) This behavior is really mysterious; I’ve used X Windows for many years when we worked with Sun workstations and never saw something this odd.

– With Gnome, I can only maximize a virtual display. When I manually resize the window by grabbing an edge or a corner, the virtual display window snaps back to its original size as soon as I release the mouse. However, I can manually resize the window from the NoMachine Display settings. Under Resolution, I need to enable “Use custom resolution”, choose a width & height; toggle it off & on and click done.

If the width/height fits within 1 physical monitor, clicking done will resize the virtual desktop window accordingly.

If the width/height exceeds 1 physical monitor, clicking done will not resize the virtual desktop window. However, if it can fit within the logical arrangement of physical monitors (e.g. with 2 Apple Thunderbolt side-by-side & laptop closed; 5120×1440), then in the NoMachine Display settings, I can unselect “Use custom resolution” and instead use the Resolution slide above which coincidentally shows the custom resolution I had entered. Then I can slide the resolution to that setting and click Done. The window isn’t resized; however, it now has vertical/horizontal scrollbars and I can manually resize it by grabbing an edge/corner (maximize behavior is still limited to 1 physical monitor in this case).

Thanks again for you comments/suggestions. As far as I’m concerned, there’s enough of the functionality of the feature request in the 5.1.26 client with Displays have separate Spaces turned off that it’s practically usable; however, I would certainly welcome improvements in the usability of the resizing behavior.

[graywolf]

Maximizing a floating window only stretches it to span only one monitor.

This is the usual behavior of any windowing system. It is the only behavior that is consistent with any possible layout of multiple monitors. No matter if you are resizing a single application or a whole virtual desktop: the windowing system of the client side host treats both in the same way.

With KDE, I can manually resize a virtual display

With Gnome, I can only maximize a virtual display

Gnome and KDE react to screen changes in order to keep the desktop consistent with configuration. This would explain the different behavior.

I can unselect “Use custom resolution” and instead use the Resolution slide above which coincidentally shows the custom resolution I had entered.

It should work on the first shot, instead. So it should be improved.

The window isn’t resized; however, it now has vertical/horizontal scrollbars and I can manually resize it

That looks normal. Window size is kept in order to fit in the single monitor, but desktop is resize. The only problem is it should just work when you chose “Use custom resolution”.

[NicolasRouquette]

With KDE, I can manually resize a virtual display.

With Gnome, I can only maximize a virtual display.

Gnome and KDE react to screen changes in order to keep the desktop consistent with configuration. This would explain the different behavior.

Is there a way to alter Gnome’s reaction to screen change so that resizing the virtual display window would result in a corresponding resize of the virtual root display? As I said before, KDE behavior would be better except that / characters are mysteriously displayed in background color, which makes them indistinguishable from space characters .

[graywolf]

I tried with Gnome and I found the same behavior on resizing. This issue should be studied more in depth, so I’m going to open a trouble report about that.

I also found this workaround:

• Open NoMachine menu (Ctrl+Alt+0) and turn off “Resize remote screen”
• Resize the NoMachine window as desired
• Turn on “Resize remote screen”: the remote desktop change size to fit the NoMachine window

 

 

[Britgirl]

Here is the link to the Trouble Report opened: https://www.nomachine.com/TR07N07020

[Author]

Posts