fix: disable pillarboxing when display screen is in portrait orientation

[CodingDozent]

Fixes #1180

Problem

When using a mixed portrait/landscape multi-monitor setup, the control view is incorrectly pillarboxed to match the width of a portrait display screen, cropping the usable drawing area.

In boardViewResized(), setBoxing() is called with the geometry of mDisplayView. If that screen is portrait (e.g. 1080×1920) while the control screen is landscape (1920×1080), the boxing logic crops the control view to the portrait width — which is clearly unintended.

Root cause

Boxing is conceptually only meaningful for ScreenRole::Display when it mirrors content to students at a different aspect ratio. The Previous screens serve a different purpose — they simply scale and show previous pages for the teacher. Their geometry should never influence the control view's usable area.

This worked correctly before 1.7.0, where monitors were used as-is without boxing. The feature introduced in 1.7.0 improved the standard two-screen setup but inadvertently broke more complex configurations that previously worked fine. Making boxing configurable per screen role would restore this flexibility for complex setups.

Context

This issue was reported by a teacher using OpenBoard for online classes since 2020. The four-monitor setup is purposeful: one landscape monitor for the video conferencing tool, one landscape monitor as the OpenBoard control view, and two portrait monitors showing previous pages for reference during class. The portrait orientation is not accidental — DIN A4 material displayed on a 22" portrait monitor appears larger than a physical A4 sheet, making it ideal for multi-page exercises during online teaching.

This setup worked flawlessly until a monitor replacement changed the Windows display initialization order, causing a portrait monitor to land on ScreenRole::Display and triggering the boxing regression while ignoring their actual order in the setup.

As discussed with @kaamui in #1180, the gray borders should not appear when portrait monitors are used as previous-page screens. This PR implements the fix for that specific case.

Fix

Skip boxing when the display screen is portrait:

// src/board/UBBoardController.cpp, in boardViewResized()

QRect displayGeom = mDisplayView->geometry();
if (displayGeom.width() >= displayGeom.height()) {
    setBoxing(displayGeom);
} else {
    setBoxing(QRect()); // no boxing for portrait display screen
}

This is intentionally minimal and does not affect standard landscape setups.

Analyzed on

• Windows 11, OpenBoard 1.7.3
• 4 monitors: 1 landscape primary (desktop), 1 landscape secondary (control view), 2 portrait side monitors (previous page previews)

Note: The fix has been verified by code analysis with AI assistance. A compiled test was not possible without a build environment.

[CodingDozent]

As an addition to this fix, I'd like to propose a feature request: it would be very helpful to have an explicit role assignment for monitors in the preferences, e.g.:

• Control (mandatory)
• Display (optional, boxing only applies here)
• Previous 1/2 (optional, independent of Display)
  In my use case I don't have a separate student display at all — I only need Control + Previous monitors. This combination worked fine before 1.7.0 but is currently broken because the boxing logic assumes Display is always present and uses it to constrain the Control view.
  Explicit role assignment would make such setups robust and independent of monitor initialization order.

Thank You for Your time.

Yours Frederik