keyhac
keyhac copied to clipboard
crftwr
`keymap["W-S-Left"] = "W-C-A-Left"`で`W-C-A-Shift`のショートカットが発動する
FancyZonesのホットキーを変更するために、以下の設定をしました。
この状態でW-S-Leftを押すと、W-C-A-Leftは発動しますが、同時に別のアプリのグローバルなホットキーW-C-A-Shift(修飾キー全押し)も発動してしまいます（いずれもアプリ側ではホットキーが変更できません）。
恐らく、変更前のS-が、変更後も生きて居るのだと思います。
keymap["W-S-Left"] = "W-C-A-Left"
何か回避策はございませんでしょうか？
例えば、AutoHotkeyでは{Blind}をつけることで、変更元の修飾キーをキャンセルできます。
#+Left:: Send("{Blind}#^!{Left}")
先頭にU-S-をつけてキャンセルを試みましたが、W-C-A-Leftは発動せず、W-C-A-Sだけ発動してしまいました（U-は全体を修飾している？）。
keymap["W-S-Left"] = "U-S-W-C-A-Left"
@hkcomori さん、 この問題が起きるとき、"内部ログをON"にしたときに、どのようなログが出力されているでしょうか？ また、"W-C-A-S" が発動するとのことですが、これは、Win-Ctrl-Alt-(アルファベットのS) という意味でしょうか？または、Win-Ctrl-Alt-Shiftでしょうか？
@crftwr 様
内部ログは以下のとおりです。
IN : D-LShift
TRU : D-LShift
IN : D-LS-LWin
TRU : D-LS-LWin
IN : D-LS-LW-Left
OUT : [KeyDown(162), KeyDown(164), KeyUp(160), Key(37), KeyDown(160), KeyUp(162), KeyUp(164)]
IN : U-LS-LW-Left
TRU : U-LS-LW-Left
IN : O-LS-LW-Left
IN : U-LW-LShift
TRU : U-LW-LShift
IN : U-LWin
TRU : U-LWin
OUTが左から順に実行されるとすれば、 KeyDown(162), KeyDown(164) までで Win-Ctrl-Alt-Shift が押下された状況ができあがります。
言葉足らずで申し訳ございません。
アルファベットの S ではなく、修飾キーだけのショートカットキー Win-Ctrl-Alt-Shift です。
具体的にはこちらで紹介されているものです。
ありがとうございます。まずは状況が理解できました。
Keyhacは、モディファイアキーの状況を実際のものから指定されたものに変更するために、差分を見て、架空のキー押下、キーリリースを発行するのですが、キー押下の方が先に処理されるため、途中でWin-Ctrl-Alt-Shift が全て押されている状況ができているということですね。
ちなみに、キー押下を先に処理するのは、モディファイアキーが単体で押して離されたことにならないようにするためです。たとえば、Win-Left を Ctrl-Left に変換する場合、Ctrlを押す前にWinが離されると、Winキーが単体で押して離されたことになり、Start メニューが開いてしまいます。モディファイアキー単体押しが特別な意味を持つのは、WinとAltなので、ShiftやCtrlは先に離したことにしても良いかもしれません。
検討します。
ご検討ありがとうございます。 キー押下を優先している理由は理解しました。
setInput_Modifier のコードを拝見しましたが、キーリリースの前に Win と Alt の単体押しをキャンセルする処理が実装されています。
キャンセルの発動条件は、変換前後の修飾キーが以下の条件を満たすときになっています。
- Altのみ → 修飾キーなし
- Winのみ → 修飾キーなし
この発動条件を以下のように拡張すると、キーリリースを優先してもスタートメニューやメニューバーにフォーカスが移ることは無いと考えられます。
- Altのみ → Altを含まない
- Winのみ → Winを含まない
私の環境で実際に試したところ、ご指摘の問題を発生させることなく、本問題を解消できることが確認できました。
この変更内容を Pull Request させていただいてもよろしいでしょうか？