[Top][All Lists]

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

[XBoard-devel] Board sizing

From: H.G. Muller
Subject: [XBoard-devel] Board sizing
Date: Tue, 5 Apr 2016 17:56:34 +0200
User-agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

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.

reply via email to

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