[ Return to Bugs & Features | Roadmap 1.3 ]

STR #2474

Trouble Report Files:

	Name/Time/Date	Filename/Size
	#1  manolo 14:33 Dec 20, 2010	Fl_x.patch2 1k
	#2  manolo 06:07 Dec 21, 2010	Fl_x.patch3 0k

Trouble Report Comments:

	Name/Time/Date	Text
	#1  sparkaround 00:02 Dec 10, 2010	1.The application based on fltk will start with a warrning "XOpenIM failed" and ignore x input method if the x input method start after the application. 2.The application will ignore x input method if x input method crashed and start again. But the application based-on gtk (such as Gnome-Terminal) or qt4 will accept the input from x input method at once if the x input method starts whether the x input method starts before or after the application.
	#2  manolo 02:08 Dec 11, 2010	Please, could you describe in great detail (that is, for who never used an XIM) how to replicate the bug you describe and how to start and stop the x input method. Thanks.
	#3  matt 13:09 Dec 12, 2010	Starting an Input Method on Fedora is simple: just go into user preferences menu and select "Input Method". Enable the recommended method and click on "Settings...". Then add Korean-Hangul and close all dialogs. Log out and back in. Now if you go into any application that allows text input, type Ctrl-Space to start the Korean input. A Korean character is basically a syllable created from three keystrokes (consonant->vowel->consonant). In the Hangul layout, all consonants are on the left and all vowels are on the right. Just type something like 'S' 'O' 'S' will assemble a character (so does DPD DPS, etc. - I have no clue what they mean ;-). "Assemble" means that the symbol on screen will show the first character, then the combined character of two keystrokes, then the combination of three characters at the third keystroke... . Typing space will advance as expected. Unfortunately this does not work with FLTK. I looked at the code I can't understand a work :-( . Is anyone more into the subject of Input Methods? This looks like the top 24 bits are stripped from the final character?
	#4  matt 13:13 Dec 12, 2010	Oh, I just realized that my font does not necessarily support Korean characters - DOH!
	#5  AlbrechtS 06:14 Dec 15, 2010	Changed "Subsystem" to X11.
	#6  matt 01:16 Dec 19, 2010	This seems to be non-catastrophic because the XInput method is normally active at system startup on machines that need it. Can we move this to 1.4?
	#7  sparkaround 08:09 Dec 19, 2010	I haven't find a simple input method to replicate this problem. To use fcitx, at least one chinese font (such as wqy) should be installed and chinese locales (I prefer zh_CN.GBK) may need to generate with locale-gen if none. Then install fcitx (http://fcitx.googlecode.com/files/fcitx-4.0.0_all.tar.gz). For gentoo, just emerge fcitx. At last, prepare the environment vars for fcitx: export GTK_IM_MODULE=xim export QT_GL_USE_OPENGL1ENGINE=1 export LC_CTYPE=zh_CN.GBK export LANG=zh_CN.GBK export XMODIFIERS="@im=fcitx" export XIM=fcitx export XIM_PROGRAM=fcitx export LC_ALL=zh_CN.GBK I write these in ~/.xinitrc to make sure the vars existed before startx. If everything is well, start x window and type "fcitx &" to start fcitx. Then press "ctrl-space" to input chinese characters in the application based on fltk or others and press "space" key to let chinese characters appear in the application or "enter" to let the input character appear in the application. To switch off fcitx on the fly, just  "ctrl-space" again. Press another "ctrl-space" to enable fcitx again. To exit fcitx, I use "killall -9 fcitx". To start fcitx again, just type "fcitx &" in a terminal. there are tow lines in the configuration of fcitx: export GTK_IM_MODULE=xim export QT_GL_USE_OPENGL1ENGINE=1 But I dont't think this have something to do with this bug. I tried to input chinese characters in rxvt , it works even I stop and start fcitx again.
	#8  sparkaround 08:18 Dec 19, 2010	I add fcitx to ~/.xinitrc to start fcitx at x startup. My application based on fltk have to be started at x startup too, then I found that I can't input chinese characters in that application. As a workaround, the application have to be start with "sleep N && application" to make sure fcitx have been ready.
	#9  manolo 09:48 Dec 19, 2010	Many tanks for these detailed explanations. Could you, please, tell me if the small patch below solves the problem ? Index: src/Fl_x.cxx =================================================================== --- src/Fl_x.cxx (revision 8022) +++ src/Fl_x.cxx (working copy) @@ -1203,7 +1203,13 @@      event = FL_UNFOCUS;      break;   -  case KeyPress: +  case KeyPress: { +    XIMStyles *xim_styles = NULL; +    if(!fl_xim_im || XGetIMValues(fl_xim_im, XNQueryInputStyle, &xim_styles, NULL, NULL))) { +      fl_init_xim(); +      } +    XFree(xim_styles); +    }    case KeyRelease: {    KEYPRESS:      int keycode = xevent.xkey.keycode;
	#10  sparkaround 19:55 Dec 19, 2010	manolo,  it almost works!   1.If the xim starts after the application, the application will not accept input via xim immediately. But if I let the application window have input focus , press some keys , leave focus , and let the application window have focus again, then I can input with the xim! 2.If the xim was killed and started again, I can't input with xim in the application. That is to say,the xim window will not appear if I press "ctrl-space". And the application stop to give "XOpenIM() failed" error if the xim start.
	#11  manolo 14:34 Dec 20, 2010	Can you, please, tell me whether the attached patch Fl_x.patch2 solves completely your point 1, that is, when xim starts after the FLTK application. Thanks.
	#12  sparkaround 04:46 Dec 21, 2010	Fl_x.patch2 solves completely the point 1. If xim starts after the FLTK application, I can input with xim in the application immediately with patch2.
	#13  manolo 06:10 Dec 21, 2010	Thank you for replying to my queries. Can I ask you a last test ? Please, try the attached Fl_x.patch3, and tell me if you can then run your FLTK application at login time without having to delay its launch, as you explained you do as a workaround.
	#14  sparkaround 18:30 Dec 21, 2010	I can run the FLTK application at login time without having to delay its launch with patch3 (even in patch1, although not test well). The patch3 also solves completely point 1. Just as patch2, patch 3 does not solve point 2. As a supplement for point 2, either the killing or the starting of xim was done after the launch of the FLTK application.
	#15  manolo 23:16 Dec 21, 2010	Fixed in Subversion repository. Only part of the STR is fixed really, that where the xim server starts after the FLTK application. X input now runs well in this situation. The other part, where the xim server is killed and restarted while the application runs is not fixed. However, while the first part corresponds to a practical need (run an FLTK application at X startup: it can start before the xim server is ready), the second part seems theoretical. Furthermore, it seems that other applications (e.g., xterm, the gnome terminal) react very badly to xim server stop and restart.
	#16  manolo 23:34 Apr 29, 2011	Hi Sparkaround, Could you, please, help for a question related to X input methods? In STR #2599, a user proposes to modify the processing of keyboard input to be able to track dead keys or composed characters. I would like to be certain these changes don't interfere with X input methods before committing these changes. Could you help me ? You would have to install this patch: fltk-1_v5.3.x-dead-chars-x11.patch from   http://www.fltk.org/str.php?L2599 to the current FLTK 1.3 from the svn repository, and test the functionality of X input methods. The same issue applies also to the MSWindows FLTK platform. If you have access to that also, it would be very helpful to add this other patch fltk-1.3.x-dead-chars-win32.patch and see if Chinese character input is unaffected. Many thanks, and best wishes, Manolo

[ Return to Bugs & Features ]