Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 1146 by [email protected]: ibus-anthy-1.2.4 failed to
lookup kana_typing_rule table.
http://code.google.com/p/ibus/issues/detail?id=1146
What version of the product are you using? On what operating system?
OS (Linux distributions, UNIX or ...): Fedora 14
Architecture (i386, x86_64): x86_64
IBus version: 1.3.7
Input method name and version: anthy 9100h-15.fc14
Python version: Python 2.7
dbus version: 1.4.0
dbus-python version: 0.83.0
gtk version (if bug is about gtk applications):
qt version (if bug is about qt applications):
What steps will reproduce the problem?
1. Configure IBus-Anthy's Input Type to Kana.
2. Turn on Japanese input mode.
3. Type Yen key of jp106 keybord.
4. A backslash character is entered and not converted.
What is the expected output? What do you see instead?
U+30FC KATAKANA-HIRAGANA PROLONGED SOUND MARK should be entered.
Please provide any additional information below.
The variables 'keyval' in engine/engine.py are retrieved by unichr
function. So 'keyval' has unicode type in python language.
On the other hand, each items of a dictionary
_config['kana_typing_rule/default'] in setup/anthyprefs.py are defined as
string type.
This type incosistency causes failure to find appropriate value. See code
in (Line 56, __get_kana_typing_rule method, engine/kana.py).
In this case, the character in _config['kana_typing_rule/default'] was "¥"
or '\xc2\xa5', but 'keyval' was unichr(keysyms.yen) or u'\xa5'.
At least in Python 2.7 on Fedora 14, the comparison between them are
evaluated as False,
'\xc2\xa5' == u'\xa5'
False
even though the follow comparison becomes True.
'a' == u'a'
True
--
You received this message because you are subscribed to the Google
Groups "ibus-devel" group.
iBus project web page: http://code.google.com/p/ibus/
iBus dev group: http://groups.google.com/group/ibus-devel?hl=en
