Etsushi Kato
ekato****@ees*****
2005年 2月 2日 (水) 14:04:10 JST
加藤です。いちおう前の話題にコメントです。 On 2005/01/30, at 5:41, YamaKen wrote: > Caps Lockなしの場合で言うと、加藤さん案では<Shift>jというユーザ > 入力が"J"、<Control><Shift>jが"<Control><Shift>j"としてユーザに > 見える事になり、<Shift>jの表現が<Control>のあるなしで変化する事 > になります。これを指して一貫性が無いと表現しました。 そうですね。一貫性はありません。 ただし、たぶん、これはぼくの独特の感じ方だと思いますが、modifier として Shift key だけを押す場合は、そのままでは出せない ascii char (大文字や、! とか #とか) を出すための手段だと思っているので、 他の modifier とは違うように認識していて違和感は無いです。このため 逆に大文字のキーなのに、表記に <Shift> が付いていると違和感を感じて しまいます。 >>> 上記の"l"の例はskkでは起こり得ないシチュエーションですが、anthy >>> でskk風モード遷移を使っている場合にはCaps Lockしたまま操作する場 >>> 合に発生します。 >> >> 確かにこの場合は (アルファベットキーのみで case を無視した挙動が欲し >> い場合)、l の case を区別すると問題になりますね。ユーザに明示的に、"L" >> も追加してもらうという方法になるでしょうか。 > > uim-pref上で"L"を登録するためには、最初に"<Shift>L"をキャプチャー > してから<Shift>のチェックを外すという操作、もしくはCaps Lock on > 状態で"L"を入力する事が必要になります。 > > はたしてこれらの表記の違いと意味をユーザに理解させる事が可能だろ > うか、というのが今回の提案のそもそもの動機になっています。 これは、uim-pref の方で、shift-mask のみの文字キーのときは、 shift_toggle を gtk_toggle_button_set_active しないことによって 回避することをぼくは意図していました。 > 私の結論は「無理」です。なので、ユーザが押した通りのキーをキャプ > チャーするだけで登録が可能で、かつ表記が一貫している必要があると > 考えました。 そうですか? 上で書いたように、gtk_toggle_button_set_active のしかた 次第で加藤案でもキーのキャプチャーだけで意図どおりに登録できるように思います。 >>> ・アルファベットキーはuim-pref上では常に *小文字* で表す >>> ・アルファベットキーに対する<Shift>の暗黙無視を行わない >>> ・アルファベットキーに対しては大文字・小文字を無視する > >>> "L" → "<Shift>l" >>> "l" → "l" >>> <Control>j,<Control>J → <Control>j >>> <Shift>space → <Shift>space >> >> 小文字であれば大丈夫です。 別のメールで問題にしましたが、"<" のキーが、現在 uim-pref 上で、 "<Shift><" となっているのは、この説明と食い違っているように感じます。 "<" はアルファベットキーではありません。また、今使っているキーボードには、 "<" というキーは存在しないので、uim-pref 上に表示されている "<Shift><" って何? と一瞬不思議に感じました。 もし、ヤマケンさんの本来の案で行くと、このキーは、uim-pref 上で、"<" と表示されないとおかしいと思います。しかし、この場合、ユーザがこのキーを GUI で登録しようとすると、uim-pref 上では、shift_toggle が on になって 一貫性が逆になくなってしまいます。 このあたりの混乱を避けるためにも、ascii character だけのキーの場合は shift mask が当っても無くてもそのまま (case を区別したり、"<" は "<" のまま) 表示したほうが良いような気がもう一度してきましたが、どうでしょうか? -- Etsushi Kato ekato****@ees*****
