Re: [XBoard-devel] 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()?

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!

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.

On Apr 7, 2016 6:20 PM,
"H.G. Muller" <address@hidden>
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?