YamaKen
yamak****@bp*****
2005年 2月 3日 (木) 14:53:13 JST
At Thu, 3 Feb 2005 11:49:13 +0900 (JST), handa****@m17n***** wrote: > > In article <20050****@mbox0*****>, YamaKen <yamak****@bp*****> writes: > > > 私も個人的には"<Shift>j"よりは"J"の方がわかりやすいです。あくま > > でもCaps Lock on/offに関係なく1つの表現にマッチさせるための妥協 > > 案なので、別の解決策さえあればこれにはこだわりません。 > > 僕もここんところ m17n-lib の次のバージョンでの input key の表 > 現について考えていたんですが、基本的には上記に賛成です。 結局[Anthy-dev 1718]の最後で提案したように変更しました。 > ただ modifier を key の表現に付加するかどうかについては、もっ > とシステマティックに、「その modifier の有無が KeySym に影響 > を与える場合は modifier を付加しない」という方法を使おうと思っ > ています（X Window ベースの話ですが）。 なるほど。Xの場合はその方が合理的ですね。 > つまり 'a' '[' などはshift-modifier の有無で KeySym が変わる > ので shift-modifier なしで表現、 Delete とか Return は > shift-modifier が有ろうが無かろうが KeySym は変わらないので > shift-modifier が有る時には S-Delete, S-Return になる。他の > modifier についても同様。 uimでは今のところ受け付けるキーの種類が少ない事もあって、 isgraph(3)の判定でも許容範囲だと思います。Caps Lock時と以下のよ うに一般的でないマッピングが行なわれている場合はおかしくなってし まいますが。 > 例えばあるユーザが a も <Shift>a も KeySym a にマップしている > 場合は <Shift>a は S-a が入力されたと認識され、大抵の入力メソッ > ドはそんなキーは知らないので application に戻されることになり > ます。 こういう設定をされるとシステム寄りの情報無しでは正確には扱えませ んね。 将来の話になりますが、uimでこの手の設定を行う場合は一旦物理的な キー配列への逆マッピングを行ってからもう一度uim上で柔軟に論理的 な入力に変換できるようにしたいと思っています。 ------------------------------- ヤマケン yamak****@bp*****
