Recent problem: typing separator char ignored

Yasuaki Taniguchi/谷口康明 yasuakit at
Fri Feb 26 06:21:47 EST 2010


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.

I confirmed both of them. Thank you for your pointing them out.

1) is easy to fix and I've already made a patch.
But it is necessary to discuss more on 2).

At first, I ask you two questions.
a) Which type is your keyboard layout.
b) What is the accurate action?

I suppose you use the US-ASCII keyboard layout or similar ones. The
relation between
keypress and keycode are as follows:
<keypress minus> = [keycode '-']
<keypress shift + minus> = [keycode '_']
<keypress equal> = [keycode '=']
<keypress shift + equal> = [keycode '+']

But most Japanese people (except me) use jp106 or traditional JIS layout.
Please see Wikipedia about keyboard layout.

The relation is:
<keypress minus> = [keycode '-']
<keypress shift + minus> = [keycode '=']
<keypress equal> = unknown
<keypress shift + equal> = unknown
<keypress shift + semicolon> = [keycode '+']
<keypress shift + backslash or Yen> = [keycode '_']

When I think other keyboard layouts, the situation is far complex.
What do you have ideas to resolve these complexity?

Many applications and guidelines take "keyboard acceleration with Alt
and/or Control"
and throw away "one keypress acceleration" in order to globalize themselves.

>> Seems like the correct usage of the Asian character input methods in
>> the context of our register is rather complex. :-(

I think so too. But this is the way Gnumeric passed several years ago.


2010/2/25 Phil Longstaff <plongstaff at>:
> On Thu, 2010-02-25 at 09:15 +0100, Christian Stimming wrote:
>> Zitat von Phil Longstaff <plongstaff at>:
>> > Has anyone else noticed this problem recently with trunk when entering
>> > the account for a split?  I enter "A" "s" and it shows "ASsets:current
>> > assets" (capital letter show current match and then lower case show
>> > potential typeahead).  Before a few days ago, ":" "C" would complete
>> > selection of "Assets" and start on "Current assets".  However now, it
>> > doesn't complete the match.
>> It does? This can very well be caused by r18713. If in doubt, please
>> revert r18713 locally and see whether the issue disappears. If this is
>> the cause, please (someone) revert r18713 in svn and re-open
>> bug#605802 ("Input of Japanese characters") with a clear description
>> of your problem so that the original contributor can fix that one as
>> well. I already had some iterations with him because I noticed similar
>> problems in other columns of the register already, and he readily
>> fixed each of them one by one.
>> Seems like the correct usage of the Asian character input methods in
>> the context of our register is rather complex. :-(
> Yes, reverting 18713 fixes it.  It also fixes the problem that <SHIFT>+
> and <SHIFT>- don't change the date field by 1 week.
> I'll commit and reopen 605802.
> Phil
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

Yasuaki Taniguchi (谷口康明)
  yasuakit at

More information about the gnucash-devel mailing list