Bug 115656 - getInputBoxValue does NOT output Unicode chars.
Summary: getInputBoxValue does NOT output Unicode chars.
Status: RESOLVED FIXED
Alias: None
Product: superkaramba
Classification: Miscellaneous
Component: general (show other bugs)
Version: unspecified
Platform: Slackware Linux
: NOR normal
Target Milestone: ---
Assignee: Ryan Nickell
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-11-04 09:49 UTC by Daniel
Modified: 2005-11-05 00:38 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments
Example applet and screenshot (50.53 KB, application/octet-stream)
2005-11-04 09:53 UTC, Daniel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel 2005-11-04 09:49:59 UTC
Version:           0.37 RC2 (using KDE KDE 3.4.3)
Installed from:    Slackware Packages
OS:                Linux

SuperKaramba 0.37 RC2's getInputBoxValue function does not OUTPUT Unicode. (At least Russian/Cyrrilic)

SYSTEM:
Slackware 10.2
2.6.13.x kernel
"set | grep LANG" = LANG=en_US.utf8

BUG SUMMARY:
The widget displays the Unicode text properly when entered directly in the box. (see screenshot)
When getInputBoxValue function is called from python, it seems to return only CHAR type. All unicode letters are replaced by question marks. (see same screenshot)
(By the way, keyPressed karamba function also returns ?'s on Unicode input (russian in my case). related?)

DETAILS:
- entering some German chars seems to work, so it may be a problem for chars outside of Latin 1 codepage. (I don't know German, or know how to use German keyboard correctly. I just tried to enter letters a and u with dots on top. My test applet seemed to return correct char numbers 228, 252 to stdout.)
- the problem seems to stem from the fact of getInputBoxValue returning a "char" as opposed to "unicode" object. getInputBoxValue seems to overwrite the pre-declaration of the return variable as unicode. So, (i would like to think) it's not a problem with my python code. Example:

def keyPressed(widget, meter, char):
    global input # this is the pointer to inputBox
    if meter == input:
        print "keyPressed: key= '", char, "' | Ordial is '", ord(char)
	text = u''  # manual declaration as Unicode, and test (print bellow)
	print "text type BEFORE geting text from inputBox is: ",type(text)
        text = karamba.getInputBoxValue(widget, input)
	print "text type AFTER geting text from inputBox is: ",type(text)
	print text

Returns something like that:

keyPressed: key= ' t ' | Ordial is ' 116
text type BEFORE geting text from inputBox is:  <type 'unicode'>
text type AFTER geting text from inputBox is:  <type 'str'>
jobnot
[lots of errors here due to using of a layout switch key combination]
[I switched to russian(winkeys) layout]
keyPressed: key= ' ? ' | Ordial is ' 63 (I entered russian letter here)
text type BEFORE geting text from inputBox is:  <type 'unicode'>
text type AFTER geting text from inputBox is:  <type 'str'>
jobnot?
(the fact that it "prints" it without an error, supports that the string doesn't contain non-latin chars.)

ATTACHMENTS:
One tarball containing the testing SuperKaramba widget and a screenshot.
Comment 1 Daniel 2005-11-04 09:53:55 UTC
Created attachment 13270 [details]
Example applet and screenshot

Attachment contains 4 files:
2 files (.theme and .py) of example SuperKaramba applet.
1 file of a stdout log on my system.
1 file screenshot
Comment 2 Ryan Nickell 2005-11-05 00:38:23 UTC
Problem cs2() gives pointer to short (2 Bytes)
wchar_t is the same as Py_UNICODE (4 Bytes)
Casting short to Py_UNICODE causes it to be
tmp[i] + tmp[i+1] which is not correct.
This may be platform and distributation dependant,
but should work on every platform, beacuase wchar_t is
always bigger or equal than short.

Committed revision 477748

This also possibly addresses another bug regarding locale issues:
http://bugs.kde.org/show_bug.cgi?id=115486
This isn't verified so if someone could do that, it would be great.