[Top][All Lists]

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

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

From: h.g. muller
Subject: Re: [Bug-XBoard] [bug #33241] xboard quits with 'Unable to create font set.'
Date: Wed, 08 Jun 2011 20:55:31 +0200

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

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.)

reply via email to

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