I am new to wxPython, and I would like to start building applications with
So am I
and I require the ability to display the GUI using various languages:
So do I
Does anyone have experience with using multiple languages with wxPython,
Don't think it is possible on win32 yet.
I will post a summary of responses to this list; please email me directly or
Seems evident
Here's a summary of what I found out after a weekend of "research".
I'll mainly focus on win32 here as this is where I tried out everything.
I hope someone does it for Unix too!?
I guess the picture is not complete.
I hope more knowledgable people will be so kind
to fill the gaps/correct my misunderstandings.
(these things I'm not sure of are marked with an astrix at the line start).
From Python 1.6 onwards there's the Unicode support.
Unicode allows you to represent special character in the source code.
There's the unicode type (a kind of string) build in and
easy to use conversion methods from this type to an ordinary string
and unicode string operation (even with ordinary strings as operand).
This conversion is done through codecs.
The standard codecs I know about are:
- ASCII: only characters representable through 7 bits are converted from the
unicode string
- Latin-1: only character representable through 8 bits are converted from
the unicode string
- UTF-8: a unicode character is represented through several bytes (from 1 to
?3? bytes)
e.g. u'\u304b' becomes '\xE3\x81\x8B'
- UTF-16: a unicode character is represented through 16 bits (there's an
endian issue here!)
e.g. u'\u304b' becomes '\x48\x30' or '\x30\x48' depending on endianess.
Some people made other codecs so you might find something for Hebrew, ...
e.g. I found and successfully used a Japanse codec from
http://pseudo.grad.sccs.chukyo-u.ac.jp/~kajiyama/python/
With I could read files I edited with emacs' MULE system.
On the win32 (m$ nt X.Y) the underlying string representation is unicode.
Note that win32s (m$ 9X/ Me ...) has only very, very limited support for
unicode.
E.g. Imagine one does a call to the CreateWindow(...) API.
Depending on the global macro's UNICODE and _UNICODE
this gets translated to an actual call to
- CreateWindowW(...): the real unicode version
(revealing the "special" characters depends on the font you use)
- CreateWindowA(...): the ascii version.
First all the "char*" parameters are converted to "unsigned short*" ones and
at the end CreateWindowW(...) is called.
ActiveState python 2.1 I tested does not seem to have
UNICODE and _UNICODE defined while compiling their binaries.
Logical otherwise it would not run on m$ win98 for instance.
It also means that you are not able to access the CreateWindowW()
through their win32 extentions even though
you specify the string parameters as unicode strings.
You are only able to show the ordinary ASCII characters correctly.
One is able to compile the wxWindows 2.2.5 library on win32 with Unicode
support.
Therefor you have to change the following macros in the msw\setup.h file:
- wxUSE_UNICODE: a wxChar type will be a wchar_t (otherwise it would be
just a char)
This wchar_t (a 16 bit type) supports win32's underlying UNICODE system
directly.
A wx program using this will only run on m$ nt (as explained higher) only.
- wxUSE_WCHAR_T: necessary for wxUSE_UNICODE
* According to a comment you can setup wxUSE_WCHAR_T
* only for limited unicode support.
* You program will run on win32s too.
* You are unable to display "special" characters however.
* Therefor this seems to be a useless option to me.
* I could be misunderstanding something here.
wxWindows uses the GTK widget set on Unix.
* I know not much about the underlying datatypes and techniques
* for showing special characters on this platform (there the pango thing
...).
* I think wchar_t* is never used here as the basic type, just char*.
* This in theory also allows to "encode" a special character but
* through multiple bytes (UTF-8 and UTF-16 as shown above).
I once made research on the autoconf/automake and gettext tools.
See http://gallery.uunet.be/Francis.Meyvis/
These combination of tools allow you to write a binary program
that is ready for translation to other languages on Unix.
Now at last wxPython.
The SWIG utility helps creating a wrapper around the wxWindow library.
This all is then presented as the wxPython module to the python.
I first got the sources (faster and this cheaper in downloading ;-).
These did not "setup.py" until Robin Dunn was so kind to
point me to a fixed my_distutils.py for 2.2.5. Thanks!
In the mean time I got the binary wxPython 2.2.5 modules.
for the python 2.1 used by ActiveState 2.1.
* With these I'm unable to use Unicode on win32 (hence the special
characters).
* I guess this is because the used wxWindow library is not compiled
* with the needed wxUSE_UNICODE support.
I then tried to get this to work from the sources.
I stumbled on type problems between the wxChar
(that is a wchar_t thus an unsigned short* when wxUSE_UNICODE is set)
and several python functions that require a char*.
I modified helper.cpp only to find out that the next file (wx.cpp)
that is compiled by the "setup.py" has even more problems.
This file is auto generated by SWIG.
I'm considering having to run wxPython in Unicode.
But my knowledge is very limited:
Don't know SWIG (and its 300+ pages users manual scares me off)
Don't know wxWindows at all
Don't know well how this python embedding thing works.
Don't know much on Unicode on unix/GTK (I'm not interested
on having it to work on win32 only)
Are there already people out there working on this?
Or perhaps I miss something and is is done already?
Thanks
Kind regards,
francis