WinBoard/XBoard 4.8.0 released

[Evert]

The amount of clippling looks suspiciously similar to the size of the clocks or the buttons line.

Looks like the size of the title-bar to me. It might be an issue with the window decorations not being taken into account.

[hgm]

OK, so the initial sizing is OK, and it is the handling of a 'reconfigure event' (which is triggered by moving the board) that then actually spoils it.

My guess is that the height you are missing is actually that of the window title bar. That somehow the window manager is tardy in dressing up the window with an outerframe. So that the initial size measurement is too small. And later resizings calculate the required window height from it, but part of it is then lost to the title bar.

Looks like the size of the title-bar to me. It might be an issue with the window decorations not being taken into account.

Ah yes, our postings crossed. I think that is exactly it. The decorations are applied later than we can bear. I suppose I will have to delay taking the measurement somehow.

[Evert]

The GTK documentation (for gtk_window_get_size) says the following:

Code: Select all

Note 2: The returned size does not include the size of the window manager decorations (aka the window frame or border). Those are not drawn by GTK+ and GTK+ has no reliable method of determining their size.

I guess that also applies to whatever size you set. What seems odd is that it appears that window managers are apparently free to choose whether the requested size should refer to the canvas or to the size of the window as a whole.
Presumably it would be possible to use an X11 call to get the information needed, but that defeats the purpose of using GTK. Perhaps there's a way to hint that the requested size should reflect the canvas, and not the whole window?

[hgm]

OK, I pushed another fix.

It turns out to be essential to run the main loop of GTK event handling to process the window_resize before resetting the size_request of the board.

After I did that, it turned out essential to treat the first configure event different: normally such an event is caused by the user moving the window (which is ignored) or resizing it. In which case I calculate a new square size to make the board fit the new window.

But the first such event occurs when the window manager adds the decorations, and with those eats away part of the window height. In this case we should not make the board fit the window, or we would always get a board that is smaller then we asked for. (And narrower than the clocks were calculated to be). We should instead increase the window size to fit the board with the requested square size.

[Evert]

OK, I pushed another fix.

It turns out to be essential to run the main loop of GTK event handling to process the window_resize before resetting the size_request of the board.

After I did that, it turned out essential to treat the first configure event different: normally such an event is caused by the user moving the window (which is ignored) or resizing it. In which case I calculate a new square size to make the board fit the new window.

But the first such event occurs when the window manager adds the decorations, and with those eats away part of the window height. In this case we should not make the board fit the window, or we would always get a board that is smaller then we asked for. (And narrower than the clocks were calculated to be). We should instead increase the window size to fit the board with the requested square size.

Ah, that makes sense! Hopefully that fixes it.

[michiguel]

OK, I pushed another fix.

It turns out to be essential to run the main loop of GTK event handling to process the window_resize before resetting the size_request of the board.

After I did that, it turned out essential to treat the first configure event different: normally such an event is caused by the user moving the window (which is ignored) or resizing it. In which case I calculate a new square size to make the board fit the new window.

But the first such event occurs when the window manager adds the decorations, and with those eats away part of the window height. In this case we should not make the board fit the window, or we would always get a board that is smaller then we asked for. (And narrower than the clocks were calculated to be). We should instead increase the window size to fit the board with the requested square size.

You are in the right track. Now it works and xboard can be used!

But... minor issue (I can live with it, but you may want to take a look at it): If I try to resize the window with the mouse to a smaller size, it comes back (slowly, looks like a loop). If I resize it to a bigger window, it is fine, but I can never resize it to a smaller one than the one determined by -size.

Miguel

[hgm]

OK, next attempt is pushed to hgm.nubati.net!

[michiguel]

OK, next attempt is pushed to hgm.nubati.net!

Thanks, better. Now, the horizontal size cannot be smaller than a given length (probably the original). If I try to resize it smaller, it leaves a blank space to the right side.

The words on the menu are limited to three letters (Opt, Hel, etc.) is that intentional? I suspect it is not because previously it was four letters.

Clearly, whatever you are modifying is the right place.

Miguel

[hgm]

Well, these are still intrinsic limitations of the current version. The width of the clock, font sizes and such are all determined by the initial size (either given by an explicit -size argument, or remembered from its value on the previous run in the settings file). We are not at the stage of WinBoard yet, where resizing of the window would trigger a -size recalculation that would become the new setting and change all -size-associated properties accordingly. Resizing after startup affects the board only.

The clipping of the menu texts is necessary to make the menu bar not dominate the window width at small -size values, and is just another of those properties that will not adapt to later user sizing of the window. To get more text you have to start at a larger -size, and then you cannot shrink below that, because, amongst other things, shrinking below it would leave no room for these longer texts. (Note that even WinBoard switches to 1-letter menu texts below some size; in the GTK version this is just done somewhat more gradually.)

So we can consider the problem fixed, and 4.8.0 working as designed now also on your system.

[Richard Allbert]

Hi HG,

just installed the Mac version. The checkboxes still do not show in the menus.

Using 10.9.5

Richard