Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'

[h.g. muller]

OK, I am back from Greece, so I had access to my Linux system 
again.
I started pushing all the WinBoard fixes I had accumulated in the mean
time
to hgm.nubati.net (hgmaster branch), after syncing with Savannah.

There seems to e a problem, though, with the file browser. I suspect
this
is a side effect of some of the general changes of the text widget
settings
done for the internationalization, as the git log shows now changes in
the
browser file, and the probem is definitely new:

If I use the browser through a browse button in another popup, (e.g.
the
for setting the tournament file in the Match Options dialog), it seems to
only
copy the first character of the selected file name to the file-name
field.
I put some debug prints in the browser, and it seems the problem
occurs
in SFsetText() in path.c, in this piece of code:

        text.firstPos = 0;
        text.length = strlen(path);
        text.ptr = path;
        text.format = FMT8BIT;

        XawTextReplace(selFileField, 0, strlen(SFtextBuffer), &text);
        XawTextSetInsertionPoint(selFileField, strlen(SFtextBuffer));

This code is called when one clicks a filename in the lists in the
browser window,
the clicked text being passed to it as 'path'. selFileField is the
uppermost text widget
in the browser window, and the purpose is to load it with the clicked
text.
Now what happens is that 'path' is OK: when I print it, it prints the
complete clicked text,
and acknowledges the correct length of it in text.length. However, when I
print the
contents of SFtextBuffer after the XawTextReplace, it only prints the
first character.
Now SFtextBuffer is the 'use-in-place' string that is supposed to be in
selFileField.
On the display I see that the selFileField widget contains the complete
filename,
but it seems to be stored in the provided buffer array in a format that
the rest of the
code no longer understands. The InsertionPoint is set after the first
character, which is
aready suspicious. It seems like the buffer does not store the text in an
8-bit encoding,
leading to null bytes in between the characters, which the rest of the
code interprets as
end-of-string.

Other minor weirdnesses I observed are:
*) The browser seems to use a fixed-width font in its lists (but not in
the text widgets).
*) The background of the font in all text widgets of al dialogs is now
light gray. (I don't know
if this was intentional or even if it is desirable; I just noticed that
it was different than before.)