On Sat, Jun 09, 2012 at 11:46:39PM -0700, Henner Zeller wrote: > Which brings me to a (newbie-to-project) question: I am new to > wxWidgets and for me the mix between UTF-8 strings and wide strings > (UTF-16?) seems to be a mess. Personally, I'd do everything in UTF-8 > (which is kindof the industry standard for at least 10 years), but it > seems that wxWidgets needs to be compatible with Windows compatibility > legacy that predates UTF-8. So my question: how is this usually > handled in this project: keep things as much as possible as wxString > and deal with the inconvenience ? Is this still necessary for Windows > compatibility ?
*It is* a mess. The wx rule is 'always use wxStrings unless you can't use it'. *Our* (IIRC consensus was reached) wish is: junk the whole wxString class since it's obsolete anyway (and convert the whole wx stuff to std::string). 'Fun' ensues since the std::string is not unicode under windows... well depending on the decided encoding. Part of the problem is that a wxChar (so the wxString element) can be a char or a wchar_t (or something else, it seems) depending on the platform *and* wxWidget compile options! The fact that Linux/Macos X uses UTF-8 (so a MBCS encoding) while Windows is still stuck to 16-bit unicode (so not even UTF-16!) complicates life anyway... the gtk people uses UTF-8 under Windows too, ISO says to use wstring (which *nobody else* uses and suck 4 bytes a character), so anyway portable string handling is suffering XD And, yes, you can build a 'differently compatible' wxWidget library when configuring it... Another thing, good luck when you stumble on the hashtable declaring macros, too... -- Lorenzo Marcantonio Logos Srl _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
