STR #3502

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

Return to Bugs & Features | Roadmap 1.3 ]

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
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:

Name/Time/Date Text top right image
#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:


This code is incorrect, and should be changed to


It's said in 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:

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


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.  
bottom left image   bottom right image

Return to Bugs & Features ]


Comments are owned by the poster. All other content is copyright 1998-2022 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.