GNOME Bugzilla – Bug 605802
Can't input Japanese characters at an account register window on windows with SCIM, IIIMF and XIM
Last modified: 2018-06-29 22:32:31 UTC
Created attachment 150608 [details] Account register window image: I can't input Japanese here. This issue happens on both Linux and Windows, and I file this issue as Linux. Assumption Knowledge: When we input some Asian characters (like Japanese, Chines), we use special input methods and protocols. We use XIM, SCIM, IIIMF on X Window System. And we use IME on Windows. Issue Description: When I enter transactions or splits on an account register window, I can't input Japanese characters into them properly. This issue happens only in the GnuCash original text fields, but it doesn't happen in the gtk+ text fields. So I think it a problem of GnuCash. Workaround: I can indirectly input Japanese characters. Once I input Japanese characters in gedit(Linux) or notepad(Windows), I can input Japanese with "copy and paste".
Created attachment 150609 [details] New account window: I can use Japanese because it uses gtk+ fields.
See bug#337020 bug#399351 : Did you activate "Embed Preedit String into client window" in scim-setup? Does it help if you remove that flag?
Dear Mr. Stimming, Thank you for your reference information. It seems the same bug as bug#337020 and bug#399351. But I'm not a programmer, and I can't write codes for a fundamental solution. So I'll add a note to Japanese translation of Concepts Guide. *** This bug has been marked as a duplicate of bug 399351 ***
Created attachment 153255 [details] [review] IMContext fix in register
(Reopening because of new Patch) Dear "yasuakit", thank you very much for this patch. Can you add a short explanation as for what the patch is supposed to do, other than fixing this bug? It's a rather large section of code that is being changed, so I would prefer to hear a few sentences about what was wrong and how it had to be fixed. I'll apply the patch to SVN soon, but an explanation would be good in any case. Thanks!
I reopened this issue because I made a patch to fix this problem. This patch is very important for Asian users. Would you review, test this patch and commit to svn? The main functions are (1) synchronization of preedit string in the register window and sheet->entry, (2) application to pango attributes to preedit string in the register window. I tested on the environments as follows: Ubuntu Linux 9.04, LANG=ja, IM Protocol = scim , IM Engine = Anthy Ubuntu Linux 9.04, LANG=ja, IM Protocol = iiimf , IM Engine = ATOK X3 Ubuntu Linux 9.04, LANG=ja, IM Protorol = none
Dear Stimming, My comment is crossed your comment. Please see comment 6.
Comment on attachment 153255 [details] [review] IMContext fix in register Very well worth a try. Thanks for the patch!
Created attachment 153257 [details] [review] IMContext fix in register rev 2 I accidentally remove this chunk. https://bugzilla.gnome.org/attachment.cgi?id=153255&action=diff#gnucash-sheet.c_sec16 I update the patch.
Comment on attachment 153257 [details] [review] IMContext fix in register rev 2 r18638, thanks a lot!
Thank you for your committing, Christian. But this patch seems to be effective only on X Window system. And it is necessary to make additional hacks for Windows because of the difference of the input APIs. Now I start analyzing. I'll file another issue later when I fix it on Windows.
You're welcome. In this particular case I think it is more helpful to add your Windows-related comments to this bug again. I'll reopen because of this.
*** Bug 609628 has been marked as a duplicate of this bug. ***
OK, I'll converge IMContext related information to this issue. When an input string is longer than item-edit field, a scroll happens in the item-edit field. It is necessary to tell its offset to IMContext in order to show the auxiliary window at the proper location.
Created attachment 153514 [details] [review] IMContext scroll offset patch
Created attachment 153518 [details] [review] IMContext preedit string rollback patch It is necessary to rollback an uncommitted string before deactivate cursor cell. This case doesn't happen by the key press event but it happens by the mouse button press event. So I change the location of gnucash_im_context_reset() before disconnecting signal handlers. The gtk_im_context_reset(), which is called in the gnucash_im_context_reset(), emits "preedit-changed" signal and delete uncommitted string.
Comment on attachment 153257 [details] [review] IMContext fix in register rev 2 Unfortunately I had to revert this patch again as we're trying to release 2.3.9 right now, where it won't be included. It can be included into trunk again, but you would need to work on the following issue as well: Unfortunately this changes the behaviour in the amount entry cell of the register significantly: The string seems to be evaluated into a number right after each keypress, which means one cannot enter arithmetic expressions anymore as they will cause immediate error messages as long as they are not complete. Hence, the patch needs more work.
Could you attach a new patch that includes the three above patches into one? Could you then also mark the "obsolete" patches with the respective checkbox, so that one can clearly see which one should be applied and (if any) in what ordering? Also, I would kindly ask you to create the patches in the top-level source directory (e.g. by running "svn diff" in the top-level directory) because otherwise when applying the patch I have to look up the directory where your changed files are located. Thanks a lot!
Oh, and the test case for "entering an arithmetic expression" goes as follows: Expected behaviour: Enter a new transaction in the register. Move cursor to "amount" field. Press the following four keys: "1" "+" "1" "<enter>". Previous result: Before pressing <enter>, the string "1+1" is visible. After pressing <enter>, the string is calculated into the number "2" and "2.00" (or "2,00" according to the locale) is visible. Observed behaviour after your patch: After pressing "1" "+", an error message pops up saying there is an error evaluating the expression "1+". This should not happen.
Review of attachment 153514 [details] [review]: .
I confirmed the problem what you said. Thank you for your pointing it. The simple way to fix this problem is bypassing the function gtk_im_contex_filter_keypress() when we edit a formula cell. It is necessary to distinguish the type of editing cell at the GnucashSheet object. But the type of cell seems to be capsuled *too good*. Do you know the way to distinguish the type at the GnucashSheet? If we can't distinguish it, we need to change huge codes.
I found we can get the type of cell from gnc_table_get_cell_name( sheet->table, vert_loc). I'll continue to hack it.
Created attachment 154265 [details] [review] IMContext fix in revister rev3 Update IMContext fix patch. The main functions are as follows: (1) synchronization of preedit string between the register window and sheet->entry, (2) application to pango attributes to preedit string in the register window, (3) include scroll offset patch (id=153514), (4) include preedit string rollback patch (id=153518), (5) fix formula and account cells input problem which Christian pointed out, (6) surpress quick-fill when preedit string exists, (7) fix Windows IME problem.
Comment on attachment 154265 [details] [review] IMContext fix in revister rev3 Dear Yasuaki, the patch looks good and works as expected in the amount field. However, there is still some unexpected behaviour being introduced, this time in the quickfill function. To reproduce: Open register window; start a new transaction by selecting the date; press <tab> <tab> to move cursor to Description field; enter the first character of a previous description (say "F" for "Food"), which immediately causes the quickfill to present the rest of the text as quickfill option, where the "F" character is unselected and the "ood" part is selected (displayed inverted). Previous behaviour: I could enter the next character of the old word, here "o", and the quickfill would still present the old word, so that the "Fo" part is unselected and the "od" part is selected. Erroneous new behaviour: When pressing the "o" character, the quickfill suggestion disappears.
Created attachment 154381 [details] [review] IMContext fix in register rev 4 Thank you for your testing, Christian. I update this patch in order to fix Comment 24. From (1) to (7) and (8) Fix quick-fill problem. I changed gnucash_sheet_commit_cb() function. (a) I changed the sequence of the deletion of preedit and selection. (b) I stopped blocking "delete-text" signal when deleting selection. (c) I cleaned up some unnecessary codes.
Comment on attachment 154381 [details] [review] IMContext fix in register rev 4 r18713, thanks a lot! In some first testing I was able to use the register unchangedly, so it seems fine.
Revert r18713 (reopen 605802 "Input of Japanese characters". This commit had 2 problems: 1) when entering an account name, the account separator would no longer accept at the current level of the account tree and move to the next level 2) <SHIFT>+ and <SHIFT>- in a date field would not change the field by 1 week.
*** Bug 605665 has been marked as a duplicate of this bug. ***
Created attachment 154755 [details] [review] IMContext fix in register rev 5 This patch fix problems as follows: From (1) to (8), (9) fix selection activities when preedit exists, (10) Remove GTK_ALLOWED_SELECTION_WITHIN_INSERT_SIGNAL definition and #ifdef clauses, (11) when entering an account name, the account separator would no longer accept at the current level (12) workaround for <SHIFT>+ and <SHIFT>- in a date field would not change the field by 1 week. I add checking the type of COMBO_CELL_TYPE_NAME in gnucash_sheet_check_direct_update_cell() in order to fix (11). I add a variable sheet->shift_state to GnucashSheet class, save the state of shift key into it, and restore state when doing direct update in gnucash_sheet_commit_cb() to fix (12). I tested comment#19, comment#24, comment#27 and seems to fine.
Comment on attachment 154755 [details] [review] IMContext fix in register rev 5 Applied as r18742
(In reply to comment #29) > (11) when entering an account name, the account separator would no longer > accept > at the current level ... > I add checking the type of COMBO_CELL_TYPE_NAME in > gnucash_sheet_check_direct_update_cell() > in order to fix (11). > Issue (11) is fixed for the normal register, but the problem is still there in the business ledgers. Testcase: Create an invoice/bill, and try to use the account separator when entering xfer accounts in the invoice to move to the next level in the account hierarchy -> this doesn't work.
Created attachment 156061 [details] [review] IMContext business fix (against r18899) This patch adds business ledger's DATE_CELL_TYPE_NAME and COMBO_CELL_TYPE_NAME into gnucash_sheet_check_direct_update_cell(). I made this patch against r18899 instead of marking the previous patch obsolete, because Christian re-indented gnucash-sheet.c in r18790. Thank you for pointing out this problem, Greet.
Review of attachment 156061 [details] [review]: Thank you for your patch. Yet I'm afraid there's a problem with it: The business module depends on the register module. With your patch, you make the register dependent on the business module. Such a circular dependency is not allowed. Can you see if you can correct this ?
Review of attachment 156061 [details] [review]: I understand what you say but it is hard to fix it right now, because the code of GnuCash registers/ledgers/UIs are designed without the consideration of input method. GnuCash registers/ledgers pass the ASCII key press events as a "SIGNAL" in order to act mutually. They are not for enough for Asian input method and cause unexpected behaviors like Bug#612803. The fundamental solution is rewriting registers/ledgers to use g_signal, but I can't afford to do it. I think it is better to rewrite the code of registers/ledgers gradually toward 2.6, 3.0 or cutecash. If you want more information of Asian input method, please read CJKV Information Processing, Ken Lunde, 2008, O'Reilly. http://oreilly.com/catalog/9780596514471/
A quick hack is to move all the definitions of the normal and business cell name from split-register.h and gncEntryLedger.h to table-allgui.h respectively, and keep Makefile.am unchanged. But it is a bit strange.
Created attachment 156094 [details] [review] IMContext business fix rev2 (against r18899) An updated patch in order to avoid a circular dependency.
I decided to add a member variable into a basiccell so as to save its type name, but I need more time. Just a minute.
Created attachment 156271 [details] [review] IMContext business fix rev3 (against r18902) Update patch for fixing a business ledger's completion problem and a circular dependency. I found the same functions static void gnc_register_add_cell() at src/register/ledger-core/split-register-layout.c and src/business/business-ledger/gncEntrLedgerLayout.c. I didn't join them in this patch. But I think it's better to unify them if unnecessary.
Review of attachment 156271 [details] [review]: Thank you for your patch. I have tested the business register and now it all works fine on my system. I have commited it in r18974.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=605802. Please update any external references or bookmarks.