Mac OS can't use Chinese IME input in account tag at description field, after finish spelling Chinese press enter to submit, field appear to be blank.
Created attachment 373294 [details] my chinese IME macOS Sierra 10.12.6
(In reply to linjie from comment #1) > Created attachment 373294 [details] > my chinese IME > > macOS Sierra 10.12.6 both cant input successfully
I'm able to reproduce the problem, but it will be a couple of weeks before I have time to look into the cause.
It's a Gtk problem，I can replicate it in gtk3-demo. You can work around the problem by typing a space at the end of the entry. I don't know if you use punctuation keys in Chinese. A period (.) seems to be handled correctly but comma (,) and semicolon (;) aren't.
I'm on macOS 10.14.6. I've tried installing gtk+3 from Homebrew and running gtk-demo to see how it plays with my Japanese IME (not exactly Chinese, but it has a similar live-conversion step). gtk-demo reports its version as being 3.24.10. Then running gtk3-demo --run=textview and trying to input some text while switching to Japanese input in the text box will result in exactly ... no Japanese text being input and it just reverting to standard QWERTY input. On the other hand, switching to a QWERTZ (e.g., German) layout works as expected. It's as if the gtk-demo or perhaps GTK fundamentally skips one whole step in the input handling.
IME operates in regular Gtk as part of the keyboard event handling in GtkEntry and GtkTextView. (That's also the case for everything in GnuCash *except* the register.) The MacOS IME code is in https://gitlab.gnome.org/GNOME/gtk/blob/gtk-3-24/modules/input/imquartz.c. It's basically a bridge between the MacOS IMEs and Gtk's event handler. Most character-based languages don't need input methods because the character sets are small enough that the normal keyboard layout can emit all of the necessary codepoints. Input methods are needed only for character sets needing more than 127 codepoints, with Chinese, Indian, Japanese, Korean, and maybe Arabic being the principal cases.
John, thank you for the further explanation. It neatly fits your explanation that typing Japanese in the "Find..." menu and pressing Enter/Tab there while conversion is still happening is correctly handled by the IME, and not the GnuCash UI. So, would the solution be to use GtkEntry for the register as well? I'm sure there are historical and or design reasons why things have been implemented the way they have been implemented. Browsing through the source code and just randomly searching for GDK_KEY_Return (which I suppose is the enter key which causes all my IME trouble) shows me a lot of switch statements strewn throughout the codebase and especially in GTK related modules. For example I could guess that https://github.com/Gnucash/gnucash/blob/19114cc111d5a685a31ff121a74a82d1d528275d/gnucash/register/register-gnome/gnucash-sheet.c#L1720 could be "skipping" the IME when handling certain key navigation input. I've also uploaded a video showing the issue that I have with Japanese entry: https://www.youtube.com/watch?v=2Yfs5bxtx3o Maybe it helps debug the issue.
You managed to find the place where the register handles IME input and since the Japanese IMEs seem to work OK in gtk3-demo it's probably an error there that's the cause of bug 797329. The Japanese IMEs are a bit different from the Chinese ones because Japanese's syllable-based writing systems and lack of tonality mean that any actual Japanese word or phrase maps to exactly one representation in each of romaji, hiragana, and katakana and if there's a kanji representation there's probably only one. Chinese is different: A phrase typed in roman letters can be interpreted several ways and the IME produces a little box with the choices. It's the selection from that box that's failing, and it does so in gtk3-demo and in all of GnuCash's dialog boxes, meaning that the problem here is with imquartz.c. The upshot is that I was wrong when I said in bug 797329 that it's related to this one.
John, again thanks for your detailed explanation. I'm relieved to hear that we are getting closer to what the origin of my issue might be. But just for clarification, 1) Japanese and Chinese have the same issue with homonyms, so while there is a 1:1 mapping from Romaji input to Hiragana/Katakana, as you say, with Kanji there is always a multitude of conversions to choose from. For example gyousei can be mapped to a) 行政 b) 業生 c) 暁星 and they would all make sense given the right context. Interestingly enough じゃ and ぢゃ are both mapped to "ja" in Romaji, which causes some confusion when trying to type Sangenjaya (三元茶屋), a station name for Tokyo Metro. 2) I'm pretty sure that both the Chinese IME and Japanese IME are broken for the same reason, and I made another screen recording of gtk3-demo this time with both Pinyin and Hiragana input: https://youtu.be/uBinGa0THbI I hope that this shows that gtk3-demo doesn't go well with IMEs, at least on macOS. I would be interested to see a screen recording made by the original poster of this bug, and I am curious whether in the end the two issues are related and my later submission duplicates this one.
As this is reproducable in gtk, should this be moved to their bug tracker ? (I know John also works on gtk-on-osx, so getting this fixed will probably still be done by the same person).
What's the current status of this issue?
Waiting for me to have time to work on it in Gtk.
Sorry, it took a lot longer for me to get back to this than I expected. @justusw I just repeated your test and it worked pretty well for me: https://drive.google.com/open?id=1HSw7ltNfcV-1GltKU0_v7iyN5Yxdl63M That's Gtk-3.23.10 built with gtk-osx (https://wiki.gnome.org/Projects/GTK/OSX/Building), just as I do for GnuCash. The only difference is that I built it on Catalina and GnuCash is built on Mavericks for backward compatibility -- but I tested gtk3-demo on my Mavericks VM with similar results. I'd suspect that the Homebrew recipe did something wrong; you might refresh it with the latest build and test again. Make sure that prefix/lib/gtk/3.0.0/immodules/imquartz.so is present and in immodules.cache.
I've completely reworked the input method handling so that GnuCash doesn't get in the way anymore. There's one possibly serious consequence: Quickfill (aka autocomplete) can't see the input until you commit the input. This will especially affect account selection. It also seems to stop the hot-keys (+. -, [, ], etc.) from working in the Hiragana IM but not any of the Chinese ones. I haven't tried Korean. I'm a bit hampered in testing and therefore working on these because I can't read the Japanese output and don't really know how to get it to enter those hot-key characters. The changes will appear in the Windows and Flatpak nightlies, but there won't be a MacOS bundle until 3.903 is released at the end of the month--unless you say that you've got time to test before then, in which case I'll build one for you.
