Forum Replies Created
June 15, 2016 at 10:59 in reply to: Physical monitor limitations for virtual sessions w/ floating window #11615NicolasRouquetteParticipant
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 .June 14, 2016 at 09:10 in reply to: Physical monitor limitations for virtual sessions w/ floating window #11609NicolasRouquetteParticipant
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.