Kusomoto-san, Please remember to copy the list in all replies.
> On Jan 2, 2020, at 5:38 AM, KUSUMOTO Norio <[email protected]> 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 <[email protected]>のメール: >> >> 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 _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
