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 kernel 3.16.0-4-AMD64)
デスクトップマネージャー:GNOME Shell 3.14.4
入力ペリフェラルではなくアプリケーションによってキーボードまたはマウスイベントが生成されると、そのイベントは「合成」としてマークされます。多くのアプリケーションは合成イベントを拒否します。
理論的には、そのためのセキュリティ上の理由があります。つまり、Xディスプレイで別のアカウントまたは別のマシンでアプリケーションを実行する可能性があります。ただし、Xはアプリケーションの分離が非常に悪いため(そのために設計されたことはありません)、推奨されません。信頼できないアプリケーションがディスプレイにアクセスすることをまったく許可しません。そうでない場合は、合成イベントを拒否する理由はありません。
私の知る限り、Gtkは合成イベントを許可するかどうかを決定する一般的な方法を提供していません。それは個々のアプリケーション次第であり、プログラマーが気にしない場合のデフォルトは何なのかわかりません。
XTEST拡張を使用して、入力イベントを挿入する別の方法があります。この方法で挿入されたイベントは、入力ペリフェラルからのイベントとまったく同じように見えます。事実上、これらは「テスト」入力ペリフェラルから発生します。このアプローチの欠点は、他のイベントと同じ方法でウィンドウにルーティングされるため、フォーカスがあるウィンドウに送信されることです(ウィンドウマネージャーによってインターセプトされない限り)。 XTESTイベントを(十分に最近のバージョンの)xdotoolで送信できます。これは、ウィンドウIDを渡さない場合の動作です。
xdotool windowactivate 29360262
xdotool key ctrl+a ctrl+c
はい、それは迷惑です。この問題についての議論は Selenium wiki にあります。 GTKシグナルまたはGDKイベントを介してGTK +アプリケーションに偽のイベントを送信する方法があるようですが、それがどのように機能するのかわかりません。