Xamarinは.NET5に統合されると思います。
UWP XAMLを標準として採用し、それ以降、MicrosoftとUNOがデスクトップ、モバイル、Webブラウザー（Azure）、IoTに最適になるようにすれば素晴らしいと思います。
彼らはそれを呼ぶことができます
UWP vNext（WinUIベース）/ Silverlight 6（UNO）

Blazorの取り組みは、現在のデフォルトのレンダリングを使用して、.NETを正式にWebBrowserに導入する最初のステップだったと思います。 HTML DOM
しかし、すぐに別のレンダリングエンジン、WinUIの軽量補完、Silverlight、UNOプラットフォーム、Xamarinを周回するもの（Flutter / WPFなど）を提供できるようになると思います。

UWP XAMLを標準として採用し、それ以降に機能するのは素晴らしいことです。

あなたたちが望むすべてはすでに宇野で起こっています。 MSはそれらの人を買い取り、それから彼らを雇って宇野の最終的な発展に沿って羊飼いにするのが賢明でしょう。

これはおそらく、このような機能を要求するのに間違った場所です。 このリクエストのすべてに同意したいのですが、WinUIチームとWindowsコミュニティの多くの上級開発者はWinUIを非常に狭く定義していると思います。

理想的な世界では、WinUIはマテリアルデザインのようなものです。 それを実装するあらゆる種類のライブラリを備えたあらゆるプラットフォームでそれを使用する方法があります。 ただし、WinUIはデザイン言語ではないため、FluentDesignでもありません。 マイクロソフトがモデル空間にいないことで、競合他社の背後にあるUI製品が大幅に増えています。

WinUIはWindowsアプリケーション用のUIライブラリであり、これは非常に明確です。 設計言語は実装から分離されておらず、構成などの機能がプラットフォームの依存関係に大きく依存しているため、実装はプラットフォーム専用です。 これはモバイル/クロスプラットフォーム開発者の観点からは悪いことですが、ここでの取り組みは実際にはWindowsアプリ向けです。

これは、DX 11をすべてのプラットフォームに移植しない限り、おそらくUnoプラットフォームがどこでも真にWinUIになることは決してない理由でもあります。

Comet（.Netに基づくクロスプラットフォーム開発フレームワーク）を調べることをお勧めします。 まだ初期段階ですが、コンセプトはFlutterと同じです。 また、Skia（オプションとして）を使用して、構成可能/宣言型のUIパターンでUIを描画するため、開発者はマテリアルデザインなどのUIライブラリを実装し、すべてのプラットフォームで完全に同じように見せることができます。

いいえ、クロスプラットフォームであってはなりません。 それは理由からWindowsUIと呼ばれています。 まず、すべてのWindows（プラットフォームと言語）で機能するUIシステムを入手しましょう。 それはまだ達成されていません。 まだ.netフレームワーク、.netコア、uwp、そして少なくともuwpがあるC ++ストーリーに分かれていますが、UWP / WinRTにはまだいくつかの問題があるため、ゲーム開発者はそれを使用していません-配布、強制タスクバー、タイトルバーのポップアップフルスクリーンの場合（yikes）。

クロスプラットフォームについて考えることは、膨大なリソースの浪費になります。 まずWindowsで正しく取得してください。 そして、.net 5を公開し、UWPとウィンドウストーリーを修正して、DirectXをC＃に配置します。 そしてGCを修正します。 狭いシナリオでは、Windowsだけでまだやるべきことがたくさんあります。

そしてOPに。

• UWPはユニバーサルです。 それが普遍的ではないと言うことは誤った主張です（彼らはAndroidをターゲットにすることを決して意図していませんでした、神に感謝します）。 当初の約束が果たされました。 すべてのWindowsデバイスはUWPを実行します。 Windows Mobileは別のOSであり、それらを取り除く必要がありました。 すべての新しいWindowsプラットフォームはWindows（10または10X）になります。 最終的にはCoreOSに基づいていると思います。 そして、それらはすべてWindowsアプリケーションを実行します。 現時点でWindowsPhoneを持っていないという理由だけで、偶然です。 他のすべてのデバイスタイプがあります。 そして、NeoとDuoがまもなく登場します。

• サンドボックスの制限-これらは良いことです。 Win32スタイルのシステム全体のアクセスは、一般的に打ち消されるべきです。 特定の要件がある場合は、UWPコンテナー内でどのように実行できるか、または実行する必要があるか、および提案どおりに実行できるかどうかについて話し合うことができるように、要件を提示する必要があります。 そして、UWPがその機能を必要としているかどうかを調べます。 UWPで記述できる高度なアプリケーションをいくつか考えることができるので問題ありません。 プログラムができます！ 詳細について話し合う必要があります。

• .netネイティブは置き換えられ、配布ストーリーは.net5に変更されます。Microsoftがこれに取り組んでいると言っても過言ではありません。 確かに彼らは問題を知っています。 ただし、ここで実際の根本的な問題を対象とする特定の問題を提出する必要があります。

• 「WinUIをDirectXに結合しないでください」-WTF？ ネイティブのWindowsグラフィックスタックであるDirectXと絶対に組み合わせる必要があります。 他に何も考えないでください。 私は絶対に内部でOpenGLレンダリングサーフェスに出くわしたくありません。 それは互換性を壊し、あらゆる種類の騒乱を引き起こすでしょう。

@Gavin-Williams

すばらしいです。WPFを少し進化させてアップグレードしましょう。

UWPはユニバーサルです

「すべてのWindowsデバイスがUWPを実行している」とは、モバイルなしでは何の意味もありません。 HoloLensはニッチであり、Surface Hubはニッチであり、Windows 10IoTCoreは冗談です。

絶対にDirectXと組み合わせる必要があります

開発者として、ハードカップリングは私にグースバンプを与えます。 グラフィックスタックを交換できない主な理由はありますか？

それは「モジュール性」と呼ばれます。 マイクロソフトは常にそれに苦労してきました。

サンドボックスの制限は良いことです

はい、構築できるアプリケーションの範囲を厳しく制限しない限り、そうです。 UWPからパーティションのサイズを変更しようとしましたか？

GoogleがFlutterを開発していて、GoogleUIやAndroidUIとは呼んでいないことを言及して思い出しておく価値があると思います。 Webやデスクトップでも、どこでも機能します。 「Windowsで動作させるだけ」の傾向があるように思われるので、これを述べますが、より安く、より速く、より使いやすく、Windowsと他のすべてで動作する別の競争力のある製品が存在する場合...開発者はどうなりますか（および対応する市場）選択しますか？ 私は中小企業の経営者として、2つの選択肢を考えれば、どこに投資をしているのかを知っていると言えます。

DirectXを他のプラットフォームに移植するのは大変な作業のようです。おそらく解決策は、DirectXの代わりにOpenGLまたはVulkanを使用することです。

@ Gavin-Williams、UWPに精通しているかどうかはわかりませんが、ビルド/配布するときは、Windowsの特定のバージョン（またはバージョン範囲）をターゲットにします。 そのアイデアは完全に結びついており、UWPがWPFほど主流にならなかった理由の1つです。
@nerocui UI言語の全体的な目的は、UIデザインを画面の生の描画から切り離すことです。 これが、HTMLがARM / x64/x64でレンダリングできることを示している理由です。

XAMLは、UIプリミティブ/構成/アニメーションの優れた抽象化を提供します。開発コストとプラットフォームの到達範囲のため、この要求は絶対的に理にかなっています。

私は@SuperJMNに敬意を表して反対します。 確かに、UWPはまだWPFと同等の機能を実現していません。 カーネルレベルのツールを構築するためのフレームワークとしての制限にもかかわらず、アプリマニフェストで指定された適切な機能を備えた実質的に他のすべてのソフトウェア開発タスクでは、複数の観点（セキュリティ、展開の容易さ、インストール/アンインストール）からはるかに優れたユーザーエクスペリエンスが得られます経験など）。 UWPのセキュリティサンドボックスは重要な（必須の）機能です。 多くの点で、UWPはWPFよりもはるかに進んでいます。

UWP .Netコンパイラは、コードの難読化の必要性と、これがWPFにもたらす可能性のある不安定性を排除します。 コンパイラが改善されるにつれて、コードを変更せずに時間の経過とともにパフォーマンスが向上する可能性があります。 UWP自体は、DirectXやその他のシステムレベルのリソースをどのように活用するかという点で、はるかに優れた設計になっています。 また、他の言語、特にC ++と統合する場合、WPFよりも大きな利点があります。 高性能C++コンポーネントをC＃と統合することは、UWPでは簡単です。 DirectXサーフェスへのアクセスも大幅に改善されています。

UWPの残りの穴は簡単に塞ぐことができます。 より大きな問題は、MicrosoftがWPFに関連する品質レベルを達成できなかったことであると私は主張します。 WPFは機能しました。 Microsoftはまた、データグリッド、INotifyDataErrorInfo、機能検証状態を制御するコントロール、すぐに使用できる堅牢なDBなどのLOB要件の決定的な重要性を認識できませんでした。 これらのほとんどは対処されていますが、時間がかかりすぎました。 非長方形の領域は敷居がありません。

その他の重大な障害は、UWPから離れることを選択した特定のWPF開発者にあります。 勢いをつけるには採用が不可欠です。 ただし、Microsoftがそのイニシアチブに何度も取り組んできたことを考えると、採用の物語は理解できます。 マイクロソフトが再び混乱しているのは明らかです。 WPFをUWPUIサービスにプラグインできるようにして復活させることは、表面的にはクールに思えますが、UWPを安定させることには気が散ります。

私は、開発者がマイクロソフトが正しいことをするという希望を失ったという@SuperJMNの主張に完全に同意します。 正しいことは、構築しているソフトウェアの種類によって異なります。 迅速に作成する必要があり、安全でインストールが簡単でありながら幅広い機能を備えている必要がある高性能LOBアプリケーションの場合、品質の点を除いて、UWPはほとんど存在します。 その品質のギャップが、何よりもUWPを殺しているのです。

HTML + JSは、今日のクロスプラットフォームソリューションです。 再発明する必要はありません。 XAMLをより移植性の高いものにすることが目的である場合、IOSおよびAndroidで高性能のXAMLレンダリングエンジンを使用する方が理にかなっています。

WinUIが将来的にクロスプラットフォームになることを目指すべきであることに私は非常に同意します。 ここにいくつかのさらなる考えがあります。

当面の優先事項

WinUI3が.Net5と統合されたWindowsで動作することを確認することが当面の優先事項であり、バグが修正されているというコメントのいくつかに同意します。 ただし、まだ手遅れではない場合は、アーキテクチャの決定を行う際に、将来的にクロスプラットフォームになるという目標を検討する必要があります。

WinUIをクロスプラットフォームにする必要がある理由

明白で最も重要な理由があります-開発者はコードなどを書き直さずに可能な限り多くのオーディエンスをターゲットにしたいと考えており、C＃（またはC ++だと思います）/XAMLは素晴らしい組み合わせです。 クロスプラットフォームの話がなければ、彼らはFlutterのような他のテクノロジーに移行するでしょう。

もう1つの理由は、WinUIが引き続きMicrosoftによってサポートされるようにするためです。 Microsoftは、独自のアプリがWinUIを使用している場合にのみ、WinUIのサポートを継続する可能性があります。 彼らは、独自のアプリをクロスプラットフォームにすることにますます焦点を合わせています。 React NativeやXamarinなどの一部のクロスプラットフォームフレームワークがその下でWinUIを使用するのは事実ですが、Flutterやブラウザーベースのレンダリングなどの他のフレームワークが勝った場合はどうなりますか？ その後、WinUIは冗長になり、WPFのようなメンテナンスモードになります。

クロスプラットフォームはどのように実装する必要がありますか

Unoは素晴らしいプロジェクトですが、私の意見では、ネイティブコントロールをラップするよりも、レンダリング（および入力）レイヤーをクロスプラットフォームにしてその上に構築する方が理にかなっています。これは、FlutterとAvaloniaUIが行うことです。 レンダリングレイヤーと入力レイヤーをクロスプラットフォームにするアプローチには、いくつかの利点があります。 レンダリングレイヤーと入力レイヤーのAPIサーフェスは、コントロールのAPIサーフェスよりも小さいように見えます（ただし、いくつかのベースコントロールの上にコントロールを構築するかどうかによって異なります）。 第二に、ネイティブコントロールのラッピングに依存している場合は、プラットフォームに翻弄されます。 APIを変更した場合は、APIを変更するか、回避策を実装する必要があります。 非推奨時にこれを十分に迅速に行わないと、フレームワークが壊れます。 コントロールに新しい機能を追加する場合は、プラットフォームごとに実装する必要があります。 プラットフォームフレームワークに縛られているため、フレームワークをどのように進化させたいかについての「ビジョン」を実際に持つことはできません。 また、コントロールの外観と動作が異なるため、開発者は常に各プラットフォームでテストする必要があります。 また、コンポジションレイヤーのようなより強力な機能を実装することは困難/不可能です。 レンダーレイヤーをクロスプラットフォームにすることで、これらすべての問題が解決されます。プラットフォームごとに異なる外観が必要な場合は、異なるスタイルを追加できます。 （一部の動作では、Macでのスクロールなど、プラットフォームごとに異なる動作が続くことを認めます！）。

WinUIは現在、コントロールとレンダリングおよび入力レイヤーをプラットフォームから切り離しているため、これを行うには独自の適切な位置にあるように見えます。

レンダリングレイヤーを抽象化する1つの方法は、Skiaを使用することです。 ただし、この抽象化を強制することによってパフォーマンスが低下することは望ましくありません。 レンダリングレイヤーを抽象化するための別の提案があります。これは、2DグラフィックスのC++提案です-http ://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r9.pdf 。 彼らは明らかにAPIの表面に多くの作業を投入しており、それはかなり包括的であるように思われます。 彼らは、2Dグラフィックスの「問題」は本質的に何年も前に解決されたと主張しており、APIサーフェスがかなり完全に見えることに同意する必要があります。 この提案に反対する人はたくさんいますが、受け入れられなくても、APIサーフェスを使用できると思います。 このAPIサーフェス用にDirect2Dバックエンドを作成する場合、提案が受け入れられると、MSVCチームはそれを作成する必要がなくなります。 たぶん、WinUIチームは、これを作業を許可されたり、チームメンバーを追加したりする正当な理由として使用できます。 また、おそらく論文の著者は喜んで助けてくれるでしょう。 Skiaなどを使用して他のプラットフォームのバックエンドを作成し、提案が最終的に受け入れられた場合は、それらが作成されたときにネイティブ実装に切り替えます。

最後に、さらに将来を見据えて、WASIについて言及したいと思います-https ://wasi.dev/ 。 これは今のところシステムプログラミングに焦点を当てているようですが、本格的なクロスプラットフォームアプリフレームワーク（クロスプラットフォームとセキュリティが組み込まれている）に変わる可能性があり、上記のC++提案はおそらくレンダリングレイヤーAPI。 （ただし、これは非常に遠い可能性があります）。

証拠を見ると、 @ SuperJMNのような人々は、それらのリポジトリのコンテンツを考えると、多くの信頼性を持っています。 @SuperJMNは、まだ成熟している間にUWPをあきらめた可能性があります（理解できます）。 Microsoftは、ここでコメントしている人々のリポジトリを確認することをお勧めします。 一部の声は、世界に提示する一連の作業に基づいて、特に信頼できるものではありません。

@Noemata私はかつてXAML+MVVMの大ファンでした。 私はSilverlight、WPF、WindowsPhone、Metro（WinRT）で使用しました。 UWPとXamarinに関しては燃え尽きました...

このイテレーションと、新しいXAMLスタックを調べた他のすべてのイテレーションとの違いを理解するのは困難です。

Microsoftは、いくつかの素晴らしいUWPサンプルアプリを公開しました。 彼らは本当に何が可能かをうまく紹介しています。

部分的なリストは次のとおりです。

https://github.com/Microsoft/Windows-appsample-customers-orders-database
https://github.com/microsoft/InventorySample
https://github.com/microsoft/VanArsdel
https://github.com/microsoft/BuildCast
https://github.com/microsoft/Windows-appsample-shopping

もっと良い例がたくさんあります。 サンプルが他の作品とまとまりがあるように、簡単に再利用または構造化できる方法で構築されたものはありません。

対応するWPFサンプルでの努力はほとんど覚えていません。 これはほとんど良いです。

問題？ UWPとXAMLを使用して現在の場所に到達するのに時間がかかりすぎました。 そして今、メッセージは再び混乱しています。 UWPが最初にリリースされたときにMicrosoftがVisualStudioに適切なプロジェクトテンプレートを提供しただけであったとしたら、UWPについてはそれほど否定的ではなかったでしょう。 最高のVSテンプレートを入手するには、次の場所にアクセスする必要があります。

https://github.com/microsoft/windowsTemplateStudio

UWPアプリの非常に柔軟で完全なビルディングブロックのセットであるにもかかわらず、箱から出してすぐに使用できるわけではありません。 これらすべてをどのように見つけますか？ 全く分からない。 あなたの仕事をするために宝探しに行くことは自信を築きません。 WinRTの採用を拒否したOfficeチームは役に立ちませんでした。 それらは、理論上のアームの長さに関係なく、OSに入る多くのことを駆動します。 品質の問題、バグ、Windows Phoneの障害、一貫性のない投資とメッセージングを投入してください。

Microsoftは、いくつかの素晴らしいUWPサンプルアプリを公開しました。 彼らは本当に何が可能かをうまく紹介しています。

@Noemata同意します、彼らは本当にクールなサンプルです。 しかし、UWPを使用して、複雑なアプリを開発するのは非常識です。 それは確かに可能ですが、それははるかに困難です。 はい、私はWPFの「それはうまくいく」時代を懐かしく思います。

MSがサンプルとして最初に提供する必要があるものの1つは、MSストアの外部に公開できる単純なUWPアプリです（もちろん、思ったほど簡単ではありません）。

私に合わないもう1つの点は、UWPが「モバイルファースト」を念頭に置いて考えられ、適切なデスクトップエクスペリエンスを捨てたことです。

私が間違っている場合は訂正してください。ただし、ほとんどの開発者はUWPを使用してデスクトップアプリを開発しており、UIはそれに一致しません。 最初に頭に浮かぶのはスクロールバーです。スクロールバーは、最初からタッチパッド用に最適化されています。 しかし、デスクトップのユーザーにとって、スクロールエクスペリエンスは非常に悪いです（補足：WinUIチームはこれの修正に取り組んでいると思います）。 スクロールバーを再び「通常」にするソリューションを見つけるために、私はかなり多くのことをグーグルで検索しました。それを行うためにAPI関数を呼び出すことができないのは非常に正気ではありません。

同様に、ラジオボタン/コンボボックスの最小サイズもモバイル向けに最適化されています。 ラジオボタンの幅を設定するだけでは無視されます。実際に考慮するには、「MinWidth=0」を設定する必要があります。

そして、テキストボタンの色は白で、次​​にフォーカスが黒になります-どうしたのですか？ そして、テキストボタンにはそれをクリアするために使用できる「x」があります-それはタッチパッドです-タッチパッドがないのになぜそこにあるのですか？

デフォルトのテキストボックスでスペルが有効になっています-なぜそれが必要なのですか？

他にも問題がありますが、私はそれらを回避しました。 しかし、最大の問題は、10分かかるはずのこと、通常は2時間以上かかることです。 私は単に推定する能力を失いました-何かが私に半日かかると言うときはいつでも、それは私に2〜3日かかります。

みなさん、こんにちは。
これは一般的な議論の問題であり、UWPの希望/機能のリクエストを他にどこに置くべきかわからないので.....私はこのスレッドで機会を利用します：

• uwpアプリをWindowsエクスプローラーのコンテキストメニューに統合するためのより良いサポート
  
  
  
  • ここで私たちをサポートしてくださいhttps://aka.ms/AA6rmrk
  
  
• UWPマークアップ拡張機能にIServiceProviderがないこと、およびマークアップ拡張機能が使用されている要素自体
• UWPスタイルトリガーがありません
• UWPの暗黙的なデータテンプレートの問題。 たとえばここを参照してください
• ユーザーの操作なしでは自動印刷はできません（POSでのみ機能します）ここを参照してください

上記のすべての機能または問題は、現在は廃止されているuservoiceで対処されました。 誰かがそれらの問題で何が起こったのか知っていますか？ フィードバックハブでそれらを再作成する必要がありますか？

「忘れられた開発者」というフレーズが大好きです。 私は彼らの多くが才能があり、経験豊富で、テクノロジーに情熱を持っていることを知っています。 彼らはベテランの.Net開発者です。 一般的に言って、iOSやAndroid向けのアプリ開発で成功している多くの子供たちよりも優れたアプリを作成できることは間違いありません。
WinUIが、C＃+ .Net + Xamlでの豊富な経験を活用してWindows、Android、iOS、およびWeb用のアプリを作成するための快適で堅牢なパスを提供できれば、多くの人がワゴンに飛び乗って、世界はその高いメリットを享受できます。高品質のアプリ。
WinUI + UnoPlatformが究極の呼びかけになる可能性があります。

UWPマークアップ拡張機能にIServiceProviderがなく、マークアップ拡張機能が使用されている要素自体

ここでカバーしました@mfe-！

ここでカバーしました@mfe-！

@ Mike-EEうわー、それはすごい！ CalcBindingをUWPに移植したかったときに、これに遭遇したことを覚えています。 私がやったことは、ビューモデルに読み取り専用フィールドを追加する回避策です。

「一度書けばどこでも走れる」。

マイクロソフトはしばらく前にこれから離れました。

よくできました。私たちは有名です。 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

忘れられた開発者は沈黙しているか、単に無視されています

「忘れられた開発者」というフレーズが大好きです。

その名前で整理しましょう！ 💪

マイクロソフトによって開発およびサポートされているクロスプラットフォームのUIフレームワークが欲しいだけです。 _Uno Platform_と_Xamarin.Forms_（まだデスクトップのターゲティングに取り組んでいる場合）を除いて、.NETエコシステムには何もありません。

また、Windowsのみのビジネスアプリケーションを最初から作成することにしたとしても、MicrosoftがUWPに完全にコミットしているとは思いません。 私が間違っている場合は訂正してください。ただし、OfficeオンラインPWAを優先してOffice UWPアプリを放棄しませんでしたか？ MSが独自のファーストパーティフレームワークを廃止した場合、なぜUWPを信頼する必要があるのでしょうか。 _咳シルバーライト_

ありがたいことに、WPFはまだ放棄されていません。 しかし、それは私の疑問を増すだけです。

よくできました。私たちは有名です。 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

ホリー🤭

素晴らしい！ 他の大きなジャーナル、ウェブサイトなどに拡大しましょう😛

アプリを開発するためのクロスプラットフォームソリューションを探している人にとっては、Unity以外に探す必要はありません。

https://unity.com/

このようなすべてのソリューションと同様に、最終的にはミニオペレーティングシステムを含むフレームワークになります。 Javaは、プログラミング言語を巧みに装ったオペレーティングシステムでした。

最近のブラウザはミニOSになりました。 これらは十分にあると思います。 WinUI / UWPは、Windows10以降のネイティブUIであると想定されています。 より多くの場所で実行されるXAMLエンジンを使用することは理にかなっているかもしれません。 Unityのようなものの逆風に逆らって飛ぶとは思いません。 MicrosoftがSilverlightの再発明を開始して、他のプラットフォームでXAMLをホストできるようになる前に、洗練された高品質のUWPを見たいと思います。 私たちは皆、それがどれほどうまくいったか知っています。 Unityをまだ見ていない場合は、見逃していることになります。 そうは言っても、多くのコーディングとさらに多くのデバッグを行う準備をしてください。

来週は、数秒でアプリを作成できるUWP用のVSテンプレートのセットをリリースします。 これは「内部」プロジェクトに使用されています。 VSだけに適切なビルディングブロックが組み込まれていれば、UWPがすぐにRADフレームワークになり得るという点が証明されます。

来週は、数秒でアプリを作成できるUWP用のVSテンプレートのセットをリリースします。 これは「内部」プロジェクトに使用されています。 VSだけに適切なビルディングブロックが組み込まれていれば、UWPがすぐにRADフレームワークになり得るという点が証明されます。

@Noemataかっこいいですね！ 私はかなり興味があります！

.NetベースのクロスプラットフォームUIフレームワークが必要な場合は、任意の設計言語に適応できます。 もう探す必要はありません、コメットです。

https://github.com/Clancey/Comet

時間があれば、まだ初期段階なので貢献してください。
Cometは基本的に存在するすべてのプラットフォームを対象とし、各プラットフォームのネイティブコントロールを対象にするか、Skiaを使用してすべてを描画するかを選択できるため、すべての一貫性が保たれます（Flutterの方法とまったく同じです）。

宣言型UIとMVUパターンを使用します。 これは、マイクロソフトのプリンシパルプログラムマネージャーアーキテクトであるJamesClanceyによって開発されました。 まだ正式にはサポートされていませんが、十分なコミュニティの牽引力があれば、サポートされる可能性があります。

Cometでは、UIは単なるライブラリであるため、Cometにマテリアルデザインライブラリがあるのと同じように、WinUIライブラリを開発できます（またはMicrosoftが作成できる場合もあります）。

.NetベースのクロスプラットフォームUIフレームワークが必要な場合は、任意の設計言語に適応できます。 もう探す必要はありません、コメットです。

@nerocuiこれはクールに聞こえますが、少なくともそれを見ると、XAMLデザイナーは存在しません。 複雑なUIを構築することは、現在の段階ではおそらく非常識です。 しかし、それは有望に見えます。

.NetベースのクロスプラットフォームUIフレームワークが必要な場合は、任意の設計言語に適応できます。 もう探す必要はありません、コメットです。

@nerocuiこれはクールに聞こえますが、少なくともそれを見ると、XAMLデザイナーは存在しません。 複雑なUIを構築することは、現在の段階ではおそらく非常識です。 しかし、それは有望に見えます。

そして、それはドラッグアンドドロップではなく、コードに変更が加えられたときのデザイナーのUIのリアル​​タイムプレビューに関するものです。

来週は、数秒でアプリを作成できるUWP用のVSテンプレートのセットをリリースします。 これは「内部」プロジェクトに使用されています。 VSだけに適切なビルディングブロックが組み込まれていれば、UWPがすぐにRADフレームワークになり得るという点が証明されます。

これはNoesisGUIを使用していますか？ もしそうなら、LOBアプリに必要な機能が不足していることがたくさんあります。 さて、UnityをターゲットにしたWinUIは素晴らしいでしょう。

私はXAMLの現在の状態を文書化するためのリポジトリを作成しました。うまくいけば、人々がXAMLのさまざまなフレーバーでタスクを実行する方法をリストする洞察と実際のコードスニペットを手伝って貢献してくれるでしょう。

https://github.com/gatewayprogrammingschool/XAML-標準化

単純な問題です。今日のサンドボックスを超えて、クロスプラットフォームに必要なものを受け入れてください。 すでにWindows/OSの他のすべての側面でそれを行っているのは、なぜUIではないのか。

サンドボックスクロスプラットフォームを取ります。

差出人： [email protected]
送信日：2020年2月29日土曜日午後8時13分
宛先：microsoft / microsoft-ui-xaml [email protected]
Cc：シャープ忍者[email protected] ; コメント[email protected]
件名：Re：[microsoft / microsoft-ui-xaml]ディスカッション：WinUIはクロスプラットフォームである必要があります（＃2024）

単純な問題です。今日のサンドボックスを超えて、クロスプラットフォームに必要なものを受け入れてください。 すでにWindows/OSの他のすべての側面でそれを行っているのは、なぜUIではないのか。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、 GitHubで表示通知/unsubscribe-auth/AD3GCLDKTTDCWIJ2ED3OKC3RFG6S3ANCNFSM4K3JAUQA 。

高性能C++コンポーネントをC＃と統合することは、UWPでは簡単です。 DirectXサーフェスへのアクセスも大幅に改善されています。

@Noemata私が気にかけているのは、最初からC ++を作成する必要がないことを除いて、WinDevは、C ++ API、Managed Direct X、XNA、.NETの適切なAOTコンパイルに関して、.NET言語を同等にするすべての試みを失敗させ続けます。コード、COM機能、...。

WinUI 3.0をクロスプラットフォームにすることは、既存の.NET/FormsアプリケーションをWinUIに移植するための議論になります。

最初はmacOSをサポートするだけで十分ですが、Windowsと同じパフォーマンスがない場合や、アニメーションなどのすべての機能がない場合でも問題ありません。

Windowsはリファレンスプラットフォームです。 もちろん、最高のパフォーマンスを得るには、DirectXに結合する必要があります。

私の意見では、macOSをサポートするためだけにHTML + JSで大規模なC＃アプリケーションを書き直そうとしても意味がありません。 また、新しいデスクトップアプリケーションの場合は、C＃の方が適しています。

デスクトップアプリケーションの場合、C＃とXAMLはHTML+JSよりもはるかに信頼性があります。

WinUI 3.0をクロスプラットフォームにすることで、.NET、C＃、およびXAMLの将来が保証されます。

こんにちは、みんな

私はロンドンで働いているWPF契約開発者です。 2006年以来、多くの金融機関向けにWPFを使用して複雑で高性能なユーザーインターフェイスを構築してきました。これについての私の見解は次のとおりです。

1）英国の雇用市場を注視しています。 2006年以降に宣伝されたWPFジョブの100％（そのうち1000は数えられています）は、金融セクター向けの高性能な金融取引デスクトップアプリを構築するためのものです。 あらゆる業界のUWP開発者に宣伝されている仕事はまだありません。

2）これらのデスクトップトレーディングアプリは、UWPまたは今後のWinUIを使用できません。複雑な理由がたくさんあるため、WPFと比較すると十分ではありません。 また、フルーエントデザインは、これらのユーザーが興味を持っているものではありません。Excelグリッドのように見える必要があります。アニメーションやスタイリングはなく、データと驚くべきパフォーマンスだけです。

3）これらの顧客は、クロスプラットフォームソリューションにはまったく関心がありません。 誰もMacを使っておらず、モバイルは彼らが興味を持っているものではありません。

4）これらのWPF開発チームは、サードパーティのWPFコントロールライブラリに多額の投資（時間とお金）を費やしているか、私のような人々を介して開発された複雑でパフォーマンスの高いカスタムコントロールスイートを持っています。 非常に重要なメリットがない限り、WPFから離れることはありません（これは、予見可能なものにはなりません）。

5）これらの金融機関の場合、デスクトップ/ WPF用に明示的に作成する必要のないアプリケーションは、WebテクノロジーとJavascriptを使用して作成されます。 彼らはそれ以上にエキゾチックなものには興味がありません-フラッターやブレイザーなどはありません。

これが英国の状況です。 何百人ものWPF開発者が、すぐに新しいものに移行することを望んでいません。 ゼロUWP開発者（ストア用のアプリを開発している少数のワンマンバンドを除く-ストアの状態を見ると疑わしい）

また、私はクロスプラットフォームに関するすべてのヒステリーを理解していません。 モバイルとデスクトップの両方にまたがるクロスプラットフォームはばか者の用事です。 決して面白くはありません。 Microsoftは、デスクトップと電話で実行されるUWPアプリでこれを試しましたが、これは惨事でした。アプリを、複雑で興味深いことを何もできない最も単純なUIに制限しました。 デスクトップデバイスとモバイルデバイスは、さまざまなタスクとユースケース向けに構築されており、さまざまなアプリが必要です。これは誰もが知っています。

私にとっては、下位互換性を犠牲にすることなく、MicrosoftがWPFに直接投資することをもっと望んでいます。 管理されていないC++でのWPFサポート制御の開発を確認して、金属に近づいて作業できるようにしたいと思います。 より優れたバインディングテクノロジー、より優れたデータテンプレート、部分継承を含むより優れたコントロールテンプレート機能が必要です。 より優れたデバッグツールとビジュアルツリーアナライザーが必要です。 XAMLデバッグがもっと具体化されるのを見たいです。 UIでより良いマルチスレッドサポートが必要です。 私はたくさんのものが欲しいので、私の仲間のUKWPF請負業者もそうです。
現在のマイクロソフトのロードマップでは、私が欲しいものは何もありませんし、気にしないものもすべてあります。

Microsoftがこのビジョンをサポートしていない場合（現時点では明らかにサポートしていません）、プランBは、オープンソースの貢献を介して必要なプラットフォームにWPFを形成するコミュニティになります-Microsoftが新しい許可に関してより軽いタッチを受け入れると仮定しますWPFフレームワークの一部になるためのコードとアイデア。

@deanchalkこれのほとんどは、WPFに関心があることを示すために、WPFリポジトリに配置したほうがよいと思います。ここに投稿すると、ほとんどの場合、WinUIリポジトリで行われていること/この問題で説明されていることに関心がないことがわかります。 それは有効な入力ですが、それはおそらく無効な議論を超えて建設的な何かにつながることはありません。

@weltkante @deanchalk WinUIで「レガシーコントロールのサポート」を要求するリポジトリに問題があります：https：//github.com/microsoft/microsoft-ui-xaml/issues/1833
少なくともポイント4）はその問題に当てはまり、Microsoftによる投資を主張するためにprobabyをそこに再投稿する必要があります。

@deanchalk 、私はまだWPFの大ファンです。 ありがたいことに、マイクロソフトから愛を得始めているのは素晴らしいツールです。 マイクロソフトが最初にWPFを削除することを選択した方法は、最も残念なことでした。 UWPは光沢のある新しいおもちゃであるため、WPFへの継続的な投資を妨げるべきではありませんでした。

UWPは多くの点で、正しい方向に進んでいました。 残念ながら、最初の反復では、WPFを使用していて、移行を検討した可能性のある人々にとって最も重要な要件のいくつかが無視されていました。 とりわけ、単一の組織の壁の中でのXAML断片化のかなり驚くべき状態です。 WPF！= Silverlight！= UWP！=Xamarin。 おお！

私は、2020年にWPFに定着することを選択したWPF開発者にはあまり同情していません。物事はかなり進んでいます。 WinRT APIを使用できるXAMLアイランドを使用すると、UWPへの移行を開始するための非常に簡単なパスが提供されます。 また、大規模な変換を行うことを選択した場合、UWPはもはや不足していません。

より大きな問題は、実際に次に何が起こるかについてのマイクロソフトからの明確さの欠如のままです。 XAML Nirvanaを望んでいたすべての人は、UWPでもう一度再生しているSilverlightの大失敗をあきらめました。

WinUIは明らかに再ラベル付けされたUWPであるため、目撃するのは苦痛です。 また、Microsoftが、UWPが何であるか/何であったかを私たち全員が忘れてしまうことを望んでいることも同様に明白です。

それでも、Microsoftの左手は、右手が行っていることと常に調和しているわけではありません。 WindowsXは、Win32とそれに付属するすべてのもの（WPF / Winformsなど）を、パフォーマンスの低いサンドボックスで「実行される可能性のある」アプリケーションの見込みが薄いものにしました。 UWPは、現在もWindows 10、WindowsX以降のネイティブUIです。 WinRT APIは、Win32よりも大幅に改善されています。 ですから、2020年代に移行するか、2010年代にそれを突き出すかを選択する必要があると思います。

WinUIは明らかに再ラベル付けされたUWPであるため、目撃するのは苦痛です。 また、Microsoftが、UWPが何であるか/何であったかを私たち全員が忘れてしまうことを望んでいることも同様に明白です。

@Noemata WinUIは、UWP API（XAML、Composition、Inputなど）に基づく新製品です。 この名前は、基になるアプリモデルに関係なく、WindowsアプリのUIを構築するために使用できるため意味があります。

よくわかりません。 あなた自身が最後の段落で10Xについて言及しています。 UWPアプリモデル自体は、Windows10Xでプッシュされています。 さて、10Xが成功するかどうかは、時が経てばわかることです。 しかし、MSはそのメッセージングにおいて明確です。ご指摘のとおり、UWPは（Webと並んで）10Xのネイティブプラットフォームです。

@Noemataは2020年まで2010年に利用可能な機能に追いつき、私たちの多くは2010年にとどまることを余儀なくされています。

私たちの多くは、Silverlight、XNAを削除することから始まった書き換えトレインに飽きてしまい、MSが.NET Core、WinUIに必要な書き換えをどのように振る舞うかを見て、その過程で機能を削除しても、多くの人の心をつかむことはできません。顧客は、機能を減らすために書き換えを支払う必要がある理由がわからない、完全に機能するアプリケーションを使用しています。

現在、AndroidとWindows 10 Xタブレットを巧みに利用できるおかげで、XamarinとPWAは、WinUIではなく、私たちが楽しみにしているものです。

@pjmlp 、おそらく。 どの機能が欠けているのか知りたいですか？ かなり大きなWPFアプリをUWPに移植しました。 最大の頭痛の種は、セキュリティサンドボックスと、それと戦うのではなく、それを使って作業することを学ぶことでした。 以前は、データグリッド、DB接続、高速通信用の適切なAPIなどの欠落部分がありました。 現在、不足しているものはほとんどありません。 WPFでは、これほど簡単に実行できなかったことがたくさんあります。 公平を期すために、現時点では、WinRT APIへのアクセスを利用してWPFで実行できなかったことはありません。ただし、UWPはより最適な方法でマシンコードにコンパイルされ、より優れたDirectXレンダリングスタックを使用するため、パフォーマンスが低下します。 さらに、IPを保護したり、侵入者を防止したりする場合は、WPFコードを難読化する（脆弱にする）必要があります。

電話/タブレットは、ポイントソリューションのようなアプリに最適なデバイスです。 電話で交響曲を採点したり、超高層ビルを設計したりしたくはありません。デスクトップでモバイルを機能させるよりも、デスクトップアプリのポイントソリューション部分の一部をモバイルに向けることができます。

@Felix-Dev私はWinUIが何であるかを理解します。 WPF、Winforms、およびMFC / Win32開発者が購入しないという理由だけで、なぜさらに別のフォークが必要になったのか疑問に思います。 より良い戦略は、移行をより魅力的にするか、痛みを軽減するか、またはその両方にすることでした。

MicrosoftはUWPで多くのことを正しく行ってきました。 あらゆる種類のユースケースをカバーするサンプルアプリが豊富にあります。 不足している機能と同様に、彼らは遅れて到着しました。 本当に手遅れですか？

@Noemata WinUIは、UWP UIスタックをOSから切り離すことが絶対に必要な手順であるため、おそらくどちらの方法でも（WinUIデスクトップの有無にかかわらず）発生します。 Windows 10が最初にリリースされたときにWinUIがすでに存在していたとしたら、それが最善でしたが、そうでなかったのには理由があります。

手遅れです...UWPコミュニティの不和チャンネルで多くのそのような議論があり、ここでも数え切れないほどの情熱的な交流がありました。 船はすでに出航していると考える人もいれば、UWPプラットフォーム/ WinUIが成長して成熟し、主要な開発プラットフォームになる可能性があると考える人もいます。 多くのアイデアを持つ多くの人々は、MSの最良のアプローチがどのように見えるか（つまり、xplatformに移行するかどうか）。 事実、チームは現在WinUI 3の開発に熱心に取り組んでおり、そのリリースにより、WinUIを前進させ、コミュニティの支援を得て、Windowsをターゲットとする開発者が選択するフレームワークとなるようになります。 。

@Noemata 、まず第一に、Telerik、Component One、...などの既存のサードパーティコンポーネントライブラリとの互換性

そうすれば、最初に何も書き直す必要がなくなります。前述のように、書き直しにうんざりしています。

DirectXに関しては、WPFの3Dモデリングクラスがサポートされていないだけでなく、C ++を作成することが期待されています。これは、MicrosoftがDirectXのランタイムプロジェクションを作成するのに煩わされることがなく、なんとなく快適なC ++/CXダイアレクトが言葉に置き換えられたためです。能力は劣りますが、C ++/WinRTの方が準拠しています。

これに加えて、完全に機能するWPFコードを破棄するだけでなく、WCF、EF6コードにも同じことを行う必要があります。

UWPはWin32よりもはるかに優れたAPIであり、どういうわけかLonghornが本来あるべき姿であると私は信じていますが、Microsoftが多くの組織からの書き換え予算を使い果たしたため、これが実行される方法はあまりにも多くのブリッジを焼き尽くしました。

@pjmlp 、これらはすべてかなりおとなしいカウンター引数を持つ良い点なので、私も試してみません。 WPF 3D APIのサポートがないことは、個人的には大きな打撃でした。 3DのWPFバインディングオプションを考えると、新しいアプローチを学ぶ必要は面白くなく、はるかに能力が劣っていました。 UWPでの3DのC＃の代替手段がありますが、3Dモデルでのバインドの利点を体験すると、あまり役に立ちません。

C ++ / CXは、C ++ / WinRTで解決するのに時間がかかりすぎたもう1つの問題点でした。これは、来週いつか安定する可能性があります（まだ変化しています）。

WCFは機能していません（申し訳ありませんが、新しいオプションの方がはるかに優れています）。 EF6には、はるかに優れた移行ストーリーが必要でした。 あなたは再書き込み予算の大失敗@pjmlpに絶対的に正しいです、明らかにこれはマイクロソフトが取得していたものであり、テクノロジーの狂気/一貫性のないチャーンを考えるともはや考慮しません。

@ Felix-Dev、あなたも完全に有効なポイントを作ります。 UIデカップリングは、最初から存在している必要があります。 XAMLに基づくxplatformUIを求める人々は、要求を言い換えて、APIサーフェス（別のJava / Silverright / Uno Platform / Unity / Whatever…最終的には）を複製するミニOSを備えた選択したプラットフォーム上のXAMLレンダリングエンジンを求める必要があります。メタルアプリに近いHTMLで終わることは考慮し始めることができません）。 私は現在、最新のMS内部イニシアチブに精通していません。 外を見ると、WinUIは、船が再び直立していることを示す手を振っているフラグです（あと何回ですか？）。 Silverlightの死により、Microsoftを守ることは不可能になりました。 二度とその剣を拾うことはありません。 私が実際にやっているのは、UWPの死を嘆いていることだと思います:-(...痛いです。https：//www.youtube.com/watch？v = uBiewQrpBBA

チャーリー==マイクロソフト

クロスプラットフォーム？ マイクロソフトはUNOを購入し、titで済ませる必要があります。

クロスプラットフォーム？ マイクロソフトはUNOを購入し、titで済ませる必要があります。

私は、どんな解決策がそれ自体を提示するにせよ、それがウェブブラウザやある種のウェブビューに依存しないことを望みます。 プラットフォームのネイティブウィンドウまたはUIサーフェスが何であれ、UIを表示しますが、Windowsの場合と同じように見えます。

クロスプラットフォーム？ マイクロソフトはUNOを購入し、titで済ませる必要があります。

私は、どんな解決策がそれ自体を提示するにせよ、それがウェブブラウザやある種のウェブビューに依存しないことを望みます。 プラットフォームのネイティブウィンドウまたはUIサーフェスが何であれ、UIを表示しますが、Windowsの場合と同じように見えます。

これが、Windows 7を除いてUNOが行う方法です。Windows7は、Webブラウザーを使用しているため、唯一の例外です。

クロスプラットフォームのデスクトップソリューションを必要とするWPF開発者にとって、Wineは実行可能なオプションかもしれません。 大規模なWPFアプリケーション（主に.NET Core WPF）をLinuxwithWineで実行するように移植することに大きな成功を収めました。 私はあなたが始めるのを助けることができる記事を持っています：
https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html

また、いくつかのWinFormsアプリをLinuxに移植し始めました。 これまでのところ、問題は発生していません。

Wineは、Mac、Chrome OS、Androidでも実行できるようにする必要があります。 Linuxを試しただけです。

私にとってこれは、抽象化レイヤーとしてDirectXを使用することが機能し、従うべき実行可能なモデルであることを示しています。 .NET WASMが成熟すれば、WebGLを使用したWebでもうまく機能すると思います。

MicrosoftにWineを手伝ってもらうこと（少なくとも彼らがWineを壊さないことを確認すること）は大いに役立つでしょう。 彼らはWineLibを使用して真にネイティブなソリューションを作成するのに役立つ可能性があり、彼らの専門知識を考えると、それほど手間はかからないと思います。

AvaloniaUIはすでにクロスプラットフォームです。 WinUIを改善するために、プロジェクトの人々にヘルプとフィードバックを求めないのはなぜですか？

ええと、宇野プラットフォームほどではありません。 UnoプラットフォームはWeb上でも実行されます（WASM）。 アバロニアにはこの機能がありません。

Avaloniaは、独自のXAML方言も使用しています。これは、Unoが避けようとしていることです。

差出人： [email protected]
送信日：2020年3月27日金曜日4:09:30 AM
宛先：microsoft / microsoft-ui-xaml [email protected]
Cc：シャープ忍者[email protected] ; コメント[email protected]
件名：Re：[microsoft / microsoft-ui-xaml]ディスカッション：WinUIはクロスプラットフォームである必要があります（＃2024）

AvaloniaUIはすでにクロスプラットフォームです。 WinUIを改善するために、プロジェクトの人々にヘルプとフィードバックを求めないのはなぜですか？

ええと、宇野プラットフォームほどではありません。 UnoプラットフォームはWeb上でも実行されます（WASM）。 アバロニアにはこの機能がありません。

—
コメントしたのでこれを受け取っています。
このメールに直接返信するか、GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024#issuecomment-604893750で表示するか、 https：//github.com/notifications/unsubscribe-auth/の登録を解除してください

WinUIのテクノロジのほとんどはSliverlightからのものであり、Sliverlightは実際にクロスプラットフォームを実現しています。 したがって、WinUIクロスプラットフォームは、テクノロジーではなく戦略に依存します。

正直なところ...それは実際にはとても哀れなマイクロソフトが追いつくことを試みています...彼らは「大きな」市場シェアだけを気にし、彼らの顧客/製品ファンが何を望んでいるかを見ていません。

マイクロソフトは、Webが非常にひどい場合でも、DESKTOPAPP開発が古いWEB開発に移行した理由です。

すべてのXAML開発者は、HTML/CSSが非常にゴミであることに同意していると確信しています。

しかし、それでも... HTML、CSS、DOM ... React、Angular、Vueなどのフレームワークを使用して、もう少し快適なものにしようとしています。 人々はまだこの時代遅れのウェブに焦点を合わせていましたが、新しいもののために2〜4年ごとに死ぬMicrosoftの新しいクローズドソースのWindows専用プラットフォームには焦点を当てていませんでした。

XAMLベースのWin-appプラットフォームは、何年も前にオープンソースになっているはずです。 WEBSITE、Windows、Mac、Linux、Android（お客様が希望するプラットフォーム）にデプロイしたら、writeを実行する必要があります。 Windowsストアは、XAML/UWPアプリレンダラーとクロスプラットフォームである必要があります。 （GoogleChromeがHTML/ CSSレンダラーとクロスプラットフォームであるのと同様です）。

Microsoftの黄金時代には、XAMLベースのクロスプラットフォームアプリがWebを破壊する可能性があり、このCSS、HTML、DOM、および無数のフレームワークを処理する必要はありませんでした。

しかし、いいえ、マイクロソフトがプロプライエタリソフトウェアに執着しているため、Webに負けてしまいました。

一方、GoogleのFlutterは、私が常にXAMLに求めていたものになりつつあります。

WinUI3がMAUIのターゲットプラットフォームになることを期待しています。 Unoプラットフォームは、 WinUI3プレビューがサポートされることをすでに発表しています。
では、 @ jeromelaban / Microsoftが本当に必要としているのは、Uno / MAUIの統合ですか？ MAUIは、Web（ブラウザー）ターゲットのないFlutterやUnoよりも有用なIMOではありません。

MAUIリポジトリにもコメントを残してください。

どこでもWPF（Silverlight）！

DirectXを他のプラットフォームに移植するのは大変な作業のようです。おそらく解決策は、DirectXの代わりにOpenGLまたはVulkanを使用することです。

GoogleにはANGLEがあり、呼び出しとシェーダーをネイティブAPI（desktop gl [swiftshaderソフトウェアレンダラーによって提供される可能性があります]、vulkan、directx、metal）に変換することにより、任意のプラットフォームでOpenGLESをネイティブに実行できます。 また、Skiaと一緒に実行される、ChromeとFlutterのコア部分でもあります。

Microsoftは、GUIアプリ用のDirectXの小さな（おそらく出発点として）サブセットを作成し、ANGLEと同じようにネイティブAPIに変換することができます。

「異なるLinuxディストリビューションサポート」の問題は、Linuxユーザーが自分で非互換性を修正するのに十分なスキルを持っていることが多く、それでもDockerがサーバーに対して行うのと同じようにデスクトップ用のパッケージを統合するFlatpakがあります。

Lonjeチャットで言及https://www.lonje.com/message/1968439855/

WinUIは、カスタムテーマをサポートしながら、MacとLinuxのネイティブテーマもサポートする必要があると思います。
Macユーザーについてはよくわかりませんが、Linuxコミュニティはデスクトップの外観を制御するのが好きです。
彼らはすでにGtkを持っているので、WinUiフレームワークにラップするのは良いことだと思います

WinUIは、カスタムテーマをサポートしながら、MacとLinuxのネイティブテーマもサポートする必要があると思います。
Macユーザーについてはよくわかりませんが、Linuxコミュニティはデスクトップの外観を制御するのが好きです。
彼らはすでにGtkを持っているので、WinUiフレームワークにラップするのは良いことだと思います

WinUIはスタイル言語であり、基盤となるXAMLフレームワークでは自分でテーマを設定する必要がありますが、デフォルトのテーマも提供されているため、これを行うのは間違いなく困難です。

私は過去に、プロジェクトは、コミュニティがmacOSおよびiOS用のメタルレンダラー（場合によってはAndroid用のSkiaレンダラー）を開発できるように構成する必要があることを提案しました。

すべてのプラットフォームで同じデフォルトのスタイルとテンプレートを使用することも、AndroidとmacOSスタイルのデフォルトのテンプレートとリソースを作成することもできます。