クイック設定ライクなアプリの作り方

Windows 11では、Mica(マイカ)と呼ばれる塗られ方をするデザインが一般的なウィンドウ背景などに使われています。

マイカ素材 (Windows Learn)

マイカは、アプリや設定などの長時間のウィンドウの背景を塗り分け、テーマとデスクトップの壁紙を組み込んだ不透明で動的な素材です。

対してWindows 10では、Acrylic(アクリル)と呼ばれる塗り方が主流でしたが、一部用途ではWindows 11でも利用されています。

アクリル素材 (Windows Learn)

アクリルは、半透明のテクスチャを作成するブラシの一種です。 アクリルをアプリ サーフェスに適用すると、奥行きを加えたり、視覚的な階層を確立したりすることができます。

両者ともに背景の色に合わせて色が変わる点では共通していますが、Micaはデスクトップ壁紙、Acrylicはすぐ下の色を利用しています。 使い分けとしては長時間のMica/短時間のAcrylicとなっています。 上記のとおり、Windows11ではMicaだけでなくAcrylicも引き続き利用されており、クイック設定でもAcrylicが利用されています。

ウィンドウ端には影がついており、背景が白でもグレーに見えます。 特に意識せずにウィンドウを作成すればWindows管理で標準な影を落とすことが可能です。 しかし後述する通り位置・サイズ固定のウィンドウ特有の課題があるため独自実装が必要になります。

Windows 8および10以降、Windowsでの個人設定として各種色の設定が可能となっています。 押下済みのボタンなどをAccent Colorで色付けすることや、Light/DarkのThemeに応じて背景色の明暗を変える必要があります。 この際、単に起動時に色を取得するだけでなく、設定変更時にリアルタイムで反映させる必要も出てきます。 最近のUIフレームワークでは標準で追従してくれますが、条件次第ではアプリ側で変化を検知する必要が出ます。

Windows 11では、ウィンドウの角やUI要素の角が丸くなっています。 この角丸についてもOS標準でウィンドウの四隅は切り取ることができますが、こちらについてもしっかりとした作りこみのためには独自実装が必要でしょう。

勢いよく滑ってきて、ゆっくり止まる。Easingの効いたアニメーションが採用されています。 もにまねでは、CubicBezier(3次ベジェ曲線)のEasing Function、表示：250ms、クローズ：167msで近似させています。 なるべく滑らかに動かすためには実装に工夫が必要ですが、多要素との兼ね合いで実装が困難になる原因でもあります。

Win11で閲覧中の方は、スタートメニューとクイック設定の両者について、タスクバーとの隙間(一番下の影が出ている部分)をクリックしてみてください。 スタートメニューは閉じ、クイック設定は閉じない挙動が確認できたかと思います。 両者ともにMicrosoftが作成するタスクバーから起動するウィンドウであるにも関わらず挙動が異なります。

マウスクリックを透過する/しないの差が発生しているかのような挙動ですが、それも違います。 マウスカーソルを乗せると十字やI字に変わる、ペイントやメモ帳のようなアプリをスタートメニュー下に配置してもカーソルは変化しません。

上記から言えることは、スタートメニューは影をクリックしたらウィンドウを閉じる処理が入っており、クイック設定は影をクリックしても何もしないということです。

筆者が試す限りWindowsでは、色は付けられるが全面クリック透過なウィンドウ or 色が完全に透明な部分のみクリック透過なウィンドウ は実現可能ですが、色が不透明だが指定した領域のみクリック透過なウィンドウは実現はできなさそうでした。 影部分を完全にクリック透過するには、複数ウィンドウ(クリック透過な影を描く大きいウィンドウ + クリック非透過なUIパーツを描く小さいウィンドウ)を利用することになりそうでした。 もにまねでは、 Microsoftもサボってるみたいですし 影をクリック透過にするのは見送り、スタート同等の仕様で抑えました。

タスクバーを除いた領域を手軽に得る方法として作業領域(Work Area)の取得があります。 SystemParametersInfo関数のSPI_GETWORKAREAで取得可能な情報であり手軽にプライマリモニタのタスクバーを除いた長方形を得られます。 しかし、一般的な全画面表示アプリケーションとは異なりタスクバーから呼び出す都合で注意点が存在します。

作業領域について

タスクバーの表示制御

GitHubのselastingeorge/Win32-Acrylic-Effectを見ると涙ぐましい努力が垣間見れます。

横断的に利用可能なのはSetWindowCompositionAttributeです。 Win10時代から存在する非公開な利用法があり、ウィンドウ「全体に」アクリル効果を付与することが可能です。 このウィンドウ「全体」というのが厄介で、半透明な部分全体に影響が出てしまうため、影部分も含めてアクリル効果が付与されてしまいます。

把握している中では最も新しく、上記を公式化したような挙動をするのがMicrosoft.UI.CompositionのDesktopAcrylicControllerです。 こちらはウィンドウの枠(影部分)へのアクリル効果付与は避けられますが、完全な透過とアクリル効果を描き分けるようなことはやはりできません。

より高度な実装を簡単にできるのはWindows.UI.Compositionです。 BackgroundSource="HostBackdrop"なAcrylicBrushでアクリル効果を持たせたい領域だけ塗れば良いです。

さらに細かい実装を行うとしたらDirectCompositionやDirectXを直接利用する方法もないことは無いようです。 しかし、非公式APIを利用することは避けられず、将来のOSアップデートで動作しなくなるリスクが高いですし、実装難易度も上がります。

なお、WPFについてはWindows11テーマへの対応作業が進んでいますが、MicaやAcrylicへのサポートはまだ対応中のようです。

上記の通り、ウィンドウ全体にアクリル効果を付与するだけであれば比較的容易に実装可能ですが

• 角丸部分は透過
• 影部分も透過
• 出てくるアニメーション時もアクリル効果を維持
• アニメーションをウィンドウの位置とサイズを変えて実装すると負荷が高い(滑らかに動きにくい)

などの課題があるため現時点では容易に実装するならWindows.UI.Composition系APIを利用するのが唯一の選択肢と思われます。

もにまねではUWPのAPIを利用してはいますが、狭義のUWPからは外れています。 狭義のUWP、すなわちApp Container環境で動作するUWPアプリの場合、セキュリティ制約の大きいサンドボックス環境で動作します。 ファイルへのアクセスなどの制約ももちろんありますが、今回のような用途の場合はウィンドウ制御に関する制約が問題となります。 具体的には、App Container環境のUWPアプリでは下記のような制約があります。

• ウィンドウの位置やサイズを自由に変更できない
• タイトルバーのカスタマイズが制限される(閉じるボタンを消せない)
• 透過ウィンドウが作成できない

回避策がある可能性はありますが、もにまねではXaml Islandsを利用することでこれらの制約を回避しています。

Xaml Islandsは、UWPのXAML UIコンポーネントを従来のデスクトップアプリケーション(Win32アプリ)で利用するための技術です。 WinForms内でWPFを使うHwndSourceなどと同様に、Win32ウィンドウの上にXaml Islands管理のWin32ウィンドウが重なるような形で動作します。

なお、IXamlSourceTransparencyを利用することでXaml Islands管理される部分の透過も可能になります。 これを透明なWin32ウィンドウに重ねることで、影部分のような半透明な部分は半透明に、アクリル効果の部分はアクリル効果が施された内容でレンダリングされます。

Xaml IslandsはCOM/WinRT(Windows Runtime)の都合で.NET Core 3.1もしくは.NET 9以降でのみ動作し、.NET 5-8、.NET Framework系では基本的には動作しません。 もちろん、C++/WinRTを使う場合は.NETに依存しないため問題ありませんが、UIでC#を使う場合は注意が必要です。

また、.NET Core 3.1の頃はMicrosoft.Toolkit.Win32にて容易に扱えるような整備がなされていましたが、現時点ではサポートされていません。 そのため、.NET 9以降でXaml Islandsを利用する場合はWin32 API/WinRT呼び出しを自前で実装する必要があります。 幸いドキュメントはある程度整備されており、Microsoft.Toolkit.Win32のソースコードもあることから比較的容易に実装可能です。 特に.NET 9でのUWP利用については情報が少ないですが、Sergio Pedri氏のブログ記事やGitHubでのDiscussionを参考にすることをお勧めします。