コントロールとデフォルト値でのnull許容データ型のサポートについて話してもらえますか？ 例として、DateTimeOffsetを返すDatePickerとDateTimeOffset？を返すCalendarDatePickerあります。

• これらの一方がnull可能で、もう一方が無効でないのはなぜですか？ これは、DatePickerがWindows 8の時間枠で以前のAPIを使用して開発されたためですか？
• コントロールでnullを許可/禁止する構成プロパティを追加することを検討する必要がありますか？
• NumberBoxなどの新しいコントロールでDefaultValueプロパティを検討する必要がありますか、NaNをデフォルトのままにする必要がありますか、それともデフォルトのnullでnull許容のdoubleに切り替える必要がありますか？
• NumberBoxのValueプロパティをnull許容にすることを妨げるnull許容値を返し、サポートすることに関して、WinRT / OS XAMLの制限はありますか？ もしそうなら、CalendarDatePickerはどのように実装されましたか？
• これは、＃1721と＃1708のNumberBoxの議論に直接関係しています。

また、WinUI 3.0に依存しないNumberBoxの未解決の問題を修正するためのロードマップは何ですか？ 長く待つのではなく、WinUI2.4周辺でこのコントロールの使用を開始することをお勧めします。 私の意見では、まだ完全には焼き付けられておらず、これを本番アプリに取り込むのは不快です。

私が疑問に思ったことについて話し合うもう1つの興味深いアイデアは、WinUI 3.0がオープンソースになった今、変更を壊すというMicrosoftのポリシーはどうなるのでしょうか。

これまで、Microsoftは事実上重大な変更を行ったことがありません。 これは、数年（または10年）後にすべての混乱が蓄積するまで、一般的には良いことです。 また、オープンソースプロジェクトの標準でもありません。 たとえば、最終的にはListBoxはListViewで段階的に廃止され、MessageDialogはContentDialogで段階的に廃止される必要があります。APIにももっと良いクリーンアップがたくさんあると思います。

私は企業が変化を嫌うことを知っています-正当な理由があります。 また、新しいAPIへの移植を簡単にするために、比較的簡単な（機能的に同等の）ドロップイン置換が利用可能でなければなりません。 これは、ケースバイケースで評価し、判断を下す必要があります。

重大な変更を許可するものとしてメジャーリリース（たとえば、WinUI 4.0）を確立できるかどうか疑問に思っています。 これにより、過去のすべての過ちを乗り越えなくても、プロジェクトを成長させ続けることができます。 基本的に、Microsoftは、.NETCoreをベースにして完全な.NETFrameworkを削除することにより、.NET5でこれを行うことをすでに決定しています。

これについては、話し合ったら文書化することをお勧めします。

前回の電話以降の進捗状況に基づいて、チームはWinUI3がリリースの準備ができていると現実的に考えるのはいつですか。

• ビルド2020（4月-5月）
• Ignite 2020（10月〜11月）
• 〜2021

また、新しいAOTソリューションと.NET5をまとめる.NETチームへの作業はどの程度依存していますか。

最後に、Windows側には、Windows10Xリリースの準備ができているか、その前に開発者が特殊なアプリを作成するようにというプレッシャーがありますか？

WinUI2.XプロジェクトをWinUI3.0に簡単に変換するツールはありますか/あるべきですか（これを手動で行うと、大規模なプロジェクトでは多くの作業が必要になる可能性があるため）？

部屋の中の象-WinRT（＃1856）

部屋の中の象-WinRT（＃1856）

サンドボックス化されていないアプリモデルが登場します。これはWPF（Win32 APIを含む）と同じ方法で実行されますが、最新のWinRT APIにアクセスでき、Direct X12で実行される新しいXAMLを使用してオープンソースのUIとコントロールを使用できます。

サンドボックス化されていないアプリモデルが登場します。これはWPF（Win32 APIを含む）と同じ方法で実行されますが、最新のWinRT APIにアクセスでき、Direct X12で実行される新しいXAMLを使用してオープンソースのUIとコントロールを使用できます。

わお。 うわーうわー!!!!

それは驚くべきことを超えています！ このためのETAはありますか？それは電話で話し合われますか？

めちゃくちゃすごい！

サンドボックス化されていないアプリモデルが登場します。これはWPF（Win32 APIを含む）と同じ方法で実行されますが、最新のWinRT APIにアクセスでき、Direct X12で実行される新しいXAMLを使用してオープンソースのUIとコントロールを使用できます。

わお。 うわーうわー!!!!

それは驚くべきことを超えています！ このためのETAはありますか？それは電話で話し合われますか？

めちゃくちゃすごい！

それは私たちがWinUIについて最初に学んだことでした。 ETAは今年のもので、// Build /で明確な日付が与えられると思いますが、電話中に気軽に質問してください。

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

@jtorjoWinUIロードマップを参照してください。 詳細（VSプロジェクトテンプレートなど）については、 https：//github.com/microsoft/microsoft-ui-xaml/issues/1045も参照して

@ mdtauk @ Felix-Devこれらのドキュメントを読み直します。 以前にこれを尋ねたことを覚えています-（サンドボックス化されていない）アプリからwin2dを簡単に使用できる限り、私は幸せ以上になります！

@jesbis noobの質問で申し訳ありません-どうすれば通話に参加できますか？

今日の後半に明日の電話の情報を設定します。数時間以内に道順を投稿します。

遅延は、新しいブロードキャストシステムを初めて使用するためです。この後、スムーズに進み、早期に準備が整うはずです🙂

私は（とにかく私にとって）面白い考えを持っていました。

今日のASP.NETCommunity Standupライブストリームを見ると、技術デモのようなものでしたが、基本的に4人のMS開発者がライブコーディングストリームを実行しているのがわかりました。 また、ライブコーディングセッションをフルにこなすTwitchの耳を傾けます。

つまり、WinUI 3がリリースされ、コードベース（またはそのほとんど）がすべてオープンソースになった後、WinUIでの作業の一部を時折ライブストリーミングするチームメンバーはいますか？

WinUIの露出を増やし、人々がコードベースを気軽に探索できるようにする良い機会であり、質問はたまに出される可能性があります。 〜チャットエンゲージメントを常に完全に行うことは非常に逆効果になるため、お勧めしませんが、たまにQ＆Aを行うこともあります。

私は、特に就業時間中に、そのタイプのものにどのようなMSポリシーがあるのか​​わかりません。 あなたの考えを聞くのは面白いでしょう。

こちらが明日のYouTubeライブイベントリンクです！

https://youtu.be/MXTVqgB4rW0

これまでのすべてのコメントと質問に感謝します！ 私たちはすべてに到達しようとするか、時間がない場合はフォローアップのために追跡します。

UIのパフォーマンス/ fpsについてガイドに何かありますか？ 最近のWindows10で私が抱えている最大の不満の1つは、Surface Bookのようなマシンでは、高DPIディスプレイでひどいパフォーマンスが得られ、透明度と追加のモニターを組み合わせるとさらに悪化することです。 それは可能なことの範囲外かもしれませんが、特にこれらの条件下で、それがどのように流動的でうまく機能するかについてここで考慮事項はありますか？

ボーダレス/透明ウィンドウの優先度を上げることを検討してください（https://github.com/microsoft/microsoft-ui-xaml/issues/1247）。 これは、私たちのようなアプリのWinUI採用ブロッカーです。

cc： @crutkas

フチなし/透明ウィンドウの優先度を上げることを検討してください（＃1247）。 これは、私たちのようなアプリのWinUI採用ブロッカーです。

cc：@crutkas

これには、WPFと同様に、プロパティを使用してWinUIXamlに追加されたトップレベルウィンドウ要素が必要になる可能性があります。 ＃1323

WinUIの「ウィンドウ処理の将来」についてさらに学ぶことは素晴らしいことです-少なくとも議論/対処するのに役立つ関連するリクエストがたくさんあります。

おそらく以前に尋ねられたことがあります。

私にとって、それは常にコードの再利用性の問題でした。
これは2つの質問につながります：

1. .NET Core 3およびC＃8.0のサポートは間もなく開始されますか？
2. Unoプラットフォームアプリの開発を容易にするために、UWP / WinUIチームからのさらなるステップが表示されますか？

もう1つは、UWPでサポートされているWPFの欠落ビットがいつ表示されるのでしょうか。

おそらく以前に尋ねられたことがあります。

私にとって、それは常にコードの再利用性の問題でした。
これは2つの質問につながります：

1. .NET Core 3およびC＃8.0のサポートは間もなく開始されますか？
2. Unoプラットフォームアプリの開発を容易にするために、UWP / WinUIチームからのさらなるステップが表示されますか？

もう1つは、UWPでサポートされているWPFの欠落ビットがいつ表示されるのでしょうか。

.NET Coreコードは両方で機能するはずなので、WPFアプリはUIXamlとUIコードを変更するだけで済みます。

UWPアプリは、WinUI 3.0の名前空間の変更で正常に動作するはずです。サンドボックスから抜け出すには、さらに作業が必要になる場合がありますが、詳細はまだ不明です。

WPFの欠落ビットは確認されていませんが、問題が発生しました。 ＃719

@weitzhandler

公式にはサポートされておらず、C＃8のすべての機能が機能するわけではありませんが、WinUI / UWPでC＃8のほとんどを既に使用できます。 こちらをご覧ください。

私はこれを行い、問題は発生していません。 私はすべてを試したわけではありませんが、「デフォルトのインターフェイスメンバーとインデックスと範囲」だけが欠落しているビットのようです。

kmgallahanがC＃8の使用について言ったことを増幅するだけです。私は多くの新機能を使用してきましたが、まだ実装されていないデフォルトのインターフェイスメンバーが本当に必要でした。

皆さん、ありがとう。
それでも追加できるとしたら、古いcsprojタイプもちょっと面倒です。

@jesbis

この問題をXAMLコントロールギャラリーで開いたところです。 よろしければ、通話中に話し合うこともできます。

おかげで、私たちはすべての質問に答えようとします！

UIのパフォーマンス/ fpsについてガイドに何かありますか？

@ryvanvelここにいくつかのパフォーマンスガイダンスがあります：

https://docs.microsoft.com/windows/uwp/debug-test-perf/performance-and-xaml-ui

そして、役立つかもしれない他のいくつかのブログ投稿とビデオ、例えば：

https://blogs.windows.com/windowsdeveloper/2015/10/07/optimizing-your-xaml-app-for-performance-10-by-10/

https://channel9.msdn.com/Events/Build/2015/3-698

https://channel9.msdn.com/Events/Build/2017/P4173

このバグは、私が覚えている限り、Windows 10にありました。もっと早く対処されることを願っています： https ：

残念ながら、時間通りに調整することができません。録音はありますか？

編集：通話の録音はここで見つけることができます： https ：

@jesbisはこちら：

こちらが明日のYouTubeライブイベントリンクです！
https://youtu.be/MXTVqgB4rW0

YTリンクをたどると、通常の時間より1時間遅れて、この時間の終わりにのみ開始されるように見えますが、本当ですか？

@weitzhandler開始時間は投稿の上部にあります。 これも3回目の呼び出しなので、「通常」はストレッチです。

@weitzhandlerこれまでの3つの通話はすべて、太平洋時間の午前9時に開始するようにスケジュールされていたと確信しています。

お二人ありがとうございます、ご迷惑をおかけして申し訳ありません。 また近いうちにお会いしましょう。

Chromiumを利用したWebView2が、現在のWebViewからWebResourceRequestedようなイベントを公開して、開発者が個々のWebリクエストを除外できるようにするかどうかを知りたいと思いました。 私は自分のアプリの1つでその特定の機能に大きく依存しており、それが新しいコントロールでも引き続き使用できるかどうか疑問に思っていましたが、同じように機能します。

頑張ってくれてありがとう！ 😄🚀

PDFを生成するためのツールはありますか？ Win2Dにはすでに多くのすばらしいツールがあり、 CanvasRenderTargetからPDFを生成する機能は素晴らしい追加になるでしょう。

取得できませんでした-vsixのインストール方法は？ どこからダウンロードしますか？

たぶん私だけかもしれませんが、今日の電話にはがっかりしました。 より多くの技術者を含めてください。 PMは、議論に焦点を合わせ、スケジュールに合わせて移動する必要がありますが、回答は専門家に委任する必要があります（最後に向けてさらに行われたように）。

この電話の全員が開発者だと思います。詳細を知り、話し合う必要があります。 PMは非常に基本的なトピックに焦点を合わせており、詳細に立ち入ることができません。 たとえば、documentation / WebView / ProgressRingについての電話の冒頭での議論は、概念的には素晴らしいですが、非常に基本的であるため、私たちにとっては役に立たないと思います。 私たちは何年も何十年もXAMLを使用しており、あなたは専門家の聴衆に話しかけています（プレゼンテーションを聴衆に適応させることが重要です）。

@SavoySchuler言い換えると、基本的に、コントロールの使用方法、会社、アプリの使用方法を教えてください。 これは、材料のニーズと持っているのが良いことを区別するために必要です。 これは、機能のリソースに優先順位を付けるのに役立ちます。 これについては、次の2つの点で異なる考え方をする必要があります。

1. 機能-この場合、あなたが言ったことはおおむね正しいです
2. バグ/問題-この場合、いいえ、優先順位付けに役立つ例を提供するコミュニティは必要ありません。 製品をお届けする際には、品質が最優先事項です。 私たちはあなたにバグを伝えています、そしてあなたはそう、そう、それは持っていてうれしいと言っています。 修正が必要であることを証明します。 バグです。 たぶん、あなたは消費者にアプリを出荷したことがありませんか？ 少しでも間違ったことは、会社の最も価値のある部分であるあなたのイメージと認識に影響を与えます。 アプリ業界は非常に競争が激しいです。

コミュニティからバグが報告されたら、修正するようにスケジュールする必要があります。 不完全なコントロールの出荷を停止し、修正する予定はありません。 これは非常に馴染みのあるものに聞こえ始めています–それは何年も前にUWPで起こったことです。

電話で、私はウィンドウを2回起動し、次のように述べられました。

• これは実際にはWinUI3で作業中です（問題が凍結されているにもかかわらずhttps://github.com/microsoft/microsoft-ui-xaml/issues/1247）
• 機能追跡プロジェクト（昨日更新）（https://github.com/microsoft/microsoft-ui-xaml/projects/4）はWinUI2のものだけを追跡しています???

ここで明確にできますか？ WinUI 3バックログを表示する別の場所はありますか？ 何が来て何が来ないかを知ることは、計画の目的にとって非常に重要です。 ありがとう！

@SavoySchuler @jesbisと他の素敵なWinUIチームの皆さん、私は個人的にあなたの素晴らしい仕事と多大な努力に感謝し、WinUIをとても素晴らしいものにし、私のすべての質問に答えてくれたことに感謝しています。

参加してくださった皆様、本当にありがとうございました！

また、オーディオとTeamsの問題についても申し訳ありません。ハードウェアの問題を特定し、来月に向けてすべてを整理できると思います。

レコーディングは、それを作ることができなかった人のために今もライブです。

私たちは質問に目を通し、このスレッドで見逃したものに到達しようとします。

いくつかの質問のキャッチアップ：

PDFを生成するためのツールはありますか？

@MuziburRahman

WinUI 3.0 RTMでこれに到達する時間はありませんが、＃672のバックログでこれを追跡しています。この問題に、どのように使用するかについてコメントを追加してください。

vsixをインストールする方法は？ どこからダウンロードしますか？

@hannespreishuber

本番アプリのWinUI2.xの使用方法については、 https ：//docs.microsoft.com/uwp/toolkits/winui/getting-startedを

vsixをインストールして試すためのWinUI3.0Alphaの手順は次のとおりです。
https://aka.ms/winui/alpha

たぶん私だけかもしれませんが、今日の電話にはがっかりしました。 より多くの技術者を含めてください。 PMは議論に焦点を合わせ続ける必要があります[...]私たちは何年も何十年もXAMLを使用しており、あなたは専門家の聴衆に話しかけています（プレゼンテーションを聴衆に適応させることが重要です）。

@roblooこれに関するフィードバックをありがとう。 誰もが興味を持っている場合は、より多くの開発者を含め、特定のトピックについてより深く掘り下げることができます-久しぶりで、一般的なキャッチをしたかったので、最初の呼び出しではそれを試したくありませんでした-上。

また、過去にフィードバックがあり、多くの聴衆がまだWinUIに精通していないために、技術的すぎて詳細になりすぎることがあります。そのため、フィードバックのバランスを取るようにしています。

また、注意が必要な場合：開発者プラットフォームチームのPMの多くは非常に技術的であり、主要なプラットフォームや実際のアプリの本番コードを作成した経験があります。 それらのいくつかは、以前はマイクロソフトや他の会社のフルタイムの開発者でした。 また、PMとして常にコードを記述していますが、それが私たちの唯一の焦点では​​ありません🙂

最後に、バグと品質について：品質は私たちにとって非常に重要であり、バグ、テスト、品質インフラストラクチャに多くの時間を費やしています。 WinUI 2のコミットログで品質修正と新機能の比率を確認できます。オープンソースになると、WinUI 3でも同じように確認できます。とはいえ、バグのない主要なコードベースはありません。常にビジネスの優先順位のバランスを取る必要があります。

コントロールが不完全であると思われる場合は、未解決の問題を実行してください。

電話で、私はウィンドウを2回起動し、次のように述べられました。
これは実際にWinUI3で作業中です（問題がフリーズしているにもかかわらず＃1247）
機能追跡プロジェクト（昨日更新）（https://github.com/microsoft/microsoft-ui-xaml/projects/4）はWinUI2のものだけを追跡しています???
ここで明確にできますか？ WinUI 3バックログを表示する別の場所はありますか？ 何が来て何が来ないかを知ることは、計画の目的にとって非常に重要です。 ありがとう！

@riverarは、現在リポジトリ内の唯一のコードであるため、プロジェクトボードは現在WinUI2用です。

WinUI 3が適切に対処されるまで待機する必要がある問題には、 needs-winui-3ラベルを使用し

Chromium WebView仕様など、主要なアイテムの機能提案を別の仕様リポジトリに投稿し続けます。

https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/WebView2/WebView2_spec.md

WinUI 3 Xamlをオープンソース化できるようになると、追跡をGitHubに移行できるようになりますが、さまざまな理由から、3.0の開発を通じて、日々の作業項目の追跡の大部分は現実的には内部にとどまる可能性があります（多くの理由があります）。プライベートOSの依存関係を解きほぐし、他のOSコンポーネント開発チームと緊密に連携する必要があるなど）

ただし、これらのタグ付き機能の提案のほとんどは、最初の3.0リリースでは対処されないと言えます。主な重点分野は次のとおりです。

• WinUIをOSから切り離し、個別に出荷する
• Xamlフレームワークのオープンソーシング
• 優れたWinUIデスクトップアプリ開発エクスペリエンスの作成（win32の使用、パッケージ化、ウィンドウ処理など）
• Windows10Xを有効にする
• .NET Core / 5 + WinUIアプリの有効化

同時に大量の追加の新機能開発を試みて、それを遅らせたり不安定にしたりしたくはありません。

デスクトップ/ウィンドウサポートなどの大きな領域で具体的な進展が見られたら、提案と更新をリポジトリに投稿します。

WinUI 3 Xamlをオープンソース化できるようになると、追跡をGitHubに移行できるようになりますが、さまざまな理由から、3.0の開発を通じて、日々の作業項目の追跡の大部分は現実的には内部にとどまる可能性があります（多くの理由があります）。プライベートOSの依存関係を解きほぐし、他のOSコンポーネント開発チームと緊密に連携する必要があるなど）

これらの内部作業項目は、内部問題のような一般的な名前の空白のエントリとして表示されている場合でも、公開してリストすることはできますか？ これらが「ToDo」から「InProgress」、「Complete」に移行するのを見ると、プロジェクト全体がある程度進んでいることがわかります。

ただし、これらのタグ付き機能の提案のほとんどは、最初の3.0リリースでは対処されないと言えます。主な重点分野は次のとおりです。

• WinUIをOSから切り離し、個別に出荷する
• Xamlフレームワークのオープンソーシング

これはもちろん努力の中核ですが、OSコードから解放されているため、現在の実装に関するさまざまな問題や問題を解決できる可能性があります。

• 優れたWinUIデスクトップアプリ開発エクスペリエンスの作成（win32の使用、パッケージ化、ウィンドウ処理など）
• Windows10Xを有効にする

これは正しく行うために不可欠であり、フィードバックを受け入れる心を開いて、これらの両方をユーザーと開発者の手に渡す必要があります。 また、アプリランタイムとアプリモーダルはこのWinUIチームが所有していないため、それらを担当する人にフィードバックをフィルターできるようにする必要があります。

• .NET Core / 5 + WinUIアプリの有効化

現在のネイティブサポートは、C ++コードとWin32APIの形式で提供されますが、これは、C＃開発者が.NETをターゲットにする必要があることを意味しますか？ サンドボックス化されていないアプリモデルでは、.NETなしでC＃コーディングが可能ですか？

同時に大量の追加の新機能開発を試みて、それを遅らせたり不安定にしたりしたくはありません。

デスクトップ/ウィンドウサポートなどの大きな領域で具体的な進展が見られたら、提案と更新をリポジトリに投稿します。

CoreWindowがない場合（今後はUWPのみになります）-ウィンドウ処理は、初日から導入する必要があるものの1つです。 WPFには、コントロール、視覚的なスタイル設定、透明度などを処理するXAMLのWindowオブジェクトがあります。サイズ変更、最小化などを処理します。古いWin32フレームワークでは、XAML UIには関係のないサーフェスを手動でペイントする必要があります。したがって、このギャップはどのように埋められますか。 ？

これは、デュアルスクリーンデバイスに到達する前であり、UWP以外のアプリモデルとウィンドウ設定がそれにどのように適応するかを示しています。

これらの内部作業項目は、内部問題のような一般的な名前の空白のエントリとして表示されている場合でも、公開してリストすることはできますか？

私たちの目標は、コードに加えて、プロセス（問題追跡を含む）をオープンソースに移行することです。

まず、高レベルの追跡のためのWinUI 3.0マイルストーンがあり、

ただし、WinUI 3.0の日常の開発タスクのすべてがすぐに含まれるわけではありません。参考までに、現在、2020年に関連する数千日分の開発作業を追跡しており、まだすべてを移動する準備ができていません。今日のGitHubへの超きめ細かい追跡。 ただし、WinUI 2で行ったように、時間の経過とともにそれに到達します。

そのため、機能レベルの問題（これまでに開始されたもの（WebViewなど）など）から始めて、時間の経過とともにプロセスをGitHubに完全に移行します。

現在のネイティブサポートは、C ++コードとWin32APIの形式で提供されますが、これは、C＃開発者が.NETをターゲットにする必要があることを意味しますか？ サンドボックス化されていないアプリモデルでは、.NETなしでC＃コーディングが可能ですか？

.NET Nativeについて質問していますか、それとも.NETがまったくないのですか？ 技術的には、言語としてのC＃仕様は.NETに依存していないと思いますが、現在、C ++などにトランスパイルする予定はありません。

CoreWindowがない場合（今後はUWPのみになります）-ウィンドウ処理は、初日から導入する必要があるものの1つです。 WPFには、コントロール、視覚的なスタイル設定、透明度などを処理するXAMLのWindowオブジェクトがあります。サイズ変更、最小化などを処理します。古いWin32フレームワークでは、XAML UIには関係のないサーフェスを手動でペイントする必要があります。したがって、このギャップはどのように埋められますか。 ？

@ marb2000はそれに取り組んでおり、利用可能な場合はより多くの情報を共有できるようになります。

これは、デュアルスクリーンデバイスに到達する前であり、UWP以外のアプリモデルとウィンドウ設定がそれにどのように適応するかを示しています。

明確にするために、WinUI 3は、すべてのwin32デスクトップをHoloLensなどの他のプラットフォームに導入するわけではありません。複数のデバイスをターゲットにする場合は、ユニバーサルアプリとAPIが引き続き使用できます。

投稿が早すぎます。 完全なコメント：

@ robloo-私はあなたの多くの感情に同意することから始めたいと思います、そして私たちの成長する痛みを通して私たちと一緒にいてくれてありがとう。 私は私たちの技術的な問題のすべてに非常に散らかっていました、そして私は私が望むようにその質問を処理しませんでした。 ここでもう一度試してください。

憲章とリソース

このようなトピックを踏むことは決して人気がないことを私は知っていますが、私は透明性を信じており、私たちが直面している課題についてコミュニティとして率直に話し合い、私たちがそれらをどのように解決するかを決定するのに役立つ議論に参加できるようにしたいと思います。 この特定の課題は、時間とリソース資産の分割に焦点を当てています。 私たちのチームは3つの主要なイニシアチブに分かれています。

1. WinUI2の進歩
2. WinUI3の提供
3. オープンソーシングWinUI3

ご存知のように、A）これらは結合された目的であり、B）オープンソーシングWinUIは、WinUIが最終的にコミュニティのプルリクエストを受け入れる権限を与えられるため、チームの有限のリソースによってブロックされるのを防ぐことができるため、2と3にしっかりとダイヤルされます。

WinUI 2がコミュニティメンバーに十分なサービスを提供していないという点まで、目標2と3についてあまりにも前向きにダイヤルされた場合、その会話を行うことができ、優先順位を変更することができます。 バックログのすべてのバグを解決すると、WinUI3の市場へのリリースが最大6か月遅れることを知っておいてください。 代わりに、オープンソースのWinUIだけでなく、Win32開発者の大規模な基盤への関連性を拡大する、2と3を優先する場合、オープンソースコミュニティとチームの力でバグと機能リクエストのバックログをクリーンアップできます。私たちをサポートする細心の注意。 そのために、私たちの現在の理論的根拠は、アプローチの計画がこのプラットフォームをより速く前進させるだけでなく、より包括的にも前進させるということです。 バグの優先順位付けを手伝ってくれるように頼んだとき、質問は「私たちのチームが取り組むのに十分重要か」ではありませんでした。 しかし、代わりに「これは、WinUIをより早くオープンソーシングするよりも重要ですか？」 現状では、優先度1を進めるために取り組んでいる開発者のサブセットがあり、コミット履歴やアクティブな問題に影響を与えることができますが、その目的の範囲内で同じように優先順位を付ける必要があります。 「これがあなたにとってどれほど重要かを教えてください」というこの概念は、ニーズ（たとえば、製品がブロックされ、WinUI 3を待つことができない）と優れた点（たとえば、この技術的なエラーに気付いたが、既存の開発がない）をフィルタリングするのに役立ちますWinUIを待つことができるようにブロックされています3）。

私が明確に言いたいもう1つのことは、WinUI 2のバグの提出、機能要求の記入などにかかるすべての作業が、私たちに失われることはないということです。 WinUI 3がリリースされると、チームのかなりのサブセットが自由に作業項目に戻ることができるようになります。これにより、コミュニティがコードを送信できるようになるだけでなく、プラットフォームが進化します。 これは、現在、チームの全力が既存のUWPコミュニティと、まもなくWin32の助けを借りて取り組むというバックログを準備していることを意味します。

注意すべきもう1つの点は、OSからWinUI 3にコードを移行している間、可能な場所の背後にあるコードを単純にクリーンアップするための手順を実行していることです。 これは、WinUI 3で解決された場合、特定の機能の追加とバグ修正に必要な時間と労力が大幅に削減されることを意味します。

NumberBox

特徴

NumberBoxに戻りましょう。 あなたは、V1が必要な機能のサブセットであると言っているのは事実上正しいです。
計画されたV1機能は、入力検証（ちなみにWinUI 3 alphaでプレビュー中）などに依存しているため、V2まで延期されました。 仕様（ここ）でV1に値すると思われるすべてのことを認めることで仕様を完成させようとし、WinUI 3V2リリースのコントロールでそのコミットメントを完全に実現する予定です。

オープンソースの精神を取り入れることで、私の望みは（そして、これを行うことでエラーが発生したかどうかを教えてください）、信頼性が高く便利なコードをできるだけ早くリリースし、機能セットを段階的に構築することを完全に好むことです。 アプリケーションでは、これは、WinUI 2で_ほとんど_完全なV1をリリースし、WinUI 3でできるように、入力検証を備えたフル機能のリリースでフォローアップすることを好むことを意味しました。

バグ

@jesbisが言ったように、バグのないコードベースはありませんが、品質は私たちにとって絶対に最@jesbisは、WinUI 2のコミットログで品質修正と新機能の比率を確認でき、オープンソースになるとWinUI3でも同じことを確認できるようになります。

私はNumberBoxを使用してこれらのバグの解決を支援することに引き続き取り組んでおり、未解決の問題、バグ、および資産となることができる質問に対応するために、残りの時間を取っておきます。 来週も1日取っておきます。 Twitterで質問を送信するか、ここのリポジトリで私と交流することをお勧めします。

次のステップ

私たちにとって、オープンソースとは、まるでレドモンドのオフィスに座っているかのように、コミュニティをチームメンバーとして受け入れることを約束することです。 聞いているのが聞こえます。 これらの決定について一緒に話し合い、1つの大きなチームとして素晴らしいものを構築することに集中できるようにしましょう。 🙂

私たちは❤️WinUI

オープンソースの精神を取り入れることで、私の望みは（そして、これを行うことでエラーが発生したかどうかを教えてください）、信頼性が高く便利なコードをできるだけ早くリリースし、機能セットを段階的に構築することを完全に好むことです。 アプリケーションでは、これは、WinUI 2でほぼ完全なV1をリリースし、WinUI 3でできるように、入力検証を備えたフル機能のリリースでフォローアップすることを好むことを意味しました。

これは私だけかもしれませんが、コードをできるだけ早く出荷することが重要ですが、何かを出荷する前に解決する必要がある特定の種類の問題があると感じています。たとえば、＃1846はV1を出荷する前に対処する必要があります。他にもいくつかあるかもしれません。

@yaichenbaum私はそこで自分の言葉をもっとよく選ぶことができたでしょう。 🙂

ADが_必須_機能であり、EHが_優れた_機能である場合、私の優先事項は、ADをドアから出して、可能な限りEHを段階的に追加することです。

検証パートナーと一緒にプレビューブランチでステージングを行う理由は、コントロールが安定したリリースにプッシュされる前に、＃1846のようなバグをキャッチするためです。 申し訳ありませんが、これにボールを落としました。 @ teaP ASAPと協力して、これをどれだけ早く解決できるかを確認します。 🙂

通話のある時点で、WinUIアプリはAppDomainを介したサンドボックス化を許可することが言及されました。

WinUI 3.0+がアプリケーションの分離とリソース制御のために機能とAppDomainをどのように位置付けるかについて誰かが話すことができますか？

また、私が.Net Coreについて最後に知ったのは、AppDomainの完全なサポートが行われていなかったことです。

連絡が取れないかもしれませんが、.Net 5はAppDomainを完全にサポートする予定ですか？

本日はこの電話をご利用いただきありがとうございます。

WinUI 3.0+がアプリケーションの分離とリソース制御のために機能とAppDomainをどのように位置付けるかについて誰かが話すことができますか？

通話ではっきりしなかった場合は申し訳ありませんが、AppDomainではなくAppContainerについて話してい

ああ、わかりました、ジェシーの説明に感謝します。

まず、今日のコミュニティコールを企画してくれた、 @ SavoySchulerと@jesbis （およびWinUIチームの他のすべて）に感謝します。 いくつかの技術的な問題がありましたが、この電話は非常に洞察に満ちていました!!!

@jesbisが述べたように、WinUI3.0に要求されたツールと機能の追跡に問題があります。 WinUI 2.xから3.0への変換ツールのリクエストを別の問題に分割して、追跡を容易にする方がよいでしょうか。 また、すでに計画はありますか？ 他の開発者がツールの開発を支援できるように、ツールをオープンソースにする計画はありますか？

もう1つのより一般的な質問（他のWinUIチーム以外のメンバーにも当てはまります）は、貢献についてです。 現在、人々の貢献を妨げている障害はありますか？ 寄稿者のためのより良い入門ガイドが役立ちますか？

私の意見では、プロジェクトに貢献し始めた場合、VSプロジェクトは少し圧倒される可能性があり、開発方法、どのテストプロジェクトを何に使用するかなどに関するドキュメントはあまりありません...

たぶん、その分野の改善は人々が貢献するのをより簡単にするでしょう😅

WinUI 3.0レンダリングレイヤーはどのように行われますか？ D3D11、D2D、抽象化レイヤーなどを直接利用していますか？ ソフトウェアレンダリングレイヤーがありますか、それともD3D WARPを利用しますか？

@chingucoding

ここで私が今言ったポイントを繰り返します：

• 永遠にラングを使用していません
• WinUI 3リリースのバックグラウンドで、今日行われた変更を上書きするコードチャーンがどの程度発生しているかはわかりません。
• 必要となる、および/または問題の解決に大いに役立つ大量のソースコードにアクセスできない

編集：例を挙げましょう。 ＃1555と＃1849は、マルチタスク中のテキストの入力と選択を妨げるコアコントロール（TextBox）の主要な問題のようです。

それらは解決すべき重要な問題のリストの上位にありますが、どこから始めればよいのかわかりません。 また、デバッグするためにステップスルーしたい/必要なコードが利用可能かどうかもわかりません。

@SavoySchuler

WinUI 2がコミュニティメンバーに十分なサービスを提供していないという点まで、目標2と3についてあまりにも前向きにダイヤルされた場合、その会話を行うことができ、優先順位を変更することができます。 バックログのすべてのバグを解決すると、WinUI3の市場へのリリースが最大6か月遅れることを知っておいてください。

私は確かに理解しています。 ただし、ここではNumberBoxが少し異なり、すべてのバグに焦点を当てるべきだと言っているわけではありません。 今のところ、NumberBoxのコンテキストでのみ話します。 確かに対処する必要がある他のいくつかの明白な問題がありますが。

NumberBoxは、WinUI 2.3用に新しく開発されたコントロールであり、現時点で誰もが受け入れる必要のあるレガシーコントロールではありません。 開始するためにこれを正しく行わないのはなぜですか？ これは、新しい開発モデルのリトマス試験です。

ADに機能が必要であり、EHに機能があると便利な場合、私の優先事項はADをドアから出して、可能な限りEHを段階的に追加することです。

私はここであなたに完全に同意します。 ただし、機能とバグの違いを理解する必要があります。 マイクロソフトのリソース/マンパワーの観点からのみ考えているのではないかと心配しています。 ただし、アプリ開発者がコントロールのバグを回避するために数え切れないほどの時間を浪費していると考えたことはありますか？ これらをソースで修正する方がはるかに効率的であり、プラットフォーム/ツールの認識にも役立ちます。

もう1つはっきり言いたいのは、WinUI 2のバグのファイリング、機能リクエストの入力など、すべての作業が失われることはないということです。 WinUI 3がリリースされると、チームのかなりのサブセットが自由に作業項目に戻ることができるようになります。これにより、コミュニティがコードを送信できるようになるだけでなく、プラットフォームが進化します。

マイクロソフトは、不完全なソフトウェアをリリースしてから、最後のソフトウェアを完成させる前に、次の最新かつ最高のテクノロジに移行するという非常に悪い実績があります。 あなたの約束に懐疑的だったことを許してください。

NumberBoxに戻りましょう。 あなたは、V1が必要な機能のサブセットであると言っているのは事実上正しいです。
...オープンソースの精神を取り入れることで、私の望みは（そして、これを行うことでエラーが発生したかどうかを教えてください）、信頼性が高く便利なコードをできるだけ早くリリースし、機能セットを段階的に構築することを完全に好むことです。

機能の面であなたと完全に同じページにあります。 バグは異なります。 機能とは異なる方法でバグに対処し、より多くのリソースをそれらにコミットする必要があります。 NumberBoxのようなまったく新しいコントロールをリリースしてから、1年後までバグの修正にリソースを投入できないと言うのは悪いことのように思えます。

WinUI3.0に依存しないコントロールのV1のバグに対処するようにお願いしています。 かなり基本的なものもあれば、設計上の明らかな間違い（NaNが双方向にバインドされたデータをクラッシュさせるなど）もあります。 機能/コントロールのリリースを確約したら、すぐにバグを閉じる作業を行う必要があります。 ソフトウェアに最初のワイドリリースがある場合は常にバグがあります。リソースを計画して、V2をすばやくバグ修正する必要があります（他のアプリ開発者と同様）。 品質が最優先事項であることに同意しますので、他のことに進む前に、NumberBoxで次の問題を修正してください。

1708-プレースホルダーテキストは、コントロールのフォームの使用法と、仕様にすでに含まれている基本機能の1つで絶対に必要です。 これが実際にNaNで修正されている場合は、閉じる必要があります。 ヌルサポートは、以下の別のトピックです。

1721-UWPの大きな問題は、特定のコントロールでのデータバインディングのサポートが不完全だったことです。 多くのアプリケーション開発者が数年前にMVVM設計に投資し、UWPコントロールにジャンプしようとすると、データバインディングが部分的にしかサポートされていないことがわかりました。 これは大きな問題点であり、MVVMがMicrosoftのベストプラクティスにとってどれほど基本的であるかを考えると受け入れられません。 古いWindows開発者ツールチームはこれを支持することは決してありません-これはここでのWindows /ネイティブの考え方です。

1839-ここに基本的なもの。 これらはコントロールテンプレートの基本的なバグであり、修正する必要があります。 言い訳しない。

1846-以前、他の多くのコントロールでこの問題が発生しました。 これをテストするリリースチェックリストが今までにないのはなぜですか？ 繰り返しますが、修正が必要な基本的なもの。 これは、このコントロールを使用するすべてのアプリの使いやすさに影響します。

1852、＃1853、＃1854-繰り返しますが、これらはそれほど複雑ではなく、最初の実装では見落とされていました。 ただし、特定の地域で販売されている、または政府向けに開発されたソフトウェアのアクセシビリティをサポートすることは法的要件です。 プラットフォームとして、アプリケーション開発者がコントロールを使用できるように、これをすぐに修正する必要があります。 繰り返しますが、私はあなたとこの種のことを議論する必要はありません、それは基本的なことです。

注意すべきもう1つの点は、OSからWinUI 3にコードを移行している間、可能な場所の背後にあるコードを単純にクリーンアップするための手順を実行していることです。 これは、WinUI 3で解決された場合、特定の機能の追加とバグ修正に必要な時間と労力が大幅に削減されることを意味します。

高レベルで理解します。 ただし、上記の問題を修正しても、WinUI3.0が6か月遅れることはありません。 また、対処するためにWinUI 3.0に依存しません（潜在的に＃1721を除く）。 NumberBoxをリリースし、それを固執せずに最初のバグを閉じることで、危険な前例を設定しています。 このレッスンは、UWP自体ですでに学習しているはずです。

たぶん、その分野の改善は人々が貢献することをより簡単にするでしょう

貢献したいと思います。 C ++ / WinRTでの作業が好きではなく、私が見たようにコードベースに触れる資格があるとは感じません。 コントロールがC＃で管理されていれば、さらに多くの貢献があったでしょう。 アーキテクチャが何であるかは理解していますが、結果の1つは、コミュニティへの貢献が少ないことです。 ここではシステム開発者ではなく、エンドユーザーアプリ開発者です。

RE：貢献：

もう1つのより一般的な質問（他のWinUIチーム以外のメンバーにも当てはまります）は、貢献についてです。 現在、人々の貢献を妨げている障害はありますか？ 寄稿者のためのより良い入門ガイドが役立ちますか？
私の意見では、プロジェクトに貢献し始めた場合、VSプロジェクトは少し圧倒される可能性があり、開発方法、どのテストプロジェクトを何に使用するかなどに関するドキュメントはあまりありません...
たぶん、その分野の改善は人々が貢献することをより簡単にするでしょう

現在リポジトリにあるコードベースであるWinUI2への貢献を妨げるものは何もありません。 取り組みたいWinUI2の問題がある場合は、お知らせください。割り当てさせていただきます。

良い創刊号でタグ付けされたアイテムがたくさんあり、誰かが（比較的）簡単に始められるはずのアイテムを手伝いたい場合は助けが必要です🙂

バグ修正については、PRを開くだけです。 それが主要な新機能である場合は、最初にプロセスも少しあり

私は、寄稿者ガイドの方が優れている可能性があり、始めるのが難しいことに完全に同意します-私は最近、新しい機能（ RadialGradientBrush ）を実装するためにそれに従うことを試みる演習を行い、それが多くの改善を使用できることを発見しました-それは今私のガイドを改善するためのtodoリスト。

例を挙げましょう。 ＃1555と＃1849は、マルチタスク中のテキストの入力と選択を妨げるコアコントロール（TextBox）の主要な問題のようです。
それらは解決すべき重要な問題のリストの上位にありますが、どこから始めればよいのかわかりません。 また、デバッグするためにステップスルーしたい/必要なコードが利用可能かどうかもわかりません。

それらはまだ開発所有者によってトリアージ（分類）される必要があります（したがって、「needs-triage」ラベル-私は現在、それらがまだ行われていない理由をフォローアップしています、申し訳ありません）が、TextBoxがないので期待していますWinUI 2は、WinUI3を待つ必要があります。

トリアージされたら、 needs-winui-3ラベルを適用するます。これは、対処する前にWinUI3を待つ必要があることを示しています。

WinUI 3がオープンソースになると、誰でもこれらの問題の解決を支援できるようになります。

C ++ / WinRTでの作業が好きではなく、私が見たようにコードベースに触れる資格があるとは感じません。 コントロールがC＃で管理されていれば、さらに多くの貢献があったでしょう。

C ++はC＃よりも高い障壁であることはわかっていますが、WinUIはC ++プラットフォームのままであることが計画されています。

貢献すべきもう1つの優れたプロジェクトは、 Windows Community Toolkitです。これは、C＃であり、要件が緩和されているため、貢献が容易です。

私たちはメンテナと協力し、コミュニティツールキットを使用して、最終的にXamlプラットフォームに移行する新しいコントロールをインキュベートすることがよくあります（これにはC ++での再実装が含まれます）。

WinUIにはC ++ / CXが必要ですか？ もしそうなら、これはWin32や他の将来のターゲットの問題であると思われますか？

WinUI 3.0レンダリングレイヤーはどのように行われますか？ D3D11、D2D、抽象化レイヤーなどを直接利用していますか？ ソフトウェアレンダリングレイヤーがありますか、それともD3D WARPを利用しますか？

WinUI Xamlフレームワークのレンダリングは、主にWindows10コンポジションエンジンに実装されてい

結局のところ、これは通常、Direct3D、Direct2D、DirectWriteを使用したハードウェアアクセラレーションによるレンダリングを意味し、場合によってはソフトウェアによるレンダリングが理にかなっています。

相互運用APIを使用して、独自のカスタムレンダリングされたDirectXコンテンツを含めることもできます。

WinUIにはC ++ / CXが必要ですか？ もしそうなら、これはWin32や他の将来のターゲットの問題であると思われますか？

いいえ-WinUIプラットフォームはC ++で記述されていますが、アプリは絶対にそうである必要はありません。

今日のWinUI2では、.NET（C＃、VB.NET）またはC ++を使用してUWPアプリを作成できます。

WinUI 3の目標は、今後の.NET5またはC ++を使用して、UWPやwin32APIを使用するアプリを作成できるようにすることです。

@jesbisあなたは私の質問の意図を少し誤解しているかもしれないと思います。

1）WinUIがC ++で記述されていることは知っていますが、WinUIコードにはWindowsのみのVC ++ / CX拡張機能が必要ですか？ それがCX拡張機能を必要とする場合、WinUIが他のプラットフォームに拡張したいのであれば、これは将来的に移植性の問題を引き起こす可能性があると思います。 これにより、たとえばUNOチームがコードを採用するのが難しくなる可能性があります。

2）レンダリングシステムについて。 ここでいくつかのこと。

2.a）「ビジュアルレイヤー」抽象化APIは、DirectX APIから十分に離れているため、後でVulkanバックエンドをサポートできますか？ （ソースがリリースされたときにこの質問に答えられると確信していますが、私はただ疑問に思っています）

2.b）ソフトウェアのラスタライズについての私の質問は、次のようなものでした。WinUI3.0は、完全なソフトウェアレンダリング（テキストレンダリングなどだけでなく）をサポートしますか？ 画面共有ソフトウェアでGPUアクセラレーションアプリ（少なくともD3D9 / WPF）で問題が発生し、ソフトウェアレンダリングを強制すると、そのような状況で問題が修正される場合があります。 または、アプリがハードウェアGPUのないVMで実行されている場合。

vsixをインストールして試すためのWinUI3.0Alphaの手順は次のとおりです。
https://aka.ms/winui/alpha

Edge Newでそれを行いましたダウンロードリンクdoenstが表示され、chrome-downloadで繰り返しました

Edge Newでそれを行いましたダウンロードリンクdoenstが表示され、chrome-downloadで繰り返しました

@hannespreishuberダウンロードリンクは調査の最後のページにあるはずです。 調査はChromiumEdgeでは機能しなかったが、Chromeでは機能したということですか？

ダウンロードリンクは、調査の最後のページにある必要があります。 > Chromium Edgeでは調査が機能しなかったが、Chromeでは機能したということですか？

両方について調査を行いましたが、最後のページは異なっていました。おそらく私のせいです。

両方について調査を行いましたが、最後のページは異なっていました。おそらく私のせいです。

わかりました。ありがとうございます。両方のバージョンのEdgeで調査をテストしましたが、うまくいったようです。ダウンロードに問題がある場合はお知らせください。また、ページのコンテンツのレンダリングがChromeと異なる場合はEdgeで問題を報告してください（[設定]> [ヘルプ]と​​[フィードバック>フィードバックの送信）🙂

WinUIがC ++で記述されていることは知っていますが、WinUIコードにはWindowsのみのVC ++ / CX拡張機能が必要ですか？ それがCX拡張機能を必要とする場合、私はこれがおそらく移植性の問題を引き起こしていると思います

@ zezba9000標準のC ++ 17であるC ++ / WinRTを使用してWinUI2のコントロールと機能（現在リポジトリにある新しいコード）を実装しましたが、WinUI 3の残りの部分ははるかに大きく、古いコードベースであり、現在も依存していますWRLなどについては、現時点では移植性に重点を置いていませんが、将来的には議論の余地があります。

「ビジュアルレイヤー」抽象化APIは、DirectX APIから十分に離れているため、後でVulkanバックエンドをサポートできますか？ （ソースがリリースされたときにこの質問に答えられると確信していますが、私はただ疑問に思っています）

現時点では、ビジュアルレイヤーの移植性にも重点を置いていません。 VisualレイヤーとDirectXAPI（実装は含まない）の間にはいくつかの緩い結合がありますが、ほとんどが抽象化されています。 また、オープンソースについて明確にするために：オープンソースコードの最初のターゲットと日々の開発プロセスはXamlフレームワークであり、現時点ではビジュアルレイヤーのオープンソースは含まれません。

ソフトウェアのラスタライズについての私の質問は、次のようなものでした。WinUI3.0は、完全なソフトウェアレンダリング（テキストレンダリングなどだけでなく）をサポートしますか？ 画面共有ソフトウェアでGPUアクセラレーションアプリ（少なくともD3D9 / WPF）で問題が発生し、ソフトウェアレンダリングを強制すると、そのような状況で問題が修正される場合があります。 または、アプリがハードウェアGPUのないVMで実行されている場合。

はい、VMなどでの画面共有によるレンダリングはすべて機能するはずです。 ほとんどのコンテンツでは、目に見える違いはありません。 リポジトリ内のWinUI2コードを見ると、実行時に特定の効果がサポートされているか「高速」であるかどうかを照会するために使用するAPIの使用法が表示され、場合によっては特定の効果のより単純なレンダリングにフォールバックすることもありますが、アプリはすべきではありません。デフォルトのプラットフォームコントロールと機能を使用する場合、ソフトウェアレンダリングをサポートするために特別なことをする必要はありません。

私はここであなたに完全に同意します。 ただし、機能とバグの違いを理解する必要があります。 マイクロソフトのリソース/マンパワーの観点からのみ考えているのではないかと心配しています。 ただし、アプリ開発者がコントロールのバグを回避するために数え切れないほどの時間を浪費していると考えたことはありますか？ これらをソースで修正する方がはるかに効率的であり、プラットフォーム/ツールの認識にも役立ちます。

100％同意する-UWP / WinRTのバグを回避するために費やした時間数を思い出したくありません。

ジェシー、

私は主にエンタープライズアプリケーションの開発に関心があります。 私は現在、WinUI 3.0 Alphaを使用して概念実証を構築し、Xaml、GPRC、複数のウィンドウ、および真のマルチスレッドがビジネスとビジネスユーザーにより生産的なアプリケーションエクスペリエンスを提供する方法を示しています。

どうして？ ブラウザベース/小画面アプリケーションに代わるものが必要だからです。 そのトピックについてはまだまだ言いたいことがたくさんありますが、ここでKISSに行きます。

WinUIチーム、そして実際にMicrosoftに求めているのは、ビジネス向けのデスクトップアプリの構築を受け入れてサポートすることです。

Webアプリが企業に急速に採用された主な理由は3つありました。クロスプラットフォームのサポート、セキュリティ、展開のしやすさです。実行可能な代替手段となるには、デスクトップアプリがこれらの質問に答える必要があります。

ソフトウェア開発業界のほとんどは、ブラウザやモバイル/タブレットのフォームファクタ向けのアプリケーションの提供に重点を置いているようです。

エンタープライズアプリケーションは、「モバイルファースト」アプリケーションと比較した場合、多くのCPU、画面サイズ、メモリ、ストレージ、グラフィックス、および帯域幅を備えたワークステーションで実行されます。 これらのLOBアプリケーションのユーザーは、一度に何時間も従事する可能性があります。 これらの要因に対処するには、アプリの設計ガイダンスが必要です。

エンタープライズアプリケーションには、寿命とスキルセットなど、あまり議論されていない他の側面があります。 繰り返しになりますが、ここで言うことはたくさんありますが、要約します。 企業はアプリケーションの構築にお金を投資し、それらのアプリを「長期間」使用することを計画しています。 これは、基盤となるテクノロジーを数十年にわたってサポートする必要があることを意味します。 WinUIが、Win32 / MFCおよびWinFormsに取って代わる次の長寿命テクノロジーになることを望んでいます。

IT部門は、適切なスキルセットを備えたSEを見つけるのに常に苦労しています。 Web技術により、これはさらに困難になっています。 デスクトップアプリの構築に重点を置いた新しいスタックC＃、Xaml、SQL（C＃XS）が欲しいのですが。

スタイリングに関して私が言いたいマイナーな点もあります。 WinUIエンタープライズアプリケーションが機能するためには、「箱から出して」最小限のスタイリングが必要です。 また、これはFluentに直接向けられる可能性がありますが、コントロール（スクロールバーなど）を非表示にしないでください。 ビジネスユーザーは多くの画面の実状態を持っており、ページにさらに多くのものがあることを知らなくても、UIがどれほど「ゴージャス」であるかは気にしません。

堅牢な（無料の）データグリッド制御が必要です。 それを十分に強調することはできません。

興味があれば共有できるアイデアが他にもありますが、ここでやめて要約します。

•マイクロソフトは、包括的なデスクトップアプリケーション開発ソリューションを提供する必要があります。
•WinUI / Fluentは、関数/フォーム、デスクトップ用UX、複数のウィンドウを示すコードサンプル/プロジェクトテンプレート、真のマルチスレッド、データ検証、「フォームのような」ページなど、ビジネスユーザーの要件に対応する必要があります。
•マイクロソフトは、生産性が高く、長寿命のビジネスLOBアプリケーションを構築するためにWinUIを提供していることを明確にする必要があります。 また、なぜ.Net 5 + WinUIが別のDLL地獄にならないのか。
•WinUIがWin32 / MFCおよびWinFormsの代わりになることを明確にします。
•ITのスキルセットとしてC＃XSをプッシュします。
•（無料）データグリッド

これがお役に立てば幸いです。

@robloo安心してください-議論は必要ありません！ 🙂私は私の初期のコメントでこの失効を修正することを約束しました、そしてそれはまだ当てはまります。 私も、一般化を続けることで、以前に間違いを犯したと思います。 あなたがリストしたバグについて話しましょう。 ここでの主要な休暇の直前に2つが提出され（ @teaPについて話すことはできませんが、12月のほとんどはオフラインでした）、エンジニアリング側で管理の変更が行われました（@ranjeshjおめでとうございます！）。 言い訳にはなりません。これらの変更と不在の間、これら2つのバグに迅速に対応できなかったことをお詫びします。 ここにリストされている他のすべては、過去10日以内に提出されています。

特にNumberBoxが原因であり、これらが積み重なっていることは、私たちが時間の戦略を立てるのに役立つことを指摘してもらうために、これを確認するのを手伝ってくれてありがとう。 来週の初めに、NumberBox dev @teaPと（新しいタイトルの）エンジニアリングマネージャー@ranjeshを使用して、未解決のNumberBoxバグリストを確認し、それらをできるだけ早くまとめて解決できるようにする

@SavoySchulerありがとう！

@SavoySchuler 、次のいずれかを選択するのが難しい立場にあるようです。

a）WinUI 2.xのバグを修正し、WinUI3.0のリリースを遅らせます
また
b）WinUI 2.xをコミュニティに任せ、WinUI 3.0に向けて内部リソースを割り当て、最も早いリリース日を達成します。

多くの既存のWinUI2.xユーザーは、現在影響を受けているため、最初にバグを修正することを望んでいると思いますが、十分なリソースがあれば、WinUI 3.0がいつ利用可能になるかを現実的に予測することで、これを軽減できる可能性があります（ WinUI 3.0が2.xを超える追加の修正を提供すると仮定します）。

個人的には、WinUI 3.0のリリースが遅れることは望んでおらず、コミュニティがWinUI 2.x（結局のところオープンソース）で重要な問題の解決に関与することは合理的だと思います。 一部の人々は、それがマイクロソフトのプロジェクトであるため、すべての作業を行う必要があると期待しています。 残念ながら、それは現実的ではなく、他のオープンソースプロジェクトがどのように機能するかでもありません。

@ jesbis 、 Windows.UI.Compositionクラスに依存するということですか？ WinUI 3.0に抽出する前に、ビジュアルレイヤーをサポートするためにOSに追加される機能を追加する可能性はありますか？

参考までに、私が興味を持っていること：

• Win32「AppContainer」モデル。 他のOSではサンドボックスと完全に互換性がありますが、「最新の」APIにアクセスしたいのですが
• ビジュアルレイヤー（ Windows|Microsoft.UI.Composition ）
• ビジュアルレイヤーのDXGIスワップチェーン/ SwapChainPanel
• ウィンドウ管理API（AppWindowなど）

@infoequipt詳細なメモをありがとう！ 間違いなく役に立ちました。 可視性のための@ marb2000

WinUI3.0に関してビジュアルレイヤーについて聞いたのは興味深いことです。 初期リリースでは、WinUI 3.0はWindows.UI.Compositionクラスに依存するということですか？

@MarkIngramUKいいえ、混乱してすみません-私の以前のポイントは、オープンソーシングについてでした。

Microsoft.UI.CompositionはWinUI3の一部であり、Microsoft.UI.Xamlはそれに依存します。 WinUI 3Alphaの場合はすでにそうです。

私たちはオープンソーシングXamlに取り組んでいます。つまり、Xamlフレームワークコードはこのリポジトリに存在し、エンジニアリングチームは今後GitHubでXamlの作業を毎日行います。 ただし、Xamlが依存するMicrosoft.UI.Compositionパッケージは引き続き内部で開発され、バイナリ形式でのみ更新されます。

明確化してくれてありがとう@jesbis大いに感謝します。 これにはどのような配布方法を使用しますか？ 私たちはクロスプラットフォームアプリなので、CMakeを使用しており、Windows.UI.Compositionに依存しているため、新しいdll、lib、ヘッダーなどを簡単に取り込む方法が必要です。

OSからビジュアルレイヤーを抽出することでパフォーマンスに影響はありますか？ つまり、ビジュアルレイヤーのみに依存している場合、新しいライブラリに更新することにはマイナス面がありますか？

最終的にMicrosoft.UI.Compositionをオープンソース化する計画はありますか？

@MarkIngramUK私はあなたが言っていること、そして@SavoySchulerが「全体像」の観点から言っていることに大体同意します。 ご指摘のとおり、現在本番アプリがあるため、WinUI2.0ユーザーがバグを受け入れるのは困難です。 WinUI 3.0を遅らせないいくつかのバグを修正することと、WinUI3.0を軌道に乗せることの間の妥協点を見つける必要があります。 NumberBoxがまったく新しいコントロールであり、すぐに無視されているように見えるという追加の不満がありました。Microsoftは1年以上それを取り戻さないだろうというコメントがありました。 とにかく、私は確かにWinUI 3.0が優先事項であり、それが大幅に遅れることを望まないことに同意します。

マイクロソフトがここで行っているすべての作業と、より透明性が高く、方向性を伝えるための彼らの努力に感謝していると思います。

これにはどのような配布方法を使用しますか？ 私たちはクロスプラットフォームアプリなので、CMakeを使用しており、Windows.UI.Compositionに依存しているため、新しいdll、lib、ヘッダーなどを簡単に取り込む方法が必要です。

@MarkIngramUKは、NuGetパッケージをつまり、WinUI2.xと

OSからビジュアルレイヤーを抽出することでパフォーマンスに影響はありますか？ つまり、ビジュアルレイヤーのみに依存している場合、新しいライブラリに更新することにはマイナス面がありますか？

しばらくお待ちください🙂パフォーマンスのベンチマークと作業は今年後半のロードマップにあるため、数値を取得するには少し早すぎます。

最終的にMicrosoft.UI.Compositionをオープンソース化する計画はありますか？

潜在的に検討することは私たちのバックログにありますが、私たちはそれについての計画を持っていません。

@MarkIngramUK質問できれば、オープンソースであることからどのようなメリットが得られると思いますか？

構成とレンダリングのコードは少し厄介になる可能性があるので、人々が実際に貢献したり、参照として使用したりすることに興味があるかどうか興味があります。

現在、本番アプリがあるため、WinUI2.0ユーザーがバグを受け入れるのは困難です。 WinUI 3.0を遅らせないいくつかのバグを修正することと、WinUI3.0を軌道に乗せることの間の妥協点を見つける必要があります。 NumberBoxがまったく新しいコントロールであり、すぐに無視されているように見えるという追加の不満がありました。Microsoftは1年以上それを取り戻さないだろうというコメントがありました。 とにかく、私は確かにWinUI 3.0が優先事項であり、それが大幅に遅れることを望まないことに同意します。
マイクロソフトがここで行っているすべての作業と、より透明性が高く、方向性を伝えるための彼らの努力に感謝していると思います。

@roblooありがとう！ 私たちは本当に透明性を追求しているので、それが価値があることを知っておくのは良いことです🙂

Savoyが言ったことを繰り返すと、開発者はWinUI 2.xに取り組んでいるので（PRログからもわかるように）、WinUI2と3の両方に並行して投資していることは間違いありません。リソースはWinUI3にあります。特に注意が必要なNumberBoxについて同意し、Xamlコントロールの開発リーダーが現在調査中です。

@roblooあなたは最高です！ 😄混乱して申し訳ありませんが、言及された最大1年の遅延の対象となるのは、3.0で予定されているすべての入力検証作業でブロックされているため、NumberBoxの追加の入力検証モードだけでした。 それ以外の場合、 @ teaP 、 @ ranjeshj 、および私は来週からNumberBoxバグリストに載ります。 🙂

@jesbisは他のすべてをカバーしたと思います！

@jesbis 、

@MarkIngramUKは、NuGetパッケージをつまり、WinUI2.xと

正直なところ、私はNuGetにあまり詳しくありませんが、このSOの回答を見ると、CMakeを使用してVSプロジェクトファイルを生成した場合にのみ機能するようです。これは通常の作業方法ではありません（通常はフォルダーを開くだけです）。 、Ninjaをジェネレーターとして使用します）。 vcpkgも使用できるので、ソースを出荷できないのは残念です。 参考までに、すべてのライブラリをソースからビルドします（これにより、特にWindowsでもClang / LLVMを使用してビルドする場合、潜在的なABIの問題を回避できます）。

最終的にMicrosoft.UI.Compositionをオープンソース化する計画はありますか？

潜在的に検討することは私たちのバックログにありますが、私たちはそれについての計画を持っていません。

私はこれに興味があるので、もしそれが起こったら、議論に参加したいと思います。

@MarkIngramUK質問できれば、オープンソースであることからどのようなメリットが得られると思いますか？

構成とレンダリングのコードは少し厄介になる可能性があるので、人々が実際に貢献したり、参照として使用したりすることに興味があるかどうか興味があります。

最初の考えは貢献/拡大しています（前述したように、Windows.UI.Compositionに依存していますが、Xaml Framework / UWPには依存していません）。プラットフォームはエキサイティングかもしれませんが、私はそれを文字通り30秒しか考慮していません。 また、オープンソーシングは、数年後にMicrosoftによって最終的に放棄される別のフレームワークを採用するという厄介な心配を軽減します（現在のアプリはWPFで構築され、以前のアプリはMFCで構築され、Silverlightを使用するWebコンポーネントがありました。 、あなたは私がここから来ているところを見るかもしれません...）。

NumberBox

皆さんこんにちは！ @ teaP 、 @ ranjeshj 、そして私は今日、開いているすべてのNumberBoxアイテムを処理しました。

• すでにいくつか閉鎖しました。
• @teaPは、さらにいくつかの複合PRを提出しました（ラベルフィルタリングはこちら）。
• 残りのアクション（＃1721を除く）を決定し、できるだけ早く修正を加えて対応します。 ＃1721は、今後の最善の道を診断するために、さらに多くの作業を必要とします。 これを解決するために引き続き作業します。

皆様、ご協力ありがとうございました。 🙂私たちは❤️WinUI！

WinUIコミュニティの呼び出し用の「カレンダー」はありますか？ 例：通話の詳細を自動的に更新するために、ライブ/ google / *カレンダーに追加/統合できる公開カレンダーの形式。

YouTubeイベントは事前にスケジュールされているため、ここの「今後のライブストリーム」の下にGoogleリマインダーを追加できます。

https://www.youtube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA

.icsカレンダーの招待もありましたが、一部の人に問題が発生し、更新する方法がなかったため、今のところあきらめました。