Etsushi Kato
ekato****@ees*****
2005年 2月 3日 (木) 11:23:20 JST
On Thu, Feb 03, 2005 at 02:51:43AM +0900, YamaKen <yamak****@bp*****> wrote: > > このあたりの混乱を避けるためにも、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を削除する いいですね。 こちらも言葉が厳密ではありませんでしたが、ascii character だけ、という のはまちがいで、isprint() で sp 以外の文字を意図していました。これを isgraph() というのは知りませんでした。また、加藤案だと、Control と Shift の両方が押されたときの記号類の表現で混乱する可能性があるので、こ ちらのほうが良いですね。 あと、これに関連して混乱の元は、uim-pref のキー取得に関する GUI がいま いちな点にあるように思います。 つまり、キーの capture において uim によって必要な情報、(keysym name と 必要な modifier state) が得られれば良いのであって、ユーザが、 modifier のボタンをクリックして変更できる必要性はまったくありません。 一見使いやすように見えて、混乱を招いているのではないでしょうか。 Modifier の情報をボタンにするのではなく、実際に treeview に表示される 情報 "<Control>a" などを、gtk_entry にそのまま表示するので十分だと思い ます。これを直さないと、ユーザが "a" を gtk_entry においてキャプチャー して、そのあと、Shift をトグルする、ということが起きてしまいます。それ を add した場合どうなりますか。新しい表現だと、これは、"A" になるべき で、ユーザとして混乱します。 > Caps Lock時の挙動については以下のように考えています。 > > ・普通のユーザは <Control><Shift>j のように<Shift>付きの操作は登 > 録せず<Control>jや<Alt>jを使う事が多いだろう > > ・<Shift>を使うようなユーザに対しては「ちょっと特殊な挙動」とし > て解説する事で勘弁してもらえるのではないか > > この仕様で良ければcustom.scm及びuim-pref-gtkをそのように変更して > おきます。 > > そうなった場合はuim-pref-qtの追従をお願いします >kzkさん 他の人の異論が無ければ良いと思います。 -- Etsushi Kato ekato****@ees*****
