#424 setWindowCaption encoding

[Kyle Mills]

I'm trying to add the character ½ (1/2) to the window title in a simple irrlicht program.
This character works in the window titles of firefox (google search "½"), urxvt (mkdir ½; cd ½), and xchat (/join ##½).
This character also works in gui::IGUIEnvironment->addButton and ->addStaticText, and in the tooltips.
It is definitely possible to fix this bug.
With
device->setWindowCaption(L"Old Caption");
device->setWindowCaption(L"A ½ of a New Caption");
the window caption will be "Old Caption".
In CIrrDeviceLinux.cpp in the function CIrrDeviceLinux::setWindowCaption the if statement
if (Success==XwcTextListToTextProperty(display, const_cast<wchar_t**>(&text),
1, XStdICCTextStyle, &txt))
is where the action of setting the title ends.
If I remove "If (Success==" and ")" causing it to no longer be an if statement (leaving the {}), the title does get set. The ½ character is removed, and there is a double space "A of a New Caption".
If I change XStdICCTextStyle to any other style (XStringStyle, XCompoundTextstyle, XTextStyle, XUTF8StringStyle) the character is still removed.
If I hardcode the title
{
char mystring = "A ½ of a New Caption";
unsigned char goal = (unsigned char*)mystring;
txt.value = goal;
⋮
//XFree(txt.value);
}
the character is not removed, but another character is added. Because I haven't also changed txt.nitems, the title may end earlier. But it now reads "A ½ of a New...". It adds an A with a ^.
Now if I go to firefox and do a google search for without the quotes "A ½ of", firefox's title now reads "A ½ of - Google Search - Mozilla Firefox (Build 2013062200)". Running the command
xdotool search --name "Mozilla Firefox" getwindowname | hexdump -C
has a result that starts with 41 20 c2 bd 20 6f 66 0a…. Running the command
xdotool search --name "of a New" getwindowname | hexdump -C
also begins with the same hex values.
So even though it is the same string for the window title, firefox reads as "A ½ of" and the irrlicht window reads as "A ½ of".
Then instead of piping to hexdump, I piped to a file, opened that file with firefox, and changed the encoding I viewed the page with. UTF-8 appeared correctly, while Western (ISO-8859-1) and Western (Windows-1252) appeared with the added Â. Other encodings changed the ½ to ˝ or added other-language characters.
So I can conclude that the current irrlicht title is not in UTF-8.
What encoding is it in? When I send it the string "Old Caption", txt.encoding is 31. When I send it the string "A ½ of a New Caption", txt.encoding is 374. I don't remember what string I put in for it to choose this number, but if I set
txt.encoding = 376;
then the irrlicht window starts with "A ½ of a New...", correctly displaying the ½ but ending incorrectly because txt.nitems is still wrong when I hardcode the title.
How do I find out what text encodings 31, 374, and 376 are in human-readable terms?</wchar_t**>

[Kyle Mills]

If I edit minetest source and tell it to set a title with that character it just works. I'm so confused. It must be doing something before device->setWindowCaption that makes the difference.

[Kyle Mills]

setlocale(LC_ALL, "");

That was the problem. Something so simple. Now I ask, why? If it works in (the window titles of) other programs I can only assume they have the same line of code. But if it works in gui::IGUIEnvironment->addButton, the tooltip that comes with it, gui::IGUIEnvironment->addStaticText, why wouldn't it also work in the window title?
Of
A) The locale affects every part of a program - button the same as title - separate from other programs
B) The system locale overrides program locale when window titles are involved - all titles the same - programs different from titles - programs different from programs
C) The program locale affects the title - buttons the same as system locale - other programs using own locales
The last thing I would expect to be true is C.
This was a very difficult thing for me to find. Both strings are function(L"½"). Why does locale affect window title but not button text?

[Michael Zeilfelder]

The reason is pretty much what you found out already - setWindowCaption uses internally the string-conversion function XwcTextListToTextProperty while the Irrlicht gui doesn't use that. No idea right now if/how this can be improved. But thanks for telling anyway, maybe someone has an idea or at least we can now help the next person running into this.