[XBoard-devel] Board sizing

[H.G. Muller]

I pushed a few patches to hgm.nubati that address the issue of board sizing.
In the first place I fixed the problem that changing the clock font 
would push
part of the board out of view (by making the board incompressible during the
font change). I had a hard time getting thi sto work, because it seemed 
to interfere
with popping down of the font dialog, which usually would be covering 
the board
while the font change was applied. After I discovered that most problems
(mainly the board not being drawn at all) disappeared when I first moved the
Fonts dialog to a place where it would not overlap the board, the solution
suggested itself: I now first pop down the dialog, and only then change 
the fonts.

Next step is that I write back the altered square size (rounded down to one
of the standard sizes) in the settings file (if saving settings is on). 
This makes
changes brought about by sizing the window also (approximately) persistent.
This altered standardized square size will now also be the size for 
which the
current font will be saved. The font won't change on sizing, however; 
you would
have to do that through the Fonts dialog if you are not happy with the size
you inherited from the previous -boardSize. It does mean, however, that
you will start next session with the exact font and the approximate board
size that you ended, which doesn't seem so bad.

Another problem, which I could only partly solve so far, is the shrinking of
the window. By removing the size requests needed to pop them up initially
with the correct width, the user can now shrink the width to below the 
initial
width. But unfortunately the menu bar and clocks will very quickly put up a
new barrier, set by their text content. The clock font is usually chosen 
so large
that it nearly fills the clock widget. But this could be solved by 
changing to a
smaller font before sizing. The menu bar can only be made smaller by 
clipping
the menu texts, which is currently decidet at startup based on -boardSize,
without interactive user control.

Fortunately the board size can be forced small by adjusting window 
height alone.
So in principle it is possible to replace all the menu text based on the new
square size through the same algorithm as normally used at startup,
after a sizing event. This would then alow the width to collapse to that of
the board (if the clock font doesn't obstruct this, and otherwise after you
also changed the font). I have not tried this yet.

Please let me know if this is a step in the right direction.

A problem I have is that the vertical size of the outer window sees very 
reluctant
to snap back to the board size when you decrease the latter. The GTK calls
that order this seem to be ignored most of the time.