[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: Thu, 09 Jun 2011 13:04:57 +0200

At 00:09 9-6-2011 -0700, Tim Mann wrote:
* The file browser uses a somewhat kludgey feature (useStringInPlace) that doesn't work the way it's expecting if its widgets inherit international = True from the resource database. In the international case, the AsciiText widget keeps its internal string representation in UCS-4 (32-bit wide character) format. Normally that doesn't matter, but if you say useStringInPlace, the in-place string you are looking at is also in 32-bit wide character format. The existing code is expecting null-terminated strings of 8-bit bytes.

It should be possible to fix the above temporarily by turning off international for just the affected widget(s) in the file browser, but I don't have that working yet for some reason.

This isn't a good permanent solution because it means the file browser (still) won't be able to handle filenames with characters above 0x7f. Well, or maybe it can handle ISO8859-1 characters up to 0xff -- I'm not sure -- but definitely not general Unicode utf8 filenames.

* The fixed-width font in the directory lists happens because draw.c looks for the "font" resource and falls back to 9x15 is there is none. Since we are only setting fontSet now and not font, it uses the fallback now. We could probably improve this by taking the first font out of the messageFont fontset and setting it as "font", similarly to what I did with coordFont. That still leaves the code not handling international characters in directory names.

The lists look like more work to internationalize properly because of the explicit character drawing in draw.c -- they don't use Xaw text widgets for some reason. Maybe doing it this way is more efficient and that mattered on the slow computers years ago when this code was written.


OK, so the file browser sucks in multiple ways, and we should probably not waste too much time on it. It is not really part of XBoard, and I did not like the user interface of it very much anyway. GTK will come with its own file browser, I suppose.

It is very inconvenient that the browser now doesn't work at all, though. Perhaps we can overrule the resource-database setting for this single useStringInPlace widget, and set international = False there, for the time being. I don't mind the fixed-width fonts so much, that is still workable, so we can ignore the font problem.

The way the XBoard front-end has evolved by now, it shouldn't be very difficult to provide our own browser dialog from scratch, using the GenericPopup routine. I could define a dialog with two single-line text widgets for the file name and the extension filter, a large multi-line text widget for the (filtered) directory contents, and the standard OK & cancel buttons. The only thing that would really have to be programmed is a callback for clicking in the contents widget, which should either transfer the clicked name to the filename widget (if it is a file), or change to the clicked directory (possibly "..") and refresh the list. Internationalization should then automatically work, like in all other dialogs. I will have a look into it next week.

reply via email to

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