Re: Board sizing

"H.G. Muller" <[email protected]> Tue, 5 Apr 2016 23:38:36 +0200
Newsgroups gmane.comp.gnu.xboard.devel
Message-ID <[email protected]>

Op 4/5/2016 om 9:55 PM schreef Joshua Pettus:
> I think this is definitely a step in the right direction!  Great job!
>
> Unfortunately I get some weirdness when I make the board very large, 
> save it and quit.  When I open it up again, the clocks have way too 
> much vertical space (Screenshot included).

This is weird. What is in the settings file before you open it, for 
-boardSize and -clockFont for that size? And if you would start an older 
version (e.g. the latest development release) with those same settings, 
does it also do this?

Could you print the clock font in the function Resize() in gtk/xboard.c 
like this:

     if(initialSquareSize != sizeDefaults[h].squareSize) { // boardSize 
changed
         initialSquareSize = sizeDefaults[h].squareSize; // used for 
saving font
         if(!fontValid[CLOCK_FONT][initialSquareSize]) 
fontTable[CLOCK_FONT][initialSquareSize] = CLOCK_FONT_NAME;
         appData.clockFont = 
InsertPxlSize(fontTable[CLOCK_FONT][initialSquareSize], 
2*(sizeDefaults[h].clockFontPxlSize+1)/3);
printf("resize square=%d clock font = %s\n", initialSquareSize, 
appData.clockFont);

It could be that we start with some ridiculously large font, and that 
the font change causes another resize events that makes the font much 
smaller, and that the widget somehow does not follow the size decrease 
of the font. Normally it should, however. (Also in the Fonts dialog 
itself, when you operate the - button.) I never have to do anything 
special for that; If I make the font in the label widget smaller, the 
height of the widget decreases. It is just a matter whether the outer 
window will also shrink, or stay the same leaving a blank area below the 
board. I have to issue a gtk_window_resize call to shrink it tight 
around the board, and even that is sometimes ignored.

>  I am also somewhat concerned with what will happen with OSX’s 
> fullscreen feature.  Where it actually gets the menubar out of the way 
> so the board is the largest it can be on your screen.
Umm, that reminds me that in any case the menu-bar clipping code needs 
to be surrounded with an #ifndef OSXAPP, which I did not do...
> I expect what will happen is if it is saved and then opened up again 
> (which will be before fullscreen mode is started), you will always 
> start the board with the bottom of the board below the screen.  Not 
> sure if there is anything you can do about that.  Although of course 
> with the clocks the way they are at large boards, I don’t get to fully 
> try it out.
Well, you should be able to shrink the window from the top too. And then 
you have space to move it up by the title bar, to bring the bottom edge 
on screen. Plus that the 'ellipsis' mode I set on the clock seems to 
have solved the problem that the clocks did not want to shrink below the 
text width. So when the menu bar is also not in the window you should be 
able to shrink the width of the window as much as you like, and that 
should eventually bring the bottom edge in view.

H.G.