Skip to content

feat: open the main window on the screen under the mouse cursor - #1512

Open
obook wants to merge 1 commit into
OpenBoard-org:devfrom
obook:feat-main-window-on-active-screen
Open

feat: open the main window on the screen under the mouse cursor#1512
obook wants to merge 1 commit into
OpenBoard-org:devfrom
obook:feat-main-window-on-active-screen

Conversation

@obook

@obook obook commented Jul 24, 2026

Copy link
Copy Markdown

On a multi-monitor setup, OpenBoard always opens its main window on the primary screen. If you work on another monitor, you have to drag the window over every time you start the app. This makes it open on the screen where the mouse is instead.

A few things worth noting:

  • It only changes the default case. If you set an explicit screen list in the preferences, that still wins.
  • The screen numbers in the preferences don't change, only the role assignment order does.
  • If the cursor screen can't be resolved, it falls back to the old behavior (primary screen).

On X11, Windows and macOS the cursor position is read directly with QCursor::pos(). Wayland doesn't allow that before the app has received a pointer event, so I show a tiny transparent probe window and use whichever output the compositor places it on.

Tested on a 3-monitor Wayland session (KDE Plasma, Qt 6). The X11, Windows and macOS paths are structurally unchanged, but I haven't run them on those systems, so feedback there would be welcome.

Regards,

When no explicit screen configuration is stored, the main OpenBoard
window always opened on the primary screen. On a multi-monitor setup
this forces the user to drag it to the monitor they work on every time
the application starts.

The control screen is now chosen from the screen under the mouse
cursor. Only the role-assignment order is affected: the screen numbers
shown in the preferences keep the system order, and an explicit screen
list still takes precedence.

On X11, Windows and macOS the cursor position is read directly with
QCursor::pos(). Wayland does not expose the global cursor position
before the application has received a pointer event, so a short-lived
transparent probe window is shown and the output the compositor places
it on is used instead.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant