YamaKen
yamak****@bp*****
2005年 2月 3日 (木) 02:51:43 JST
ヤマケンです。ちょっと考えてみました。 At Wed, 2 Feb 2005 14:04:10 +0900, ekato****@ees***** wrote: > 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> が付いていると違和感を感じて > しまいます。 私も個人的には"<Shift>j"よりは"J"の方がわかりやすいです。あくま でもCaps Lock on/offに関係なく1つの表現にマッチさせるための妥協 案なので、別の解決策さえあればこれにはこだわりません。 > > uim-pref上で"L"を登録するためには、最初に"<Shift>L"をキャプチャー > > してから<Shift>のチェックを外すという操作、もしくはCaps Lock on > > 状態で"L"を入力する事が必要になります。 > > > > はたしてこれらの表記の違いと意味をユーザに理解させる事が可能だろ > > うか、というのが今回の提案のそもそもの動機になっています。 > > これは、uim-pref の方で、shift-mask のみの文字キーのときは、 > shift_toggle を 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 になって > 一貫性が逆になくなってしまいます。 正直に言うと、アルファベット以外の記号の事について失念していまし た。skk.scmからキー定義をcustomに移植する段になってようやく気付 きましたが、私もこれはユーザを困惑させるだろうと思います。 > このあたりの混乱を避けるためにも、ascii character だけのキーの場合は > shift mask が当っても無くてもそのまま (case を区別したり、"<" は "<" のまま) > 表示したほうが良いような気がもう一度してきましたが、どうでしょうか? 加藤さんの言うようにcapture時に<Shift>を削除するという事を前提に もう一度考え直してみました。以下のようなルールではどうでしょう。 以下の要求を満たすため、 ・Caps Lockのon/offにかかわらずマッチする単一の表現を実現する (define-keyの<Control>j,<Control>J方式の廃止) ・<Control>等のmodifierのありなしにかかわらずアルファベットキー の表現を一貫させる 次のようなルールでキー表現を扱います。 ・アルファベットキーはuim-pref上で大文字・小文字を区別する ・アルファベット及び記号類(isgraph(3)な文字)キーに対する<Shift> は常に暗黙に無視する ・アルファベット及び記号類をuim-prefでcaptureした時は他の modifierの状態と無関係に常に<Shift>modifierを削除する 実際の組み合わせは以下のようになります。 uim-pref上の表記 : マッチする入力 : マッチしない入力 : Caps Lock j : j : <Shift>J : off : J : <Shift>j : on J : <Shift>J : j : off : <Shift>j : J : on <Control>j : <Control>j : <Control><Shift>J : off : <Control>J : <Control><Shift>j : on <Control>J : <Control><Shift>J : <Control>j : off : <Control><Shift>j : <Control>J : on % : <Shift>% : : off : <Shift>% : : on <Control>% : <Control><Shift>% : : off : <Control><Shift>% : : on space : space : <Shift>space : any <Shift>space : <Shift>space : space : any <Control>space : <Control>space : <Control><Shift>space : any <Control><Shift>space : <Control><Shift>space : <Control>space : any これを見てわかる通り、Caps Lockがonの時には実際に入力される大文 字/小文字とは逆の表現にマッチします。しかし、それ以外の場合につ いては一貫性の問題は発生しません。 Caps Lock時の挙動については以下のように考えています。 ・普通のユーザは <Control><Shift>j のように<Shift>付きの操作は登 録せず<Control>jや<Alt>jを使う事が多いだろう ・<Shift>を使うようなユーザに対しては「ちょっと特殊な挙動」とし て解説する事で勘弁してもらえるのではないか この仕様で良ければcustom.scm及びuim-pref-gtkをそのように変更して おきます。 そうなった場合はuim-pref-qtの追従をお願いします >kzkさん ------------------------------- ヤマケン yamak****@bp*****
