#Nomachine linux full screen windows#

But in that case should ThinLinc implement something equivalent, or should that be something the local client OS should handle? Also note that Wayland doesn't have such functionality, neither does Windows and macOS as far as I can tell.) (This use case can probably be handled on a X11 system using xrandr's panning system. (This was also likely not a use case that was explicitly targetet in the current design, but every change breaks someone's workflow¹.)

#Nomachine linux full screen install#

And if this user would have had a local Linux install then they would likely have to make do with the space the local monitor provides. Our general principle is that ThinLinc should provide the same experience as running Linux locally. The use case is reasonable, but it is not entirely clear if it is a problem that ThinLinc should solve. The user can then pan around the larger remote desktop using the scroll bars or edge panning in the client. The stated reason is to be able to have many large windows opened, that would otherwise be very crowded on his monitor. The user there wants to have a larger desktop area than what his local monitor can actually display. > Bug 7201 (or more specifically the user report it links to) discusses another use case that isn't considered here. > We can come up with a few typical use cases that we should cater for: (In reply to Pierre Ossman from comment #4) This could of course be changed to some other, more specific, method of informing vncviewer. This information needs to be sent to vncviewer somehow, and right now we've solved it by specific placement of vncviewer's window and letting it infer the monitor from that. * If full screen on the current monitor is configured, the only reasonable interpretation of 'current' is the monitor that tlclient is on. Unfortunately no platform seems to have a good way to express this association so we've resorted to a very specific placement of the vncviewer window * vncviewer should show up on the same monitor as tlclient, as that seems natural as they are related. We're also not really interested in an exact placement of windows. Since this is a reasonable position, we should probably avoid trying to place windows ourselves, even if the platform allows it. This ensures a consistent behaviour across application, and makes sure the window manager can apply the desired policy on where windows should show up. To clarify, Wayland has removed this 'feature' because they consider window placement to be the job of the window manager, not the applications. The latter might also prefer the ability for full screen to track the currently used monitor (the current behaviour), rather than a specific monitor (like bug 7006). The usage in scenario c) can probably vary a lot with some users keeping the client at the same size and position constantly, and some users resizing and moving actively as they mix between the client and local applications.

because they aren't available for the local system, licensing requirements, or the remote system has much higher performance than the local one.įor these we see the following screen setup needs:Ī) Full screen over all available monitorsī) Full screen over some, but not all monitors ( bug 7006 is important here) a time reporting system that only works on Windows, or a teleconference application.Ĭ) The local environment is the primary work environment with most applications, but a few important applications must be used remotely. A thin terminal is a prime example of such an environment.ī) The remote environment is the primary work environment with most applications, but there are still a few important applications available locally.

We can come up with a few typical use cases that we should cater for:Ī) All applications are in the remote environment and there is no need to reach the local system at all. The client settings used to get this behavior. Screenshot of the session when in full screen. (except for fixed session size, and disabling remote resize) * Old configurations should continue having the previous behaviour when loaded by a new client * It should not be possible to choose conflicting options * The session should start on the same monitor as the login window if this mode is enabled at login

* It should be possible to configure ThinLinc to use the current monitor when toggling from window mode to full screen * It should be possible to configure ThinLinc to be full screen over one specific monitor (or more, after bug 7006) * It should be possible to configure ThinLinc to be full screen over all monitors * The session window should be created on the same monitor as the login window * It should be possible to configure ThinLinc to be a resizable window