1) using processes sounds ... brittle
Agreed. It feels slightly dirty to me as well. The risks as I see them are:
- The output format of xrandr changes, breaking the parsing: xrandr is the standard way to manipulate screen resolution and so on - the output is probably relied upon by plenty more people than me. I can only imagine that the devs will be loathe to alter it.
- Weirdly configured systems that have the xrandr library but not the command-line: Sounds like a pathologically bizarre case, but the current behaviour will work as normal here
And on the purely positive side:
- The current behaviour (close a window - your monitor switches off) is just flat-out broken
- Less native code to deal with
- Multi-monitor information is exposed. Might be useful in the future.
On the whole I reckon it's a win. To handle this stuff properly in your own native code, you'd essentially be reimplementing the xrandr command-line. Besides, hooking up simple command-line tools to form new programs is the Linux Way
TM.
edit: probably should have put this in the previous post. A jar with the changes included is
over here, just
gagging for a bit of firm testing.
edit2: Made some small changes to the XRandr class - fails faster, more defensive, logs to LWJGLUtil, etc. Find file attached, jar linked above updated also.