I'm developing in parallel on Mac and Linux (Fedora Core 1), wxPython 2.5.1.5 , and these only apply to linux gtk2 (both seem ok under gtk and mac).
1) wxChoice crashes when passed any choice string that contains non-printable characters (well, I haven't tried all, but at least 0x91 and 0x92 cause a segfault).
2) Dialogs that use standard icons on gtk2 segfault, sometimes without warning, sometimes with a Gtk-WARNING: Error loading icon: Failed to load image <valid path to stock gtk icon> Fatal error in PNG image file: invalid stored block lengths. The images are ok, as other programs display them fine from the same path. Similarly, in various bits of the demo (like message dialogs) I get a segfault with gdkdrawable-x11.c:1012 drawable is not a pixmap or window
I can file bug reports if these are reproducible with others and unknown so far.
As said, using the gtk version of 2.5.1.5 both do not crash, but glcanvas flickers badly (I remember there being a fix mentioned sometime - can anyone remind me?)
I'm developing in parallel on Mac and Linux (Fedora Core 1), wxPython 2.5.1.5 , and these only apply to linux gtk2 (both seem ok under gtk and mac).
1) wxChoice crashes when passed any choice string that contains non-printable characters (well, I haven't tried all, but at least 0x91 and 0x92 cause a segfault).
In the unicode builds wxPython tries to convert all strings that it receives into unicode objects. Since the string you pass is not a valid string for your default encoding the unicode conversion is failing, but in this case the wrappers are not checking for the failure, hence the crash. (I'm adding that check right now, such that it will pass on the exception from the conversion.)
2) Dialogs that use standard icons on gtk2 segfault, sometimes without warning, sometimes with a Gtk-WARNING: Error loading icon: Failed to load image <valid path to stock gtk icon> Fatal error in PNG image file: invalid stored block lengths. The images are ok, as other programs display them fine from the same path. Similarly, in various bits of the demo (like message dialogs) I get a segfault with gdkdrawable-x11.c:1012 drawable is not a pixmap or window
I don't see this problem here with wx.MessageDialog.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
In the unicode builds wxPython tries to convert all strings that it
receives into unicode objects. Since the string you pass is not a valid
string for your default encoding the unicode conversion is failing, but
in this case the wrappers are not checking for the failure, hence the
crash. (I'm adding that check right now, such that it will pass on the
exception from the conversion.)
I'm probably being foolish here.. but how will this allow us to pass in
strings in encodings that are not our default?
I've only just just started to play with 2.5 for my multi-language thing, but
I often need to have a single string with, say. english, korean, and mandarin
in the same string, therefore utf-16/utf-8 is about the only option..
Yes, I have fonts that include ALL the required characters in a single font..
tricky as they are to get..
Or am I missing the point here again
PS: rebuilding the 2.5.1.5 source rpms under fedora for the 2.3.3 distribution
fixes the 4-byte, 2-byte unicode problem perfectly!
In the unicode builds wxPython tries to convert all strings that it
receives into unicode objects. Since the string you pass is not a valid
string for your default encoding the unicode conversion is failing, but
in this case the wrappers are not checking for the failure, hence the
crash. (I'm adding that check right now, such that it will pass on the
exception from the conversion.)
I'm probably being foolish here.. but how will this allow us to pass in strings in encodings that are not our default?
I've only just just started to play with 2.5 for my multi-language thing, but I often need to have a single string with, say. english, korean, and mandarin in the same string, therefore utf-16/utf-8 is about the only option..
Yes, I have fonts that include ALL the required characters in a single font.. tricky as they are to get..
Or am I missing the point here again
PS: rebuilding the 2.5.1.5 source rpms under fedora for the 2.3.3 distribution fixes the 4-byte, 2-byte unicode problem perfectly!
Regards,
Stuart W.
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
.
HI,
this is a question, not help. I am myself learning with wxPython and I've been solving this multilanguage problem too. Utf-8 works fine. If I understand it correctly, you don't want to use utf-8 for everything, but only for few strings. Why? I work on Debian.
Cheers
Petr
In the unicode builds wxPython tries to convert all strings that it
receives into unicode objects. Since the string you pass is not a valid
string for your default encoding the unicode conversion is failing, but
in this case the wrappers are not checking for the failure, hence the
crash. (I'm adding that check right now, such that it will pass on the
exception from the conversion.)
I'm probably being foolish here.. but how will this allow us to pass in strings in encodings that are not our default?
Pass unicode objects directly. If you pass strings, then the wrappers in the unicode build first have to convert to unicode, and then to a wxString to pass to the API. But if you pass a Python unicode object it goes straight to wxString.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
You are, as always, you make everything look so simple and obvious!
Thanks for untangling my brain again!
Regards,
Stuart W.
···
On Tue, 06 Apr 2004 18:28, Robin Dunn wrote:
> I'm probably being foolish here.. but how will this allow us to pass in
> strings in encodings that are not our default?
Pass unicode objects directly. If you pass strings, then the wrappers
in the unicode build first have to convert to unicode, and then to a
wxString to pass to the API. But if you pass a Python unicode object it
goes straight to wxString.
Not really, I convert just about everything to unicode types in python,
unfortunately some of the other API's I have to live with don't support
unicode so things get pushed back into enocded forms, such as utf-8, iso8859,
and others. Multi-language support can be a REAL pain once you have to use a
pile of binary-only API's and multiple character sets at the same time.
Regards,
Stuart W.
···
On Tue, 06 Apr 2004 18:15, Petr Šimon wrote:
HI,
this is a question, not help. I am myself learning with wxPython and
I've been solving this multilanguage problem too. Utf-8 works fine. If I
understand it correctly, you don't want to use utf-8 for everything, but
only for few strings. Why? I work on Debian.
