STR #3502: Cannot use Chinese input method in linux for fltk >= 1.3.4

STR #3502

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	3 - Moderate, e.g. unable to compile the software
Scope:	2 - Specific to an operating system
Subsystem:	Core Library
Summary:	Cannot use Chinese input method in linux for fltk >= 1.3.4
Version:	1.3.4
Created By:	TsReaper
Assigned To:	AlbrechtS
Fix Version:	1.3.6
Fix Commit:	924289a40c2f112772e0b44325ba2297b2e07a35
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

No files

Trouble Report Comments:

#1	TsReaper 09:50 Nov 24, 2018

I'm trying to input some Chinese characters in my fltk 1.3.4 program running on linux but failed. I've tested on Ubuntu 18.04 and Arch Linux and none of them succeeded. But if I switch to fltk 1.3.3 things just work well. I'm using fcitx, and specifically fcitx-googlepinyin as the Chinese input method. After studying X input method, I discover that it's the modification of STR #3192 that causes this bug. On line 673 and 1329 of file src/Fl_x.cxx we have the following code: XSetLocaleModifiers("@im="); This code is incorrect, and should be changed to XSetLocaleModifiers(""); It's said in https://linux.die.net/man/3/xsetlocalemodifiers that: The local host X locale modifiers announcer (on POSIX-compliant systems, the XMODIFIERS environment variable) is appended to the modifier_list to provide default values on the local host. If a given category appears more than once in the list, the first setting in the list is used. So I think the problem in STR #3192 is caused by forgetting to set the XMODIFIERS, not by the empty string parameter of XSetLocaleModifiers.

#2	TsReaper 11:21 Nov 24, 2018

After some consideration, I think it's also OK not to fix this problem, but to set the XMODIFIERS to "fcitx" instead of "@im=fcitx"...

#3	TsReaper 11:31 Nov 24, 2018

Hmm... Strange, but changing XMODIFIERS from "@im=fcitx" to "fcitx" still doesn't solve this problem, only changing the source code and recompiling the library solves it. This "append" might not be as simple as I thought...

#4	AlbrechtS 07:43 Jan 01, 2019

Reduced priority to 3 (moderate). This issue should not block the release of 1.3.5.

#5	matt 06:56 Feb 05, 2019

@TsReaper, I would love to fix this, but I don't have a Chinese keyboard to test this out. I do feel a tiny portion of your pain because for decades, getting German characters (äöüÄÖÜß) to appear was a mess, too. What exactly do I need to change to make this feature work again? Maybe you can check fltk 1.4 from GitHub as well.

#6	ossman 05:10 Jan 21, 2020

I'm fairly sure you should just revert that commit. Whatever bug was causing STR 3192, this was not the proper fix. Other toolkits like GTK+ call XSetLocaleModifiers() with an empty string, so I'd say that is the correct way to call it. This of course means more debugging is needed to figure out a proper fix for 3192.

#7	AlbrechtS 12:05 Jan 22, 2020

This STR refers to STR #3192. Adding a direct link: https://www.fltk.org/str.php?L3192 I have no idea what the correct solution for this STR and for #3192 is though. Just adding the link for now.

#8	AlbrechtS 03:56 Feb 10, 2020

After reading lots of documentation and doing some tests I agree that using XSetLocaleModifiers(""); is the correct solution for interaction with X Input Methods (XIM). Using "@im=" would prevent users from setting their own input method by using the XMODIFIERS environment variable (for instance by setting XMODIFIERS='@im=ibus' or XMODIFIERS='@im=fcitx' as usual) because "@im=" would fix the input method to be using the system default input method, as the documentation says. Hence I'm going to fix this in FLTK 1.3 (supposedly 1.3.6) and in 1.4 (Git master). I'm also reopening STR 3192.

#9	AlbrechtS 04:43 Feb 10, 2020

Fixed in Git repository. Committed in: - FLTK 1.3.6 (branch-1.3): 219ae5e455e7943ffb35fdd5edbe13dcc6955423 - FLTK 1.4.0 (master): 924289a40c2f112772e0b44325ba2297b2e07a35 This should fix the issue reported here (STR 3502) but may affect STR 3192 because this reverts the patch used for 3192 which appeared to be incorrect.

#10	AlbrechtS 04:46 Feb 10, 2020

@OP (TsReaper) and others: please report if this fixes the issue for you in FLTK 1.3 (Git) and/or 1.4 (Git or next snapshot on Friday Feb 14) so we can close this STR.

#11	AlbrechtS 06:34 Jun 30, 2020

This STR has not been updated by the submitter for two or more weeks and has been closed as required by the FLTK Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR.