MULTIPLE MONITORS - Module controls window opens with incorrect width (opens to width of primary monitor even if its location isn't ON the primary monitor)

[uckelman]

Bugzilla
ID	BZ14146
Reported	2021-02-27 22:51:00 +0100
Modified	2021-03-25 05:38:24 +0100
Product	VASSAL
Component	Unknown
Version	3.5.3
Platform	PC
OS	Linux
Status	NEW
Resolution	None
Priority	unspecified
Severity	minor
Milestone	---
Reporter	Jonathan Watts
Assignee	Bugs
CC	brian@brianreynolds.net

Jonathan Watts 2021-02-27 22:51:27 +0100

When I open a VASSAL module, its controls window always opens to the width of the primary monitor, but is always positioned at global coordinates (0,0), even if that isn't the primary monitor.

For example, my system has 3 monitors: #0 (as identified by the OS) is 1920x1080, at coordinates (1920,0).  #1 is 1920x1080, at coordinates (0,0).  #2, the primary, is 2536x1440, at coordinates (0,1080).  The controls window always starts 2536 pixels wide, but is stretched across monitors #1 & #0.

I suspect this would require different solutions for different OSes (on Linux, for example, you could query Xrandr for the location of the primary monitor or the size of the monitor at (0,0), but that won't work for Windows)...a useful compromise could be to save the controls window size and/or coordinates last used with each module, so at least I don't have to resize it every...single...time.

FYI, this occurs in 3.4.x, as well (and probably older versions; I doubt that portion of the code has changed in a long time).

Jonathan Watts 2021-03-25 05:38:24 +0100

Discovered a related problem with 3.5.x only--the editor now stretches the trait editing window's height, apparently to a large percentage of the primary display's height.  As with the controls window, it doesn't check to see if this window is actually on the primary display, so I'm ending up with it stretching off the bottom of monitor #0 onto the top of monitor #2.

[jonathanrwatts]

Just discovered the V_Global prefs file has settings for mainWindowHeight and mainWindowWidth; changing mainWindowWidth from -1 to a positive integer appears to be a workaround for this issue (but it would still be nice if the automatic sizing worked correctly).