This is probably a dupe of bug 797264; it's at least closely related.

Thanks for your swift reply. If you have any patch I can try out, please let me know. I kind of wish I knew how to fix it myself!

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.

(In reply to John Ralls from comment #3)
> 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.

If you need any help with testing, I'd me more than happy to help. I'm on macOS Catalina (10.15.4) right now.

Super. I'll bundle up a build tomorrow and stick it on Sourceforge for you.

https://sourceforge.net/projects/gnucash/files/Development/Gnucash-Intel-3.902-test-ime-1.dmg/download

The SHA-256 is 469584c2b75bb057d2241727688165025f4f9414c08ca9480067cbdd7b96aca5

Note that there's some weirdness in the account picker that's not related to the IM changes: If you enter text that doesn't match the drop-down goes blank. The only way to get it to repopulate is to remove all of the text from the field and start over, but if you back out the non-matching text and enter matching text it will appear to fill in the entry without bringing back the dropdown contents, but when you tab out the value won't be saved because nothing is selected in the dropdown. That originated in the typeahead search enhancements from last mont and I'm starting on fixing it now.

(In reply to John Ralls from comment #6)
> https://sourceforge.net/projects/gnucash/files/Development/Gnucash-Intel-3.
> 902-test-ime-1.dmg/download
> 
> The SHA-256 is
> 469584c2b75bb057d2241727688165025f4f9414c08ca9480067cbdd7b96aca5
> 
> Note that there's some weirdness in the account picker that's not related to
> the IM changes: If you enter text that doesn't match the drop-down goes
> blank. The only way to get it to repopulate is to remove all of the text
> from the field and start over, but if you back out the non-matching text and
> enter matching text it will appear to fill in the entry without bringing
> back the dropdown contents, but when you tab out the value won't be saved
> because nothing is selected in the dropdown. That originated in the
> typeahead search enhancements from last mont and I'm starting on fixing it
> now.

Thanks for the upload. I just tried it, but couldn't get it to run (App would appear in Dock and then immediately disappear).

Running directly in shell (MacOS/Gnucash bin) gave me this:

=====
(process:75053): gnc.gui-WARNING **: 16:03:01.232: [mac_find_close_country()] Apple Locale is set to a value en_JP not supported by the C runtime

(process:75053): gnc.gui-WARNING **: 16:03:01.234: [mac_find_close_country()] Using ja_JP instead.

(process:75053): gnc.gui-WARNING **: 16:03:01.237: [mac_set_languages()] Language list: en:en_JP:C:ja_JP:ko_JP:de_JP:zh_CN:zh_CN


This is a development version. It may or may not work.
Report bugs and other problems to gnucash-devel@gnucash.org
You can also lookup and file bug reports at https://bugs.gnucash.org
To find the last stable version, please refer to https://www.gnucash.org/
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: unable to load the file system codec
ModuleNotFoundError: No module named 'encodings'

Current thread 0x0000000111937dc0 (most recent call first):
fish: '/Users/justusperlwitz/Applicati…' terminated by signal SIGABRT (Abort)
===========

Looks like it's python related (I saw a python 3 dlib) and perhaps the required files are missing (e.g. encodings/__init__.py)

Damn. I made a fresh one without Python: https://sourceforge.net/projects/gnucash/files/Development/Gnucash-Intel-3.902-test-ime-2.dmg/download

Thanks for the new build. It works quite well! Almost feels native. Awesome job!

On a few occasions, it would enter the text twice, for example when I prepare to enter text, the IME selection screen pops up, and I switch focus to a different window (I think expected behavior would be to enter the text only once.

I could also notice that the cursor doesn't follow the input words and only jumps ahead once IME input is finished. I'm attaching a screenshot of how that looks like to this issue if that's OK.

All-in-all, this makes Gnucash much more usable! I wish I knew how to contribute to this project so that I can help with the fine tuning. But I also understand that some of this might be gtk related?

Created attachment 373701 [details]
Cursor position during IME selection screen

Good to know that it's forward progress.

I'm afraid that I'm not able to interpret the screen shot. I can't read more than a couple of words in Japanese and I can't intelligently use the IM. You'll need to tell me exactly what romaji to type, what characters to expect in the IM box and what should be appearing and isn't (or what is appearing and shouldn't) in the register. The bug tracker can handle unicode so you can type or paste Japanese into it.

The way to distinguish between GnuCash problems and Gtk problems is to try to use the IM in a dialog box. The Account Editor and Transfer Dialog are readily available from the menus, and the Transfer Dialog has an accelerator (it's command-T when typing in ASCII) though I can't get the accelerators to work when the IM is turned on. If it works differently in the Register and the dialog then it's a GnuCash problem; if it works the same it's a Gtk problem. However, I'm also a maintainer for Gtk so if I can figure out a Gtk IM problem I can fix that too.

Yes, I'd also think that text getting entered twice is unexpected behavior. ;-) Does it happen when you switch away from the GnuCash control or when you switch back? Is that for other GnuCash windows, other apps, or both?

(In reply to John Ralls from comment #11)
> Good to know that it's forward progress.
> 
> I'm afraid that I'm not able to interpret the screen shot. I can't read more
> than a couple of words in Japanese and I can't intelligently use the IM.
> You'll need to tell me exactly what romaji to type, what characters to
> expect in the IM box and what should be appearing and isn't (or what is
> appearing and shouldn't) in the register. The bug tracker can handle unicode
> so you can type or paste Japanese into it.
> 
> The way to distinguish between GnuCash problems and Gtk problems is to try
> to use the IM in a dialog box. The Account Editor and Transfer Dialog are
> readily available from the menus, and the Transfer Dialog has an accelerator
> (it's command-T when typing in ASCII) though I can't get the accelerators to
> work when the IM is turned on. If it works differently in the Register and
> the dialog then it's a GnuCash problem; if it works the same it's a Gtk
> problem. However, I'm also a maintainer for Gtk so if I can figure out a Gtk
> IM problem I can fix that too.
> 
> Yes, I'd also think that text getting entered twice is unexpected behavior.
> ;-) Does it happen when you switch away from the GnuCash control or when you
> switch back? Is that for other GnuCash windows, other apps, or both?

You're right :) Sorry, I should have made a screen recording in the first place. If you have some time, could you look at this? https://youtu.be/KUDBtnPXNlo

I do two things in the video:

1) Enter text "akasata" (it's the first 4 syllables in the kana alphabet) in Find Transaction (watch how | cursor moves) and switch focus between desktop and app
2) Enter text "akasata" in random ledger (watch how | cursor moves before & after pressing enter) and switch focus between desktop and app

Observations:
1) Here I'm able to duplicate text by switching focus, given that I haven't "committed" (or converted) the raw input. The cursor follows correctly.
2) Here, I'm able to triplicate text, and I've also observed that the cursor doesn't follow the pending input.

So assuming that the Find dialog uses the GTK functionality, we can assume it's a GTK problem, according to what you've described before.

Then, the cursor not following in the ledger appears to be a GnuCash problem, but honestly I can absolutely live with that. It still feels "buggy" to me, as it deviates from common UI behavior.

Aside from CJK languages, there is another way to observe and replicate this, and I assume this will be easier for non CJK speakers. On macOS, dead keys are usually option+e/u/a (depending on kb layout). When, for example, trying to type ü, the keyboard input sequence is option+u, u.

1) When I do this here in Firefox typing this text, the cursor will have already wandered right after typing option+u, and my input will look like this: "¨|". Then, typing u will make the input look like this: "ü|" (with the pipe representing the cursor position.
2) Aside from the find dialog, or other more native GTK UIs in Gnucash, the Gnucash behavior with typing U umlaut is: "|" -> "|¨" -> "ü|"

It's like the cursor is "unaware" of the pending input and decides to wait until all input is finalized.

Sorry for the confusion and I hope this can clear it up. Let me know if you have any other questions :)

OK, now I understand about the cursor. Interesting about the dead keys, I'd never noticed that (there are actually 5 on a US keyboard: `, e, i, n, and u).

Most of my work on this for the last couple of weeks has been on getting the cursor and selections to behave right.

Has quickfill ever worked well enough in Japanese to be of any use to you? It's mostly disabled now because it would interfere with the IM character prediction.

> It's like the cursor is "unaware" of the pending input and decides to wait until all input is finalized.

That turned out to be exactly correct, but it took some major code-diving in the Gtk sources to figure out how to fix it. Fixed now, please take 3.903 for a spin after we release it this weekend.