xboard-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XBoard-devel] 4.9.0 what's new


From: H.G. Muller
Subject: Re: [XBoard-devel] 4.9.0 what's new
Date: Fri, 1 Apr 2016 12:02:23 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1



Op 4/1/2016 om 7:07 AM schreef Joshua Pettus:

ApplyFont and FontsOK in dialogs.c
Yes, I know. I firt wanted to get it to work as intended for GTK, before seeing what I would have to add in Xaw to not break it.

Also I still have to build xaw version with --without-gtk instead of --with-xaw
Wasn’t this suppose to be fixed?
For me it works, but it could be that --with-Xaw requires a capital.

That’s great!  Couple of things... Which one controls the ICS console window?  Also wouldn’t we want the Coordinates to be board scalable? I feel that may be one area where it would make sense (if it were to work that is).  Should that be a checkbox?  Also it doesn’t seem to save the new settings to the settings file, at least for me.
I pushed a more-polished version now. (It was 2am last night before I had anything working at all...) I replaced the coord-font control by an ICS-font control. The ICS Console pane was a bit troublesome, because it already had its own mechanism to control fonts (for the colorization), where all text inserted to it received its own font instructions, which would overrule the general font setting of the widget. I now added code to alter the font type used in this insertion, which before was only set at startup. The effect is that existing text will not change its font after using the Fonts dialog, but any new text appearing there will use the new font setting.

The Cairo plotting currently calculates the font size directly from the square size, and ignores the -coordFont argument. This might not be easy to fix in an acceptable way. The point is that the fonts are organized per value of the -boardSize argument, (and what you change with the Fonts dialog only affects the current -boardSize). While the actual square size can be affected by sizing the board window. And it would be very inconvenient when the coordinate font would not adapt to the square size when you do that. Just as it is inconvenient that the clocks and logos do not adapt to that. So perhaps we should postpone this to when we have a more integrated approach to resizing of the board window.

The font settings should be saved with the other settings. But perhaps resizing will interfere with it after all. Saved fnont options will get a prefix "sizeNN:" to their value. I am not sure what exactly determines the NN at the time of saving. It could be the current squares size as affected by sizing (or switching variant).


reply via email to

[Prev in Thread] Current Thread [Next in Thread]