Bug 7201 - improve controls for panning a large session
Summary: improve controls for panning a large session
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: VNC (show other bugs)
Version: 1.3.1
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.14.0
Assignee: Pierre Ossman
URL:
Keywords: prosaic
Depends on: 7785
Blocks:
  Show dependency treegraph
 
Reported: 2018-06-25 11:02 CEST by Pierre Ossman
Modified: 2021-12-09 14:55 CET (History)
2 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2018-06-25 11:02:11 CEST
We've gotten requests to improve the user interface of panning around in a session that is larger than the client window. Right now we have two methods:

 - Scroll bars (in windowed mode)
 - Edge scroll (in fullscreen mode)

First off it's a bit weird that we switch method in fullscreen, rather than staying consistent.

Secondly the edge scroll is a bit rough in its current implementation and could probably be made to be more responsive.

What has been requested is a third mode, where the panning follows the position of the cursor in the window. E.g. if the cursor is at the top left, then so will the panning position. And as the cursor moves across the window, the panning follows until you hit the opposite extremes.

Apple's VNC client in macOS offers all three of these and lets the user choose which is preferred rather than automatically switching between things.


Note that our default settings automatically resize the session, so it shouldn't be common that sessions are larger than the window.
Comment 2 Pierre Ossman cendio 2021-06-30 09:27:30 CEST
Upstream has now gotten some improvements to how edge panning works:

https://github.com/TigerVNC/tigervnc/pull/1242
Comment 3 William Sjöblom cendio 2021-12-09 10:34:53 CET
After a quick test on Fedora 34, the new edge panning is both far smoother and far more responsive than the previous implementation.

Worth noting is that bug 7793 will change up the "Screen" options dialog. This will likely result in the fixed session resolutions being removed. It will still be possible to change the session resolution on the server (e.g. using xrandr) so the use-case for features like this will not be entirely nuked, but likely a lot less common.
Comment 4 William Sjöblom cendio 2021-12-09 14:01:55 CET
I've now tested the upstream change on Fedora 34, Windows 10, and macOS 12.0.1 without any issues.

I've tested the following:
 - No panning occurs if the session resolution is smaller or equal to the
   monitor resolution
 - Panning occurs (and is very smooth) when the resolution is larger than 
   the monitor resolution

For the above cases I've tested all possible combinations of resolution (in)equalities, e.g.:
  - session height < monitor height AND session width > monitor width
  - session height > monitor height AND session width > monitor width
  - etc.

One thing that we might want to take another look at is the fact that panning does not stop when the cursor leaves the monitor with the ThinLinc session. This is problematic if using ThinLinc on a multi-monitor setup with one ThinLinc dedicated monitor and the other dedicated to the local machine. If the user's workflow involves a lot of jumping between the local machine and the ThinLinc session, this will certainly be annoying as panning the session will be panned to one side when working locally. This behavior is not a regression and can be reproduced with the inferior panning available in ThinLinc 4.13.0.

Maybe we should consider only panning the session under certain conditions, for example:
- The mouse is inside the ThinLinc session, or outside with the pointer grabbed
- The ThinLinc session is focused

With one of the above alternatives (or another similar solution in the same fashion), it may even seem viable to get rid of the scroll bars and use panning even when running ThinLinc in windowed mode.
Comment 5 William Sjöblom cendio 2021-12-09 14:53:08 CET
Since we are removing support for fixed resolutions (bug 7793), the utility of the final notes made in comment 4 seems niche (at best). We'll therefore settle with the upstream changes and ignore the rather clunky windowed scroll bars for now.

Note You need to log in before you can comment on or make changes to this bug.