Does it fix it with my test ( -g 600x400+0+0 ) for you?
Yes, but I only have access to single-head systems now, so my testing is
not indicative for the multi-head case...
In my case
it still positions the window on the 2nd screen, just as I found
during my tests before (this is as expected,
On 19.08.2011, at 13:07, MacArthur, Ian (SELEX GALILEO, UK) wrote:
maybe someone else can remember why we did it this way...
Oh buy, this code is over 10 years old. I can barely remember what I had for
lunch yesterday ;-)
If a window is fully off screen, we should probably loop through all
On 17 Aug 2011, at 16:39, MacArthur, Ian (SELEX GALILEO, UK) wrote:
OK - I think there is something wrong with fltk-1.3, and by extension
fltk3, in terms of handling windows placed at an (x,y) of (0,0).
This also affects windows that would have been created slightly
off-screen, which
Though once fltk-1.3 is broken, it stays broken until I
quit and restart it, whereas once I shows a good properties
window it tends to stay fixed.
I hazard that there's an initialization issue - something is
not setting a root or parent correctly or something, and once
it is set it
