QuickLook-Next 5.0.10

Fixed: the preview window spanned several monitors (upstream #827)

On a laptop with a 4K panel at 250% next to an external 1080p screen at 100%, previewing a wide,
large image on the external screen made the window stretch across all three monitors. Portrait
images and small images were fine, and so was the same image reached with the arrow keys.

The reason was that the monitor used to size the window and the monitor used to place it were not
the same one:

• the plugin measured against the monitor of the foreground window (Explorer);
• the viewer positioned the window on the monitor the preview window itself was on.

A size measured on the foreground screen, once it lands on a screen with a higher scale factor, is
multiplied on the way into pixels (250% means 2.5×) — and a wide image, whose fit is limited by its
width, runs out of screen first. Portrait images are limited by height, which keeps a 10% margin, so
they looked fine. The placement code only ever clamped the position, never the size, which
is how the window ended up covering all three monitors.

Three places now agree on one screen

1. The target screen is handed to the plugin at the start of every preview
   (ContextObject.HostDesktopSize); SetPreferredSizeFit() prefers it and only falls back to the
   old "current desktop" when it is unavailable.
2. The size is clamped to the screen it will be placed on before it is applied — including
   hard-coded plugin sizes and size requests that arrive after the preview opened (a PDF measuring
   its page, for example). A size the user dragged themselves is not clamped; that is their
   intent.
3. A scaling change re-fits the window: Windows keeps a window's physical size when it moves
   between screens, so the size in DIP changes; on a DPI change the window is clamped to the screen
   it is on now (and that correction is not remembered as the user's own size).

The arithmetic lives in the pure helper PreviewWindowSizing: it never enlarges, a ratio above
100% counts as 100%, and a ratio of 0 / negative / NaN or a failed desktop query (0×0) is treated as
"the whole screen" — none of them can collapse the preview to a zero-sized window.

Verification

• Unit tests: 12 new, covering the two extreme screens from #827 (4K@250% = 1536×864 DIP,
  1080p@100% = 1920×1040 DIP) and the 4289×631 "wide and flat" shape: no enlargement when it
  already fits, no zero-sized window for invalid ratios or an unknown desktop, the clamp only ever
  shrinking, and an end-to-end case where a page measured on a 1080p screen would overflow a 4K
  screen but lands inside after clamping. Suite 60/60 (48 before).
• No single-screen regression: this machine has one screen (1536×960 DIP @200%) and the
  6000×4000 image still lands at 2308×1540 @(382,190) — pixel for pixel the same as before the
  change, so this was a path replacement rather than a behaviour change. png / pdf / md previews
  keep the process alive and the window centred inside the screen.
• Honest limitation: with one screen the real mixed-DPI effect cannot be reproduced here. The
  evidence above is "the maths is right + no single-screen regression + a diagnostic switch", not
  "seen fixed on a two-screen machine". The full analysis, a reproduction recipe and that limitation
  are in
  docs/research-mixed-dpi.md.

/test-preview-diag also records every placement into <smokeDir>\preview-rect.txt
(dip / px / at / monitorPx / desktopDip). On a mixed-DPI machine that file answers "is the
window completely inside monitorPx?" in one look; if anything is still off, attaching it to an
issue is enough to locate it.

Upgrading

Version 5.0.10. Recommended, especially for machines with monitors of different resolution or
scaling. Automatic update installs straight over the top.