フォーカス (GUI)

索引トップ用語の索引ランキングカテゴリー

出典: フリー百科事典『ウィキペディア（Wikipedia）』 (2022/08/05 15:51 UTC 版)

この概念は、テキスト環境でのカーソルに似ている。しかし、GUIでは同時にマウスカーソルも関係してくる。マウスを動かすとマウスカーソルも動くが、フォーカスは変化しない。フォーカスは通常、マウスボタンのクリックでフォーカスを付与するコンポーネントを指定することで変更する。多くのデスクトップ環境では、キーボードからもフォーカスを変更できる。一般に「タブ」キーを押す毎に順次フォーカスを付与されるコンポーネントが変わっていき、⇧ Shift+⭾ Tabで逆順に変化していく。状況によっては、矢印キーでフォーカスを動かす場合もある。

ウィンドウフォーカス

デスクトップでのフォーカスの振る舞いは、ウィンドウ管理のポリシーが支配している。マイクロソフトやAppleのGUIでは、クリックに追随してフォーカスが移動するFFC^[1]である。すなわち、あるウィンドウ内でマウスをクリックすると、そのウィンドウがフォーカスを得る。その際に同時にそのウィンドウが最前面に表示される。

UNIXの X Window System では、マウスの移動に追随してフォーカスが移動するFFM^[2]というポリシーもある。すなわち、マウスカーソルの現在位置に従ってフォーカスがウィンドウからウィンドウへ移動する。このポリシーの当然の帰結として、マウスカーソルの下が背景であってどのウィンドウの上でもない場合、どのウィンドウにもフォーカスがない状態になる。そこで、マウスカーソルがどのウィンドウ上でもない場所に移動したときは、直前までフォーカスを持っていたウィンドウが引き続きフォーカスを保持するというポリシー（英: sloppy focus）もある。なお上述のとおり、マイクロソフトのGUIは通常FFCポリシー動作だが、Windows 10ではコントロールパネルでの設定によりFFMポリシーで動作させることも可能になっている。

どのポリシーがよいかは議論の分かれるところである。FFMの場合、マウスに何かが当たるなどしてマウスカーソルが意図せずに移動したとき、知らないうちにフォーカスも移動するという状況があり、初心者が戸惑うことがある。しかし、慣れてくると便利であり、特にフォーカスを得たウィンドウを最前面にしないポリシーと組み合わせると、様々な制御が可能になる。例えば、大きなウィンドウが背面にあって小さなウィンドウが前面にあり、これらウィンドウ間のコピー・アンド・ペーストをするときに、ウィンドウ配置（前後関係）を全く変えることなく実行できる（⎇ Alt+⭾ Tab でアクティブウィンドウを切り替える必要がない）。

FFMは、メニューバーが個々のウィンドウ内に組み込まれているようなインタフェースでのみ実施可能である。macOS のように単一のグローバルなメニューバーが画面上端にある場合、画面下部にある小さいウィンドウのメニューを使おうとすると、まずそのウィンドウにマウスカーソルを移動させてフォーカスを与え、続いて画面上端まで他のウィンドウを横切ることなくマウスカーソルを移動させなければならない。したがって、非常に使いにくくなる。

ウィンドウ内のコンポーネントのフォーカス

テキストの入力や編集ができるコンポーネントには、それぞれにカーソルが存在する。そして、そのカーソル位置でテキスト編集をするには、そのコンポーネントにフォーカスが無ければならない。

ウィンドウ内でどのコンポーネントがデフォルトでフォーカスを得るか、コンポーネント間でどのようにフォーカスを移動するのか、はインタフェース設計の重要だが難しい問題である。間違ったところにフォーカスがあると、ユーザーはフォーカスの移動に時間を浪費することになる。逆に適切なところにフォーカスがあれば、ユーザーエクスペリエンスの向上につながる。

脚注