Right. My reference to the "BT keyboard input method" was incorrect, because this GTK input method does not exist. It appears, from information on the BT keyboard plugin homepage, that when the plugin is used, GTK switches to the xim input plugin. It is unclear what causes this switch to occur because I could find no mention of "xim" in the source code for the plugin, and a cursory examination of the GTK source code didn't turn up anything. Maybe there are issues with xim.
Aaron On Tue, 17 Jan 2006, Nils Faerber wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > If I am not mistaken then the Bluetooth Keyboard plugin does not have > much influence on the actual input at all. It just starts the Bluetooth > HID daemon (hidd) which will handle the Bluetooth HID protocol. > The actual keyboard events are generic Linux input events which will be > fed through the console driver to the X server to GTK. I have not looked > at the code yet but the keytable switching will probably be done using > something like xmodmap. > Does that help? > > Cheers > nils > > Aaron Levinson schrieb: > > I seriously doubt that this problem has anything to do with the Hildonized > > GTK+, considering that special characters such as the German umlaut work > > fine in my VNC viewer port (at least with the virtual keyboard). In > > addition, an examination of the xterm implementation will demonstrate that > > it makes significant use of GTK, and this is likely the case for Opera as > > well. > > > > More likely, the problem is due to an improper implementation of the > > signal handlers for the input method's "commit" and possibly > > "preedit-changed" signals. The strings passed to these input handlers, at > > least for the hildon-im-context (virtual keyboard) and handwriting input > > methods are in UTF-8 format, and while a simple parse of the string as if > > each character is a byte long will work for many characters, it won't work > > for multibyte characters such as the umlaut. > > > > Another possibility is that the BT keyboard input method is passing a > > string with a different format (i.e. not UTF-8) to "commit" and > > "preedit-changed" signal handlers. This seems like a real possibility, > > because when the notes application is used with the virtual keyboard and > > special characters are used, these special characters display fine. > > > > One final possibility is that there is no requirement for the format of > > the string passed to the "commit" and "preedit-changed" signal handlers of > > input methods. The GTK API documentation is limited for this class, but > > there is some limited mention of UTF-8 in the documentation for some > > methods, such as gtk_im_context_get_surrounding(). > > > > Aaron Levinson > > > > On Tue, 17 Jan 2006, Simon Budig wrote: > > > > > >>That as well. I just wonder what crack the Notetaking application has > >>smoked to ignore the german umlauts. As you've noted on your homepage > >>they work in Opera and xterm, so it seems to be the fault of the > >>Hildonized GTK+ (they don't work in the GPE-PIM stuff either). > > > > - -- > kernel concepts Tel: +49-271-771091-12 > Dreisbachstr. 24 Fax: +49-271-771091-19 > D-57250 Netphen Mob: +49-176-21024535 > - -- > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.1 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org > > iD8DBQFDzUOSJXeIURG1qHgRAsW3AJ9gW0F9SNWyI3XA9MpIxrGvintQrgCg3EmT > LTzokI4iy/RRSSlWr/Sq1ws= > =a6cK > -----END PGP SIGNATURE----- > _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
