Re: 4.9.0 readiness

Disappointing that the explicit call to DelayedDrag() does not solve it. 
It gives more output than I get when starting XBoard without it, so it 
seemes to trigger some avelanche of events. The third one should be 
ignored, as none of the window parameters changes. But is is very 
strange the first two don't do anything. These should lead to calls of 
ReSize(), as the window width changes from -1 (a stored value indicating 
'default') to 958.

So we seem to have solved one problem (that DragProc() was not called at 
all), but there still is a remaing problem (that ReSize does not seem to 
do anything).
Could you put the following four print statements in ReSize()?

printf("table size %dx%d squareSize=%d\n",w,h,squareSize);
     if(a.width < w || a.height < h) { // outer window smaller than 
dialog content?
         w = a.width - w; h = a.height - h; // subtract matrgins, 
measured as table minus board dimensions
         gtk_widget_get_allocation(optList[W_BOARD].handle, &a);
printf("board size %dx%d\n",a.width,a.height);
         w += a.width; h += a.height;
     } else {
         gtk_widget_get_allocation(optList[W_BOARD].handle, &a);
         w = a.width; h = a.height;
     }
printf("new board  %dx%d\n",w,h);
     sqx = (w - lg) / BOARD_WIDTH - lg;
     sqy = (h - lg) / BOARD_HEIGHT - lg;
     if(sqy < sqx) sqx = sqy;
printf("square size %d\n",sqx);

There seem to be two possibilities here: the newly calculates square 
size can end up below 20, in which case ReSize() ignores the size 
request. (Unlikely!) Or the newly calculated sqx ends up the same as the 
previous squareSize, despite the fact that the size of the outer window 
changed. Normally the 'else' part of the above 'if' is taken, and it 
interrogates the size of the board drawing area. Normally this size in 
GTK is automatically coupled to that of the outer window, as we pack 
'Graph' widgets in the layout table such that they expand to fill all 
available space, and the layout table in the outer window as well. So 
any window sizing the user does is taken up by the board (the clocks and 
message widget do not have the vertical GTK_EXPAND flag set), and the 
new square size can be determined from the new size of the board widget. 
It is very difficult to determine the size directly from the outer 
window, as we don't know how much space the window frame and 
clocks+message takes. (Initially we did it that way, by measuring a 
startup window size with a 1x1 board, but with bad results, as the clock 
height could still change afterwards due to font change or multiple lines.)

What seems to be the case here is that i3wm did not only fail to inform 
the application through a configure-event that the outer window was 
enlarged, but also failed to inform GTK of this fact, so that it did not 
calculate a new layout for the widgets inside it. This is strange, as 
horizontally the clocks obviously do expand to fill the full window. So 
it seems GTK is informed by i3wm only of the horizontal window 
expansion, not of the vertical one.

Instead of faking that the application got the configure-event signal by 
calling DelayedDrag(), it might help to actually fake the entire signal, 
so that GTK would also respond to it.
I have never done such a thing, but it seems doable through

g_signal_emit(shells[BoardWindow], "configure-event", ...);

where the manual says the ... should be the parameters normally passed 
to handlers for this event. In this case that should be a 
configure-event structure with details about the new window parameters. 
We shoud obtain these first, however, and at a time after i3wm messed 
with the outer window. Requesting them in GenericPopUp will probably be 
too soon. That means it should be done in DragProc(), which is called 
after a timer delay. So we should continue to call DelayedDrag() by 
hand, like we we do now, but let DragProc() the first time it sees the 
window height go positive from the requested the window parameters, use 
the latter to fake a configure-event. Very complicated...

H.G.

Op 4/12/2016 om 3:20 PM schreef Adrian Petrescu:
> Okay, I have results to report!
>
>   * If I only add the print statement to DragProc from your branch,
>     *nothing gets printed* when xboard launches
>   * Even I add the same line to the ReSize method above it, still
>     *nothing gets printed* when xboard launches
>   * Hitting F2 right after launching xboard flips the board, but it's
>     still small
>   * Adding if(dlgNr == BoardWindow) DelayedDrag(); to the end of
>     GenericPopUp() (in gtk/xoptions.c) still makes the board small,
>     *but* it does result in the following prints as soon as xboard is
>     launched:
>         resize: new 958x1043 @ (960,18) old -1x1043 @ (960,18)
>         resize: new 958x1043 @ (960,18) old -1x1043 @ (960,18)
>         resize: new 958x1043 @ (960,18) old 958x1043 @ (960,18)
>   * As soon as I resize a tiny bit with the situation above, it also
>     prints:
>         resize: new 962x1043 @ (956,18) old 958x1043 @ (960,18)
>         resize: new 962x1043 @ (956,18) old 958x1043 @ (960,18)
>         resize: new 962x1043 @ (956,18) old 962x1043 @ (958,18)
>         resize: new 962x1043 @ (956,18) old 962x1043 @ (958,18)
>     (and then the board is the right size)
>
> Hope that helps :) Let me know if there's any other diagnostics I can do!
>
>
>
>
>
> On Mon, Apr 11, 2016 at 3:34 PM, H.G. Muller <[email protected] 
> <mailto:[email protected]>> wrote:
>
>     OK, I now pushed a version with a special debug print statement to
>     gather info about the cause of this problem.
>
>     When the size of the outer window changes, XBoard should get a
>     "configure-event", which eventually should
>     cause DragProc() to be called. (There is a timer delay involved
>     here to prevent XBoard from drowning in a barage
>     of configure-events while the dragging is going on, and only call
>     CoDrag() once after the sizing or dragging has stopped.)
>     I put a print statement in DragProc(), to print the new window
>     parameters that it requests from the system after
>     the drag, and the parameters it had before.
>
>     I would like to see what this prints in combination with i3wm, and
>     also when it prints it. It seems that i3wm
>     does size the outer window other than XBoard requested it during
>     the creation of this window,
>     and normally this should cause a configure-event. But CoDrag()
>     should redraw the board at the new size,
>     and as this obviously is not done, it seems that it is not called.
>     Which suggests that the configure-event
>     does not occur. But I want to check that for sure, to see if
>     something is already printed when the wrong
>     board size is still displayed before you do the minor resizing
>     that corrects it.
>
>     I also wonder what would happen if you press F2 (for Flip View)
>     before you resize. Does it then flip
>     the small board, or does it immediately draw a flipped large one?
>
>     If setting the outer window to a different size as XBoard requests
>     is not considered a resize by i3wm,
>     so that it doesn't think it necessary to send XBoard the
>     configure-event signal, then we must devise
>     some other method for XBoard to determine that it did not get what
>     it asked for. Perhaps we should
>     always fake a configure-event when the main window first pops up,
>     by putting at the end of GenericPopUp():
>
>     if(dlgNr == BoardWindow) DelayedDrag();
>
>     This would execute DragProc() after a delay of 200 msec, which
>     would check the actual size of the window,
>     and do nothing if it already has the right size.
>
>     Op 4/11/2016 om 6:59 PM schreef Adrian Petrescu:
>>     Hello!
>>
>>     I can confirm the bug still occurs on the latest master branch.
>>
>>     Here's a screenshot right after launching the newly-compiled
>>     xboard: http://i.imgur.com/kSyO1Ff.png
>>     And here it is after I've triggered a tiny resize event:
>>     http://i.imgur.com/zs2tWQC.png
>>
>>     Hope this helps with the diagnosis. And I hope my message
>>     actually gets through to the list this time :P
>>
>>     Cheers,
>>     Adrian
>>
>>     On Fri, Apr 8, 2016 at 3:27 AM, H.G. Muller <[email protected]
>>     <mailto:[email protected]>> wrote:
>>
>>
>>
>>         Op 4/8/2016 om 12:37 AM schreef Adrian Petrescu:
>>>
>>>         On Apr 7, 2016 6:20 PM, "H.G. Muller" <[email protected]
>>>         <mailto:[email protected]>> wrote:
>>>         > The sizing bug reported by Adrian Petrescu still stands,
>>>         but since I did
>>>         > change a fair amount in that area, I wonder if that
>>>         problem still exists.
>>>
>>>         I can check on my i3wm machine :) Which branch should I
>>>         build to find out?
>>>
>>
>>         The master branch at
>>         http://hgm.nubati.net/cgi-bin/gitweb.cgi?p=xboard.git;a=summary
>>
>>         (I still have to rebase that onto Savannah master, because in
>>         the mean time
>>         some .po files have been pushed there, but I wanted to wait
>>         with that untill
>>         all .po files were in.)
>>
>>         H.G.
>>
>>
>>>         Thanks for looking into it!
>>>         Adrian
>>>
>>
>>
>
>