I guess wxgtk 2.6 in Debian is built in Unicode mode, and while I
noticed some random bits and pieces of TerAngreal with stuff in #ifdef
wxUSE_UNICODE conditionals, and some wxStrings are converted with
wxString::mb_str(), it's generally incomplete.

If build in Unicode mode, wxChar is a wchar_t, otherwise it's an 8 bit
char.  Wx provides some objects to convert between char* in various
encodings, and wxChar (whichever of the above it might be).  So I think
to create a wxString from an ASCII char* you do this:

  const char* cstr = "foo";
  wxString wxstr(cstr, wxConvUTF8);

In Unicode mode, wxString uses the predefined wxConvUTF8 object to
convert cstr from UTF8 (ASCII) to Unicode.  In non-unicode mode it just
uses cstr, or maybe wxConvUTF8 actally does no conversion... whatever.

And to get a UTF8 string:

  cstr = (const char*) wxstr.mb_str();

Again, in Unicode mode, mb_str() converts to ASCII, while in non-unicode
mode it just returns the ASCII string.  Maybe you need to do this, not
100% certain yet:

  cstr = (const char*) wxstr.mb_str(wxConvUTF8);

And of course string literals have different syntax, wx provides the wxT
macro to do the right thing depending on the mode (though for the most
part we are already using that in terangreal).

I made a few changes along those lines and got wxterangreal to build but
now it crashes in CS, as does wxtest, in csDriverDBReader.

Has anyone else been hacking on Terangreal to build in unicode mode?
Anyone want my patch while I figure out why it's crashing? (I suspect
that some combination of my graphics hardware and X configuration is
revealing the crashing bug)  I have a bunch of other modifications I
made to terangreal mixed in at the moment, though, I'd have to seperate

One thing we will need to do is add support for different encodings to
things like the talkative message strings and property values.  Or maybe
just change them to always use unicode?


vos-d mailing list

Reply via email to