Re: [XBoard-devel] (no subject)

[H.G. Muller]

Nalin.x.Linux schreef op 3/12/2014 3:51 AM:
> Dear list
>
> I am Nalin a student from kerala india. i am going to propose a 
> project that develop GTK3 UI for XBoard to Portland State 
> University(PSU). Following are the tasks that i plan to deliver.
>
> 1 - Port XBoard-GTK to GTK3 (Considering bugs in XBoard-GTK2)
> 2 - Made XBoard accessible for visually impaired.
> 3 - Make Fonts (pieces) movable using keyboard(arrow keys).
> 4 - Small finishing touches such as menu items for changing the board 
> to High contrast,etc
>
> Please let me know what are the parts that are not implemented in GTK 
> version of XBoard. and also let me know suggestion for further 
> improvement.
OK, I will be available as advisor on this project. A few remarks:

As to (4): I am not sure a special menu item would be needed for this. 
It seems to be something that the user would do only once, and then 
never again. The current development version (in hgm.nubati.net; I have 
not pushed it to Savannah yet) now supports the same mechanism for 
supporting 'themes', which can be recalled as a single click in a 
listbox displaying theme names. So it seems that all that is needed is 
to pre-configure a High-Contrast theme.

As to (3): I am not sure why 'fonts' are mentioned here; the pieces are 
not fonts in XBoard. Moving pieces using the arrow keys seems an 
essential part of (2), although from experience with the WinBoard JAWS 
version it seems that it is far more convenient for visually impaired 
people to simply type the move than to start messing with the arrow 
keys. In WinBoard JAWS the arrow keys are used to move a 'square cursor' 
over the board, (triggering auditory feedback on square coordinates and 
occupant), after which the space bar can be used to select the square. 
Another important feature was to define a key-binding (Ctrl-R) for a 
right mouse click at the current position of the system text cursor, to 
give the user access to context menus.

Currently unsolved problems / unimplemented features with the GTK 
front-end are the sizing of the board (initial as well as resizing of 
the window), and handling of fonts (in the Xaw version controlled by the 
options -messageFont, -clockFont and -coordFont). An unsolved problem 
not dependent on a specific front-end is how to handle graphics themes. 
(How to distribute non-standard themes, and what features would be 
needed in XBoard to facilitate their installation.)

As to (1): What difference would it make to switch to GTK3, other than 
that XBoad could no longer run on all platforms that only support GTK2? 
Is GTK3 intrinsically incompatible with GTK2, so that it is not possible 
to make a version that would work under both?

Some detailed explanation of the specific problem areas:

The old XBoard front-end was based on Xaw and pixmaps. Pixmaps are not 
scalable, so XBoard could be sized only to a discrete number of square 
sizes (18, to be exact). The square size was fixed during a session, 
although the board window could change size due to a change in board 
format, when switching to a variant. (E.g. switching from normal to 
crazyhouse would switch from 8x8 board to 12x8, in order to display the 
holdings.) The properties of the available sizes were tabulated, and 
involved not only the square size, but also the point size of the 
various fonts (for board coordinates, clocks and all dialog texts) that 
would go well with that square size, as well as 'layout hints' for the 
board window. The latter would for instance determine if there was room 
to display a text (like the window title) next to the menu bar, or that 
it would have to be displayed on a separate row above the board, and 
whether there texts on the menu bar needed to be truncated to single 
letters for lack of space.

For comparison WinBoard stil uses the system of 18 discrete sizes. But 
the board window there has always been sizable by the user; the new 
window size triggers a table lookup to determine which board size would 
fit, and then the size of the window and all 'attributes' are reset to 
the sizes belonging to that board size. In WinBoard the entire board 
window is a graphics widget, while in XBoard message and clocks are in 
separate widgets. The font size is user-configurable through -clockFont 
and -messageFont options just like in XBoard (except there are many more 
different fonts than the three used in XBoard: the memos in the Engine 
Output and Move History windows have a separate font, to allow use of a 
'figurine font' there, while the ICS Console has its own font to allow 
mono-space fonts there, etc.) The options apply only to the board size 
they were used with, and are remembered in the persistence file for each 
size separately. Some years ago I organized the persistence of font 
options the same way in XBoard. (Otherwise making the font options 
persistent would have very undesirable effects.)

The current XBoard uses SVG graphics, and is thus in principle 
continuously sizable as far as square size goes. Fonts could still be 
available only in discrete sizes, though. Currently user resizing of the 
board window recalculates the square-size, and then redraws the board. 
But it does not affect the choice of the fonts, (which in the GTK 
version is not yet controlled at all), and does not affect the board 
size that would be stored back into the persistence file (which stays at 
the size that was valid at start-up).  The ideal system would be the one 
that was used at startup in the old XBoard front-end: it would look in 
the table for the standard square size most similar to the actually 
requested size, would use that as new persistent board size, and then 
use the font and layout parameters belonging to that size to completely 
redesign the board window.

I am not sure how important it is to make font size in dialogs dependent 
on the square size. E.g. when someone selects a small board, would he 
really also want smaller font in the ICS Console? Of course for fonts in 
elements of the board window this becomes a bit different. When the user 
selects a small square size, and the font in the message or clock 
widgets would stay the same, the PV and clock texts would get severely 
clipped.

Another issue is how to handle other board formats than 8x8. So far 
selecting a variant that used another board format would keep the same 
square size, and change the size of the window to accomodate the new 
board. This has undesirable effects for large board formats, which would 
push a large part of the board off-screen when the board auto-sizes at 
startup to the maximum size that fitted the display (for 8x8), and then 
the format is changed to, say, 12x12 at the request of the engine. So it 
seems more sensible to have a system based on total size rather than on 
square size, and keep the total size fixed during a variant switch. A 
problem here is that not all variants use the same aspect ratio, so it 
would not be possible to keep both total width and total height constant.

Currently there is the problem that the clock and message widgets above 
the board refuse to resize to below their initial sizes. From recent 
search through the GTK2 manuals I got the impression that 'geometry 
widgets' might be relevant for solving this. They were mentioned as a 
way to implement resizing of an x-term, which seems very similar to what 
is needed for XBoard: in the x-term the size of the text widget must 
remain a multiple of the character size, and this affects sizing of the 
top-level window. In XBoard the board widget offers the same constraint: 
although with SVG the square size is continuously sizable, the entrire 
board would have to resize in multiples of the square size.