`xdotool`はキーを送信しません

を介してキーストロークを送信しようとしていますxdotool。ただし、送信は正常に機能しません。

以下は、Geditですべてのテキストを選択してコピーする（ただし、代わりに何もしない）スクリプトのログとその出力（stdoutとstderrの両方をリダイレクトすることによってキャプチャされた）です。

+ xdotool getwindowname 29360262
*Unsaved Document 1 - gedit
+ xdotool key --window 29360262 ctrl+a
+ sleep 1
+ xdotool key --window 29360262 ctrl+c
+ sleep 1

私はThunderbirdで試しましたが、スクリプトはキーを送信しますが、修飾子Controlはありません（いいえ、つまり）。ちなみに、スクリプトでは、キーはの"ようにで囲まれています"ctrl+a"。

GeditとThunderbirdの違いは、GeditがGTK3アプリケーションであるのに対し、ThunderbirdはGTK2アプリケーションのようです（ただし、Firefox（GTK3アプリケーションのように見える）はThunderbirdのように動作します）。

xdotoolバージョン3.20141006.1
オペレーティングシステム：Debian GNU / Linux 8.1（Linuxカーネル3.16.0-4-amd64）
デスクトップマネージャー：GNOME Shell 3.14.4

入力ペリフェラルではなくアプリケーションによってキーボードまたはマウスイベントが生成されると、そのイベントは「合成」としてマークされます。多くのアプリケーションは合成イベントを拒否します。

理論的には、それにはセキュリティ上の理由があります。アプリケーションをXディスプレイで実行しても、別のアカウントまたは別のマシンで実行する可能性があります。信頼できないアプリケーションがディスプレイにアクセスすることをまったく許可しません。そうでない場合は、合成イベントを拒否する理由はありません。

私の知る限り、Gtkは合成イベントを許可するかどうかを決定する一般的な方法を提供していません。それは個々のアプリケーション次第であり、プログラマーが気にしない場合のデフォルトは何なのかわかりません。

XTEST拡張を使用して、入力イベントを挿入する別の方法があります。この方法で挿入されたイベントは、入力ペリフェラルからのイベントとまったく同じように見えます。事実上、これらは「テスト」入力ペリフェラルから発生します。このアプローチの欠点は、他のイベントと同じ方法でウィンドウにルーティングされるため、フォーカスがあるウィンドウに送信されることです（ウィンドウマネージャーによってインターセプトされない限り）。（十分に最近のバージョンの）xdotoolを使用してXTESTイベントを送信できます。これは、ウィンドウIDを渡さない場合の動作です。

xdotool windowactivate 29360262
xdotool key ctrl+a ctrl+c

はい、それは迷惑です。この問題についての議論はSelenium wikiにあります。GTKシグナルまたはGDKイベントを介してGTK +アプリケーションに偽のイベントを送信する方法があるようですが、それがどのように機能するのかわかりません。