kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

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