Comment 1 Frida Flodin 2021-11-17 10:07:10 CET

Created attachment 1004 [details]
Screenshot of the session when in full screen.

Comment 2 Frida Flodin 2021-11-17 10:07:57 CET

Created attachment 1005 [details]
The client settings used to get this behavior.

Comment 3 Pierre Ossman 2021-11-17 13:42:02 CET

This is actually by design as some might want the opposite, that the size they've explicitly chosen is respected. So there is no objectively correct answer here.

Much of this interface is from back before we had dynamic resizing of the sessions. As such, it is probably time to re-evaluate the overall design and try to avoid ambiguous situations like the one described in this bug.

Comment 4 Pierre Ossman 2021-11-30 13:24:59 CET

We can come up with a few typical use cases that we should cater for:

a) All applications are in the remote environment and there is no need to reach the local system at all. A thin terminal is a prime example of such an environment.

b) The remote environment is the primary work environment with most applications, but there are still a few important applications available locally. E.g. a time reporting system that only works on Windows, or a teleconference application.

c) The local environment is the primary work environment with most applications, but a few important applications must be used remotely. E.g. because they aren't available for the local system, licensing requirements, or the remote system has much higher performance than the local one.

For these we see the following screen setup needs:

a) Full screen over all available monitors

b) Full screen over some, but not all monitors (bug 7006 is important here)

c) Windowed mode

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. 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).

Comment 5 Pierre Ossman 2021-11-30 13:52:57 CET

For reference, Citrix doesn't seem to have an option for selecting full screen monitor. Instead you have to resize the client in windowed mode until it is mostly covering the screens you want, and then enter full screen:

https://support.virsage.com/kb/article/5-citrix-desktop-with-dual-screens/

This has the advantage of avoiding options, and toggling between windowed and full-screen mode is a less drastic change. However the windowed mode doesn't seem very user friendly in this case as it will be weirdly stretched over multiple monitors and remote applications will likely no longer know the monitor edges.

Comment 6 Pierre Ossman 2021-11-30 16:22:16 CET

NoMachine has a bit more settings than Citrix:

https://knowledgebase.nomachine.com/DT10R00167#5

They basically are:

 * Pan (assuming remote session is larger)
 * Scale
 * Resize remote to client (this seems to be an independent setting)
 * Full screen, one monitor
 * Full screen, all monitors

So some of these look like they can be combined, and some look mutually exclusive. Nothing unexpected except pan and scale, but those are reasonable if the server is a workstation where the resolution cannot be freely changed.

Noteworthy that they don't have any settings to set specific resolutions.

Comment 7 Pierre Ossman 2021-11-30 17:01:14 CET

VMware horizon offers the following options:

 * Full screen, all monitors
   * Once this is selected, you can visually deselect screens you don't want to use (like bug 7006)
 * Full screen, one monitor
 * Windowed, in three sizes:
   * "Large"
   * "Small"
   * Custom

These are clearly shown to be mutually exclusive by all being in a drop-down box, so only one can be selected at a time.

For all options except full screen over all monitors, you get a second choice of resolution and scaling. The default is to follow what the client does.

https://docs.vmware.com/en/VMware-Horizon-Client-for-Windows/2103/horizon-client-windows-user/GUID-FC4A3F61-7C8B-4F08-87AE-007E2A598169.html
https://communities.vmware.com/t5/Horizon-Desktops-and-Apps/Choosing-Multiple-Horizon-Client-Screens/td-p/2807722

Comment 8 Pierre Ossman 2021-11-30 17:09:22 CET

X2go doesn't have a clear documentation, so it's a bit more guesswork there. They have this though:

https://wiki.x2go.org/doku.php/doc:usage:multi-display

It seem you get a choice between:

 * Some form of full screen
 * Fixed session size
 * Full screen over one specific monitor

The page mentions two different keyboard shortcuts to toggle windowed/full screen over current or all monitors, so there is some support for that distinction. Overall the configuration looks very technical and confusing.

Comment 9 Pierre Ossman 2021-11-30 17:27:35 CET

NICE DCV has toolbar buttons that lets you toggle between three states:

 * Full screen, current monitor
 * Full screen, all monitors
 * Windowed

The way they are structured makes it fairly clear they are mutually exclusive.

They also have some server side settings to restrict session resizing:

https://docs.aws.amazon.com/dcv/latest/adminguide/managing-session-display.html

I don't see how the client settings for resolution works. Their screenshots show a menu called "Display resolution", but there is no documentation on how it works. Their feature document states that it automatically adapts to the client resolution though:

https://github.com/awsdocs/nice-dcv-admin-guide/blob/master/doc_source/what-is-dcv.md

Comment 10 Pierre Ossman 2021-12-07 13:54:02 CET

HP/Teradici's PCoIP client seems to have a gui very similar to NICE DCV:

https://www.teradici.com/web-help/TER1706002/3.3/Content/Topics/Using/Changing_window_mode.htm

They also have a different client for terminals, that they call PCoIP zero. It's display setting are very heavily geared towards constant full screen though, where the client and server are in constant sync:

https://help.teradici.com/s/article/1295

Comment 11 Pierre Ossman 2021-12-07 14:35:29 CET

It's not entirely clear how RealVNC presents things to the user. They have the following settings at least:

 * Windowed
 * Full screen, one monitor (seems to be one specific, rather than current)
 * Full screen, all monitors¹

I don't see any options about automatically resizing the remote session. It does have an option to try to resize the local resolution though.

¹ Seems to be problematic on macOS though

https://help.realvnc.com/hc/en-us/articles/360002254618

These are just the configuration parameters though. It's unclear which of these are exposed in the GUI. The expose the full screen toggling, including one/all monitors, on the session menu though:

https://help.realvnc.com/hc/en-us/articles/360006483577-Switching-between-multiple-monitors-

Comment 12 Pierre Ossman 2021-12-07 15:27:23 CET

Microsoft's old terminal server client (i.e. their default RDP client) has a slider that lets you pick from fixed resolution, and full screen over the current monitor at the end. It also has a check box that allows you to extend that full screen to all monitors.

This is mostly unambiguous. It would have been even better if they included the "all monitors" option in the slider as well.

Microsoft's new client (MSRDC/URDC) is in a bit of a flux right now as Microsoft is pushing their cloud desktops. Screenshots shows that it has an option for server resolution though, and settings for full screen over all monitors. But it is unclear how these interact so we cannot get a full picture of the user experience.

Comment 13 Pierre Ossman 2021-12-07 15:29:38 CET

There is some variation among other software, but I don't see anything prominent that suggests we need to alter our suggestion on use cases. So let's go ahead with that plan.

Comment 14 Pierre Ossman 2021-12-08 11:18:24 CET

One deviation I've noted is that we are alone in calling these "Screen" setting. Every one else seems to use "Display" as the heading for these kinds of setting. 

Might be worth changing at the same time if we're shuffling things around.

Comment 15 Pierre Ossman 2021-12-08 14:42:04 CET

A side effect or this change is that we get some problems with window placement, primarily for vncviewer (originally fixed in bug 4275). However window placement is explicitly forbidden in Wayland, so this might be an excuse to abandon such efforts anyway:

https://gitlab.freedesktop.org/wayland/wayland/-/issues/183

Comment 16 Pierre Ossman 2021-12-09 10:29:06 CET

To clarify, Wayland has removed this "feature" because they consider window placement to be the job of the window manager, not the applications. This ensures a consistent behaviour across application, and makes sure the window manager can apply the desired policy on where windows should show up.

Since this is a reasonable position, we should probably avoid trying to place windows ourselves, even if the platform allows it.

We're also not really interested in an exact placement of windows. What we are after are two effects:

 * vncviewer should show up on the same monitor as tlclient, as that seems natural as they are related. 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

 * If full screen on the current monitor is configured, the only reasonable interpretation of "current" is the monitor that tlclient is on. 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. This could of course be changed to some other, more specific, method of informing vncviewer.

Comment 17 Pierre Ossman 2021-12-09 10:34:08 CET

Also note that even though Wayland won't tell a window ("top level surface" in Wayland lingo) its coordinates, it will tell it what monitors it is shown on. See for example GTK's gdk_wayland_display_get_monitor_at_surface().

This means that the principle of coordinating monitors between tlclient and vncviewer is somewhat feasible even with a Wayland future.

(I'm not seeing any method to see which monitor you are mostly on though. GTK seems to pick the last one the window entered)


Finally, this might not be relevant until we're using Wayland natively (bug 5646). Right now we do operations via Xwayland, which has a bunch of back doors in to the compositor that lets it do things that normal Wayland clients can not.

Comment 18 Pierre Ossman 2021-12-09 14:48:32 CET

I've checked the ICCCM, the EWMH, and the Wayland protocol specification. Unfortunately it is as I suspected that there is no hint in either X11 or Wayland to indicate which monitor a window should show up on. Or saying that it is associated with an existing window. So exact placement seems to be the only option for now. :/

The reason this is problematic with this change is because our current logic is to center the vncviewer window. But that requires us to know the size of the window as we need to specify the top left corner for placement. And we will now no longer know the size as we no longer try to enforce something specific.

So if we want to keep some of this behaviour it would need to be something just relative the top left corner of the monitor. Either 0,0, or some specified offset from that.

Comment 19 Pierre Ossman 2021-12-09 15:53:37 CET

(In reply to Pierre Ossman from comment #4)
> We can come up with a few typical use cases that we should cater for:
> 

Bug 7201 (or more specifically the user report it links to) discusses another use case that isn't considered here.

The user there wants to have a larger desktop area than what his local monitor can actually display. The stated reason is to be able to have many large windows opened, that would otherwise be very crowded on his monitor. The user can then pan around the larger remote desktop using the scroll bars or edge panning in the client.

The use case is reasonable, but it is not entirely clear if it is a problem that ThinLinc should solve. Our general principle is that ThinLinc should provide the same experience as running Linux locally. No more, no less. 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.

(This was also likely not a use case that was explicitly targetet in the current design, but every change breaks someone's workflow¹.)

¹https://xkcd.com/1172/


(This use case can probably be handled on a X11 system using xrandr's panning system. 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.)

Comment 20 Pierre Ossman 2021-12-09 15:57:25 CET

(In reply to Pierre Ossman from comment #17)
> 
> Finally, this might not be relevant until we're using Wayland natively (bug
> 5646). Right now we do operations via Xwayland, which has a bunch of back
> doors in to the compositor that lets it do things that normal Wayland
> clients can not.

We've confirmed that Xwayland has some magical back door as GNOME using Wayland respects the position we request for vncviewer.

Comment 23 Pierre Ossman 2021-12-10 13:47:25 CET

All done. Tested the following changes:

 ✓ Correct initial size for new sessions in mode:
   ✓ Windowed
   ✓ Full screen on current monitor
   ✓ Full screen on all monitors

 ✓ Correct actual window behaviour with new session in mode:
   ✓ Windowed
   ✓ Full screen on current monitor
   ✓ Full screen on all monitors

 ✓ Correct actual window behaviour when reconnecting in mode:
   ✓ Windowed
   ✓ Full screen on current monitor
   ✓ Full screen on all monitors

 ✓ Session is shown on the same monitor as tlclient
   ✓ Windowed
   ✓ Full screen on current monitor

 ✓ -l display locks the display tab

Regression testing:

 ✓ Settings are remembered correctly
 ✓ "-f fullscreen" forces a full-screen mode
 ✓ xdm mode
   ✓ forces full-screen
   ✓ disables display mode settings
 ✓ it remembers which full-screen mode when toggling between full screen and windowed when connected

 ✓ -l screen locks the display tab

And for the acceptance criteria: 

> * It should be possible to configure ThinLinc to be a resizable window
> 

It is.

>   * The session window should be created on the same monitor as the login window

It is.

> * It should be possible to configure ThinLinc to be full screen over all monitors

It is.

> * It should be possible to configure ThinLinc to be full screen over one specific monitor (or more, after bug 7006)

Not yet fixed. Will be handled on bug 7006.

> * It should be possible to configure ThinLinc to use the current monitor when toggling from window mode to full screen

It is.

>   * The session should start on the same monitor as the login window if this mode is enabled at login

It is.

> * It should not be possible to choose conflicting options

The options are via radio boxes, so it's impossible to select multiple.

> * Old configurations should continue having the previous behaviour when loaded by a new client
  (except for fixed session size, and disabling remote resize)

No issue as we kept the existing options and just present them in a different way. Remote resize is forced on now though, and we don't try to enforce a fixed size.

Comment 24 Frida Flodin 2021-12-14 09:34:58 CET

There are still some screenshots in the documentation with the old "Screen" tab.

Comment 25 Frida Flodin 2021-12-14 09:58:03 CET

The release notes don't mention that we have renamed the "Screen" tab to "Display". In the release notes, we just mention the "display settings". This might be confusing if you look at an old client and try to understand what will be changed?

Comment 28 Pierre Ossman 2021-12-15 14:17:12 CET

Screenshots and release notes updated.

Comment 29 Frida Flodin 2021-12-16 13:09:30 CET

The release notes and documentation looks good now. More clear release notes and the screenshots are updated.

Comment 30 Frida Flodin 2021-12-16 13:15:37 CET

I have tested that the new options work and are more clear than before. Tested build 2292 on Fedora 34.

* It should be possible to configure ThinLinc to be a resizable window
> Yes
  * The session window should be created on the same monitor as the login window
> Yes
* It should be possible to configure ThinLinc to be full screen over all monitors
> Yes
* It should be possible to configure ThinLinc to be full screen over one specific monitor (or more, after bug 7006)
> Yes, one works.
* It should be possible to configure ThinLinc to use the current monitor when toggling from window mode to full screen
> Yes
  * The session should start on the same monitor as the login window if this mode is enabled at login
> Yes
* It should not be possible to choose conflicting options
> It's not, radio boxes fixes this. 
* Old configurations should continue having the previous behaviour when loaded by a new client
  (except for fixed session size, and disabling remote resize)
> Yes


Functional tests:
 ✓ Correct initial size for new sessions in mode:
   ✓ Windowed
   ✓ Full screen on current monitor
   ✓ Full screen on all monitors

 ✓ Correct actual window behaviour with new session in mode:
   ✓ Windowed
   ✓ Full screen on current monitor
   ✓ Full screen on all monitors

 ✓ Correct actual window behaviour when reconnecting in mode:
   ✓ Windowed
   ✓ Full screen on current monitor
   ✓ Full screen on all monitors

 ✓ Session is shown on the same monitor as tlclient
   ✓ Windowed
   ✓ Full screen on current monitor


 ✓ -l display locks the display tab

Regression tests:
 ✓ Settings are remembered correctly
 ✓ "-f fullscreen" forces a full-screen mode
 ✓ xdm mode
   ✓ forces full-screen
   ✓ disables display mode settings
 ✓ it remembers which full-screen mode when toggling between full screen and windowed when connected
 
 ✓ -l screen locks the display tab
 

As I understand it, in windowed mode the size is decided from the server side. So for a user that uses windowed mode before will get the same size as when (s)he last connected to that session. As mentioned in comment #18 the position is not centered anymore. Now the window appears in the left corner with some fixed offset. So that might be a change the user will notice.

When using the client for the first time the default is the same, full screen over all monitors.

These config values will be left in an old configuration file but when installing the client on a fresh system they are not present:
> REMOTE_RESIZE=1
> SCREEN_SIZE_SELECTION=1
> SCREEN_X_SIZE=10000
> SCREEN_Y_SIZE=1768


The code changes are the same for all platforms so there is no need to test Windows and macOS thoroughly. But I did some light testing by just trying the three new settings and they worked as I expected.

Did a code review, the code looked good and I did not find any obvious bugs.

Comment 31 Pierre Ossman 2021-12-29 17:03:55 CET

This isn't working well when you reconnect to a huge session in windowed mode. At least macOS and Windows don't properly restrict the size of the window so you get a huge, unwieldy window. On Windows it was also positioned very oddly and in at least one case the window title wasn't reachable to reposition the window.

Comment 32 Pierre Ossman 2021-12-29 17:07:37 CET

Also note that the second call to SetCurrentScreen() in MainWindow isn't working properly. At the point that it is called the vncviewer arguments have already been constructed.

Comment 34 Pierre Ossman 2021-12-30 13:47:19 CET

Initial window size fixed. Not going to do anything anything about SetCurrentScreen() right now. It requires some larger restructuring of the code, and should (hopefully) be a rare corner case.

Comment 35 William Sjöblom 2022-01-03 16:08:01 CET

I have reproduced the issues mentioned in comment 31 using client build #2300 on Windows 10 and macOS.

I have then tested client build #2302 containing the fix mentioned in comment 34 on Fedora 35 (using GNOME 41+Wayland and XFCE4+X11), Windows 10, and macOS 12.1 on multi-monitor setups with one of the monitors in portrait mode. When testing I initially connected with full-screen mode over all monitors, disconnected, connected with windowed mode, switched to single monitor full screen, disconnected, and connected with windowed mode. During this procedure, I made sure that the windowed mode windows got did not become larger than the screen on which they reside, which proved to be the case for all platforms.

I also had a look at the source code and deem that the changes introduced for this fix do not motivate retesting of the acceptance criteria since they are very non-intrusive.

Marking as closed.