After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 102779 - XIMLookupKeysym not supported
XIMLookupKeysym not supported
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Input Methods
2.0.x
Other Linux
: Normal normal
: ---
Assigned To: Hidetoshi Tajima
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-01-07 20:11 UTC by Raphael Finkel
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Raphael Finkel 2003-01-07 20:11:32 UTC
My X input method, keypressIM (available at http://www.cs.uky.edu/~raphael/private/keypressIM.c) uses result_data.flag = XimLookupKeySym, which will let
XmbLookupString() return XIMLookupKeysym in the XIM client side, but the
gtk2.0 is not supporting the XIMLookupKeysym case. See
gtk+/modules/input/gtkimcontextxim.c.
Comment 1 Owen Taylor 2003-01-07 20:26:14 UTC
Yes, see that comment. As indicated there, I don't think
there is anything that can be done about this.
Comment 2 Raphael Finkel 2003-01-07 20:39:51 UTC
That's too bad.  My input method needs to generate Unicode characters.  I can't put utf8 into the buffer, because it is treated as char *.  So I put a single keysym such as 0x10005d4 in the request,
where the 0x1000000 bit indicates "UCS-2" in the lower bits, which is a pretty standard convention.  I also hand ordinary keysyms such as 0xff08 (backspace).  I don't see why gtk+ can't understand these cases; the first is a simple conversion, and the second can be converted by Xlib.
Comment 3 Hidetoshi Tajima 2003-01-07 22:01:05 UTC
Why don't we add

 if (status == XLookupKeySym)

case to support minimumly 0x10000000 bit Unicode keysyms
and convert a UCS-2 character to UTF-8's unless it break
accelerator?

Not sure how we should do with Xlib standard keysym names
such as XK_Backspace 0xff08. Does keypress XIM really 
modify the keysym this case?
Comment 4 Owen Taylor 2003-01-07 23:14:29 UTC
This is a misuse if XIMLookupKeysym. If you want to do
Unicode input using XIM, you shoudl be using an UTF-8
locale, in which case the normal facilities of 
XIM for sending text will work fine.

I think we agreed at some point that XIMLookupKeysym
(as compared to XIMLookupBoth) meant specifically that 
there was no text translation of the key that was pressed.

Comment 5 Hidetoshi Tajima 2003-01-08 00:58:12 UTC
Yes, we agreed, just recently...

As far as XIM goes, it is true that using XIMLookupChars or
XIMLookupBoth and returning locale encoded commit string should
support as many as existing clients, not only GtkIMContextXIM.

Comment 6 Raphael Finkel 2003-01-08 01:26:12 UTC
keypress XIM does not modify standard X keysyms; it uses one standard


(the backspace) and the 0x1000000 convention for all other characters.




I don't use a UTF-8 locale because I have been unable to get the C 


libraries to accept yi.UTF-8 (Yiddish in a UTF-8 locale), either in


my XIM or in my applications (in this case, AbiWord).  Although 


locales were invented to make things portable, I have had nothing but


failure using them; they have to be bound too early, and one must use


a locale that is already known on the machine.  I was hoping to make


keypress XIM very portable; the C locale should accomplish that.


Comment 7 Hidetoshi Tajima 2003-01-08 01:38:17 UTC
If only keypress XIM can use CT encoded text to 
return compound text, the locale to run XIM clients and the keypress
XIM does not really matter, so 
you don't have to use UTF-8 locale.

Isn't it possible to modify the keypress XIM so that is should convert
a UCS-2 encoded keysym
value to locale's text with iconv, and then convert it again to CT
with XmbTextListToTextProperty()?