7

処理のためにすべてのウィンドウマネージャーコマンド（Alt + F4など）をキャプチャするために、フォーカスされたときにキーボードをつかむことが望ましいアプリケーションを考えてみます。さて、これには、キーボードをつかんだときにユーザーがキーボードを介して別のアプリケーションや仮想デスクトップに切り替える方法がないという欠点があります。グラブから除外されるキーの組み合わせ（たとえば、仮想デスクトップを切り替えるためのキーの組み合わせ）のユーザー定義のホワイトリストが欲しいのですが。

私は2つの可能なアプローチを考えることができます。ホワイトリストに登録されたキーイベントが到着すると、

  1. どういうわけか、Xに通常どおり処理を続行するように指示します。これはより自然な方法のように聞こえますが、これを行う方法が見つかりません、または
  2. キーボードのグラブを解除し、イベントを手動でウィンドウマネージャーに再送信して処理しますが、送信先（ルートウィンドウ？）や、それでも機能するかどうかはわかりません。

誰かがそれらの空白を埋めることができますか？他に何か提案はありますか？

グラブからキーを除外する方法がない場合は、押されたときにキーボードをアングラブする「エスケープキー」を用意する必要があると思います。ただし、ユーザーはそれとウィンドウマネージャーコマンドの両方を押す必要がありますが、これはそれほど良いことではありません。

4

1 に答える 1

4

私はそれをする方法がないと思います。どのメカニズムも、必要な方法で完全に機能するわけではありません。

アプローチ1は、たとえばクリックやキーをインターセプトしないことを決定した場合にウィンドウマネージャーが行うことの一種です。ただし、WMは、特定のキー（XGrabKey=パッシブXGrabKeyboard= active）で「パッシブ」グラブを使用してから、XAllowEvents（）を使用しています。XAllowEvents（）はXGrabKeyboard（）では機能しません。また、リプレイモードの1つでXAllowEventsを実行すると、リプレイされたイベントは、元のグラブがあったウィンドウとそのすべての親ウィンドウのすべてのパッシブグラブをバイパスします。WMのグラブは常に親になるルートウィンドウ上にあるため、ルートウィンドウを再生する方法はありません。考えられるすべてのキーに対してXGrabKeyを実行することは、とにかく一種の心理的です。

アプローチ2では、再送信する前に他のキーとマウスのイベントが処理される可能性があるため、競合状態の問題が発生します。そのため、キーを並べ替えて、破壊されたウィンドウやその他の混乱にイベントを送信します。また、重要なイベントを送信する良い方法はありません。XSendEvent（）は、多くのクライアントによって無視されます（これを許可するイベントにsend_eventフラグを設定します）。XTest拡張機能を使用できますが、実稼働Xサーバーでは無効になっている可能性があり、それでも競合状態の問題があります。

おそらく必要になるのは、GrabKeyboardの後で、親ウィンドウのパッシブグラブをバイパスせずにAllowEvents（mode = ReplayKeyboard）を実行できるようにするプロトコル拡張です。

1つの注意点は、XKBとXInput2で実行できるすべてのワイルドなことを私が知らないということです。したがって、これらの拡張機能に何かがあるかもしれません。

とにかく、私が知る限り、「エスケープキー」を受け入れる必要がありますが、最終的にはXサーバーやウィンドウマネージャーの仕様に「VMWare/VNCタイプのものの認識」があると便利かもしれません。短期的には役に立ちません。EWMH仕様の拡張は、vnc / vmware / stuff-likeの新しい_NET_WM_WINDOW_TYPEのように単純であり、ウィンドウマネージャーは、キーバインディングを減らしたり、ウィンドウがフォーカスされたときにキーバインディングなどに追加の修飾子を追加したりできます。

于 2010-09-26T04:47:21.703 に答える