Microsoft、Windows 11のUIフレームワークWinUIのオープンソース化を段階的に進める
(neowin.net)- MicrosoftはWindows 11のユーザーインターフェース フレームワークであるWinUIのオープンソース化に向けた段階的計画を発表した
- WinUIは複雑な構造と多数の独自コードを含むため、即時の完全公開は不可能で、公開可能な部分と非公開の部分を区別する作業が必要（必要がある）
- オープンソース化は4段階で進められる予定
- 第1段階: ミラー更新頻度の増加：WASDK 1.8配布（8月末）以降、社内コミットをGitHubとより頻繁に同期し、透明性と開発進捗を共有する
- 第2段階: 外部開発者によるローカルビルド：外部開発者がコードをクローンしてローカルでビルドできるようになり、設定および依存関係に関するドキュメントも提供される
- 第3段階: 外部貢献とテスト：コミュニティ貢献者がPull Requestの提出およびローカルテストを可能とし、内部依存関係の整理とテストインフラの公開も行われる予定
- 第4段階: GitHub中心開発体制への移行：最終的にGitHubが主要な開発、Issue管理、コミュニティとのコミュニケーションの中心となり、内部のミラーシステムは段階的に廃止される
- WinUIのオープンソースロードマップはGitHubプロジェクトボードで公開管理されている
- 開発者とユーザーはフィードバック、明確なIssue作成、既存意見への投票などを通じてWinUIの発展に貢献できる
3件のコメント
COMもWebViewも嫌なんだよね… もう少し使えるGUIがあればいいのに。 これまでWindows向けUIとして試してきた中で一番気に入っているのはQt4でした。Qt5からは、なんだかずいぶん感じが変わってしまったようです。
実際、MFCもそれほど悪くはなかったという記憶があります……www
Hacker News の意見
Windows のネイティブ UI 技術の将来が心配だ
OS 開発者は通常、自分たちが実際に使う製品を通じて、よく機能し一貫したネイティブ アプリを作ってきた。
しかし Windows 11 では逆のことが起きている。
Windows 10 以降、少なくとも最低限動作する標準のメール・カレンダー アプリがあったが、Windows 11 の最新アップデートではそれが消え、遅い WebView ラッパーに置き換わって起動まで数秒かかる
WinUI コミュニティコールを見れば、ほとんどの新入社員が Windows 経験をほぼ持っておらず、経営陣もそれを気に留めていないため、基本をきちんと習得していない様子が見える。
Windows 開発者なら当然知っているだろう質問にも答えられず、なぜその質問が出たのか理解できない顔をしている。
こうした要因で Windows 11 のあちこちに Webview2 インスタンスがあふれんばかりになっている
Windows 11 の UI の問題は、新規アプリや機能にこそ注力し、昔のツールは最新化しないという印象だ。
たとえばコントロールパネルは Windows 7 以来、ほぼ同じスキンのまま残っている。
さらに突き詰めると、まるでホーマー・シンプソンの頭にクリップをつけたミームのように、あちこちに古いツールが隠れている。
見た目だけは新しく感じるが、使ってみるとすぐ限界が見えてくる
いつか MSO（Office）を Dart や WASM のような技術で完全に作り直す日が来るかもしれない。
ネイティブツールキットとは完全に独立した形で、Excel のすべての機能を再現し、O365 プレミアムプラン形式でどこからでもアクセス可能にすることもできるだろう。
結果として、ChromeOS のように変容して、ロック画面やサインイン画面のような場所だけ簡易なネイティブ UI が必要で、残りは軽く扱われるかもしれない
Microsoft 内部の権力争いと厳しい社内政治を理解すれば、こうした変化がなぜ起きるのか分かる。
各部門が互いに優位を取ろうと競っている状態だ
Windows には少なくとも 10 種類の異なる UI フレームワークが混ざっているように感じる。
Windows 11 はまるで自然史博物館を見て回っている気分だ。
MSC のように Windows 2000 時代のデザインにそのまま残っているアプリもあり、Metro スタイルの影響で無骨で原色的な UI も見られる。
最新の Win11 スタイルは見栄えはするが、実際は「豚に口紅を塗る」ように見える。
右クリックメニューが代表的な例で、見た目はよくとも実際は機能が足りず、「もっと見る」ボタンを押さないと旧来スタイルでより多くの機能を見られない。
全体的にドタバタしている
Microsoft の「Microsoft 目標とのアライメント」や「リソース配分を慎重にする」といった発表で、誠実さは感じられない。
結局はフレームワークを外に委ね、情熱ある外部開発者に保守を任せるためにリソースを引き抜く、という方針に見える
「情熱のある敗者」という表現はあまり否定的すぎる。
自分が Win11 UI に関心がない、もしくは今回のオープンソース化が単なるコスト削減用だという冷笑的視点に共感するとしても、
この仕事を続けようとする人たちには、ある程度の敬意を示したい
はっきり言えば、これは「保証付きサポートなし、セキュリティバグ以外の追加アップデートはなし、好きに使ってください」という大企業の言い回しだ
冗談めかして「Apache Windows はいつ出るんだろう」と言いたくなる。
真面目に言うと、もはやデスクトップ UI ツールキットは競争力や参入障壁ではない。
Windows で 3〜4 種類の異なるスタイルが公式に流通していることがその理由だ。
ただセキュリティと安定性は、Windows が企業・金融・官公庁で生き残るために依然として必要な要素だ
他社の UI フレームワークをオープンにする場合は、納得できる点がある。
たとえば Atlassian や AWS のフレームワークは Jira/AWS で使われているので、B2B SaaS でも試す価値があると感じる。
しかしこのフレームワークを使うべき理由はわからない。
本当に Windows ネイティブアプリだけを作りたいのでなければ、すでにより良い選択肢があると思う
WinUI は失敗だと思う
Windows 開発コミュニティで WinUI にこだわる人はほとんどいなく、WinRT/UWP に既に投資して抜けられない開発者だけが抱え込まれている。
Windows 8 以降であまりにも多くのつなぎ目が断たれ、コミュニティの信頼を失った。
事実上、Microsoft が問題を修正する代わりにコミュニティに委譲しようとしているということだ
DevExpress、Progress Telerik といった企業も独自で WinUI コントロール開発へ投資していないので、
これらも WinUI の未来を信じていないというシグナルだ。
現時点でエンタープライズ向けアプリとして現実的な代替は WinForms と WPF くらいしかない。
実際に WinUI3 で作られ、業務で使っているアプリを見たことがない
正直なところ、これから Microsoft のどの UI フレームワークを真面目に使うのかと思ってしまう。
以前から使っていたフレームワークは、いつも完成しないまま半端に作られた状態で捨てられ、
新しく派手なフレームワークへ目を向けることで、結果的に全部忘れられてしまう。
逆に、オープンソースのクロスプラットフォームフレームワークの方が基盤と機能面でずっと完成度が高く、保守もきちんと行われている。
今回の WinUI も、最終的には忘れ去られ、冷遇されるもう一つの UWP の末路だ
Windows でどれだけの UI フレームワークがあるか、もう数えるのも難しいくらいに感じる。
オープンソース化して何を期待しているのか疑問だ。
単に「公開されている」という見せかけの演出なのか、Windows ターゲット開発者に実質的なメリットがあるのかが気になる
WinUI は UWP から発展したバージョンで、UWP 自体は WinRT の進化だ。
WinUI の意図は明確で、長い年月育った技術だ（現在は WinUI 3）。
MAUI は競合製品というよりはクロスプラットフォーム向けだ。
しかし、OS 全体、特に管理ツールまで WinUI で再構成しない限り、長期的な信頼は得にくい
上の多数の略語と説明を見て、最初は風刺だと思った。
WinUI、UWP、WinRT、XAML、Avalon、WPF、Project Reunion、Win2D、MFC、wxWidgets、Qt など。
バージョンやフレームワーク名が非常に混在していて、説明を聞いただけでも長くて混乱する
おそらく Microsoft はまたいつものように新しいトレンド（今は AI）に集中しながら、
以前の技術は大きな反発なしで整理する方法を探しているのでしょう。
実際、そのような反発者は少数にしかいないだろう
実際 Windowsには UI フレームワークが三つあり、そのうち二つだけが実質的に生きている
残りは Win32/ネイティブ、WPF/Managed の二系統の繰り返し進化に過ぎない。
WinUI3 はそのギャップを埋めるために出てきた
長期的に見ると MFC がまだ最も長く生き残る選択肢だ。
今は更新が止まっているが、これから 20 年は安泰で生き残るだろう
Microsoft が WPF を引き続き進化させてくれたらと思う。
さまざまなプロジェクトで長く使ってきており、ラーニングカーブはあるが Data Binding、ViewModel、XAML は今でも満足できる。
ただし WPF が完璧になるにはいくつか改善が必要。
最近の Microsoft 新フレームワークやオープンソース（Avalonia、Uno など）も試したが、サンプルが動かなかったり開発方法が合わなかったりした。
結局、また慣れた WPF に戻る。
WPF 最大の改善案は、Data Binding システムをランタイム Reflection ではなく .NET のコンパイル時コード生成にすることだ。
この方式なら本当の AOT ビルドが可能で、性能が飛躍的に向上し、XAML の型安全性、クロスプラットフォーム対応など多くの利点がある。
直接オープンソースでやってみようとしたが、時間が足りず、やることが多すぎた
話の二段落目は Avalonia にぴったり当てはまる。
Avalonia はすでに AOT、コンパイル時バインドエラー、クロスプラットフォーム機能をサポートしている。
最近の更新をしばらく見ていなければ、Avalonia compile-time data binding docs と XamlX プロジェクト を参照してください
この方式ならアセンブリトリミングも可能になる。
独立配布を行う場合、現在は .NET ライブラリが 200MB 以上付きだが、この方法なら大幅に減らせる
以前 WinUI3 を評価したとき、開発者体験があまりにも悪かった。
配布したいアプリをデバッグするためには、実際にシステムへインストールする必要があった。
そうするとスタートメニューに無駄な項目が多数入り、レジストリも汚れた。
さらにはサンプルコードのボタンをクリックしただけでアプリが即クラッシュした。
自分が Windows アプリを開発するとき、いまも Win32+WTL で作っている
機能と権限処理が必要なので、そうなっている。
macOS も同様で、パッケージアプリならインストールが必要だが、Launchpad に表示されなくても Spotlight で検索できる
多くの人が指摘するように、Windows 用 UI フレームワークは長い間まともに整理されず、混乱だけが増している。
残念だがクロスプラットフォームオープンソース側も同じ。
GTK も一時期はひどい状態で、Qt は機能は豊富だがプロフェッショナル用途ではライセンス体系が重すぎる。
（Nokia 時代の Hope、MS のエロップ、そしてその後の Qt 所有者交代などで消えてしまった）
特定分野では Dear Imgui など良いソリューションもあるが、
全体としてネイティブとクロスプラットフォームの UI/ウィジェットフレームワークで、寛容なライセンス・ネイティブコンパイル・優れたウィジェット構成・Vulkan 3D レンダリングまで備える代替はほぼない
実際プラットフォームの柔軟性を求めるなら、事実上の代替がほとんどない現実を見落としている。
Microsoft がこの領域で本当に意味のある製品を作れたはずなのに、試み自体があまり熱くなく、結果としてちゃんとした成果が出たことがない
Windows 11 でネイティブの縦向きタスクバーが再追加されるとよい。
この機能は Windows 98 からあったが、11 では消えた。
Windhawk（水平 taskbar 強制）や StartAllBack（Windows 10 コード復元系）などのサードパーティ製ツールはあるが、完璧ではない
UI フレームワークをオープンソースにしたからといってタスクバーの機能が拡張されるわけではない。
この領域での外部貢献は、UI フレームワークではなくタスクバー本体、つまり explorer.exe がオープンソース化される場合にしか不可能ではない
参考までに、最初は Windows 95 時代から縦向きタスクバーはオプションにあった
タスクバー機能は explorer.exe の機能だ。
今議論されているオープンソース化の発表は explorer とは無関係だ
Windows チームが WinUI でネイティブデスクトップ UI を本当に作っているのか疑問だ
Windows 用 UI 作業は最近、Win32、GDI、DirectDraw などを使って進んでいる。
CsWin32 と最新の C#（ref returns）のおかげで、以前よりアクセスしやすくなった。
以前は普通 C++ で別プロジェクトを組む必要があったが、いまは NativeMethods.txt に必要な関数だけ書けば、コードジェネレーターが処理してくれる。
Win32 は確かに他の UI フレームワークより低レベルだが、逆に Microsoft が手を加えたり廃棄したりしにくい。
長期的に見ると、この API ほど安定して生き残っているものはない。
ウェブプラットフォームも長期的には比較にならない
それでも多くの場面でなお C++ が必要。
これは Windows チームが COM へのこだわりのせいだ。
Windows Runtime Components は .NET エコシステムの水準を上げる機会だったのに、見逃してしまった。
シェル拡張やコンテキストメニュー拡張などは C++ で行わなければならず、これを .NET でやろうとすると、結果として C++ スタブを置いて .NET プロセスを呼び出す形になる
この高レベルフレームワークの議論より、低レベル API の話のほうがより興味深い。
Windows のレンダリングスタック全体が GDI/DirectX 上にあるとすると、Win32 自体も結局 GDI の上にある。
本当に金属寄りの Windows UI スタックを論じるなら、DirectX から始めるほうが意味があると思う
ユーザー目線では Win32 でも十分高レベルだ。
現時点でボタンやスクロールバーを適切に描画できるツールキットは Win32 だけである
Windows ネイティブ開発向けの本当に良いフレームワークをコミュニティが作ってくれればよいが、
現実には、それを作れるだけのコミュニティ規模が十分ではない
昔の Windows UI 開発で最も懐かしかったのは
Microsoft が直接作ったかのように自然に馴染むアプリを簡単に作れるよう支援してくれた点だ。
ウェブ技術導入後、Windows UI 経験の一貫性は大きく崩れた。
Microsoft が以前のアプリを最新化しなかったのも問題だが、新しいツールもスタイルガイドに沿ったライブラリを提供しない。
ビスタの頃からこの現象が現れ始め、MSDN でも「この機能をこのように使う」などの具体例が豊富な資料がどんどん減っていった