Viewport Considerations

Current implementations combine zoom, guest display resize and window size in a way that's not obvious.

• No windows can become larger than host display size (eg can't have a 1200x800 window on a 1024x768 display).
• No scaling of content when windowed, always 1:1, pan ala accessibility control in gnome-shell, include overlay scrollbars.
• No host window resizing when changing guest resolution (unless smaller than window).
• When going fullscreen, show how to leave fullscreen with an overlay
• Zooming doesn't affect display size (zoom == pixel size). Never skew pixel aspect ratio.
• Guest display resolution change on window resize: When resizing the window down while no zoom is applied (1:1), or when scaling up past the viewport size, the guest resolution is chaged. This happens on mouse release, while the content is shaded and a spinner appears as the user can't really interact with the guest properly. Once the guest finishes changing resolution, spinner and shading disappears. If no guest resolution changes are supported, regular panning logic is applied. No scaling (zooming really) is applied wen scaling window up.
• Zooming and scaling are separate actions. Scaling a window never changes zoom. The only exception is when going fullscreen. If the guest doesn't support resolution changes, viewport is zoomed to fit when going fullscreen.

Meta Control

By default, all input and user focus is on the guest OS (virtual or remote). To execute certain functions, you "step back", defocus the guest. Such functionality includes:

• Take a screenshot
• Zoom control [+/-]
• Send a key sequence (Capture input, rather than list)
• Fullscreen/restore view

When fullscreen, this meta mode is indicated with an overlay, while input not being captured by the guest. On touch this is done with a gesture (FIXME), on kbd+mouse with a shortcut (FIXME). When windowed, no overlay is being drawn when input isn't captured, the same meta functionset is accessible in the app menu.