yamabuki4.2.0.zip
・メニューにフォーカスが当たっていると判別できるものについては、そのときに文字キーのキーの入れ替えをしないようにしました
判別は完璧でなくFirefoxなど判別できないアプリもあるのですが、多くのアプリで判別可能となったので搭載してみました。
・仮想キーコード直接指定にモディファイアを付加できるようにしました
私としては出来るつもりでしたが出来るようになってなかったので搭載しました。
・XP＋ATOKで英数文字を入力しようとするとフリーズする不具合を修正しました
この修正により、Google日本語入力に対してはvista以降でも、設定ダイアログの「動作モード」タブの「IMEへのアクセスに使うAPIの種類」をTSFに設定することが必須となりました。Google日本語入力をお使いの方は注意してください。
MS-IME、Google日本語入力、ATOKではテストしましたが、それ以外のIMEでは不具合が出てしまうかもしれません。
・文字キー前置シフトが使えない不具合を修正しました
・シフトロジックの細部調整をしました
快適です。ありがとうございました。
ただ、以前修正済みの不具合が再発しています。
過去Ver.4.0.0のときに指摘したことがあり、
Ver.4.1.0で、「文字キー同時打鍵シフトで、シフトとして消費されたキーはキーリピートしない」というふうに直してもらった症状です。
詳細については、当時の書き込みを下に引用しました。
この現象は、Ver.4.2.0プラス
WinXP＋（ワード or Win付属メモ帳）
の環境で発生し、
Win7＋（ワード or Win付属メモ帳）
で発生しません。
発生する頻度は三度に一度ぐらいです。
確認してみてください。
＞[A]キー単独打鍵に「あ」が、[B]単独打鍵に「い」が割り振ってあり、
＞[A][B]同時打鍵にカーソルの「下」が定義されていたとします。
＞1. [A][B]を同時に押す。（「下」が出力される）
＞2. もう一行下まで行こうかな…と考えて、[B]だけを離し、[A]を押したまま保留する。
＞→この状態で１秒ぐらい経過すると、「あああああ…」がリピートで出てきてしまいます。
＞しかし、
＞1. [A][B]を同時に押す。（「下」が出力される）
＞2. [A]を押したまま、[B]をいったん離してもう一度押し直す。（再び「下」がひとつ出力される）
＞3. もう一行下まで行こうかな…と考えて、[B]だけを離し、[A]を押したまま保留する。
＞→この状態ではいくら待ってもキーリピートは始まらず、次に[B]を押したときに三つめの「下」が出力されます。
これ以外は正常に動いているようです。
ご報告の不具合はこの形でしょうか？
よーく調べてみたら、「どうやら外付けキーボードのせいらしい」ことが分かりました。
今まで使っていた安物のUSBキーボードを普通のPS/2キーボードに変えたら、報告したような現象が見られなくなりました。
というわけでどうかお気になさらぬよう…お騒がせしました。
了解しました。
たとえば、文字キー同時打鍵で「文字キー同士が同時打鍵と判定される時間範囲」を90として、[D]押下、[K]押下、[D]離す、[K]離すという順番で入力したとします。
この場合、[D]に対して[K]のシフトが掛かるかどうかは、[D]押下を0、[D]離すを100として、[K]押下が90以内かどうかで判定をしていると思います。
では、親指シフトの連続シフトで「親指シフトが同時打鍵と判定される時間範囲」を90として、[K]押下、[変換]押下、[J]押下、[K]離す、[変換]離す、[J]離すという順番で入力したとします。
この場合は、[J]に対して[変換]のシフトが掛かるかどうかは、どこを0、どこを100として、どこが90以内かどうかで判定しているのでしょうか？
文字キー同士同時打鍵と、親指連続シフトとでは、(仮に実装上の差異はあっても)同じ「考え方」で処理しているのではないかと想像しているのですが、実際の挙動についてお尋ねしたいと考えていました。
【私が想像している前提】
[K]押下、[K]離す……は、[J]と[変換]の打鍵シーケンスに影響を与える要素ではないので、ここでは無視。
そのため、(文字キー同士同時打鍵と同じ考え方で)[変換]押下、[J]押下、[変換]離す、[J]離す……というシーケンスで見る。
【私が想像している動作】
[変換]押下を0、[変換]離すを100としたときに、[J]押下が90を超えていればシフト残りが起きたと見なして、シフトを「掛けない」([J]押下が90未満であれば、シフトを掛ける)……という判定をするものと、私は想像しています。
そして、これと全く同じ考え方で、文字キー同士同時打鍵についても、「シフト残り」を検知してる。
こういう認識であっているのかと、正直ドキドキものではありますが……正解についてお教えいただけますと嬉しいです。
p.s.ただいま「やまぶき」の「シフト残り対策付き連続シフト」を使って、NICOLAが使えるか？実験への参加者を募っているところです。今のところテストいただいた4人中、4人全員の親指シフトユーザさんから「大丈夫っぽい」という反応をいただいてます。いいロジックは、配列の壁をも超える……という、そういう時代が来るのかもしれませんね。
親指シフトについては、先に押されたのが文字キーか親指シフトキーかによって少し違っています。
先に押されたのが文字キー（[K]押下、[変換]押下、[K]離す、[変換]離す）のときは、「[K]押下」を0、「[K]離す」を100として、「[変換]押下」が前にくっつくか後にくっつくかを判定します。
「くっつく」という考え方はちょっと奇妙ですが、要は、同時打鍵時間範囲が90なら、「[変換]押下」が90以内（前にくっつく）のときはシフトが掛かり、90以上（後にくっつく）のときはシフトが掛かからないということです。
先に押されたのが親指シフトキー（[変換]押下、[K]押下、[変換]離す、[K]離す）のときは、まず「[変換]押下」、「[K]押下」、「[変換]離す」の３点で判定し、「[K]押下」が前に付くならシフトが掛かったとみなし、後に付くなら、さらに「[K]押下」、「[変換]離す」、「[K]離す」の３点で判定して、「[変換]離す」が前に付くならシフトが掛からず、後に付くならシフトが掛かるという結果になります。
このように、先に押されたのが親指シフトキーのときは、２段階で判定しています。
今では２段階判定していますが、もともと（バージョン2時代）は後者だけでした。
文字キーと親指シフトキーでは文字キーの方が主なので、「文字キーの打鍵に対してどのシフトが掛かっているかを時間判定する」という言葉を素直に実装すると、後者の「[K]押下」、「[変換]離す」、「[K]離す」の３点で判定するということになります。
しかし、実際打ってみるとシフトミスし易かったので、前者も加えることになりました。
親指シフトキーと文字キーを同時に押したら、それはシフトが掛かったとしてよいだろうという判断です。
以上を踏まえて、「[K]押下、[変換]押下、[J]押下、[K]離す、[変換]離す、[J]離す」という打鍵列について解説すると、まず、「[K]押下」、「[変換]押下」、「[J]押下」の３点で判定し、「[変換]押下」がどちらに付くかを判定することになります。
「[変換]押下」が前に付くときは、[K]にシフトが掛かり、[J]については連続シフト判定（「[J]押下」、「[変換]離す」、「[J]離す」の３点で判定）扱いになります。
後に付くときは、[K]にシフトが掛からず、以下「[変換]押下、[J]押下、[変換]離す、[J]離す」のような親指シフトキーを先に押した状態とみなされ、まず「[変換]押下」、「[J]押下」、「[変換]離す」の３点で判定し、シフトが掛からないなら、さらに「[J]押下」、「[変換]離す」、「[J]離す」の３点で判定するという流れになります。
NICOLAと連続シフトについては、おくまさん（http://okuma-room.cocolog-nifty.com/okuma/2010/01/340-2e2d.html）のようにシフトミスするからいらないという方もいらっしゃるようです。連続シフトに起因するシフトミスは、いろいろな対策で減らすことはできても０にはできませんから。
結局は使う人がトレードオフをどう価値判断するか――連続シフトを取ってシフトミスを我慢するか、連続シフトに起因するシフトミスが無いことを取って連続シフトを捨てるか、という話になるのだと思います。
双方に利点がある以上、自分が使いやすい方を選べる状況が最高なのかなと思います。
シフトといえば、普通の小指シフトの挙動も「キーダウン時に文字が出る」という利点があるので、選択肢として有りだと思います。
同時打鍵シフトは文字が出が遅延しますから、それが許せない人は普通の小指シフトの挙動でシフトを掛けるしか無いでしょう。
前置シフトも、打鍵数が増えますが「シフトミスが一切無い」という利点があります。
すべて、トレードオフをどう価値判断するかにかかっている気がします。
3点だけで判定していると解釈するとどうも納得できない挙動をすることがある気がしていたのですが、やっぱり工夫があったんですね。