ハクソク

世界を動かす技術を、日本語で。

ウィンドウのアクティベーション

294日前原文(blog.broulik.de)

概要

Wayland環境では、アプリケーションがウィンドウを前面に表示するにはXDG Activationプロトコルが必要 XDG Activationトークンを使ったウィンドウアクティベーションの仕組み KWinの「フォーカス奪取防止」機能の違いと進化 QtやKDEアプリケーションの対応状況 今後の課題と改善点

Waylandとウィンドウアクティベーションの仕組み

  • Wayland では、アプリケーションが勝手にウィンドウを前面に出すことができない設計
  • ウィンドウを前面に表示するには XDG Activationプロトコル の利用が必須
  • アプリケーションは自らフォーカスを奪うことはできず、 フォーカスを受け取る ことのみ可能
  • 例：チャットアプリがリンクを開く場合
    • XDG Activationトークン をコンポジタから取得
    • システムにURLを開くよう依頼し、トークンを渡す
    • ブラウザはこのトークンを使いウィンドウをアクティベート

XDG Activationトークンの詳細

  • トークンは 単なる文字列 で、アプリ間で自由に受け渡し可能
  • 新規アプリ起動時は XDG_ACTIVATION_TOKEN 環境変数として渡される
  • 既存アプリの場合は、 activation-tokenプロパティ がDBus経由で送信
  • 古いプロトコル（通知、トレイアイコン、PolKit等）は既存仕様を変更できないため、呼び出し直前にトークンを設定する仕組みを追加

トークンの有無とコンポジタの制御

  • トークンがあっても 必ずウィンドウを前面にできるわけではない
  • コンポジタはトークンを 無効化 したり、アクティベーション要求を 拒否 可能
  • リクエストには、ウィンドウ、入力イベントのシリアル、アプリIDなどの情報を添付可能
  • 情報が不十分・不一致の場合は、アクティベーションが拒否される可能性が高い

Qt・KDEアプリケーションの対応状況

  • QtやKDE Frameworks など多くのツールキット・アプリは既に対応済み
  • 例：QWindowのrequestActivateはトークンがあれば利用し、なければ新たに取得
  • ApplicationLauncherJobやOpenUrlJobも自動でトークンを取得してから処理を進行
  • KDBusServiceはDBus経由でトークン受信時、自動で環境変数を設定

KWinのフォーカス奪取防止とその進化

  • KWin-X11には focus stealing prevention （フォーカス奪取防止）機能あり
  • _NET_WM_USER_TIMEを利用した複雑なヒューリスティクスで制御
  • X11ではアプリがXSetInputFocusを使い、KWinが後から検知・修正するため、一瞬だけでもフォーカスが変わる場合あり
  • Waylandではより厳密に制御可能

XDG Activation未対応の課題と改善

  • 一部アプリやツールが XDG Activation未対応 のまま
  • XではforceActiveWindowでごまかせたが、Waylandでは正しく修正が必要
  • KWinの「Extreme」レベルのフォーカス奪取防止設定でテスト推奨
  • 最近の修正例
    • Dolphinが新規インスタンス起動時にトークンを破棄していた問題修正
    • KRunner、KickoffなどのPlasmoidポップアップがアクティベーション要求しなかった問題修正
    • LayerShell-Qtのshow時にアクティベーション要求追加
    • PlasmaやKGlobalAccelなど特権クライアントのトークン取得問題修正
    • 修飾キーのみの押下はフォーカス奪取防止の判定対象外に変更

DBusRunner仕様の改善と今後の展望

  • DBusRunner仕様 にSetActivationTokenメソッドを追加、Run直前に呼び出し
  • BalooやKClockランナーが既存ウィンドウを正しく前面表示可能に
  • recent documents runnerやplaces runnerもOpenUrlJobにファイルタイプを渡すよう改善
  • KRunnerでの完全な解決にはさらなる対応が必要
  • 今後はKWinのフォーカス奪取防止をWaylandで標準有効化し、アプリ側の修正進捗に応じて厳格化予定

Hackerたちの意見

このメカニズム、めっちゃ価値ありそうだね。X11でチャットメッセージを打ってると、他のプログラムからのポップアップが出てきて、うっかりスペースキーを押しちゃって確認ボタンを押しちゃうことが多いんだよね。ポップアップが何だったのかもわからないし。パスワードがポップアップに打ち込まれることもあるし。昔、自分のためにi3にコードをパッチしたことがあるけど、あんまりきれいな解決策じゃなかったな。

└

KDE: 設定 → ウィンドウ管理 → ウィンドウの動作 → フォーカス → フォーカス奪取防止。「低」にしても（選択肢はなし、低、中、高、極端）この挙動は見えないな。i3の問題かもしれない。

└

へぇ、俺もi3使ってるけど、その問題には遭遇したことないな。もしどのプログラムがフォーカスを奪い始めたら、即アンインストールして、作者やベンダーに文句言うけど。

機能的で便利なセミヘッドレスUI自動化テストをいろんなLinuxディストリビューションで維持するのって、ほんとにマゾい自己虐待だと思う。理解するのもやっとだわ。

└

UI自動化があったら、たぶんDEレベルでやるだろうし、X11をWaylandに変えるなんてことはしないと思うよ。更新しなかったり、XFCEみたいなのを使ってたら、数十年はそのまま使えるんじゃないかな。

最近Linux（とWayland）に切り替えたばかりだけど、この挙動が大好き！macOSがランダムな自動アップデーターにフォーカスを奪われて、作業中にキーストロークを食われるのは、いつも狂ってると思ってた。

└

強力なアプリには強力な権限が必要だよね。この特定の問題についてはわからないけど、例えばKiCADはWaylandが過保護すぎるせいでいくつか問題があるんだ。[0] 例えば、KiCADは良いユーザー体験を提供するためにカーソルを動かす能力が必要だし、ウィンドウを好きなところに移動させたり配置したりする必要もある。フォーカスを制御する必要もあるし、非アクティブなウィンドウでOpenGLのスロットリングを防ぐ必要もある。これらの問題から、KiCADの開発者たちはWaylandのサポートを最低限に減らすことになったんだ。だから、オペレーティングシステムは強力なアプリが複雑なUIを実装できるようにしつつ、悪く書かれたアプリが不便なことをしないようにするのが難しいバランスなんだよね。[0]: https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support...

└

macOSとWindowsがどちらもランダムな自動アップデーターにフォーカスを奪われて、作業中にキーストロークを食われるのは、いつも狂ってると思ってた。え、何？Windowsはもう何十年も前からフォーカス奪取を防いでなかったっけ？ https://devblogs.microsoft.com/oldnewthing/20090220-00/?p=19...

└

どうやらmacOS 14（Sonoma、2023年後半）で「協調アプリアクティベーション」が改善されたらしいよ。これについてはWWDC 2023のこの動画で話されてるよね。

└

そうそう。昔はMacbook Proを日常的に使ってて、League of Legendsをプレイしてたけど、強制的にフォーカスが移るのが本当にイライラした。友達とDiscordで何かメッセージしてるのに、ゲームが始まるまであと10秒しかないから、Leagueのクライアントにフォーカスを合わせなきゃいけないんだよね。

└

MacOSの仕事用ノートパソコンで、約10個の承認または拒否をしたけど、何だったか全然覚えてない。文を打ってる最中にダイアログが出て、スペースバーを押しちゃったんだ。重要なやつじゃないといいけど！

└

何かにフォーカスが取られるだけなら、まだまあまあ大丈夫かな。最悪なのは、他のアプリからフォルダを開いたときに何も起こらなくて、デスクトップが全然Finderに切り替わらないこと。手動で切り替えた後に、10個のウィンドウが一斉に開くとかね。

└

Windowsはこれに関してはMacよりもひどかったよね。

そもそも、アプリケーションがフォーカスを奪うのを許可するのがいいアイデアだと思ってた人が歴史的に誰なのか理解できない。フォーカスを切り替えるのはウィンドウマネージャーの決定であって、ユーザーが決めたときだけ切り替えるべきだよ。

└

まあ、ユーザーがフォーカスが移動することを期待する場合もあるよね。例えば、あるアプリでリンクをクリックしたときに、バックグラウンドのブラウザが新しいタブを開くときにフォーカスが移るべきだっていうのがその例。だけど、ユーザーが予期しないときにフォーカスを奪うアプリもあって、それが問題なんだよね。

└

KDEにはこれを制御するKWinの設定があるよ。これが後からの修正なのか、ウィンドウマネージャーが常にこれを制御してるのかは分からないけど、少なくともKDEのX11セッションではそうなってる。

└

それが悪いと思うなら、昔、みんなが共通のUnixサーバーからX端末を使ってたオフィスでは、DISPLAY環境変数を変えるだけで他の人の画面にウィンドウを開けたんだ。楽しいいたずらが結構あったよ。

開発者のコメントがある以前の議論 https://news.ycombinator.com/item?id=44784312

記事をクリックしたのは、ぼやけた目で「Windows Activation」って読んだからで、「え、Windowsのアクティベーションって何が面白いの？」って思ったんだ。最初の段落を読んでもすごく混乱した。もう一度読んでも同じだったけど、タイトルを見たら「ああ、ウィンドウのアクティベーションのことを話してるんだ」と気づいた。

└

私も、キー管理のリバースエンジニアリングについて深く掘り下げる内容を期待してたよ。笑

└

気にしないで -- 他のフロントページのストーリー「超薄型名刺が流体シミュレーションを実行」って見た時、実は「流体シミュレーションをRUINS」って読んじゃったんだ。

└

ウィンドウ管理に関する会議があったんだよ！「ウィンドウ管理の方法論」っていうのがあって、1985年4月29日から5月1日までのAlvey Workshopの議事録だよ。これがAlveyプログラムのMMI部分の計画に入力されたんだ。議事録は1986年にSpringer-Verlagから出版された。私のお気に入りの章は、「ウィンドウシステムの10年 - 回顧的視点」っていうWarren Teitelmanのやつだよ。

└

ハハ、まさにその理由でここにいるよ。眼鏡が必要なんだ。

└

同じ。

└

もしそれが探してた話題なら、「デイブのガレージ」ってエピソードがいいかも。引退したマイクロソフトのエンジニアが、Windowsのアクティベーションについて話してるよ。 https://www.youtube.com/watch?v=FpKNFCFABp0

└

俺も全く同じこと思った。

いいアイデアだけど、今は結構辛いね。まだこのプロトコルを使ってないものが多いみたいで、例えばパスワード入力中に他のウィンドウの下に隠れちゃったりすることがよくある。時間が経てば少し改善されることを願ってるけど、Waylandの最後の痛みの一つだね。

ちょっと待って。これって本当に解決が必要な問題なの？Waylandがここでめちゃくちゃなことをしてる気がする。アプリにウィンドウを制御させればいいじゃん。最後にアプリがフォーカスを奪ったのはいつだったか覚えてないよ。パスワードを入力する時だけは意味があるけど、それは特定のケースで、パスワードダイアログを保護されたデスクトップ（そのウィンドウだけの）に表示させれば解決できるし。

└

アプリがフォーカスを奪ったのはいつだったか思い出せない。自動アップデーターがついてるアプリを使ってないんだね。アップデーターがポップアップするときにフォーカスを奪って、ゲームを最小化しちゃうし、アップデートしたメインアプリを再起動するときにもまた最小化される。開発者はユーザーを殺意に駆り立てないとは信じられない。誰かが彼らを止めないと、自分たちのためにもならないよ。

まあ、今はもう知ってると思うけど、WaylandはXとは違って、一つのアプリが他のアプリに無理やり自分の意見を押し付けることはできないんだよね。…X11ではこれを管理するのはウィンドウマネージャーの仕事じゃないの？（kwinは俺のX11セッションではこれを許可してないし…）それとも「協力的じゃない」アプリについての議論なの？

俺の超高性能ゲーミングコンソール（WindowsデスクトップPC）で、競技ゲームの真っ最中にランダムな自動アップデーターがポップアップして、フルスクリーンのアプリが最小化されると本当にイライラする。しかも、30秒後にまた同じことが起きて、アップデート後にアプリが立ち上がるとか（なんで？前は開いてなかったのに！）。これが2つの億ドル企業のQAを通過したってのが信じられないし、どっちも何も対策しなかった。ソフトウェアの品質が劣化してるのはこれだけじゃないし、言う価値もないよ。汚水の海の中の一滴の尿みたいなもんだ。せめて実際のコンピュータでは、仕事に集中できるから良かった。多分、そこで動いてるソフトウェアのほとんどがユーザーによって設計されて、実力で生き残ってるからだろうね。企業の委員会が他のことに気を取られてるよりはマシ。