Re: [XBoard-devel] Board sizing

[H.G. Muller]

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.