Invalid window geomery in OWMConfig.ini (linux)
Posted: Fri Feb 28, 2020 4:22 am
Just ran into a problem on Linux, which strikes me as particularly odd, because I've successfully run OWM multiple times on this machine before. But, trying to start it today, I get the startup splash screen, but then it crashes when it tries to open the actual main program window, with the console output:
~$ OWM
WARNING : Command not found in hash table : nouicompat
WARNING : Command not found in hash table : deflang
WARNING : Command not found in hash table : viewkind
WARNING : Command not found in hash table : uc
WARNING : Command not found in hash table : nowidctlpar
WARNING : Command not found in hash table : lang
WARNING : Command not found in hash table : sa
WARNING : Command not found in hash table : sl
WARNING : Command not found in hash table : slmult
WARNING : Command not found in hash table : lang
(OWM:6483): Gdk-WARNING **: 10:05:03.055: Native Windows wider or taller than 32767 pixels are not supported
The program 'OWM' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 12166 error_code 9 request_code 70 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Looking in ~/.Other\ World\ Mapper/OWMConfig.ini, I found
[Persistent_Options/Window/OWMMainFrame]
x=0
y=0
w=34418
h=-756823071
which looked likely to be the cause, so I changed them to w=800, h=600 and it started successfully, but the existing values were obviously incorrect. I suspect that they may have come from the previous run having been over a remote X connection (i.e., connecting from another machine using `ssh -X` so that OWM was running on this computer, but displayed windows on a different one) and/or using multiple virtual desktops on a multi-headed display. I don't know how tricky it would be to get valid window geometry values in that scenario, but it should be easy to at least add sanity checks (e.g., 0 < height/width < 32767) when persisting the geometry and preserve the old values if the sanity checks fail.
~$ OWM
WARNING : Command not found in hash table : nouicompat
WARNING : Command not found in hash table : deflang
WARNING : Command not found in hash table : viewkind
WARNING : Command not found in hash table : uc
WARNING : Command not found in hash table : nowidctlpar
WARNING : Command not found in hash table : lang
WARNING : Command not found in hash table : sa
WARNING : Command not found in hash table : sl
WARNING : Command not found in hash table : slmult
WARNING : Command not found in hash table : lang
(OWM:6483): Gdk-WARNING **: 10:05:03.055: Native Windows wider or taller than 32767 pixels are not supported
The program 'OWM' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
(Details: serial 12166 error_code 9 request_code 70 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
Looking in ~/.Other\ World\ Mapper/OWMConfig.ini, I found
[Persistent_Options/Window/OWMMainFrame]
x=0
y=0
w=34418
h=-756823071
which looked likely to be the cause, so I changed them to w=800, h=600 and it started successfully, but the existing values were obviously incorrect. I suspect that they may have come from the previous run having been over a remote X connection (i.e., connecting from another machine using `ssh -X` so that OWM was running on this computer, but displayed windows on a different one) and/or using multiple virtual desktops on a multi-headed display. I don't know how tricky it would be to get valid window geometry values in that scenario, but it should be easy to at least add sanity checks (e.g., 0 < height/width < 32767) when persisting the geometry and preserve the old values if the sanity checks fail.