On 17.08.2011 22:56, Ian MacArthur wrote:
>
> 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 then get clipped to the screen boundary edges.
>>
>> This, I think, is what is messing up fluid under win32, for both
>> fltk-1.3 and fltk3, though the bug is not in fluid, but in the fltk
>> core.
>>
>
> Yup - tested on OSX, linux and WIndows. Windows is wrong in 1.3 and fltk3,
> but OSX and Linux are OK (i.e. the same as fltk-1.1 was) so there is
> certainly a regression here.
>
> Though I do not know what is causing it.
Hah, I got it!
Though I do not know (yet) how to fix it.
FYI:
It's another regression (or maybe not?) in src/screen_xywh.cxx. First
of all, let me note that all test programs that use show(argc,argv)
can be used for testing the effect w/o recompiling. I'm using tabs.exe
with the following or similar command line(s):
$ test/tabs -g 600x400+100+100
or
$ test/tabs -g 600x400+0+0
The former loads the window's client area at position (100,100), whereas
the latter ought to position it at some x/y-offset - for my Win7 system
this is (8,30) which accounts for the borders.
Responsible for (re-)positioning is Fl_X::fake_X_wm() in
src/Fl_Win32.cxx, which calls Fl::screen_xywh(scr_x, scr_y, scr_w,
scr_h, X, Y); to find the correct monitor at line #1298 in FLTK 1.3.
Here is the regression, because this returns wrong monitor boundaries
([0,0,0,0], i.e. an unknown screen) for negative screen coordinates.
These negative coordinates result from putting the window near or at
the top left corner, since the border width and heigt are subtracted.
Hence, for showing a window at (0,0) this would be (-8,-30) - and this
is indeed not an existing monitor area in most setups. However, FLTK
1.1 returns the coordinates of the first screen that is usually at
(0,0), and then fake_X_wm() does its job correctly.
I thought that I found the culprit, because there is a simple and
(not so) obvious bug in screen_init(), but fixing *this* positions the
window on my 2nd monitor instead of the 1st. :-(
Here is what I have now, but it's too late for working further on it.
$ svn diff src
Index: src/screen_xywh.cxx
===================================================================
--- src/screen_xywh.cxx (revision 8976)
+++ src/screen_xywh.cxx (working copy)
@@ -95,6 +95,7 @@
if (fl_gmi) {
// We have GetMonitorInfoA, enumerate all the screens...
+ num_screens = 0; // reset for use in screen_cb !
// EnumDisplayMonitors(0,0,screen_cb,0);
// (but we use our self-aquired function pointer instead)
fl_edm(0, 0, screen_cb, 0);
Index: src/Fl_win32.cxx
===================================================================
--- src/Fl_win32.cxx (revision 8976)
+++ src/Fl_win32.cxx (working copy)
@@ -1296,6 +1296,7 @@
//Make border's lower right corner visible
int scr_x, scr_y, scr_w, scr_h;
Fl::screen_xywh(scr_x, scr_y, scr_w, scr_h, X, Y);
+ printf("[%s:%d] (%d,%d,%d,%d)
[%d,%d]\n",__FUNCTION__,__LINE__,scr_x,scr_y,scr_w,scr_h,X,Y);
fflush(stdout);
if (scr_x+scr_w < X+W) X = scr_x+scr_w - W;
if (scr_y+scr_h < Y+H) Y = scr_y+scr_h - H;
//Make border's upper left corner visible
@@ -1311,6 +1312,7 @@
X+=xoff;
Y+=yoff;
+ printf("[%s:%d] (%d,%d,%d,%d)
[%d,%d]\n",__FUNCTION__,__LINE__,scr_x,scr_y,scr_w,scr_h,X,Y);
fflush(stdout);
return ret;
}
The patch in src/Fl_win32.cxx is for testing only. It shows the wrong
window position in FLTK 1.3.
The patch in screen_xywh.cxx fixes the wrong screen count. It *must*
be reset here since EnumDisplayMonitors() calls screen_cb() as its
callback, and this uses and increments the global variable num_screens.
Additionally this has been changed (AFAICT) to return the screen area
(as it should and is documented), but here we need the work area (as
it was before/in FLTK 1.1). This is the same effect as in the menu
problem (STR #2695).
Looks like we need another STR...
Test output from FLTK 1.1 (with the same printf's as above):
$ test/tabs -g 600x400+0+0
[fake_X_wm:1124] (0,0,1680,1010) [-8,-30]
[fake_X_wm:1140] (0,0,1680,1010) [8,30]
$ test/tabs -g 600x400+100+100
[fake_X_wm:1124] (0,0,1680,1010) [92,70]
[fake_X_wm:1140] (0,0,1680,1010) [100,100]
The former positions the window at [8,30], the latter at [100,100],
which is correct.
Test output from FLTK 1.3 w/o patch:
$ test/tabs -g 600x400+0+0
[fake_X_wm:1299] (0,0,0,0) [-8,-30]
[fake_X_wm:1315] (0,0,0,0) [0,0]
$ test/tabs -g 600x400+100+100
[fake_X_wm:1299] (0,0,1680,1050) [92,70]
[fake_X_wm:1315] (0,0,1680,1050) [100,100]
Note the difference (1010 vs. 1050) which is work area height vs. screen
height.
Test output from FLTK 1.3 with patch:
$ test/tabs -g 600x400+0+0
[fake_X_wm:1299] (1680,0,1680,1050) [-8,-30]
[fake_X_wm:1315] (1680,0,1680,1050) [1688,30]
$ test/tabs -g 600x400+100+100
[fake_X_wm:1299] (0,0,1680,1050) [92,70]
[fake_X_wm:1315] (0,0,1680,1050) [100,100]
The former puts the window on the 2nd screen, the latter is correct.
More to do later...
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
