Re: [XBoard-devel] 4.9.0 readiness

[H.G. Muller]

Still one question: this was WITH the extra call to DelayedDrag() in xoption.c, right? Without this call it still would not work, as it printed nothing at all.

If so, I will use this solution in 4.9.0. The extra 'artificial' call to DelayedDrag should be harmless, as it just schedules events after a timeout, and if a real configure event does come in (as it should when i3wm is not used) it just would re-schedule the actual handling of the resize by cancelling the old timeout, and starting a new one.

This business that suppressed the handling of the first configure event was a legacy of old code, where we would have to wait resizing the board until the clock widget was set to its final font, as otherwise the expansion of the clock would eat away part of the board. The current code does not need that anymore, as I learned how to protect the board size during clock expansion, so that GTK must enlarge the outer window rather than eat away part of the board area.

Regards,
H.G.

Op 4/19/2016 om 6:47 PM schreef Adrian Petrescu:

Hello! Sorry for the delay in responding, it's been a busy week.

I can confirm that setting first = 0 in ReSize() fixes the problem! The incorrectly-sized still flashes on the screen for approximately 0.1 seconds, but then quickly redraws correctly. Good enough for me!

The output that gets printed (without any manual resizing at all) is:

resize: new 956x1062 @ (960,14) old -1x1043 @ (961,18)

resize: new 956x1062 @ (960,14) old -1x1043 @ (961,18)

resize: new 956x1062 @ (960,14) old 956x1062 @ (960,14)

(Note that this is still with all the previously-discussed changes still in there - I haven't gone back and tried the various permutations to find the smallest set of changes that works)

Hope this helps!

-Adrian

On Wed, Apr 13, 2016 at 2:33 PM, H.G. Muller <address@hidden> wrote:

Op 4/12/2016 om 3:20 PM schreef Adrian Petrescu:

• 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)

I just noticed something: At the beginning of ReSize there is a declaration "static int first=1".
This suppresses any square resizing on the first call to Resize(). What happens when you change that into first=0 ?
That would be a third explanation for why ReSize did not do anything, even though the above output shows it was called.
I must admit that I do not understand why resizing then did not occur on the second call, which still has new and old width different.
But in fact I do not really understand how there could be a second call to DragProc where the old width (from wpMain) was -1.
Because in DragProg there is a statemet wpMain = wpNew, which should have copied the 958 in wpNew over the -1 in wpMain.
So it should not be possible that DragProg is called a second time with wpMain.width == -1. Unless it was called recursively,
between printing the above line and the wpMain = wpNew, but the busy=1 construction is supposed to make that impossible.

But anyway, trying the first=0 seems worth the attempt, in combination with the above extra call to DeleyedDrag().

H.G.