Bug 8648

Created attachment 7419 [details] [review]
Patch for symbol/jp and rules/base.xml.in

Here is a patch to add OADG109A variant for jp keylayout.

I added jp(common) for common symbolss for current jp106 and OADG109A.	I'm not
sure about adding hidden parameter for it (I'm too ignorant about xkb).

I deleted include "us" to avoid "asciitilde" with shift+<AE10>.

Sergey, one Japanese person sent me a direct mail about this bug, and told me
that the patch still has a problem for direct Kana input with Input Method.

My patch solve the problem about producing "prolongedsound" from "yen" using IM,
but causes a problem about the position of "kana_WO" with IM, since <AE10> has
no symbol with shift modifier on the patch.

The person's view is that add symbol "backslash" for <AE13> and "underscore" for
<AB11> without shift modifier, and no "yen" symbol.   He said that this solves the
 direct Kana input problem with IM.

But I don't think it is not good idea, since we should show correct symbols
which is printed on keytop of Standard Japanese keyboard (OADG109A) as our
agreement in bug #8503.

So, it may be a workaround to produce "asciitilde" symbol with Shift + <AE10>
even OADG109A has no symbol with shift modifier on the keytop.  

Please apply the revised patch.  It satisfies all the latin symbols in OADG109A
keytop, and solved the Kana direct input with IM.

Created attachment 7420 [details] [review]
Revised patch

> But I don't think it is not good idea, since we should show correct symbols
> which is printed on keytop of Standard Japanese keyboard (OADG109A) as our
> agreement in bug #8503.

Sorry for my poor English again...  I mean, I don't agree with him.  I don't
think it is a good idea to input "backslash" on <AE13>, and "underscore" instead
of "backslash" on <AB11> without shift modifer because it is inconsistent with
what is printed on key tops of OADG109A.

So I think the revised patch is a good solusion for both consistency with
OADG109A, and direct Kana input.

I am ok with this patch. Etsushi, I'll commit it ASAP. Regarding the
questionable key - the best approach IMHO would be to deliver within default
variant the symbols engraved on most keyboards produced in the country. If it is
"106" - let it be so.
Though I must admit we do not have consistency here yet - for example, most
Russian keyboards have engraved characters corresponding to non-default ru(winkeys).

Thanks Sergey.  Please commit the patch.

> Though I must admit we do not have consistency here yet - for example, most
> Russian keyboards have engraved characters corresponding to non-default
> ru(winkeys).

Ah, really?  Regarding engraved characters on standard Japanese 109A keyboard,
IMHO OADG109A layout should be the default one day.  But for now, as Windows
also has inconsistency here, please keep jp(106) default.


BTW, about Kana input with IM, Japanese IM developers are now thinking about the
possibility of using xkb (libxklavier) mechanism even with IM on X11, since
current mechanism for Kana input in IM (using ASCII symbol to produce Kana)
doesn't satisfy the request of some people to use both jp(106) style "latin"
input (which doesn't correspond to latin engraved characters) when IM is Latin
mode, and jp(kana) style Kana input (which does corresponding to Kana engraved
characters) when IM is Japanese mode, sigh...  Anyway really appriciate for
creating libxklavier, and I'm now trying to learn how to use it.

> Thanks Sergey.  Please commit the patch.
Done!

> Ah, really?  Regarding engraved characters on standard Japanese 109A keyboard,
> IMHO OADG109A layout should be the default one day.  But for now, as Windows
> also has inconsistency here, please keep jp(106) default.
OK, I will.

> possibility of using xkb (libxklavier) mechanism even with IM on X11, since
Interesting news!

> characters) when IM is Japanese mode, sigh...  Anyway really appriciate for
> creating libxklavier, and I'm now trying to learn how to use it.
Well, libxklavier is just some set of handy methods over standard xkb API -
making some tasks a bit simpler. Anyway, you are welcome. If you have any
question - you can find me in IRC at #xkbconfig on freenode.

Hi Sergey,

I've noticed that correctly engraved OADG109A layout is sufficient for kana
input with IM.  Input Method can determine whether user required kana-WA or
kana-WO from it ASCII symbol 0 just checking shift modifier.  I was so stupid...
So comment #2 was wrong.  We don't need to produce asciitilde with shift+0 in
OADG109A.

So we can now use a layout correctly corresponding to engraved character in
OADG109A layout :)
Could you apply the attached patch to current CVS?

Thanks in advance,

Created attachment 7613 [details] [review]
a patch for symbols/jp to use correct OADG109A layout

(In reply to comment #8)
> Hi Sergey,
> 
> I've noticed that correctly engraved OADG109A layout is sufficient for kana
> input with IM.  Input Method can determine whether user required kana-WA or
> kana-WO from it ASCII symbol 0 just checking shift modifier.  I was so stupid...
> So comment #2 was wrong.  We don't need to produce asciitilde with shift+0 in
> OADG109A.
> 
> So we can now use a layout correctly corresponding to engraved character in
> OADG109A layout :)
> Could you apply the attached patch to current CVS?
> 
> Thanks in advance,

Hi Sergey,

I noticed that the last patch from Etsushi didn't make it into the CVS. Is there something wrong with the patch? If not, could you please apply it?

BTW: I did try this patch and was a bit confused that in the new OADG109A variant of the layout the shift+0 combination produces '0' - wouldn't it be better if this combination would just behave as 'dead' (i.e. producing nothing)?

Thanks,
-- Matt.

> I noticed that the last patch from Etsushi didn't make it into the CVS. Is
> there something wrong with the patch? If not, could you please apply it?
Sorry, I overlooked it. Applied.