fix: window bounds rectangle issues

[panaC]

Fixes #3466

Change list:

• set default window size to 1024×768, centered on the primary display (previously 800×600 positioned at one-third of the primary screen)

• ensure immutability by creating a copy of the window bounds object before modifying and saving it (fixes session reducer issue)

• Electron window bounds handling:

  • getBounds(): used to persist window size and position

• refactor readerNewWindowBound (getWinBound)

  • use Electron BrowserWindow instance bounds rectangle instead of the global Redux session state
  • on first publication open, initialize reader window position based on the library window position to target the active screen, with a position shift of 30px if possible
  • loop on the window bounds rectangle position until a free position is found with an offset of 30px

• use VS Code logic to normalize window bounds rectangle and to get the default display

• use VS Code logic to get the default display on single or multiple screens to compute the default rectangle

  • on macOS, new windows will be centered on the display with the current cursor

---

Browser window bounds rectangle logic:

First start of Thorium:

• window centred on the default display (active cursor position on macOS)
• window default size is 1024 x 768 if the display size allows it (on macOS, the display size excludes the top bar and dock, only the active display screen)
• window minimal resolution is 700 x 600 to target the minimal supported resolution of 800x600

First opening of a publication:

• will have the same size and position as the library window, before persistence of the bounds rectangle

Multiple reader windows opened:

• new reader window with the same position as current windows, will be shifted x/y of 20px until a free position is found
• macOS & Linux: these OSes seem to be pretty good at ensuring that a window is never outside of its bounds
• on MS Windows: it is possible to have a window with a size that makes it fall outside of the screen. The strategy is to try as much as possible to keep the window within the monitor bounds. We are not as strict as macOS and Linux and allow the window to exceed the monitor bounds as long as some pixels (128) of the window remain visible on the screen for the user to drag it back

Single display:

• strict x/y positioning, window bounds rectangle saved will be applied on the next start window, even if the window exceeds the monitor bounds (see above). On Linux and macOS, windows will not be truncated; only Windows allows it. No normalization is done when saving, only when the bounds are applied to a new BrowserWindow

Multiple display:

• window bounds rectangle normalization will try to restore the window position on the original display screen. If the restoration fails and the display is not available, the window position will either be on the intended display with the desired width/height if possible, or, as a fallback, on the default screen with the default size
• macOS: maximum width/height of the second display resolution is capped to the default display size. Fullscreen windows on the external display will be saved but restored to the default maximum size of the first display and positioned in the top-left corner
• Linux Wayland: x/y positioning is not possible
• MS Windows: window composition works; fullscreen or maximized/minimized state is not saved or applied on next start, only the window bounds rectangle is saved
• macOS: same applies to the fullscreen desktop state/mode

[panaC]

Recording.2026-03-25.113245.mp4