[GNC] Gnucash V3.x NSTextInputClient protocol non-compliance

[John Ralls]

Kusomoto-san,

Please remember to copy the list in all replies.

> On Jan 2, 2020, at 5:38 AM, KUSUMOTO Norio <kusumoto at na.rim.or.jp> wrote:
> 
> Thank you for your replay, John!
> 
> 
> (It is very difficult to draw attention to the issue of internationalization 
> of text input. However, if you can imagine the practicality of accounting 
> software that can not input virtually non-numeric text without copying and 
> pasting from other applications, you will understand our disappointment.)
> 
> 
> 
>> 2020/01/02 13:21、John Ralls <jralls at ceridwen.us>のメール:
>> 
>> The known problem with Japanese and Chinese IMs is documented at https://bugs.gnucash.org/show_bug.cgi?id=797264. there's a work-around, though with Japanese it's a bit cumbersome than with Chinese especially on a desktop where you have to move your hands to get to the mouse or trackpad: Finish typing your string with a space, which may bring up a final selection box. Double-click on the selection in the box if it does. Regardless then double click in the field that you're filling in before tabbing to or clicking in another field. In Chinese one need simply end the string with a space bar before tabbing to the next field.
> 
> 
> When we use IM to input Japanese, we use the cursor keys to specify where to separate 
> the translations. Mouse actions cannot substitute for these actions.

Is that because the cursor-key gestures are an ingrained part of typing or is there something about the operation of the IM that I'm missing?

Regardless, I understand that having to use the mouse when typing is undesirable, I offered it only as a workaround until I find time to work on this some more. 


> 
> 
>> I just tried press-and-hold in Apple Mail with the Hiragana IM to see what's supposed to happen. Holding a letter key down does raise a window, but only after the key starts repeating. The same effect is achieved by typing the letter twice, so I don't think that there's a feature there.
> 
> You can select a variation of characters by long pressing only when you use the 'U.S.' 
> keyboard, not when you select Hiragana IM.
> I gave this example because I wanted to say that it is not a limited issue when using 
> a language to input using IM, such as Japanese.

A long keypress just types the letter when I use the US keyboard. 

> 
> 
> 
>> The underlying problem is due to difficulty integrating IMs with our specialized tab, return, and arrow key handling for deciding when to commit transactions, look for accounts, and process calculations.
> 
> I worked on NSTextInputClient support for a programming language development environment 
> last year. (It's not written in C.) It can do tab-driven completion, have the same key 
> combinations as IM, or perform return based execution. I implemented it to suppress 
> passing events to the IDE when I was interacting with IM.
> 
> I'm not familiar with the internationalization of GTK, but I think there should be a way 
> to deal with similar situations because they should be a variety of applications.

The Gtk input module is https://gitlab.gnome.org/GNOME/gtk/blob/gtk-3-24/modules/input/imquartz.c and it mostly wraps NSTextInputClient. It hasn't been updated in a few years and so it has gotten a little out of sync with Apple's code, but the problem with tab, return, and arrow keys is GnuCash's fault: For the most part I think that the IM works correctly except in the register, but you're a far better judge of that than I am. Does it work the way you expect in dialog boxes?

Regards,
John Ralls