Re: [XBoard-devel] new developer release out

[h . g . muller]

Op Zo, 13 maart, 2016 7:12 pm schreef Arun Persaud:
> Known issues:
> * I tried configuring with --with-Xaw, but that version did not compile
> (I got a cairo error).

It seems that pangocairo.h is not available under Xaw. All other errors
follow from that, and they are all in the routine DrawUnicode, which is
used to draw text on piece images on the board (intended for inscribing
kanji on blank Shogi tiles). Rendering non-X-fonts on the board never
seemed to cause a problem for the board cooordinates, so this comes as a
surprise.

It is weird that I did not get this problem before. I guess the autotools
stuff is not clever enough to find this dependency. Only draw.c uses the
pango stuff, and it is supposed to be front-end-independent. So after
building the GTK version, there will be a draw.o, and reconfiguring for an
Xaw build will then happily use that. The Xaw version I built that way
immediately segfaults at startup, however. When I remove all *.o files
first, I get the compile errors in draw.c. But I did build Xaw versions
very recently that ran without problems using the draw.o from the GTK
build. (And the DrawUnicode stuff is from early last year.) Perhaps that
was just a coincidence. I don't understand how it could segfault, though;
DrawUnicode should never be used when not running with an -inscriptions
option. So it could be that the segfault is due to something entirely
different.

If the use of pango is really restricted to GTK, I guess the solution
should be to move it from draw.c to gtk/xoptions.c, and put a dummy in
xaw/xoptions.c.

> * I'm also getting a few compiler warnings about unused variables, which
> we could clean up.
> * When starting the compiled version without installing
> it, xboard might get confused since it will probably load an old init file
> from /etc... I'm wondering if we can/should detect that xboard is not
> installed in the install directory defined in the Makefile (or perhaps
> just check if we are running from the same directory as the source is in,
> e.g. test for xboard.h the init file and the svg pieces) and in that case
> just use the etc file and pieces from the source directory? We could pop
> up a message saying "development version detected" or something like this.
> I
> think this could make testing easier.
>

I am not sure what problem we are trying to solve here. Old
/etc/xboard.conf files will always be understood by later XBoard versions.
Apart from redirecting the reading and saving of settings to a
user-specific file (~/.xboardrc), what they contain is usually completely
ignored, as it will be overruled by the settings in the user-settings
file. This will be the one of the old version, no matter whether a new
/etc/xboard.conf was installed. Unless that xboard.conf would redirect to
another user settings file (like ~/.xboard490rc). But we intentionally let
it read the old user settings files, so that a user would not lose his
settings on upgrading XBoard.

Not installing is ill adviced anyway. If you had no XBoard before, you
won't have any pieces. In 4.9.0 new piece types have been added, so even
if you had 4.8.0 installed before, you will still get the Error popup each
time you start that default pieces are missing, and that you should define
a pieceImageDirectory.