これらは、問題の内容であなたが尋ねた質問に対する私の最初の考えです。

私はデザインとユーザーの観点から来ており、開発経験はほとんどありません。当時、Silverlight / Windows Phone 7の開発に非常に興味を持ち、今では少しやけどを感じています。

どのテンプレートに最も興味がありますか？

テンプレートのアイデアのリストを要求する前に、各フレームワークで最大かつ最も使用されているアプリ、つまりWPF、UWP、WinForms、MFCなどについて何らかの監査を行う必要があると思います。

これらのアプリの「シルエット」を調べて、一般的なUXシナリオを理解してください。

私の頭のてっぺんから、次のようなものがあります。

メインメニュー（すべてのフレームワーク）
MDI（1つのウィンドウに複数のドキュメント）（主にMFC）
タブとデータグリッド（WPF、WinForms、MFC）
リボン（Win32アプリOffice、3ds max、ペイント、ワードパッド、ファイルエクスプローラーなど）
システムトレイユーティリティ（MFC、WinForms）
ブラウザ
ウィザード（WPF、MFC）
複雑なMDIアプリ（Adobeソフトウェア、Visual Studio）
メディアプレーヤー
データ視覚化LoB（WPFおよびWeb）
ソーシャルアプリ（React Native、PWA-Skype、Facebook、Twitter）

これらのすべてまたは一部は、通知/アクションセンターとのWinRT / UWPシステム統合の恩恵を受ける可能性があります。

これらの新しいプロジェクトテンプレートはすべて、組み込みのWindows.Xaml名前空間、WPFコントロールテーマ、およびWinFormsビジュアルスタイルを避け、FabricWeb / Fluentコントロールデザインに一致する新しいテンプレートとビジュアルスタイルを優先する必要があります。

また、既存のWPFおよびWinFormsアプリを使用する開発者がWinUI 3.0の依存関係を追加して、単純なusingステートメントまたはマニフェストエントリで新しいコントロールデザインを提供する簡単な方法もあるはずです。

XAML諸島

Xamlアイランドが可能になるにつれて、古いWebビューコントロール、カラーピッカー、XAMLベースのダイアログの置き換えは[新規追加...]と同じくらい簡単になり、ダイアログ、または既存のC＃およびC ++コードが呼び出すことができる標準コントロールを選択できます

Xbox Nextアプリ、NavigationView、Master / Details、Hubs、Modern Ribbon、NavigationViewTop、Pivotなどの最新のアプリとページテンプレートはすべて、XAMLアイランドが配置されたサンプルコンテンツを使用して、すべてのWindowsプレゼンテーションプラットフォームで利用できるようになります。

UWP XAMLでは現在不可能なこれらのシナリオはすべて、これらを簡単にするためのコントロールとテンプレートを使用する必要があります。

Visual Studioまたは別のツールが名前空間を自動的に更新する場合に役立ちますか？

誰かが現在のWindows10SDKを使用して最新バージョンのVisualStudioでプロジェクトを開いたときに尋ねられる質問です。ボタンを押すと、名前空間と使用法が置き換えられるか、使い慣れたコントロールでない場合はフラグが付けられます。

新しいプロジェクトでは、これがデフォルトであり、nugetパッケージがWindowsSDKの将来のバージョンとともにインストールされます。

WinUI 3でUWPコンポーネントを使用するための好ましいソリューションは何ですか？

自動更新の回答と同様に、新しいページとプロジェクトにはデフォルトでそれを含める必要があり、 WinUIにToDoコメントを追加して名前空間を更新する| WinUIに移動しないでください。

WinUI 3.0を使用するのに最も興奮しているのはどのようなアプリですか？

ユーザーとして、使用されているフレームワークに関係なく、Windowsで実行されているすべてのアプリで共通のUIとUXを共有する必要があります。

レジストリをいじったり、ジャンクを残したりせずにアプリをインストールしたい。（100周年）

すべてのアプリをストア内から、またはCentennialタイプのインストーラーからインストールできるようにしたい。すべてのアプリのシステムフォルダーとWindowsフォルダーを仮想化します。

FluentUIを使用してC ++ MFCアプリを最新化しますか？

アクリルは、WPF、WinForms、およびMFCアプリで使用でき、WinUI3.0の依存関係またはマニフェストを介してデフォルトの新しいテンプレートに含まれている必要があります。 CommonControlsとウィンドウスタイルは、アクリルと拡張タイトルバーを使用する必要があります（現在のデフォルトに戻すためにオーバーライドできます）

MicrosoftのWin32非UWPアプリは、すべてWinUI 3.0で再コンパイルする必要があるため、すべてアクリルウィンドウフレーム、メインメニュー、ThemeShadows、コンテキストメニュー、テキストフィールド、プログレスバーなどを使用します。

そして、既存のアプリには、WinUI 3.0+をドロップする簡単なソリューションが必要です。これにより、すべてのコントロールの外観が更新されます。または、UI全体が更新されるまで、一度に1つのダイアログを選択して適用する機能が必要です。

mdtauk 2019年05月16日

👍31 ❤9 😕1

re：名前空間、条件付き名前空間が必要な場合でも、ターゲットに基づいて変更されることを期待します。

paulio 2019年05月16日

これが私の答えです：

新しいアプリの作成

どのテンプレートに最も興味がありますか？

最初にc ++ / winRT win32 + xamlと.netcore + xamlが表示され、次にUWPテンプレートが表示され、パッケージ化されたwin32アプリがテンプレートとして表示されないようにします。現在のアプリパッケージテンプレートは、現在のアプリと同じように機能するはずです。 win32 /.Netアプリ。
さらに、既存のwin32または.netコアアプリアプリケーションで表示するためのボイラープレートコードを含む「新しいXAMLウィンドウ」のようなアイテムテンプレートを表示したいと思います（例：既存のsystrayアプリをDockerデスクトップで表示できるようにする新しいトップレベルのXamlウィンドウ）

WinUI3.0を既存のWin32アプリに追加する

下位互換性がないことが、実際のプロジェクトでxamlアイランドを使用したことがない正確な理由です（ただし、個人的なもので楽しむために使用しました）。 UIフレームワークをWindowsAPIから分離することは、WinUI 3.0ロードマップで発表された最大のことの1つです（パッケージ化されていない/ uwp以外のターゲティングアプリがそれを活用する機能と並んで）

既存のUWPXamlアプリをWinUI3.0に更新する

耳障りに聞こえるかもしれませんが、UWP xamlアプリはニッチな感じがします（Windows Phoneが登場したため、ターゲットプラットフォームとしてのUWPへの牽引力はなくなりました）。ツールや相互運用機能があればいいのですが、私はそうしません。それがWinUI3.0の主な焦点であるべきだとは思わない。
したがって、名前空間更新ツール（実際にはグローバルな検索と置換を使用して実行される可能性があります）とUWPxamlとWinUIxamlの混合の両方が私にとって重要であるとは感じません。

simonferquel 2019年05月16日

👍12 ❤1

また、これは非常に歓迎すべき動きであり、GithubでUIフレームワーク全体をオープンソースにすることは素晴らしいことです。これをしてくれてありがとう！

simonferquel 2019年05月16日

👍6 🎉1

まず第一に、これは素晴らしい動きです！残念ながら、マイクロソフトがプラットフォーム上で最後の数人の開発者に対処した方法で少し傷ついたと感じているという事実を無視することはできません。現時点では、次の理由から、消費者向けアプリにのみUWPを使用し

WPFはWinUI（検証、既存のコントロールなど）よりもはるかに成熟しているため、エンタープライズの場合はWPFの方が適しています
UWPは、消費者がいる複数のデバイスカテゴリ（モバイル、タブレット、デスクトップなど）に最適です。

ポイント1がWinUIで取り組むことができるのを見るのは素晴らしいことです、それで私はWinUIの進歩に熱心になります。残念ながら、2はもう適用できません（これ以上クールなデバイスはなく、デスクトップだけです）。このようなものが出荷されたとき（今から1年後？）、開発者はその段階で何を必要とするのだろうかと不思議に思います。

私は、消費者のものはもはや方程式の一部ではないと思います、その船は縮小「戦略」で航海しました。ですから、それが良いのはエンタープライズアプリだけです。

一般に、大規模なWPFコードベースをWindows 10に移行するために、WPFからWinUIへの適切な移行戦略に関心があります。消費者向けアプリ（現在はUWP）を更新する必要があることの欠点は、それらが非常に依存していることです。外部コンポーネント開発者（例：winツールキットなど）。ほとんどの開発者（私が知っている）がコンシューマー/ Windowsクライアント開発への興味を失ったので、これらを更新する実行可能なオプションはもうないと思います。

質問への回答

新しいアプリの作成

どのテンプレートに最も興味がありますか？

.net core / xaml / C＃は、利用可能な最も使用されている言語の組み合わせだと思うので、ここで見たいと思います。ただし、ここでは移行テンプレートの方が適している可能性があります（できるだけ早く全員を参加させるようにしてください。時間がかかるほど、苦痛が増します）。

WinUI3.0を既存のWin32アプリに追加する

これは非常に素晴らしいと思います。私たちはこれを頻繁に使用します（ただし、現実的には、企業のお客様はまだWindows 7を使用しているため、MSサポートが終了しても、企業はWindows 7を使用することになります）。次に、WPFをWinUI3にゆっくりと移行できます。

デスクトップアプリを最新化するためのXamlIslandsをご存知ですか？

はい。ただし、Windows 7を使用している（または使用していた）顧客が多すぎるため、エンタープライズ開発者にとっては選択肢ではありませんでした。そして、消費者にとっては、とにかくUWPを使用することができます。

Windows 10でのこの拡張された下位互換性により、Xamlアイランドはより便利になりますか？

このようなものが出荷された時点で、企業でサポートされているすべてのバージョンのWindows 10で動作するため、これは良いスタートです。

既存のUWPXamlアプリをWinUI3.0に更新する

MS向けのコンシューマーアプリは終了しました。MSが選択したため、これ以上の余地はありません。このオプション全体をスキップして、忘れてしまいます。 UWPアプリに何千時間も費やしたので悲しいですが、痛みを和らげるためにこの死を早める必要があると思います。

約束されたストーリー全体は常に最新であり、すべてのデバイスをサポートしていました。私たちは皆、その約束がどのように進んだかを知っていると思います。

Visual Studioまたは別のツールが名前空間を自動的に更新する場合に役立ちますか？

名前空間だけの場合は、検索/置換でもうまくいくはずです。

既存のUWPXamlコンポーネントとWinUI3.0アプリの間の完全な互換性はあなたにとってどれほど重要ですか？

もはや重要ではありません。私は何千時間もの開発の損失を喜んで受け入れます。とにかくユーザーは残っていません。

アプリコードと一緒に簡単に再コンパイルおよび更新できないUWPXamlコントロールライブラリまたはWinRTコンポーネントを作成または使用していますか？

いいえ。

WinUI 3でUWPコンポーネントを使用するための好ましいソリューションは何ですか？

UWPアイランド（ホストされているコンポーネントの一種）

全般的

上記およびロードマップで概説されている全体的な3.0計画についてどう思いますか？新規および既存のWindowsアプリにWinUIを使用できるようになりますか？

おそらくある程度の成熟が必要ですが、私はこのようなものを1〜2年で企業開発に使用していると思います。移行の難しさに応じて、WinUIまたはWebのいずれかを選択します（Windows自体の「進化」に応じて）。

WinUI 3.0を使用するのに最も興奮しているのはどのようなアプリですか？新しいWin32アプリを作成し、MSIXでパッケージ化しますか？ WPFアプリに新しいビューを追加しますか？ FluentUIを使用してC ++ MFCアプリを最新化しますか？

おそらく、WPFアプリに新しいビューを追加して、ゆっくりと移行を開始します。

GeertvanHorrik 2019年05月16日

👎8 👍6 ❤1

私はこのロードマップがとても好きです。 UWPはその束縛から解放される必要があり、これはまさにそれを行うための優れた方法です。

既存のUWPXamlアプリをWinUI3.0に更新する

これは私の雇用主にとって非常に重要です。ストアには複雑なUWPデスクトップアプリがあります。 .NETNativeでサポートされていないwin32APIにアクセスするには、DesktopBridgeが必要です。

をお願いします

すべてのwin32APIへの直接アクセス。
昔ながらのwin32実行モデルを使用します。デスクトップブリッジのようなサンドボックス化（レジストリの仮想化など）は問題ありません。
アプリを現在の状態でストア（msix）に配置します。
引き続きWNS（プッシュ通知）を使用する。
UWPからいくつかの新しいXamlデスクトップアプリタイプへの簡単な更新エクスペリエンス。肉体労働をしてもかまいません。たぶん私はここのツールよりも良いドキュメントを好むでしょう。

既存のUWPXamlコンポーネントとWinUI3.0アプリの間の完全な互換性はあなたにとってどれほど重要ですか？

既存のスタイルは引き続き機能します。私はいくつかの小さな視覚的変化で生きることができます。しかし、行動の変化はありません。

アプリコードと一緒に簡単に再コンパイルおよび更新できないUWPXamlコントロールライブラリまたはWinRTコンポーネントを作成または使用していますか？

いいえ。

WinUI 3でUWPコンポーネントを使用するための好ましいソリューションは何ですか？

再コンパイルできない場合（サードパーティ）：XamlIslandsのようなアプローチ。それ以外の場合は、WinUI3に簡単に移植できるはずです。

全般的

WinUI 3.0を使用するのに最も興奮しているのはどのようなアプリですか？新しいWin32アプリを作成し、MSIXでパッケージ化しますか？ WPFアプリに新しいビューを追加しますか？ FluentUIを使用してC ++ MFCアプリを最新化しますか？

MSIXにパッケージ化されたデスクトップwin32アプリ。
Unoクロスプラットフォームアプリ;）

wbokkers 2019年05月16日

👍6 ❤1

_INotifyDataErrorInfo_のようなものに新しい名前空間を導入しないでください。通常はクロスプラットフォームであり、WinUIに依存してはならないビューモデルで使用する必要があります。このような他のものが配置されている場所（つまり、_INotifyPropertyChanged_または_INotifyCollectionChanged）_を定義する必要があります。

meir-pletinsky 2019年05月16日

👍1

最終的な目標がクロスプラットフォームのUIスタックを作成することであるかどうかを知りたいだけです。それを理解することは、私たちがそこに到達する方法を完全には理解していないかもしれません。ただし、それが目的である場合は、この取り組みの開始時にWinの参照なしでこれをブランド化することをお勧めします。そうすれば、長期的には頭痛が少なくなります。

XamlUIなどのラベルをん。XamlUI3.0などのリポジトリをブランド化するだけです。

お問い合わせいただきありがとうございます。このスペースで何が来るのか楽しみです：smile：

shaggygi 2019年05月16日

👍13 😕2

私にとって、すべての技術的な詳細はそれほど重要ではありません。
UWP、WPF、またはWindowsのみのフレームワークは、それが素晴らしいとは言え、すべてのプラットフォーム（少なくとも、Windows、Droid、iOS、およびWeb）で実行されない限り、十分ではなく、任意の画面サイズ。

TBHは、MSがUWPまたはXAMLをクロスプラットフォームにする計画がないことを発見した最後のビルドで私を失望させました。宇野は演説以外に公認されなかった。さらに苛立たしいのは、MSがReactNativeとHTML / JS駆動のフレームワークAGAIN（WinJS）を非常に愛している一方で、責任のある.NETスタック開発者を無視していることを発見したことです。
MSがUnoのようなクロスプラットフォームのUIスタックを公式に作成し、適切なツール、テンプレート、統合されたサポートを提供することを望んでいます。

そしてところで、私はMSによる買収以来XFと協力してきましたが、次の理由から、XFに代替手段があればいいのにと思います。 Webサポートなしb。非常にモバイルに偏っており、デスクトップが好きではないc。そのライブラリ階層は、WPF / UWPコントロールライブラリと比較すると、間違いなくずさんな感じがします。 MSXAMLを使用していません。
これが私がMicrosoftDeveloper Communityに投稿した機能リクエストです： .NETUIStandard 。

みんなありがとう！

weitzhandler 2019年05月16日

👍22 👎4 ❤3

Web（アセンブリ）でも実行できるXAMLUIが必要です。少なくともUWPのサブセット。
UNOプラットフォームを採用し、SkiaSharpを使用してWebレンダリングを作成してみませんか？
WinUIのWeb版であるSilverlight6である可能性があります

TonyHenrique 2019年05月16日

👍19 👎4 👀2 ❤2

質問への迅速な回答

どのテンプレートに最も興味がありますか？

.NETコアSDKスタイルのプロジェクト、またはいくつかの簡略化されたMSVCプロジェクト形式。
古いプロジェクトファイルは複雑すぎて手動で編集できず、古いプロジェクトシステムと新しいプロジェクトシステムの間には多くの相互作用の問題があります。新しいプロジェクトでは、古いプロジェクトシステムを完全に廃止する必要があります。

デスクトップアプリを最新化するためのXamlIslandsをご存知ですか？

いいえ。データモデルを完全に変更してアプリケーションを書き直しているため、段階的な移行はありません。

Windows 10でのこの拡張された下位互換性により、Xamlアイランドはより便利になりますか？

Windows 7にはまだ多くのユーザーがいて、XamlIslandsは役に立ちません。

既存のUWPXamlコンポーネントとWinUI3.0アプリの間の完全な互換性はあなたにとってどれほど重要ですか？

いいえ。すべてのコンポーネントは自作であるか、MUXおよびWCTKから作成されているため、手動ですばやく移行できます。

Visual Studioまたは別のツールが名前空間を自動的に更新する場合に役立ちますか？

私のプロジェクトは大きくないので、それほど多くはありません（今のところ最大20ページと最大10のカスタムコントロール）。

WinUI 3でUWPコンポーネントを使用するための好ましいソリューションは何ですか？

非常に小さなツールを作成してKBで出荷できるように、OSに同梱されているバージョン

WinUI 3.0を使用するのに最も興奮しているのはどのようなアプリですか？新しいWin32アプリを作成し、MSIXでパッケージ化しますか？ WPFアプリに新しいビューを追加しますか？ FluentUIを使用してC ++ MFCアプリを最新化しますか？

新しいWindows10専用アプリを作成し、ストアなしで出荷します。
信頼できる署名は個々の開発者にとって費用がかかり、ストアへのアップロードはドメイン固有のアプリケーションには適用できません。長期的なアプリケーションには適用できません。

UIプラットフォームの個人的な見た目

Xamlツールチェーン

xaml言語はどういうわけか深刻ではなく、「これをどのように表現すればよいか」などの多くの問題に直面しています。 WPFxamlとUWPxamlは完全には互換性がないため、それらの違いを覚えておく必要があります。 Xamlは.NET機能と完全には互換性がないため、モデルとヘルパークラスにいくつかの醜いトリックを書く必要がある場合があります。

x:Bind来ると、事態はさらに悪化します。単純なシナリオは使いやすいですが、プロパティへのアクセス以上のことを行うのは非常に複雑です。たとえば、メソッドのオーバーロードはサポートされていないため、このバインディング式にどのオーバーロードが選択されているかを確認するためにコンパイルする必要があります。単純な切り替えや、「一部のプロパティがfalseの場合に表示される」変換を行うことすらできず、ヘルパーメソッドが必要です。ドキュメントにはこれらの詳細なシナリオについては何も書かれていないので、xaml-language-designについて議論する立場があり、xamlをC＃のような真剣に設計された言語にする必要があると思います。

xamlエディターも使いにくいです。デザイナーが実際の効果を示すためにいくつかのコードを実行しようとするのは合理的ですが、テキストエディターはメタデータを認識している必要があります。 xamlファイルをソースビューで開くと、デザイナーがアクティブになり、 NullReferenceExceptionやCannot convert __ComObject to some typeなど、完全に実行に適したxamlに対していくつかの対話例外がスローされるため、処理が遅くなります。ビルドされたライブラリを介してProjectReferenceアクセスし、依存関係ライブラリの非パブリックAPI領域（通常はデータモデルの実装）を単純に編集した場合でも、複雑なエラーが発生します。 したがって、メタデータとソースコードを認識し、完全にRoslynに統合されたxamlコンパイラが必要だと思います。

より良いウィンドウモデル

情報がいっぱいで状態がいっぱいのアプリケーションでは、モデルをナビゲートする代わりにマルチウィンドウモデルを使用するのが普通です。現在UWPでは、スレッドの問題があるため、 ApplicationViewを使用して新しいウィンドウを作成するのは面倒です。新しいAppWindowはUIスレッドを共有しており、UIのパフォーマンスについてはよくわかりません。

将来的にWinUIでVisualStudioを書き直すと、成熟したUIシステムであることが証明されます。

データバインディングインターフェイス

INotifyPropertyChanged実装するモデルを作成するのに非常に疲れています。 xmlを拡張プロパティアクセサーに変換するカスタムMSBuildタスクを作成しましたが、プロパティが変更されたときにセッターでカスタムを実行したい場合は役に立ちません。

そして、スレッドの問題があります。私のデータは完全にバックグラウンドネットワークサーバーからのものであるため、 awaitコンテキストキャプチャは役に立ちません。 WPFとBindingでは、 Bindingがスレッド自体を解決するため、そのままです。 x:Bindに変更する場合、 x:Bindは呼び出し元のスレッドでのみ動作するため、イベントレイザー内で解決する必要があります。複数のアプリケーションビューが同じデータにアクセスしている場合、状況はさらに悪化します。つまり、使用可能なグローバルUIディスパッチャーがなく、唯一の解決策はイベント登録時にSynchronizationContext.Currentをキャプチャすることです。コレクションの場合、 ItemsSourceもスレッドセーフではなく、同じ回避策が必要です。

可変のバインド可能なモデルのモデリング、スレッド化、および拡張の問題を解決するためのツールチェーンが確実に存在する必要があります。 また、バインド可能なコレクションの一般的な組み込みソリューションは、「変更された子の指定されたプロパティ」のメカニズムを提供する必要があります。

IObservableVector<T>は、 objectのみを使用できる偽のジェネリック型であり、 INotifyCollectionChangedは非ジェネリックです。特に複雑なISupportIncrementalLoading / IItemsRangeInfo指向のシナリオでは、 ObservableCollection<T>ような組み込みコレクションに実装するだけでは不十分です。プラットフォームは、ベストプラクティスを備えたデフォルトの抽象実装を提供し、ユーザーが抽象データ入力メソッドを実装できるようにする必要があります。

huoyaoyuan 2019年05月16日

👍11

@shaggygi @weitzhandler @TonyHenrique

WindowsレンダラーからXAML構文を抽象化するUWP / XamlUI3.0のクロスプラットフォームの将来がある場合、残りのWindowsランタイムがそれを処理する方法になります。

プロジェクトにほぼプラグインの考え方がある場合は、AndroidまたはiOS / AppKit Renderer、およびART APIをC＃とVB、および既存のC ++、C言語に渡すAndroid / iOS AppKitShimが存在する可能性があります。サポート。
Xamarinはここで役立つ可能性があります。

マイクロソフトは、これらの代替プラットフォームレンダラーに取り組んでいる必要はありません。

しかし、今のところWindowsに焦点を当てています... WinUI 3.0には、Fabric Web / React Native / WPF / WinForms / MFCが含まれる可能性があります。 PWAはアプリ開発の第一級市民でもあるため、Windows / .NET / UWP用に直接作成されていないアプリのクロスプラットフォームストーリーがあります。

今必要なのは、C＃/。NET / UWP開発者が、アプリと投資をプラットフォームのより広いランドスケープにもたらすためのストーリーを提供することです。

mdtauk 2019年05月16日

👍12 👎1

私の2セント：私はXamarin.Formsの開発者であり、（他の多くの人と同様に）すべてのXAML方言がモバイルスペースを含むあらゆる場所で機能する方言にマージされることに興味があります。それがどのように下がるかはわかりませんが、それは少なくとも私の願いです。

anthcool 2019年05月16日

👍12

WinUI 3.0以降はおそらく-しかし、WPFアプリが多すぎて、すべてのXAMLを書き直して変換することを期待できません。新しいWPFプロジェクトでは、より最新のWinRTXAMLダイアレクトを使用できます。 DocTypeに相当するものをXAMLに導入して、同じプロジェクトに異なる方言が共存できるようにすることができます。

もちろん、言うのは簡単です。

mdtauk 2019年05月16日

@mdtauk Xamlプラットフォームが実際にオープンソースになると、スタックの最下部でXamlプラットフォームが何に依存しているかについて、より明確に理解できるようになると思います（プラットフォーム固有の主な依存関係は、DirectX11、Direct2D、およびWindowsであることがすでにわかっています。 Media Foundationですが、Windows SDKのどの部分がそこで使用されているか、およびそれがどのように階層化されているかを誰が知っていますか（移植の実現可能性について実際に感じることができるように）。
また、どのようなライセンスでソースコードが配布されるのかはまだわかりません。まだ決まっているかどうかわかりません。

simonferquel 2019年05月16日

AndroidはVulkanを使用しており、OpenGLをサポートしていると思います
iOSとmacOSはMetalを使用しています

メディアコーデックに関しては、ネイティブCベースのAPIを使用して置き換えることができる場合があります。

@simonferquelコードがリファクタリングされてチェックインされると、より明確になります。また、これらの取り組みを主導するには、iOSおよびAndroidの専門家が必要になる場合があります。

mdtauk 2019年05月16日

👎1

winuiがコントロールのコレクションであった場合、名前空間を変更することは合理的なアプローチだったと思います。しかし、基本的にプラットフォームに取って代わった今、これはもはや正当化されていないと思います。これは、WPF / Winformsでも同じように機能し、コード内の名前空間を変更せずに、コードを.netFrameworkから.netコアに移動できます。プラットフォームを有効にすると、必要なdllのwinuiバージョンを自動的にロードできるようになります。このようにして、ソースとバイナリの互換性（.netコアアプリで.netフレームワークライブラリを正常に使用しました）を維持できます。

lhak 2019年05月16日

👍1

これまでのコメントをありがとうございました！ WinUIチームは、すべての回答とポイントを注意深く検討しています。
また、考えを整理したら、いくつかの焦点を絞った問題を分割して、発生した特定のポイント（たとえば、既存のUWPフレームワークおよびコンポーネントとの互換性）について話し合う予定です。

jesbis 2019年05月16日

❤3

MSにもっと耳を傾け、.net開発者にすばらしいツールを提供してくれたことに感謝しますが、ビルド会議後のUWPXamlの将来に失望せずにはいられません。
このブログとネット上の多くの記事を読むと、UWPが独占的に「エンタープライズ」になりつつあり、多くの企業がOSにとらわれず、たとえばMacBook Proを使用できるようになっているため、それでも議論の余地があります。

私はネイティブのUWPとXamarinForms（Android、iOS）に多額の投資をしており、プラットフォームを気に入っていますが、MSがReactのネイティブサポートを発表した後、私はすぐに出荷されます。

UWPアプリをデスクトップ上でプラットフォームに依存しないようにする必要があることはわかっています。そのため、現在のuwpアプリをシェルとして使用し、Reactを組み合わせて使用することで、より多くのWebフロントエンドテクノロジーを組み込んだ「ハイブリッドアプリ」を作成できることを望んでいました。。私が理解している提案された「セット」機能のようなものは、Edge内の優先度が高いために遅れていますが、ネイティブとWebテクノロジーを実行することで、ネイティブUWPとWebテクノロジーの間の境界線を完全に曖昧にするため、現在のソリューションにとって理想的でした。「ウィンドウ/エッジタブ」。この「ハイブリッド」アプローチにより、現在のプラットフォームにWebテクノロジーをゆっくりと取り入れることができますが、いわば「ブラウザー」に「ネイティブアプリ」のタブが表示されます。（消費者の観点から）これは、「ネイティブuwpアプリ」がデスクトップで長期間失敗した場合のエスケープハッチも提供します。

上記の考えの理由は、クロスプラットフォーム機能がすぐにない場合、UWPは簡単に次のSilverlightの犠牲者になる可能性があるため、エスケープハッチを提供しないためです。 MSは、PWAのトレンドに負けないようにすることで賭けをヘッジしている、またはWindowsでのReactネイティブサポートのために彼らの手が回されている。問題は、この時点までにUWP / c＃/。netのブラウザまたはクロスプラットフォームへの「パス」があり、それらのプラットフォームへの投資のほとんどを再利用できることを期待して賭けたことです。

そこにいるすべての開発者がXamarinの購入を叫んだとき、MSがそれを行うのに永遠にかかったことを覚えています。 Web Assemblyに精通しているほとんどの開発者は、最近WebAssemblyでWindowsServerの「フルバージョン」を実行することに成功したことを知っていると思います。完全なOSをWebアセンブリで実行できる場合、MSはすべての.net開発者に、既存の投資を保護するためのクロスプラットフォーム機能への移行パスを提供する必要があります。

Blazorはそこにあると言うかもしれませんが、率直に言って、新しいプラットフォームにもっと時間を投資する前に、Reactを学ぶか、MSにはこれらすべてのリソースが限られていると言うかもしれません。確かに、Githubに75億ドルを支払うと、すべてが相対的なものになります。

MSが、既存のUWP / Win32投資のクロスプラットフォーム機能への移行パスの失敗によるレピュテーションリスクを理解することが重要だと思います。クロスプラットフォーム機能は.NET5と同義である必要がありますが、そうではありません。この場合、プラットフォームを横断するための赤ちゃんのステップがMSでうまくいくかどうかはわかりません。私は、常にxaml / .net / c＃の大ファンであると信じています。

Pinox 2019年05月16日

👍9

どのテンプレートに最も興味がありますか？

プロジェクトテンプレートまたはアイテムテンプレートも意味しますか？

Visual Studioまたは別のツールが名前空間を自動的に更新する場合に役立ちますか？

これは単に検索と置換（価値が低い）でしょうか、それとも新しいバージョンへの依存関係の更新を組み込んでいますか（より価値がありますが、どのように判断できるかわかりません）

Re：新機能の下位互換性

Creators Update（15063）との下位互換性は固定の参照ポイントになるのでしょうか、それとも現在のバージョンとそれ以前のX個のバージョンをサポートする予定ですか？

これは、公に共有したい拡張機能や独自のコントロールや機能を作成する人にとって何を意味しますか？そのレベルの下位互換性もサポートする必要がありますか？ Windows 8.1でも？

Re：名前空間の移行

既存のUWPを段階的に移行することは可能ですか（私はページを考えています）、それともアプリ全体を一度に更新する必要がありますか？アプリ全体を一度に実行すると、採用が遅くなります。

WPFアプリの移行はどうですか？ -WinUI 2.xまたは3.xを使用できるXAMLアイランドを使用する移行戦略ですか？両方を同じアプリで使用できますか？

はい、この問題を複数のより焦点を絞った問題に分割すると、アイデアをより明確に捉え、接線を回避するのに役立ちます。

mrlacey 2019年05月16日

👍1

何を参照しているのかが明確でないため、 UWPのすべてのインスタンスを適切な名前に置き換えてください。

riverar 2019年05月17日

😄1

@mrlacey ：

プロジェクトテンプレートまたはアイテムテンプレートも意味しますか？

アイテムやライブラリのテンプレートも面白いです！これまでの返信には、追加のボイラープレートとスターターコードを提供することについて、いくつかの優れた点があります。これは、おそらくWindows Template Studioのように、時間の経過とともに追加することを検討できるものです。

これは単に検索と置換（価値が低い）でしょうか、それとも新しいバージョンへの依存関係の更新を組み込んでいますか（より価値がありますが、どのように判断できるかわかりません）

良い質問-どのような種類の依存関係の更新がそれをより価値のあるものにするでしょうか？たとえば、互換性のある新しいNuGetパッケージバージョンを見つけますか？

Creators Update（15063）との下位互換性は固定の参照ポイントになるのでしょうか、それとも現在のバージョンとそれ以前のX個のバージョンをサポートする予定ですか？

サポートバージョンの範囲は、使用状況に基づいて時間の経過とともに変化することを想定しています。特定のバージョン数に制限されるのではなく、使用状況データを引き続き確認し、最もアクティブな市場に出回っているWindows10バージョンをサポートする可能性があります。

これは、公に共有したい拡張機能や独自のコントロールや機能を作成する人にとって何を意味しますか？そのレベルの下位互換性もサポートする必要がありますか？ Windows 8.1でも？

現在、カスタムコントロールに追加の要件や「認証」を課すことは想定していません。バージョン管理はあなた次第です。 2019年5月の更新、WinUI 3.0、およびWinUIの将来のバージョンにわたる全体的なバージョン管理の話は、間違いなく、私たちがすぐにさらに深く掘り下げたいトピックです。

既存のUWPを段階的に移行することは可能ですか（私はページを考えています）、それともアプリ全体を一度に更新する必要がありますか？アプリ全体を一度に実行すると、採用が遅くなります。

すばらしい質問です。ご指摘いただきありがとうございます。これは、私たちがすぐにもっと深く掘り下げたいトピックでもあります。

jesbis 2019年05月17日

何を参照しているのかが明確でないため、UWPのすべてのインスタンスを適切な名前に置き換えてください。

@riverar ：明確でない特定の使用法またはセクションはありますか？

「 UWPXaml 」という用語は、他のXamlベースのプラットフォーム（WPFなど）と区別するために、Windows10およびUWPSDKの一部として出荷されるXamlプラットフォームを指すために使用します。

また、Win32アプリモデルとは異なり、「 UWPアプリモデル」（パッケージ化とインストール、データと状態の管理、ランタイムライフサイクルなど）も参照します。

jesbis 2019年05月17日

Windowsデスクトップでも、ユーザーはWebの閲覧に多くの時間を費やしています。
UWP vNext XAML + .NET（C＃/ F＃/ VB.NET） （のサブセット）を使用して、適切なWebアプリを開発する方法が必要だと思います。

私は長年WPF + ClickOnceで開発し、その後UWPを検討し始めました。私はUWPが好きですが、スタンドアロンEXE、より優れたウィンドウAPI（必要に応じて、カスタムのWinampウィンドウスタイルのアプリを作成できる）、より多くの印刷API、Cdllとの簡単な相互運用を実行できる必要があります。、OCX、コンポーネントの少なくともサブセットはWeb上で実行する必要があります。

UNOを見たとき、私は考えました。Microsoftはこの会社を買収し、これらの開発者をUWPとXamarinのチームに参加させることができます。次のバージョンのUWPが、Web、Windows、モバイル、IoTで動作するAzureのものになったら嬉しいです。 IMOでさえAzureポータルでUWPvNextで作成できます。

マイクロソフトはそれを行うことができます。あなたはSilverlightでそれを行い、WPFを行い、UWPを行い、Xamarinを行いました。今こそ、究極のGUIXAMLフレームワークの時です。そして、私の意見では、少なくとも機能のサブセットであるWebがサポートされている必要があります。

TonyHenrique 2019年05月17日

👍5 👎2

_INotifyDataErrorInfo_

_INotifyDataErrorInfo_のようなものに新しい名前空間を導入しないでください。通常はクロスプラットフォームであり、WinUIに依存してはならないビューモデルで使用する必要があります。このような他のものが配置されている場所（つまり、_INotifyPropertyChanged_または_INotifyCollectionChanged）_を定義する必要があります。

このトピックについて。 Windows.UI.Xaml.InteropにはすでにINotifyCollectionChangedインターフェイスがあり、Windows.UI.Xaml.DataにはINotifyPropertyChangedがあります。これら2つはMicrosoft名前空間に移動されます。おそらく、System.Runtime.WindowsRuntimeアセンブリは、WinUIから.Netへのマッピングを実行できます。

marb2000 2019年05月17日

まだ追加されていない場合に追加したいのは、MSIX / Appxパッケージモデルを100％サポートし、Win10はWindowsの存続期間にわたってインストールと削除であったたわごとを修正するという素晴らしい仕事をしたことです。ただし、AppContainerサンドボックスで行われた利用可能なAPI選択の奇妙なサブセットのために、私は常に「UWP」アプリケーションの構築に苦労していました。 C ++開発者として、それは苛立たしいことであり、毎年、完全なWin32APIセットを許可するためにサンドボックスをさらに開くのを見ると安心しました。

したがって、WinUI 3.0でWin32スタックの100％にアクセスできるアプリを作成できる場合、これはすばらしいことです。私は今XamlIslandsを使ってみました、そしてそれは素晴らしい脱出ハッチです、しかしそれは私にとって不安定であり、そしてそれが本当にフィニッシュラインを越える前にそれはいくつかの仕事を残しています。

AppContainerプロセスに詰め込まれずにWin32アプリを構築し、UIで行ったすべての進歩にアクセスできるプロジェクトテンプレートを入手すれば、WinUI3は私にぴったりです。

eklipse2k8 2019年05月17日

👍6 ❤1 👎1

@ eklipse2k8リラックスしたサンドボックス内であっても、ユーザーのファイルやデバイスにアクセスするための許可システムが必要です。また、ユーザーランドを維持し、管理者やカーネルへのアクセスへの昇格を回避するためのルールが必要だと思います-何らかの公式のテストやコード署名の要件はありません。

mdtauk 2019年05月17日

👍1

こんにちはマイクロソフト、

この投稿がフォントレンダリング、 ClearType 、 DirectWrite 、およびWindows UIの将来のトピックにどの程度影響するかはわかりませんが、私は小さいながらも声高で情熱的な数少ない人の1人であり、フォントレンダリングサブシステムに深刻な不満を持っています。ウィンドウズ。

これは、Windows UIとフォントレンダリングに対するインターネットの人々のフラストレーション（または満足度）について、ほとんどどこでも十分に文書化されています。フォントスムージングが好きな人もいれば、絶対に嫌いな人もいます。

私は、一方が他方より優れているかどうかを議論するためにここにいるのではありません。また、レジストリのハッキング、「フォントチューナー」、またはOS設定を微調整してフォントの見栄えを良くする方法についても説明しません。私を信じてください、私はそれをすべてやりました。カーネルモードでDirectWrite関数にパッチを適用するカーネルモードドライバーを作成するための調査を行っているところまで行っています。

私がここにいるのは、近視/近視と呼ばれる非常に一般的な視力の病状があるからです。物事を間近ではっきりと見ることができます。しかし、ちょうど腕の距離で、私の視力は私の視力の端にあり、テキストがぼやけ始めます。

腕の距離を超えて、矯正レンズを着用する必要があります。：眼鏡：私たちは皆知っていると確信しています、デスクトップコンピュータの画面はほぼ腕の距離にあります。したがって、問題。

滑らかに見えるフォント、私にはぼやけて見えるフォント。
シャープなエッジ（ピクセルにスナップ）のあるフォントは、私にははっきりと見えます。

フォントがピクセルにスナップされると、鋭いエッジは、私の視覚が明確で焦点が合っていることを脳に視覚的私の視力が焦点から外れてます。

コードを書いたりテキストを見たりするのに長い時間を費やす仲間の開発者として、それはイライラし、地獄のように痛いです。これが、私がまだWindows10ではなくWindows7を実行している主な理由です。 Windows10のメインMetroUIのほとんどすべてが、あらゆる場所でフォントスムージングを使用しています。

このフォントスムージングの問題を説明するために、 Windows7のservices.msc MMCスナップインを見てみましょう。

mmc_3104

焦点が合っていないように見えるぼやけたテキストがありますか？ここ。もう少しズームインしてみましょう...

psp_3105

良さ、優雅さ、それは私がオートステレオグラムで斜視のテキストを見ているように感じます。

この特定のケースでは、このウィンドウのコントロール階層を掘り下げて、MMCスナップインがInternet Explorer DHTML / ActiveXコントロールをホストし、[説明を表示するアイテムを選択]パネルであいまいなテキストをレンダリングしていることがわかりました。シャープな（ピクセルにスナップされた）「ヘルプ」メニューとサービスのリストは、通常のUSER32およびGDI32プリミティブでレンダリングされます。

この小さな例は、Windowsでのフォントレンダリングに関する最大の問題の1つを強調しています。 IE8は、ClearTypeとフォントスムージングを無効にするグローバルオペレーティングシステム設定を尊重することがわかりました。ただし、IE9以降をインストールした場合、IE9 +は、フォントの平滑化を無効にするためのあらゆる努力を喜んで無視します。 IE9 +は気にせず、すべてのユーザーにフォントが滑らかなテキストを含むWebサイト（およびActiveXコントロール）のテキストを表示するように強制します。

時間が経つにつれて、Windows8とWindows10、Metro Apps、WPF、UWPの誕生はすべてIE9 +と同じアプローチを取っているため、私のようなユーザーにとっては問題はさらに悪化します。内部のこれらのUIテクノロジーはすべて、マシンで尊重されるべきグローバルなオペレーティングシステム全体の設定します。 オペレーティングシステム全体のレベルでClearTypeとフォントスムージングを無効にすると、ClearTypeAPIとDirectWriteAPI（したがって、Metro、WPF、およびUWPアプリ）はフォントスムージングで描画されないことが予想されます。

この問題を抱えているのは私だけではないことを私は知っています。

しばらく前に、Google Chromeはv31リリースで同じことを行い、IE9 +アプローチに従って試行し、システム全体のグローバル設定を無視して、すべてのフォントレンダリングをDirectWriteに切り替えました。この変化はインターネットを激怒させました。 Chromium Issue319429を参照してください。最後に、多くの歯ぎしりの後、Googleはコースを逆にし、近視の視覚障害を持つユーザーのためにChrome 37の問題を修正し、フォントスムージングを無効にするオペレーティングシステム全体の設定を尊重するようになりました。

存在する力と市場の力のおかげで、 Microsoftはブラウザ戦争に敗れ、現在Chromiumレンダリングエンジンを採用していますが、Edgeチームが無効にされたフォントスムージング設定を尊重することを私は息を切らして保持します。

私がここにいるのは、視力に問題がある人のために、オペレーティングシステム上のすべてのアプリ、すべてのUIスタックで、Microsoftが尊重する必要のある1つのグローバル設定

また、これはWindows UIの一般的なアクセシビリティの問題であり、視覚的な好みの

近視の世界的な有病率に基づいて、現在の世界人口の22％以上、つまり15億人が近視であると推定することができます。 https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

ありがとう、
ブライアン

：walking_man ：： walking_woman：行方不明者-LAを

bchavez 2019年05月17日

❤6

これは、完全なXamlフレームワークがGitHubで開発され、 NuGetパッケージとして帯域外で出荷されることを意味します。

NuGetは素晴らしいですが、 vcpkg （およびCMake ）をサポートすることもありがたいです（大規模な既存のクロスプラットフォームライブラリを使用している私たちにとって）。

どのテンプレートに最も興味がありますか？

優先順：
Win32 + Xamlデスクトップ+ WinUI
Win32 + Xaml Islands + WinUI
UWP + WinUI

デスクトップアプリを最新化するためのXamlIslandsをご存知ですか？Windows 10でのこの拡張された下位互換性により、Xamlアイランドはより便利になりますか？

はい、Xaml諸島は興味深いですが、企業顧客ではなく消費者を対象としているため、拡張された下位互換性は取引を妨げるものではありません-ほとんどの顧客はOSを更新することにかなり満足しています（そして新しいWinUIに基づいて変更を実装するためのタイムスケールを与えられていますXamlは、1903年にロックダウンされているため、おそらく1年が経過していることを意味します）。

WinUIのXaml、コンポジション、および入力APIのルート名前空間は、Windows UWPSDKルート名前空間とは異なります。
Visual Studioまたは別のツールが名前空間を自動的に更新する場合に役立ちますか？

UWPアプリ（現在、直接販売にはWPFを使用し、ストアにはWPF + Desktop Bridgeを使用している）がないため、これは私には影響しませんが、名前の変更は1回限りであり、最大のコードベースでもWindows::UI::Xamlグローバルな検索と置換は、それほど困難ではありません（私たちは皆、バージョン管理を正しく使用しています..？）。

WinUI 3.0をリリースするための最速の方法は、ミキシングをサポートしないことです。

それは私にとっては問題ありません、それらは別々の互換性のないライブラリとして扱われるべきです。 UWPXamlまたはWinUIXamlのいずれかをターゲットにします。上記のように、1回限りの変換はそれほど難しいことではありません。

ただし、私たちの最大の懸念の1つは、特にUWP Xamlコントロールライブラリを作成または使用している場合に、既存のUWPアプリとコンポーネントライブラリに発生する可能性のある互換性の問題と作業です。
たとえば、 Windows CommunityToolkitの既存のバージョンはWinUI3.0アプリでは使用できないため、Toolkitとそれを使用するアプリの両方をWinUI3.0を使用する前に更新する必要があります。

マイクロソフトはテクノロジーを選び、それに固執する必要があります。何年もの間、最新かつ最高のデスクトップUIフレームワーク（Win32、ATL、WTL、MFC、WinForms、WPF、UWP Xaml、そして現在はWinUI Xaml）が約束されてきました。選択は素晴らしいですが、それは機能と開発者の知識の断片化につながります。 Windowsで機能を実装する際に、1つのセッション/ 1つのWebページ/ 1つのstackoverflowの回答を得る方がはるかに簡単ですが、技術によっては7つの異なる回答があります。 WinUI Xamlが将来の場合、それを利用するにはCommunityToolkitを更新する必要があります。

既存のUWPXamlコンポーネントとWinUI3.0アプリの間の完全な互換性はあなたにとってどれほど重要ですか？

（Win32 / WPFと比較して）機能がないため、UWP Xamlで何かをするのを延期してきましたが、その点では私だけではないと思います。そのため、完全な互換性は問題ではありません。

アプリコードと一緒に簡単に再コンパイルおよび更新できないUWPXamlコントロールライブラリまたはWinRTコンポーネントを作成または使用していますか？

いいえ。

WinUI3でUWPXamlコンポーネントを使用するための好ましいソリューションは何ですか？

該当なし

上記およびロードマップで概説されている全体的な3.0計画についてどう思いますか？新規および既存のWindowsアプリにWinUIを使用できるようになりますか？

ロードマップにはXaml Desktopについての言及はありません。これはWinUIの権限に該当しますか？
これは// Build /の人々に以前に言及しましたが、以前にUWP Xamlを採用しなかった理由は、既存のC ++ライブラリを利用するアプリケーションを作成できなかったためです。たとえば、ユーザーがFileOpenPickerを使用してファイルを選択すると、結果はIStorageFileとして配信され、これを既存のサードパーティライブラリ（ libpng 、 libjpegなど）に渡して開く方法はありません。これが、WPFに固執しなければならなかった理由です。したがって、 Xaml DesktopまたはWin32 + Xaml Islandsこれらの制限なしで生活できる場合は、はい、新しいアプリケーションにWinUIを使用できるようになります。

WinUI 3.0を使用するのに最も興奮しているのはどのようなアプリですか？新しいWin32アプリを作成し、 MSIXでパッケージ化し

WinUIを使用して新しいWin32アプリを作成する（およびMSIXを使用してパッケージ化する）。

ご不明な点がございましたら、お気軽にお問い合わせください。さらに詳しくお話しさせていただきます。

MarkIngramUK 2019年05月17日

👍4

実際には、WPF / WinFormsからコンパクトオーバーレイを呼び出す方法があることを望んでいます。
Androidの「他のアプリの権限を上書きする」のような管理者権限システムが必要です。

このアプリモデル+パッケージング（UWP + AppX、Win32 + MSIX）でそれが可能になることを願っています（サンドボックス内の完全な抽象化）

Windowsは、最高のセキュリティを備えた、最も高度で無制限の可能性があると考えられていませんか？
セキュリティのための機能不全によるものではありません。

meteorsnows 2019年05月17日

❤1 👍1

ロードマップに関する情報をコミュニティに公開していただき、ありがとうございます。

既存のUWPXamlコンポーネントとWinUI3.0アプリの間の完全な互換性はあなたにとってどれほど重要ですか？

現時点では、エンタープライズクライアント用にかなりの数のUWPアプリが使用されており、移行パスがそれほど難しくないことを願っています。重大な変更がある場合移行パスの互換性を生成する.Net Frameworkから.Net Coreような移行ツールがあると非常に便利です。これにより、変更が必要になる可能性のあるものがすべて報告されます（たとえば、非推奨または動作が異なる可能性のあるAPI）と、可能であれば名前空間を自動的に変更するオプション。このように、UWPからWInUIへの移行パスは、エンタープライズ開発者にとってそれほど不安定ではありません。

デスクトップアプリを最新化するためのXamlIslandsをご存知ですか？
Windows 10でのこの拡張された下位互換性により、Xamlアイランドはより便利になりますか？

はい。ただし、新しく開発されたすべてのデスクトップアプリはAPIバックエンドを介したUWP通信を使用しており、ほとんどのクライアントはすでにWindows10を実行しているため、それほど問題にはなりませんでした。

上記およびロードマップで概説されている全体的な3.0計画についてどう思いますか？新規および既存のWindowsアプリにWinUIを使用できるようになりますか？

デスクトップチームはすでにWinUI3のニュースに興奮していますが、前述のように、パスがそれほどスムーズでない場合は、すべてのUWPアプリがそれに移行することを恐れています。

一般的なXAMLに関しては、XAML UIフレームワーク全体がWindowsから切り離されて生きているため、他の人が声を上げているため、レンダラーを交換することができます。これにより、他のプラットフォームでWinUI XAMLを実行できる可能性が広がります。これは、現在、スタックを選択する際の大きな決定要因です。これは、ElectronおよびJSフレームワークの人気が、プラットフォームごとにネイティブコードベースを具体的に開発するための人材。

また、WinUI 3以降では、XAMLダイアレクトも改善されるはずです。バージョン名前空間/ Doctypeを導入して、使用されているXAMLのバージョンを指定し、古いアプリとの下位互換性を維持することもできます。単純なプロパティ属性でNotifyPropertyChangedAttributeと言うのではなく、 INotifyPropertyChangedをバッキングプライベートセッターで記述して、ビルドステップでは、実装を挿入して実行時のオーバーヘッドを回避するか、カスタムコントロールのDependencyPropertiesを使用してコンポーネントの作成を簡素化します。たぶん、彼らが持っているいくつかの良い部分のために、Razorチームのいくつかの改善を行うかもしれません。

これらの要求は実行可能かどうかはわかりませんが、私はXAMLが大好きで、XAMLが引き続き改善されることを望んでいるので、私とチームの一部が開発時に抱えていた問題点のいくつかを述べます。

RyoukoKonpaku 2019年05月17日

👍2

@mdtauk私はファイルセキュリティに反対していませんが、基盤となるカーネルは、まったく新しいAPIセットを使用してwin32ファイルAPIを放棄するのではなく、許可されていない場所に書き込むことを防ぐ必要があります。また、これが話題から外れていることはわかっていますが、StorageFile / StorageFolder APIはひどい代替品であり、ファイルのセキュリティも考慮されていません。それらは遅く、ランタイムファイルブローカーを介して常にプロキシされます。さらに、サンドボックス化されたアプリがユーザーのドキュメントフォルダーに書き込むために特別なMS承認済みのアクセス許可を必要とすることは決して制限ではありませんでした。たとえば、AppContainerの取り組みのファイルストーリーがいかにくだらないかというと、ユーザーの非表示のLocalDataフォルダー以外の場所にsqliteDBを作成することは不可能でした。ユーザーがファイルを作成、保存、開いて、yadda yaddaとして保存するデスクトップシステムの場合、ユーザーのコンテンツの管理方法をユーザーに再トレーニングする必要があるという負担がソフトウェア開発者に課せられます。

管理者アクセスに関する限り、2018年10月のリリースでは、資格として「allowsElevation」が追加されました。これは理にかなっています。一部の機能セットに対してその広範なシステムレベルのアクセスが必要な場合、アプリはユーザーが管理者として実行できるようにすることができます。私たち全員がかわいい小さな写真エディタやフローチャートアプリを作成しているわけではありません。

eklipse2k8 2019年05月17日

👍1

@MarkIngramUKコメントありがとうございます。1つだけ説明します。 // Build2019のSneakPeekで提示されたXamlDesktopの概念は、WinUIDesktopに名前が変更されました。この新しいVisualStudioプロジェクトは、プレゼンテーションフレームワークとしてWinUIを備えたWin32アプリモデルを使用し、ネイティブまたは管理（.NET Core 3を使用）できます。

marb2000 2019年05月17日

👍6 ❤2

ありがとう@ marb2000-これはWinUI3.0の時間枠内ですか？

MarkIngramUK 2019年05月17日

@ marb2000 by WinUI Desktop、つまりXamlアイランドを備えたWin32アプリですか？これはどのビルドセッションで表示されましたか？

mdtauk 2019年05月17日

WinUIチームがWinUI3.0の名前変更で注意する必要があることの1つ：.NETで投影されるタイプのいずれかの名前を変更すると、投影は機能しません（また、そうでないため、これ以上追加する予定はありません）。保守可能な拡張可能なシステム）。投影するタイプのリストは次のとおりです： https ：

これらのタイプとは異なるタイプに変更を加える場合、ユーザーは、新しいインターフェイスを実装する新しいオブジェクトでオブジェクトをラップするか、データを新しいタイプにコピーする必要があります。特に、 INotifyPropertyChangedおよびINotifyCollectionChangedタイプは、XAMLアイランドおよびダウンストリームサポートの提供に関して重要です。

jkoritzinsky 2019年05月17日

INotifyDataErrorInfo
INotifyDataErrorInfoのようなものに新しい名前空間を導入しないでください-通常はクロスプラットフォームであり、WinUIに依存してはならないビューモデルで使用する必要があります。このような他のものが配置されている場所を定義する必要があります（つまり、INotifyPropertyChangedまたはINotifyCollectionChanged）
このトピックについて。 Windows.UI.Xaml.InteropにはすでにINotifyCollectionChangedインターフェイスがあり、Windows.UI.Xaml.DataにはINotifyPropertyChangedがあります。これら2つはMicrosoft名前空間に移動されます。おそらく、System.Runtime.WindowsRuntimeアセンブリは、WinUIから.Netへのマッピングを実行できます。

返信ありがとうございますが、.NET StandardのSystem.ComponentModelに既に含まれているのに、なぜMicrosoft名前空間に必要なのですか？ https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

meir-pletinsky 2019年05月17日

@ meir-pletinsky。 NETは、UWPXAMLを使用してアプリを作成するために使用できる唯一のフレームワークです。使用するフレームワークに関係なく、開発者がテキストフィールドの検証を利用できることを望んでいます。

mdtauk 2019年05月17日

@mdtauk 、いいえ、WinUIデスクトップ（以前のXamlデスクトップ）では、アイランドを使用せずに、Win32でXamlを直接使用できます。

MarkIngramUK 2019年05月17日

👍4 ❤2

@ marb2000アプリケーションパッケージプロジェクトで、Win32ウィンドウを使用してAppXを構築し、UWPプロジェクトと同じ簡単な方法でWinRTコンポーネントを含めることができれば素晴らしいと思います。リソースの追加や、含まれているWinRTコンポーネントからヘッダーを生成するcppwinrtコンパイラなど、vcxprojファイルを手動で編集しないと機能しないことがたくさんあります。

eklipse2k8 2019年05月18日

❤1 👍1

この新しいUIにとって重要なもう1つのプロジェクトは、自動実装INotifyPropertyChangedを可能にするSimon Croppによる_PropertyChanged.Fody_です（C＃/ F＃で試しました）。 https://github.com/Fody/PropertyChangedを参照して

これにより、次のような単純なコードが可能になります。

[AddINotifyPropertyChanged]
public class Person
{
    public string Name { get; set; }
    public string FamilyName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged;
}

UIにバインドするために使用できます。

TonyHenrique 2019年05月18日

👍4

WinUI 3.0で見たいことの1つ：現在、UWP XAMLコンパイラ（ genxbf.dll ）は、csproj、vbproj、またはvcxprojファイルから参照された場合にのみMSBuildから直接呼び出すことができます。これは、この機能を呼び出すために使用できるコマンドラインツールがないためです。 Windows 10 SDKのダウンロードでは、Visual Studioを必要とするものは他にないため、これは非常に奇妙な決定だと思います。（WDKアドオンにはVisual Studioターゲットも含まれていますが、これらのターゲットはすべて、VSとは独立して使用できるコマンドラインツールを呼び出します。）たとえば、 XbfCompiler.exeやXbfCodeGen.exe追加していただければ幸いです。 SDKのbinディレクトリに移動します。（前者のEXEはXAMLファイルをXBFファイルにコンパイルし、後者はコードからXAMLタイプを参照するために必要な分離コードファイルを生成します。）これは主に、CMakeまたは別の非ビジュアルを使用するC ++プロジェクトで役立ちます。 Studioビルドツールですが、必要に応じてC＃およびVB.NETプロジェクトにも使用できます。ありがとう！

wjk 2019年05月18日

👍5

@MarkIngramUKあなたは私がWinUIデスクトップについてもっと学ぶことができる場所をたまたま知っていますか。これらのBuild2019セッションは、オンラインで視聴することはできません。このリポジトリでリンクする必要がある重要な情報のように聞こえます

mdtauk 2019年05月19日

@mdtaukビルドの参加者専用の、いわゆるスニークピークで言及されました。 Afaik録音はありません。私もそこにいませんでしたが、ツイッターで入手できるスライド（おそらく最高のスライド:-)があります： https ：

thomasclaudiushuber 2019年05月19日

👍1

@mdtauk WinUI 3ロードマップには、ビルドスニークピークで示されたものよりもさらに最新の最新情報と図が含まれています。「XAMLデスクトップ」や「WinUIデスクトップ」のようなものはありません...それは、写真を撮られたスライド上の紛らわしい言葉の選択でした。伝えられている概念（およびロードマップはこれをより明確に説明しようとしています）は、WinUI 3のUIにWinUI3を使用して新しい従来のデスクトップ/ Win32モデルアプリを作成するプロジェクトテンプレートを作成できるように取り組んでいるというものです。（今日と同じように、従来のDesktop / Win32モデルの上にWinForms、WPF、MFCなどのUIフレームワーク用のテンプレートがあります）WinUI3を使用する更新されたUWP / WinRTモデルアプリプロジェクトテンプレートに加えて、それはありますか？明確にするのに役立ちますか？

pag3 2019年05月19日

👍3

3.0ロードマップは、次の戦略にとって非常に合理的であるように思われます。すべてのWindowsクライアントアプリがXAMLと「最新の」WinUIコントロールを使用できるようにします。

ただし、今日の市場の現実を考えると、この戦略は近視眼的であるように思われます。多くのアプリ開発では、AndroidとiOSが主なターゲットであり、Windowsがあれば便利です。 .NET開発者にとって、XamarinはAndroidとiOSの適切なサポートを提供しますが、Windowsのサポートは標準以下です。したがって、ネイティブモバイル/デスクトップアプリの場合、Win UI 3.0は、.NET開発者のクロスプラットフォーム開発を簡素化するために何もしません。

私が本当に見たいのは、真に普遍的な願望を持った、進歩的なXAML方言です。 XAMLを使用して.NETアプリを作成し、そのアプリをWindows、iOS、およびAndroidで実行できるようにする必要があります。アプリは各プラットフォームで真にファーストクラスであり、必要に応じてネイティブ要素にアクセスできる必要があります。前述のように、Xamarinは良いスタートですが、XAMLの方言は大きく異なり、Windowsのサポートが不十分であり、実行している作業はどれも役に立ちません。

ですから、tldr、Windows用の最新のUIプラットフォームを提供し続けているのは良いことです。さまざまな種類のアプリから使いやすくなっているのは良いことです。クロスプラットフォームのサポートを望んでいないのは残念です。

mfeingol 2019年05月19日

👍9

オプションで、サスペンド+トゥームストーンなどのレガシーモバイルアプリケーションのライフサイクル動作を無効にするか、オプトアウトします。

現実には、UWPはデスクトップ環境であり、少なくともゲームの場合、ユーザーはアプリを最小化することがよくあります。これは通常、アプリの一時停止/トゥームストンにつながります。これは耳障りな体験であり、win32デスクトップアプリやゲームとは大きく異なります。まだ期限切れになる可能性が高い延長延期を要求するだけでは、これにシームレスに対処するのに十分ではありません。

このライフサイクルは一部のアプリにとっては便利ですが、他のアプリにとっては有害です。理想的には、デスクトップアプリまたはゲームは、アプリがサスペンド+トゥームストーンライフサイクルモデルをオプトアウトできるようにする機能を宣言できる必要があります。これにより、最小化されたときにアプリが最終的にサスペンドされるのを防ぐことができます。

natemonster 2019年05月19日

👍3

@natemonster

あたり： https ：

デスクトップデバイスでは、ExtendedExecutionReason.Unspecifiedで作成された拡張実行セッションには、バッテリー対応の時間制限があります。デバイスが壁電源に接続されている場合、延長された実行期間の長さに制限はありません。デバイスがバッテリ電源で動作している場合、実行時間が延長されると、バックグラウンドで最大10分実行される可能性があります。

タブレットまたはラップトップのユーザーは、アプリの設定によるバッテリー使用量で[アプリにバックグラウンドタスクの実行を許可する]オプションが選択されている場合、バッテリー寿命を犠牲にして同じ長時間の動作を得ることができます。

kmgallahan 2019年05月19日

@TonyHenriqueは、について言及するとき、それを認識させたいからですか、それともWinUIに組み込む必要があると言っていますか？

mrlacey 2019年05月19日

👍1

アイテムやライブラリのテンプレートも面白いです！これまでの返信には、追加のボイラープレートとスターターコードを提供することについて、いくつかの優れた点があります。これは、おそらくWindows Template Studioのように、時間の経過とともに追加することを検討できるものです。

@Jesbis私は

どのような種類の依存関係の更新がそれをより価値のあるものにするでしょうか？たとえば、互換性のある新しいNuGetパッケージバージョンを見つけますか？

NuGetの更新を検出できると便利ですが、更新の取得には他にも互換性の問題が発生する可能性があります。新しいバージョンの検出と自動変換の優先度を低くします。非常に多くの考慮事項があるため、それ自体が大きなプロジェクトになるので、このようなツールよりもプラットフォームに時間を費やしたいと思います。

mrlacey 2019年05月19日

@mrlacey Fodyについて言及したのは、それが興味深い解決策であり、_INotifyPropertyChanged_ボイラープレートコードを回避するためのより良い方法が必要
C＃クラス、さらにはF＃レコードでも機能します（ただし、いくつかの問題がありました）。
したがって、WinUIロードマップにもこれが含まれているはずです。

注：F＃レコードを使用してデータエンティティを定義し、XAMLUIに直接バインドすることもできれば便利です。 F＃Records + Fody + DataBindingを問題なく使用できれば素晴らしいと思います。

[<PropertyChanged.AddINotifyPropertyChangedInterfaceAttribute>]
[<CLIMutable>]
type Person =
    {
        ID: Guid

        mutable Name: string
        mutable Addresses: ObservableCollection<Address>
    }

これは、C＃から来る人々にとってより馴染み深いでしょう。
別のアプローチは、エルミッシュの方法です。どちらもおもしろくてサポートできると思います。

TonyHenrique 2019年05月19日

@tonyhenrique / @mrlacey Fodyのもの（OAP）は範囲外である必要があると思います。 WinUIチームはすでに十分な準備が整っているので、別々のプロジェクトで織り込む方が良いと思います（改善された場合はリリースサイクルがはるかに速くなります）。

そして、これは実際にはモデルの.NET（IL）実装の詳細であり、実際にはWinUIとは何の関係もないと思います（ただし、変更イベントをリッスンすることはできます）。私の提案は、それらを別々に保つことです。たとえば、私はCatelを使用していますが、Catelには独自のFodyウィーバーがあり、すべてが正しく織り込まれていることを確認しています。

GeertvanHorrik 2019年05月20日

❤1 👍1

私が本当に見たいのは、真に普遍的な願望を持った、進歩的なXAML方言です。 XAMLを使用して.NETアプリを作成し、そのアプリをWindows、iOS、およびAndroidで実行できるようにする必要があります。アプリは各プラットフォームで真にファーストクラスであり、必要に応じてネイティブ要素にアクセスできる必要があります。

その方向に進むための長年の提案があります： Cross platform UX for .NET Core 3.0 。それに対するコミュニティの圧倒的な支持は明白であり、MSFTがこれが.NETで動作するUIフレームワークを開発するための最良の方向であることを理解することを期待できます。異なるプラットフォームグループ用に別々のコードベースを保持し、.NETでサポートされている異なるUXフレームワークに基づいて別々の開発者スキルセットを強制的に作成する理由はほとんどありません。

すべてのプラットフォームに単一のUXを作成することで、framewrk開発のすべての非効率性を解消し、開発者の採用に対する障壁を低くします。

4creators 2019年05月20日

👍2

@mfeingol / @ 4creators 、私は解決します

アプリは~~、各プラットフォーム~~で真にファーストクラスます

まずはWindowsで...

2019年です。高速なネイティブUIが必要です。また、 CreateWindowExW 、GDIなどを使用してユーザーインターフェイスを作成することを真剣に検討する必要はありません。

MarkIngramUK 2019年05月20日

👍1

WinUI3.0以降では、コードがWindows 10から切り離されたので、WinUIがLinuxとMacで動作する将来の計画はありますか？

Suriman 2019年05月20日

🎉1

@jesbisTouchのインタラクションはWinUI3.0で保持されますか？

r7dev 2019年05月20日

明確化のおかげで、3.0が機能する方法は、Community Toolkitを使用するのではなく、WinUIにXamlIslandsを含めることであると想定していました。

XAMLとWin32になると、特にWindows CoreOSがXAMLでシェルを書き換える場合に意味があります。

私が今理解しているように、この豊富なWin32APIアクセスはCおよびC ++にあります| .NETに依存するC＃のすべてのもの（現在はすべて.NET Core）。

おそらく、これらのWin32 APIにアクセスするための安全で簡単な方法と、アプリのUIを表示するためのより多くのエントリポイントが必要ですか？

WinUI3アプリ用のシステムトレイXAMLフライアウト
Hololens / Xbox / Surface Hub / IoTなどのシンプルなピッカーUI
更新されたXAMLのカスタマイズ可能な共通ファイルダイアログ、およびフォルダーピッカー
Win32 APIへの単純なC＃.NETアクセス
Win32およびWPFコントロールのサイズ設定に一致するすべてのXAML要素のコンパクトな設定（これにより、フレームワークを快適に組み合わせることができます）
WinUIを使用する場合の一致するコントロールスタイル/フォント/アクセントブラシ/アクリル
WinRT /モバイルライフサイクルが必要なデバイスの明確な定義
Xboxアプリの開発とWindowsでのテスト用に組み込まれたXboxNextコントロールスタイル
ストアおよび単一のexe / MSI / APPXパッケージングとダウンロードがデフォルトでサポートされ、インストーラーなし、100周年タイプのファイルシステム仮想化がデフォルトでサポートされます
WinForms WinUI 3.0-シンプルなUI、MFC、マウス、キーボードのみへのアクセス
WPF WinUI 3.0-高密度UI、3Dレンダリング、DPI対応、シミュレートされたタッチ、および基本的なインクのサポート
Xaml WinUI 3.0-フルタッチ、MR、ゲームパッド、インク、音声、マウス、キーボード。密度の高いシンプルなUI。新しいウィンドウサポート。 MR3Dレンダリング。オプションのマネージドライフサイクル、またはデスクトップライフサイクル。メモ帳、charmap、ペイント、ファイルエクスプローラーなどのWin32バージョンの受信トレイアプリを備えた、シェルおよび再加工された受信トレイアプリのデフォルトのすべての世界のベスト-オープンソースでストアから入手できます。

mdtauk 2019年05月20日

タッチ操作はWinUI3.0で保持されますか？

@ r7devはい、計画は同じレベルのタッチサポートを維持することです。

jesbis 2019年05月20日

WinUI 3.0ロードマップではF＃は無視されます。マイクロソフトは、自社製品の1つをもう一度無視しました。

Happypig375 2019年05月20日

👍2

Win32APIの考え

私も考えたのは、win32が立ち往生している理由です。これはレガシープロジェクトによるものだと思いますが、実際はそれよりもかなり深いです。 Win32 ABIは、選択した言語、nodejs、python、rust、go、ruby、c＃、c ++などに非常に簡単に接続できます。たとえば、コアプロジェクトが錆びていて、ウィンドウを生成したい場合出力を管理するために、Rust開発者として、win32 APIセットにアクセスし、同じ言語でフロントエンドを構築することは非常に強力です。

OS Xでは、AppKitにアクセスするには、objc_msgSend C APIをブリッジして、obj-cインフラストラクチャ全体にアクセスする必要がありました。上記のすべての言語はそれを橋渡しするのに本当に良い仕事をしました、そしてそれはあなたの選んだ言語で書くことと説得力のある何かを作り出すことを簡単にしました。

したがって、WinUI 3.xを低レイテンシ、低メモリ、高品質のWin32 UIにアクセスするための真の道にしたい場合は、他の言語メンテナがインフラストラクチャを簡単に利用できることを考慮する必要があります。

UIの一貫性

UIをシステムから切り離すことを本当に計画している場合、各OSアップグレードと一貫性を保つUIの計画は何ですか？ AppleがAppKitまたはiOSでシャドウとグラデーションを微調整すると、システムフレームワークに依存するアプリはそれらの微調整をすべて継承し、一貫性を保ちます。また、3年前にUIインフラストラクチャにロックされていたアプリは、一部の新しいシステムサービスではうまく動作しない可能性があるため、システム全体のエクスペリエンスを追加するのが難しくなります。そのため、時間の経過とともに別の互換性レイヤーが追加されます。

オプトインする必要のある機能は常に存在します。ダークモードは、アプリがそのために設計されていない場合、オプションとして提供することは実際には意味がないものと考えることができますが、それでもあります時間の経過とともに変化するシステムコンポーネントを微調整します。

バイナリサイズ

これらすべてのUI.dllをプロジェクトで提供するために計画されているストーリーは何ですか？これらのものは、プロジェクトに同梱する必要がある40MBのランタイムになりますか？プロジェクトが放棄された場合はどうなりますか？古いUIフレームワークを使用しているため、プロジェクトは古く見え始めますか？

C ++の利点の1つは、コードベースに応じてライブラリのオーバーヘッドが最小限に抑えられることです。確かに、これ以降のすべてのアプリにWinUI 3.xが必要な場合、それは40mbxアプリの数になります。

eklipse2k8 2019年05月21日

👍2 🚀1 ❤1

バイナリサイズ

WinUIは、.NETと同様に、すでに依存関係になっています。すでにシステム全体のライブラリです。 :)
重複したdllはなく、重複することもありません。
https://www.microsoft.com/store/productId/9N00JJ7S3L39

vitorgrs 2019年05月21日

@ eklipse2k8

「私も考えたのは、win32が立ち往生している理由です。これはレガシープロジェクトによるものだと思いますが、実際にはそれよりもかなり深いです。Win32ABIは、選択した言語に非常に簡単に接続できます。、nodejs、python、rust、go、ruby、c＃、c ++など。たとえば、コアプロジェクトが錆びていて、出力を管理するためのウィンドウを生成したい場合、錆の開発者として、それは非常に強力です。 win32 APIセットにアクセスし、同じ言語でフロントエンドを構築します。」

これは複雑な問題ですが、新しい言語のWinRTサポートを実装することは克服するための大きなこぶであるため、一度実行すると、新しいAPIへの自動生成された型付きバインディングになります。私は最近、Win32とWinRTをブリッジするRustプロジェクトに取り組んでいます（Win32ウィンドウでComposition APIを使用）。残りの部分を不器用に回避する必要があったとしても、Win32の部分は間違いなく全体的に苦痛です。クラス継承などの一部のWinRT機能に対するRustサポートの欠如。（アプリモデル全体に一度に取り組む必要がなく、この機能のサポートを段階的に改善できるため、Win32内でCompositionを使用できるようになったことは間違いなく役立ちます）

おそらく最大の問題は、低レベルのWinRT ABIの詳細に関するドキュメントがまとまりがなく、世界/コミュニティでそれらの理解や認識がほとんどないことですが、この状況がxlangプロジェクトで改善されることを願っています。

contextfree 2019年05月21日

👍1

どのテンプレートに最も興味がありますか？

現在、私は空白のアプリ（Universal Windows）プロジェクトから始めることを好みます。フレームワークが事前設定されたテンプレートも好きですが、何かをすばやく試してみたい場合に限ります。 UWP用の「メインメニュー」テンプレートとMDIテンプレートも便利です（これらのテンプレートはWinFormsにも存在するため）

デスクトップアプリを最新化するためのXamlIslandsをご存知ですか？
Windows 10でのこの拡張された下位互換性により、Xamlアイランドがより便利になりますか？

はい、XamlIslandを知っています。可能であれば、純粋なWPFまたは純粋なUWPアプリに固執するようにします。私はそのような機能が必要になるような状況ではありませんでした。

Visual Studioまたは別のツールが名前空間を自動的に更新する場合に役立ちますか？

はい、それが信頼できるかどうかを確認してください！私はそのような素晴らしい機能を評価しない多くのコメントに驚いています。また、この機能は、WinUI 3.0への更新が実行可能かどうかを確認し、XAMLコードを採用し、名前空間を調整して、必要なWinUIナゲットをインストールすることができます。

既存のUWPXamlコンポーネントとWinUI3.0アプリの間の完全な互換性はあなたにとってどれほど重要ですか？

WinUI 3.0で完全に機能するように、コントロールの名前空間のみを変更することを期待します。 WinUI3.0へのアップグレードにあまり時間をかけたくない

アプリコードと一緒に簡単に再コンパイルおよび更新できないUWPXamlコントロールライブラリまたはWinRTコンポーネントを作成または使用していますか？

サードパーティのUWPXamlコントロールライブラリ（Windows Community Toolkit、https：//github.com/kakone/VLC.MediaElementなど）を使用しています。 DockpanelのようなサードパーティライブラリからWinUI3.0に簡単なコントロールを自分でアップグレードできると思います。

WinUI3でUWPXamlコンポーネントを使用するための好ましいソリューションは何ですか？

Visual Studio forUWPで「WinUI3.0を使用した空白アプリ」プロジェクトテンプレートを作成します。 WinUI 3.0の依存関係は、（WinUI 2.0のように）nugetとしてインストールされます。

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] 。私はすべての基本的なコントロールを取得する限り、絶対にそのようなソリューションを好みます。 Windows.UIのすべてのクラスには、Microsoft.UI名前空間に同等のクラスがあると思います。

WinUI 3.0の主なトピックは、UWPとWPF、またはXAMLアイランドを介したWinFormsから使用できるコントロールとWindows10の互換性に関するものでした。 UWP XAMLマークアップが何らかの形で追加機能を取得する可能性はありますか？

スタイルトリガーがありません
スタイル `BasedOn = {StaticResource {x：TypeTextBlock}}がありません
DataTypesで定義されたDataTemplatesは、WPFのように自動的に適用されません（キー経由のみ）
毎秒Windows.UI.Xaml.Controlsコントロール（TextBlock、Border、...）が封印されていると宣言さ
WPFパリティのマークアップ拡張
これはすでに言及されていますが、もう一度言及します。 UWPがSystem.ComponentModel.IDataErrorInfoを利用しないのは悲しいことです。そうすると、モデルプロジェクトをUWPソリューションと共有できなくなります。
ReportControl（エンタープライズアプリケーション用）

WinUI 3.0とその下位互換性を本当に楽しみにしています！

mfe- 2019年05月21日

👍1

WinUI 3.0ロードマップではF＃は無視されます

UWP XAMLマークアップが何らかの形で追加機能を取得する可能性はありますか？

@ Happypig375 、@ mfe-：

ロードマップは最初の3.0リリースのみを対象としており、最初のリリースでは、主に既存の機能のパリティと下位互換性に重点を置いており、少数の新機能があります。

F＃サポートの改善や新しいマークアップ機能などの他の新機能が重要だと思われる場合は、新しい機能のリクエストを開いて、個別に追跡できるようにしてください。

毎秒Windows.UI.Xaml.Controlsコントロール（TextBlock、Border、...）が封印されていると宣言されるのはなぜですか？！ WinUI3.0とUWPではこれを行わないでください。

コントロールの開封は、実際には3.0に含めることを望んでいる少数の新機能の1つです😊

jesbis 2019年05月21日

🎉5

言語に関しては、組み合わせるのが良いでしょう（パッケージ化する前にすべてをコンパイルすれば問題ないはずです）

一部のバックエンドロジックに使用されるF＃-データバインディングとUIコードに使用されるC＃-コントロールと場合によってはローエンドのWin32フックに使用されるC ++、またはWinFormsダイアログを起動するために使用されます。

すべてのコード言語は同等で交換可能であり、WinUI3.0がすべてのUIを処理します

mdtauk 2019年05月21日

👍1

それはxlangです😉

MarkIngramUK 2019年05月21日

それはxlangです😉

@MarkIngramUKうーん、1つのプロジェクトで複数の言語のコードファイルを許可するのではなく、各言語を抽象化する言語間の架け橋だと思いました。

私はxlangの目的を理解するのに少し苦労しました-リポジトリで行われている更新をざっと見ています（しかし、それはまだ私のウォッチリストにあります）

xlangはコンパイル前またはコンパイル後に機能しますか？投影できる独自の抽象言語ですか、それとも既存のコードファイルの間にあるだけですか？

mdtauk 2019年05月21日

はい、1つのプロジェクトで言語を混在させることはできません。それは橋ですが、それでもそれらの目的には役立ちます。

MarkIngramUK 2019年05月21日

@MarkIngramUKコンパイルできるコードが含まれていれば、そうだと思います。

PInvokesやその他の.NETトリックを使用せずに、C＃を使用してネイティブのWin32機能にアクセスできると便利です。

mdtauk 2019年05月21日

@jesbis私は正直に言ってこのプロジェクトのクロスプラットフォームの側面にもっと興味があります...

最初は、厳密には「Windows」ではなく、もっと_generic_に名前を変更する必要があると思います。

最初の実装はWin32とバックUWP / XamarinアプリとWindowsに厳密に焦点を当てる必要があると思いましたが、それをOSSして最初から「Windowsのみ」のフレームワークと呼ばれるようにすると、UWPのように大きな牽引力が得られなくなります。そうではなく、他のプラットフォームの開発者は決してそれに興味を持ちませんでした。

.Net5のターゲットが「One.NetEverywhere」である場合、これは基本的に.Net 1.0以降、誰もが常に期待していることです。「Anything butWinUI」フレームワークの基盤はクロスプラットフォームで開始する必要があります。

それを正しくする方法の非常に良い例は、GoogleFlutterです。 Flutterは非常に初期の段階ですが、コア（別名Flutter Engine）が100％クロスプラットフォームであり、あらゆる場所（IoT、Win、OSX、さらにはWebを含む）で機能するため、多くの注目を集めています。

それは私の2cです。 Xamlでの作業に戻りたいのですが、UWPと同じ行を維持すると、適切なトラクションが得られず、WPFを書き直す別の試みになり、最終的には別の試みが必要になります。未来など。

私を怒らせたり、私のコメントを悪い批判として受け取ったりしないでください。 .Netの世界でのUIの取り組みが、Flutter、.Net Core 3.0 / .Net 5、さらにはBlazorのようなものになることを願っています。

galvesribeiro 2019年05月22日

👍8 👎1

記録として、私は.Net Worldにオプションがないため、Flutterエンジンを完全にC＃と.NetCoreで書き換え/移植するプロジェクトを開始しました...

galvesribeiro 2019年05月22日

🎉2 ❤1 👍1

ところで、 CoreUIは良い名前です...

その提案に対するジェイクヘルファートへの称賛😄

💃

galvesribeiro 2019年05月22日

👍2 ❤1

ところで、 CoreUIは良い名前です...
その提案に対するジェイクヘルファートへの称賛😄
💃

CoreUIは.NETCoreと混同される可能性があります

WinUIはWindowsに非常に重点を置いていますが、その中のXAMLフレームワークは、Metal（iOSおよびmacOS）またはVulkan（Android）のレンダラーを取得できます。FabricWebは、他のプラットフォームを処理するPWA / ChromeOSの方法である可能性があります。

チームがプレゼンテーションプラットフォームを引き継ぐことを選択した場合、XlandまたはXamarinがクロスプラットフォームアプリのランタイムを処理できます。

mdtauk 2019年05月22日

受信トレイのUWPUIからWinUI3.0への移行について、 @ dotMorten （https://www.sharpgis.net/post/2019/05/14/The-future-UWP）からの最近のブログ投稿を引用します。

おもしろいボトムノート：UWPに起こっていることは、それが殺されているということではありません。マイクロソフトは、最高のパーツを必要な場所に持ってくるためにピボットしています。これは実際には以前に発生しましたが、残念ながらピボットを実行する機会としては使用されませんでした。 Silverlightを覚えていますか？ .NETCoreのクロスプラットフォームCLRがどこから来たのかを推測します。そして、Silverlightのコードの多くもUWPになりました。彼らがピボットして「Silverlightはコンシューマースペアでは意味をなさないことに同意しますが、エンタープライズスペースで繁栄しているので、それを基に構築して、.NETCoreとWindowsStoreに進化させます」と言っただけでした。残念ながら、それはそれほどスムーズに進みませんでした、そして多くの人々はまだPTSDに苦しんでいて、マイクロソフトがどんな技術も殺しているように見えることを警戒しています。

開発者やコードベースに良い方法を与えずに既存のフレームワークを強制終了またはリセットするものとして認識されることは、既存のフレームワークの開発者に影響を与えるだけでなく、誰もがなぜ新しいことは、同じ運命をたどるだけではありません。これは、提案された特定の移行アプローチについてのコメントを意味するものではなく、既存の受信トレイUIフレームワークを使用している人が少ないため、移行は重要ではないというコメントへの回答です。それだけが考慮事項ではありません！

contextfree 2019年05月22日

@weitzhandler WinUI 3.0は、さまざまなWin32、.NET Core、およびUWPフレームワークを単一のXAMLフレームワークと組み合わせ、WPF、WinForms、およびMFC ++と相互運用することを目的としています。

Windows上のXAMLは、DirectXにレンダリングされます。

同じXAMLを.NETCoreと組み合わせて使用し、他のプラットフォームで機能させる場合。これらのプラットフォーム用に新しいレンダラーを作成する必要があります。 iOSとmacOSは、DirectXに相当するものとしてMetalを使用しています。 AndroidはVulkanを使用しています。 Linuxがレンダリングをどのように処理するかはわかりませんが、OpenGLだけだと思います。

マイクロソフトは、それが彼らにとって意味をなさないので、彼ら自身でそれをしたくないでしょう。しかし、WinUI 3.0はオープンソースになるので、他の人はそれをクロスプラットフォームにすることを選択できます

mdtauk 2019年05月22日

@mdtauk
それを明確にしてくれてありがとう。 Flutterはおそらく私にとって未来です。

それは私の理解です、私は誤解される可能性があります。

Flutterは将来的にWindowsのサポートを取得していると思われます。また、ReactNativeのサポートもWindowsに導入されます。さらに、そのWeb HTMLとJavascriptの世界に投資している場合は、PWAがあります。

mdtauk 2019年05月22日

私にとって、WinUIストーリー全体は、少なくともその基本的なサブセットをWebを含むクロスプラットフォーム（macOS、iOS、Android）で実行できるようにし、より優れたF＃サポートとプロジェクトテンプレート（ F＃レコードへのXAML双方向バインディング、およびより機能的なElmishの方法）

TonyHenrique 2019年05月22日

🎉1

XAMLは、HTMLアプリのように、最も基本的なツールアプリでも100 MB以上を使用せずに、 同じように環境に依存しない必要があります。これは、純粋なC / C ++またはC＃で記述され、移植に関して最小限の労力でWASM、Win32、UWP、iOS、Android、macOS、LinuxなどでホストできるXAMLフレームワークを意味します。 ゲームエンジンが最初に使用するような不可知論的なレンダリングバックエンドが必要です。

このUWPに焦点を合わせたXAMLが、私の会社または私がXAMLで何年も抱えていた問題を解決している場合は、何もありません...そしてそれは移植性です。 TBH MSは、UIについて完全に間違っており、どこにも速くは行きません（多くの人にとって貴重な時間を無駄にしています）。このUWPXAMLハッカーは、私が見せた人にはうまくいきません...これは、XAMLの採用に対する終わりのないプッシュバックを意味し、現時点ではこれ以上の議論がないため、悲しいことです。

私の意見では、XAMLを保存する唯一の方法は次のとおりです。

.NETCoreおよびC / C ++用の新しい不可知論的/ポータブルフレームワークベースを作成します。
プルリクエストを介して誰でも拡張できる、不可知論的なレンダリング抽象化レイヤーを作成します。
HTMLと同じように、XAMLはシングルウィンドウアプリの概念に焦点を合わせています（ゲームでも同様です）が、マルチウィンドウなどの拡張デスクトップ機能を許可します（これにより、ゲームUIと同じように、ほぼすべてのコンテキストでアプリを実行できます）

簡単に言えば、XAML適応が除外される前に、1つに組み合わせる必要がある2つの条件があります。

1 MSはXAMLプロジェクトを支援する必要があります。そうしないと、人々はXAMLプロジェクトが失敗することを恐れます。

2クロスプラットフォームである必要があります。そうしないと、誰もが狂った肥大化したHTMLランタイムで立ち往生することになります。

とにかくそれは私の2セントであり、WinUI 3.0が正しく設計されていれば、移植が可能になるかもしれません。この時点で、何を感じるかを確認します。

zezba9000 2019年05月22日

👍7 ❤1

ここにクロスプラットフォームであることについていくつかのコメントがありますが、WinUIが成功するためにクロスプラットフォームである必要があるかどうかはわかりません。いずれにせよ、MacまたはLinuxではうまく機能しません。これは、これらのプラットフォームのどちらでもネイティブであると感じられないほど異なるためです。このプロジェクトは、Windowsの内部がどのように機能するかについて豊富な知識を持っているチームによって所有されており、MacまたはLinuxで同じ程度に何かを本当にうまく機能させる方法を理解するのは気が散るでしょう。

また... MacのFluentは不格好だと感じるでしょう。iTunesを見るだけで、AppleはUIシステム全体をWindowsに移植する必要があり、それは間違いなく場違いだと感じます。フォントのレンダリングは異なります。アニメーションの曲線と影、および色の選択は、Win10では非常に違和感があります。つまり、それは問題なく使用できることは確かですが、デスクトップUIをエミュレートしようとせず、内部でWebブラウザーを使用するSpotifyを好みます。 Macの場合、角が丸くて表示効果がないデスクトップで、正方形のコンポーネントが表示されたスポットライトを見ると、それほど激しく衝突することはありません。

いいえ、このプロジェクトは、Windowsソフトウェアを構築したい/構築する必要がある開発者のために、ネイティブWindowsソフトウェアを作成するためのクラス最高の方法を提供することに焦点を当てるべきだと思います。クロスプラットフォームのものは、Electron / Typescriptチームに任せて解決してください。

eklipse2k8 2019年05月22日

👍6 👎2 ❤1 🎉1

ここにクロスプラットフォームであることについていくつかのコメントがありますが、WinUIが成功するためにクロスプラットフォームである必要があるかどうかはわかりません。いずれにせよ、MacまたはLinuxではうまく機能しません。これは、これらのプラットフォームのどちらでもネイティブであると感じられないほど異なるためです。このプロジェクトは、Windowsの内部がどのように機能するかについて豊富な知識を持っているチームによって所有されており、MacまたはLinuxで同じ程度に何かを本当にうまく機能させる方法を理解するのは気が散るでしょう。
また... MacのFluentは不格好だと感じるでしょう。iTunesを見るだけで、AppleはUIシステム全体をWindowsに移植する必要があり、それは間違いなく場違いだと感じます。フォントのレンダリングは異なります。アニメーションの曲線と影、および色の選択は、Win10では非常に違和感があります。つまり、それは問題なく使用できることは確かですが、デスクトップUIをエミュレートしようとせず、内部でWebブラウザーを使用するSpotifyを好みます。 Macの場合、角が丸くて表示効果がないデスクトップで、正方形のコンポーネントが表示されたスポットライトを見ると、それほど激しく衝突することはありません。
いいえ、このプロジェクトは、Windowsソフトウェアを構築したい/構築する必要がある開発者のために、ネイティブWindowsソフトウェアを作成するためのクラス最高の方法を提供することに焦点を当てるべきだと思います。クロスプラットフォームのものは、Electron / Typescriptチームに任せて解決してください。

他のプラットフォームで完全なフルーエントデザインを本当に望んでいる人はいないと思いますが、プラットフォーム間の共通コードを最大化できるだけです。

これは、MicrosoftDesignチームによってすでに対処されているものです。 FluentのWebサイトには、「ネイティブにiOSでありながら、独自のFluentであるカスタムアプリを設計および構築する」と明記されています。 Fluentのドキュメントには、ネイティブコントロールのスタイルを使用する必要があることが示されています。
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

避けるべきことは、プラットフォームごとに完全に別個のUIを設計および維持する必要があることです。これは、表面上は同じように見える必要があるという意味ではありませんが、共通のレイアウトを共有する必要があり、UIデザイナーは可能な限り再利用できる必要があります。実際のスタイリングは、Windows 10システムのスタイリングと一致する必要はありません（また、一致する必要はありません）。

本質的に、必要なのは、UI全体を作り直すことなく、他のプラットフォームでWindowsアプリを実行する簡単な方法です。つまり、Fluentデザインを他のプラットフォームに持ち込む必要はありません。そうすれば、人々は最初にWindows用に作成し、次に多くの作業をせずにアプリを他のプラットフォームに持ち込むことができます。

KyleNanakdewa 2019年05月22日

👎1

@KyleNanakdewaもし彼らがそれをオープンソーシングしているのなら、Xamlファンの何人かを立ち去らせて、基礎となるプラットフォームビットを作成させてください。おそらくアーキテクチャ的には十分に複雑で、Win32を十分に活用しているので、このポートは大規模な作業になると思います。

eklipse2k8 2019年05月22日

👍1

このプロジェクトは、ネイティブWindowsソフトウェアを作成するためのクラス最高の方法を提供することに焦点を当てるべきだと思います

マイクロソフトが、WinUIとはまったく異なるXAMLの方言を提供する既存のクロスプラットフォームXAMLツールキットをまだ所有していない場合、この議論は説得力があるかもしれません。

mfeingol 2019年05月22日

👎1

さらに、そのWeb HTMLとJavascriptの世界に投資している場合は、PWAがあります。

はい...ネイティブOS /ストア/ホステッド開発について私たちが知っているすべてのものをすぐに置き換えている「その世界」。 😆

https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097

HTML5レンダラーを備えた最新のデバイスには「その世界」が存在すると考えてください。

Windowsの市場シェアが最小になっていることに気付くでしょう。つまり、このプラットフォームに特化した製品はすべて、最小の市場に到達するものになります。そうすることで、アプリケーションの潜在的な最大市場リーチが低下するだけであり、その結果、潜在的な最大収益の上限が低下します。

これを、前述の3つすべての合計で構成されるWebとともに、前述のマーケットプレイスの_all_に_one_コードベースで到達するFlutterと比較してください。したがって、構築に必要なコストを削減しながら、アプリケーション開発者の市場リーチと潜在的な収益を最大化できます。そうするためのアプリケーション。

私はここでのオープンソース、コラボレーション、コミュニティフィードバックの募集の取り組みの大ファンですが、これらのディスカッション（私も楽しんでいます😁）から、ここでの取り組みがFlutterのようなもの（これはPWAにも対応しています）と比較すると、競争力があり、したがって_収益性があります_。

Mike-E-angelo 2019年05月22日

😕4 👍3 👎1

ダイアグラム制御は、まもなく公式のNET CORE 3（2019年9月）になり、最終的にはデータ駆動型の最新のデスクトップエクスペリエンスに不可欠です。 NET 5（2020年11月）

提供されているNetworkviewオープンソース管理は、Xamlを使用してWPFをWinUI管理に移植する方法の効果的な使用例だと思います。この移植されたWinUIは、他の少し複雑なWPFコントロールをWinUIに移植するための優れたギルドとして機能します。

アプリが将来のWindowsCoreOSでタブレットモードをサポートする必要がある2in1のユースケースが見られます。 Winformin。NETCore3は役に立たないと思われます。WinUIダイアグラムコントロールがPoCの単なる演習ではないが、グリッドコントロールが前進するのと同様のFIRSTクラスのwinuiコアコントロールの一部である必要があるもう1つの強力な理由。

GeorgeS2019 2019年05月22日

F＃サポートの改善や新しいマークアップ機能などの他の新機能が重要だと思われる場合は、新しい機能のリクエストを開いて、個別に追跡できるようにしてください。

@migueldeicazaは自分の手で問題を処理しているようです： https ：

mrlacey 2019年05月22日

🎉3

クロスプラットフォームで@ eklipse2k8の考えをエコーしたいと思います。クロスプラットフォームのUIライブラリを作成するときは、常に妥協する必要があります。 WinUIは妥協すべきではありません-それはWin32UIの最新の代替品である必要があり（私はこれ以上CreateWindowExW呼び出したくありません！）、Windowsで何ができるかを示すショーケースである必要があります。 macOSまたはAndroid上のWinUIは、ネイティブエクスペリエンスとは決して一致しないエクスペリエンスを常に提供します。クロスプラットフォームアプリケーションを作成し、各プラットフォームでネイティブUIを作成します。そうすることで、お客様は選択したプラットフォームで最高のエクスペリエンスを得ることができます。クロスプラットフォームソリューションが必要な場合は、それで問題ありません。その目的のために別のライブラリを探す必要があります。おそらく、WindowsプラットフォームでWinUIをラップするライブラリです。

また、PWAに関しては、これらはWindows UIシステムの完全な使用を表すものではなく、「シングルウィンドウアプリケーション」に焦点を当てることを推奨すると、プロのソフトウェア（ゲームを除く）がすぐに除外されます。 PWAとクロスプラットフォーム向けのソリューションはすでにあります。別のソリューションは必要ありません。

必須のXKCD：
https://xkcd.com/927/

MarkIngramUK 2019年05月22日

👍9 ❤1

@MarkIngramUK Cross Platformの話は、UIを宣言するために.NETとXAMLにコーディングできること、そしてそのアプリをAndroid、iOS、macOS、Linuxで実行できることについてだと思います。 -コードビハインドを変更したり、XAMLを放棄したりする必要はありません。

これらの他のプラットフォーム用のXAMLレンダラーがあった場合（XAMLをどのように解釈するかは、ネイティブUIプラットフォームに引き継ぐXamarinフォームのようになります）、または基本的にグラフィックカードバッファーに描画して画面上にピクセルを描画します-ほとんどの同じコントロールスタイル。

WinUI 3.0は、さまざまなAPIとABIを最新のXAMLベースのUIプラットフォームと統合するために、Windowsに焦点を合わせたプロジェクトであり続ける必要があります。しかし、それはXamarinや個人がレンダリングコードを取得して他のプラットフォーム用のバージョンを作成できないという意味ではありません。

本当に必要なのは（高レベルの考え方で）、Windowsの画面にXAMLをレンダリングするコードが含まれていることを確認することです。これにより、他のレンダラーがクロスプラットフォームのシナリオに介入できます。

WinRT / UWP / XAMLは、Windows 10 OSからそれらを解放するために、いくつかのリファクタリングが必要になります。したがって、将来の拡張を可能にするために、リファクタリングがどのように行われるかを覚えておく必要があります。クロスプラットフォームが現実になるかどうか。

mdtauk 2019年05月22日

😕1 👎1 👍1

@ MarkIngramUK @ mdtaukに同意します

xamlを使用してReactを含む他のライブラリのUIコンポーネントを記述できない理由はないはずです。 http://www.cshtml5.comのようなプロジェクトを見ると、htmlに変換されるxamlを使用しています。
また、UIが他のプラットフォームでも同じように見えることが最終目標であるという事実をほのめかしている人はいないと思いますが、私が個人的に望んでいるのは、UWPなどへの既存の投資を活用するために使用できるUI側のものです。

ポイントはこれだけです。企業のお客様に提案をして、あらゆる点で素晴らしいUWPアプリを提示するとします。その企業顧客に、たとえばMacBook Proを使用しているユーザーが1人いる場合、企業顧客は、実行している場合でも、私の「ネイティブアプリ」よりもどこでも機能するもの（最小公分母=> Webサイト）を使用するため、すぐに問題が発生します。 Windows10の場合。

したがって、アクセシビリティが重要です。 MSが、クロスプラットフォーム機能へのロードマップなしで2019年に「ネイティブアプリ」に投資することをまだ期待しているという事実はクレイジーです。

エンタープライズの観点から見た新しいプロジェクトは、アクセシビリティに関する上記のロジックに従う可能性が高く、XAML / UWPにクロスプラットフォーム機能を含むロードマップがないため、すべての新しいプロジェクトはWebに偏ります。

そのため、2〜3年後に早送りします。企業から、UWP / win32への新規投資はなく、誰も気にしない別の「Silverlight」を使用しています。

MSは、XAMLが明日非推奨になり、「新しい」UIライブラリがReactなどであることを教えてくれます。 c＃をこの新しいライブラリに接着できる限り、損失を減らし、XAMLをダンプして、この新しいクロスプラットフォームUIライブラリを採用します。少なくとも私の投資には耐久性があり、長期的にアクセスできます。

クロスプラットフォームのUI機能に関するこの特定の問題を明確にしないことで、MSは「ネイティブスタック」に関する不確実性を生み出しているため、ほとんどの企業は未知のものを受け入れるよりも、木製の脚で火を通り抜けるでしょう。

Pinox 2019年05月22日

👍7 🚀2

また、PWAに関しては、これらはWindowsUIシステムの完全な使用を表すものではありません。

十分に公平で、私は同意します。 PWAでの私の主なポイントは、その市場シェアがすべての市場の総計で構成されているため、特定の市場を小さくすることを実証することでした。

そうは言っても、ここでの混乱の一部は、 Microsoft.*を反映する名前空間であると思いますが、実際にはまだWindows.* （またはMicrosoft.Windows.* ）である必要があるように聞こえます。。

PWAとクロスプラットフォーム向けのソリューションはすでにあります。別のソリューションは必要ありません。

残念ながら、これは.NET開発には当てはまりません。これは、この発表とその後の議論に関する混乱とクロスプラットフォームの不安の一部です。

Mike-E-angelo 2019年05月22日

したがって、アプリケーション開発者の市場リーチと潜在的な収益を最大化すると同時に、アプリケーションを構築するために必要なコストを削減します。

パフォーマンスとUXの詳細が大きな違いを生む場合があります。 Skypeは、パフォーマンスを犠牲にしてElectronフレームワークを使用して市場へのリーチを最大化し、その結果、商業的な惨事が発生しました。

ekral 2019年05月22日

👍2 😄1

クロスプラットフォーム（xplat）ソリューションについて。
Xplatソリューションは、複数のネイティブの基盤となるシステムを抽象化したものです。 WinUIについての私の理解は、それがWindowsのネイティブシステムになるということです。

WinUIもxplatであるとしたら、Windowsに固有のものをどのように組み込むのでしょうか。それはそれが新しく革新的なことをするのを妨げませんか？それとも、Windowsから他のプラットフォームに新しいものや差別化されたものを移植するのはMicrosoftにあるということですか？他の基盤となるOSがそれらをサポートできなかったために移植できなかったものはどうですか？それらをWindowsに追加すべきではありませんか？

ネイティブのWindowsテクノロジを使用して何かを構築する場合、Microsoftが一定期間それをサポートし、将来的には新しいWindowsベースのシステムへの道を提供すると想定するのが妥当です。（SilverLightを例外として認めます。）ネイティブのWindowsテクノロジを使用して何かを構築し、それを競合するオペレーティングシステムで実行したい場合、それを簡単にするのはMicrosoft / Windows次第だと考えるのは合理的ではないと思います。 Swiftを使用してiPad用のアプリを作成し、それをWindowsデスクトップにも導入したい場合、AppleがiOS開発を変更してそれを簡単にすることを期待しますか？

ネイティブのWindowsテクノロジの使用を楽しんだり、好んだりする場合は、それは素晴らしいことです。あなたができないことは、それらのテクノロジーを選択する際に行うビジネス上の決定を他の誰かに任せることです。すべてのテクノロジーの選択には結果があり、数年後に何が必要になるか、または顧客が何を求めるかは誰にもわかりません。 Windows専用に開発されたソフトウェアを他の場所でも実行できるように要求すると、将来の任意の時点で悪影響を与える可能性のあるテクノロジの決定を回避することが目的であるという印象を与えることができます。テクノロジーの性質と変化の速さからすると、それは現実的ではないと思います。

とは言うものの、現在複数のオペレーティングシステムをターゲットにしたい、または将来的にターゲットにしたいという理由でxplatソリューションを構築したい場合（そしてそれを行う理由がたくさんある場合）、それは合理的で理解しやすいことです。シナリオ。
そのために、MicrosoftにはXamarinがあります。または、UWPのようなXAMLを使用したい場合は、Unoがあります。（他にもたくさんのオプションがあります。）
私のように、XamarinがWindowsアプリを構築するためのより優れたネイティブサポートを備えていることを確認したい場合は、WinUIに複数のことを試してもらうことが答えだとは思いません。

WinUIは、XAMLと特定のコントロールだけではありません。これらのコントロールとそれらを使用して構築されたアプリが、基盤となるオペレーティングシステムとどのように統合されるかについての詳細が含まれています。
WinUIの計画がWindowsでのWindows開発を最高のものにすることに焦点を当てている場合、それはイノベーションと優れた将来のサポートを持つための良いケースです。また、人々がWindowsを使い続けたいと思う可能性が高まる可能性があるため、複数のxplatソリューションからの確実なサポートがあることが重要になります。

mrlacey 2019年05月22日

👍4 ❤1 🎉1 👎1

クロスプラットフォーム（xplat）ソリューションについて。
Xplatソリューションは、複数のネイティブの基盤となるシステムを抽象化したものです。 WinUIについての私の理解は、それがWindowsのネイティブシステムになるということです。

申し訳ありませんが、私はそのように感じていません...

Flutterを見てください...サポートする任意のプラットフォームで何でもレンダリングできるコアエンジンがあります。

さらに、エンジン管理レイヤーを使用してDartに完全に実装され、使用するプラットフォームとデザイン言語をピクセル忠実度で表す（描画/レンダリング）コンポーネントがあります。たとえば、Material.ioやAppleのCupertinoなどです。

つまり、そのIMHOは、クロスプラットフォームを作成するための最良のアプローチであると同時に、基盤となるプラットフォームの機能を表しています。

galvesribeiro 2019年05月22日

👍5 👎1

ネイティブのWindowsテクノロジを使用して何かを構築し、それを競合するオペレーティングシステムで実行したい場合、それを簡単にするのはMicrosoft / Windows次第だと考えるのは合理的ではないと思います。

そうです...他の人が言っているここでのポイントは、特に新しいアプリケーションを開始するという文脈では、これは最近少し後ろ向き/トーンが聞こえないように見えるということだと思います。市場のごく一部にしか届かないのに、なぜ誰かがネイティブWindowsアプリケーションを構築するのでしょうか。これは資本の有効活用ではありません。

従来のWindowsアプリケーションを維持すること、または特にWindowsアプリケーションを作成することである場合、はい、私はこれらすべてに同意します。それは理にかなっています。ただし、重大な変更とさらなる投資が含まれているように見えるため、Flutterを使用する場合と比較してこれを行うことの価値提案はまだ説明されていません。

Mike-E-angelo 2019年05月22日

🚀2 👍2 👎1

それはまさに私が言っていることです...

たとえば、Win10（WPFとUWP）とOSXの両方のデスクトップ用のフラッターエンベッダーが登場します。

それらはフラッターランタイムによって100％管理されますが、ウィンドウ管理とGraphicsポインターを取得するために（たとえば）WPF / UWPのみを使用しています。残りはすべてエンジンによって管理されます...

フラッターエンジンを組み込みARMデバイスに移植しましたが、これは素晴らしい経験だったと言わざるを得ません。どうして？「エンベッダー」にGPU、ソフトウェアレンダリング、入力管理などのプリミティブのプラットフォーム固有の実装の詳細を処理させることで、ポータブルでどこでも実行できるように生まれたためです。

私はことを言っている理由ですWinUIを用いてUWP: The empire strikes back長期的に仕事に行くのではありません。

MSFTには、クロスプラットフォームでオープンでポータブルなものが付属している必要があります。 .Net CoreやBlazorなどで行ったように、UWP / XAMLの再発明はどこにも行きません。

XAMLは、UIを「説明」（または一部の人が言うように宣言）するために使用されるという意味で適切に使用されれば、優れた可能性を秘めていると思います。「エンジン」はそれからレンダーツリーを構築し、次にレンダーコマンドを基盤となるプラットフォームにディスパッチします。

MSFTが最近ChromiumをEdgeのコアとして使用したように、WinUI（またはその名前が何であれ）は、GL、DX、Vulkan、ソフトウェアレンダリング、FBなどのバックエンドを備えているためSkiaを活用できると思います。後で他のプラットフォームを追加する可能性が非常に高いこと...

galvesribeiro 2019年05月22日

👍3 👎1

@galvesribeiro 、

Flutterを見てください...サポートする任意のプラットフォームで何でもレンダリングできるコアエンジンがあります。
さらに、エンジン管理レイヤーを使用してDartに完全に実装され、使用するプラットフォームとデザイン言語をピクセル忠実度で表す（描画/レンダリング）コンポーネントがあります。たとえば、Material.ioやAppleのCupertinoなどです。

素晴らしいです。AppleがmacOSのアップデートをリリースし、UIがアップデートされるとすぐに（おそらくボタンの角の半径が変更されたり、背景のグラデーションが変更されたりします）、Flutterアプリケーションはアップデートされず、ネイティブとは異なり、以前のOSのように見え続けます。無料でメリットを得るコントロール。

MarkIngramUK 2019年05月22日

❤1 👍1

@MarkIngramUKは、更新をサポートするためのチームの作業です。

Xamarinチームが0+ 1日目から更新を提供するように、このチームも同じことを行うことができます。 Googleチームもそれを行います...

「ネイティブ」コントロールを使用することで、ラッパー（別名レンダー）だけを実行していたXamarinの世界に再び戻ります...

ネイティブコントロールへのC＃バインディングについては説明していません（Xamarinのように）... Flutterの場合と同様に、完全なUIフレームワークについて説明しています...

galvesribeiro 2019年05月22日

👍2 👎1

ちなみに、どのプラットフォームでも「デフォルト」テーマを使用する人は誰もいません。それらはすべて、各プラットフォームの設計言語の上に独自のUXを作成します。

常にネイティブコンポーネントのように見えることを非常に心配している場合、アプリはおそらく、見た目ほど良いオーディエンスを持っていないでしょう...まあ...

galvesribeiro 2019年05月22日

👍2

ここでは2つの異なるプロジェクトについて話していると思います。 WinUIはWin32の代替品である必要があります。人々はクロスプラットフォームのソリューションを求めていますが、それは合理的ですが、私はそれがこのプロジェクトであるべきではないと思います。

MarkIngramUK 2019年05月22日

👍3 ❤1 😕1

また、Flutterを使用すると、すべてのプラットフォームで「テーマ」を使用できます。したがって、Win10PCでクパチーノを実行できます。大きな例はマテリアルデザインです。これは設計言語であり、一連のコントロールではありません。どこでも使用できます...一部のプラットフォーム（Androidなど）には、ネイティブコントロールが実装されています...

galvesribeiro 2019年05月22日

👎1 👍1

@MarkIngramUK

WinUIが単なるWin32の代替品ではない理由を明確にしているだけです。それだけです。

そうだとすれば、UWPと同じように、近い将来に落ちると確信しています...

galvesribeiro 2019年05月22日

👍3 👎1

@MarkIngramUK WinUI自体は、C＃、WinRT API、Win32 ABI、C ++、F＃、VB、.NET Coreのいずれを使用するかに関係なく、Windows用の統合UIの提供に重点を置く必要があることに同意します。

WinUI 3.0では、すべてのコードとXAMLのレンダリングをWindows OSから削除し、OSの更新サイクルから独立したフレームワークにして、オープンソースにします。

それがどのように持ち上げられ、再梱包されるかはまだ空中にあります。マイクロソフトの内部にいる人だけが、それをどのように行うかを知っています。 XAMLの将来のクロスプラットフォームサポートをサポートするために、Windowsからそれを解放しているので、将来どのようにそれを達成できるかについていくつかの考えが入れられることを願っています。

.NET Coreは、他のプラットフォームでもすでに利用可能です。これが、すでに転送可能なC＃コードです。現在はXAMLとUIとコントロールだけであり、iOS / macOS / Android / Linux（および将来的に登場する可能性のあるもの）へのパスが必要です。

WinUI 3.0の範囲外かもしれませんが、このプロジェクトと取り組みに最も確実に関連しています。

mdtauk 2019年05月22日

😕3 👎1

@jesbis @terrajobst @jevansaks

デスクトップ、モバイル（Droid、iOS）、およびWebでレンダリングするUIフレームワークを.NET Coreに導入するためのMicrosoftの計画は何ですか？
これについての不確実性は非常に長い間続いています。

weitzhandler 2019年05月22日

👍8 👀4 🎉2 😕1 👎1

@weitzhandler 、彼らはすでにロードマップを持っており、次の段落があります：

WebおよびクロスプラットフォームフレームワークのネイティブWindowsターゲット
WinUI 3は、上に構築するライブラリとフレームワーク用に最適化されています。
たとえば、新しい高性能C ++ React NativeWindowsの実装をWinUI3に基づいて行うことを計画しています。

「上に構築する」という強調された部分に注意してください。私が上で言ったように、これが最初にWindowsでありえない理由はなく、その上に他のライブラリが構築されています。

MarkIngramUK 2019年05月22日

🚀2 ❤1 🎉1 👍1

では...

/me keep working on FluSharp

galvesribeiro 2019年05月22日

これは合理的ですが、私はそれがこのプロジェクトであるべきではないと思います。

@MarkIngramUKは喉が渇いてい

Mike-E-angelo 2019年05月22日

次の段落で
あまり言いません。 C＃および.NET開発をxplatにするというMSの明確な意図は明らかにされていません。ポータブルにしたい場合は、HTMLJSとCSSshi {がC＃よりも優れた機器であると言えます。

現時点では、XamarinおよびXamarin Formsは、Windows以外でのC＃および.NETCore開発に関するMicrosoftのストーリーです。

React Native for Windowsは、JavascriptコードとネイティブUI（WinUI 3.0 XAMLを使用）用に提供されます。

現時点では、MicrosoftはWinUI3.0のXAMLを他のプラットフォームに導入する計画を発表していません。

WinUIプロジェクトは、単一の最新のXAMLプレゼンテーションフレームワークの下で、Win32、WPF、MFC、UWP、.NETCore開発フレームワークを統合しようとしています。

その後、MacOS、iOS、AndroidなどのプラットフォームでWinUI 3.0用に記述されたXAMLをレンダリングする方法を見つける作業に取り掛かる必要があると思いますが、それは今のところ議題ではありません。

WinUI 3.0の作業がここで開始されると、オープンソースになるため、十分な必要性がある場合は、将来のクロスプラットフォーム作業が可能になります。そして、最終的にこれらのクロスプラットフォームパスを利用可能にするのはマイクロソフトではなく、オープンソースコミュニティである可能性があります。

mdtauk 2019年05月22日

👍7 🎉3 🚀1 ❤1

.NETの赤毛の継子であるF＃を一級市民にする計画はありますか？そして人々は、なぜ.NET開発者の大多数が10フィートのポールでF＃に触れないのか疑問に思います。

GiorgioG 2019年05月22日

👍4 😄2

現時点では、XamarinおよびXamarin Formsは、Windows以外でのC＃および.NETCore開発に関するMicrosoftのストーリーです。

はい、Xamarin.FormsはmacOS、GTK、UWP、WPFに移植されており、作品のいたるところにマテリアルデザインがあり、事実上の.NET UIフレームワークになっていますが、非常に遅くバグが多いので、Microsoftは何を考えているのでしょうか。その開発者について。問題リストを見てください！本格的な開発が始まると、バグは左右にぶつかります。 WinUIを使用することで、最終的により良い開発エクスペリエンスが得られることを願っています。

Re：F＃

F＃サポートの改善や新しいマークアップ機能などの他の新機能が重要だと思われる場合は、新しい機能のリクエストを開いて、個別に追跡できるようにしてください。

はい、個別に追跡されて再び無視されるのは常にF＃です。 UWPと.NETNativeを見てください。どちらもF＃を念頭に置いておらず、コミュニティ全体がすべてを理解する必要がありました。 🙄4年経っても、F＃は.NETNativeではまだサポートされていません。

Happypig375 2019年05月22日

👍4 ❤1 👎1

F＃の提案/質問のために、私は専用の問題を作成しました：
https://github.com/microsoft/microsoft-ui-xaml/issues/740

そこでF＃のディスカッションを自由に指示してください。

私たちは間違いなくそれに関するフィードバックを無視していません-専用の問題があると、それを整理して追跡するのに役立ちます。
チームは、3.0以降のロードマップにどのように適合するかについて話し合っており、開発があれば新しい問題を更新します。

jesbis 2019年05月22日

🎉1 👍1

RE：クロスプラットフォームUI：

これまでに提起されたポイントと、.NETとXamlへの情熱に感謝します。
私たちはすべてのフィードバックに注意深く耳を傾けていることをもう一度言いたいと思います、そして私たちは進歩するにつれて私たちの考えと更新を共有します。

現在のロードマップと出てきたいくつかのポイントを再確認するためだけに：

WinUIはWindows用のネイティブUIプラットフォーム（.NETだけでなくネイティブアプリを含む）であり、最初の3.0バージョンでは、主にOSから独立させ、より高速なリリースでオープンソース開発の準備を整えることに重点を置いています。サイクル。今年プレビューを公開するのに十分な範囲が実現可能であることを確認したいと思います。

他の現在の短期的な目標の1つは、WinUIがWindowsで使用する他のプラットフォームのネイティブターゲットとして機能できるようにすることです。たとえば、 react-native-windows高性能のC ++ React Native実装）の確保にも取り組んでいます。 Windowsの場合-WinUIを使用し、WinUIコントロールを使用してReactNativeアプリでネイティブUIビューを作成できます。

jesbis 2019年05月22日

❤2 🎉2 👍2 🚀1 😕1 😄1

私は完全に正直になります。 2006年にWinFormsで作成したネイティブのWindowsデスクトップアプリがあり、現在もオンラインで販売しています。

このアプリをWPF、UWPに移行したり、専用のWindowsUIテクノロジーを使用したりする予定はありません。 Windowsのデモがどれほど魅力的に見えるかは気にしません。このアプリで再び作業することにした場合、次のメジャーバージョンは、MacOS、Linux、およびWindowsで実行できるある種のクロスプラットフォーム実装になります。

現在、それはおそらくBlazor + .NET Core + Electronのようになります。

@ Mike-EEEはいくつかの素晴らしい点を示していると思います。 C＃スキルを活用して最大数のオーディエンスにリーチできるUX /プラットフォームは、私が選択する可能性が高いテクノロジーです。

Microsoftは、開発者が既存のスキルを活用して、アプリでより多くのユーザーにリーチできるようにすることに重点を置く必要があります。これは勝利の戦略であり、マイクロソフトをゲームに引き留めてくれると思います。

壁に書かれているのは、オペレーティングシステムソフトウェアが商品のようになりつつあるということです。つまり、人々は好きなOSを選んで、使いたいアプリを手に入れることができます。これは、世界のソフトウェアベンダーがクロスプラットフォームに焦点を合わせ続けているため、時間が進むにつれて明らかになると思います。

経済学では、商品は完全または実質的な代替可能性を備えた経済財またはサービスです。つまり、市場は、誰がそれらを生産したかに関係なく、財のインスタンスを同等またはほぼ同等として扱います。 https://en.wikipedia.org/wiki/Commodity

マイクロソフトは決定する必要があります、それは開発者ツールの話の一部になりたいですか？それとも、マイクロソフトは、Windows専用の新しいUXスタックに数百万ドルを投資して、使用する人がますます少なくなるUXスタックの墓地に加わることになりますか？

このプロジェクトは、Windowsの内部がどのように機能するかについて豊富な知識を持っているチームによって所有されており、MacまたはLinuxで同じ程度に何かを本当にうまく機能させる方法を理解するのは気が散るでしょう。

確かにいるのは難しい立場です。しかし、時代は変わりました。今日の世界は1995年の世界とは大きく異なります。私の見方では、いくつかの選択肢があります。

Windowsを超えてその知識を拡大するために、より多くの人を雇うことができます。

または、そのチームの知識を使用して、Windows内でUX配管を構築し、クロスプラットフォームUIアプリケーションフレームワークの互換性を強化して、Windows上でより適切に実行します。

WSLがWindows上でLinuxを実行するために行ったように。

チームの知識を使用して、GTKを200倍高速に実行します。
チームの知識を使用して、QTアプリを200倍高速に実行します。
チームの知識を使用して、Electronアプリを他のどのOSよりも高速にレンダリングします。

WindowsクロスプラットフォームのUX互換性ストーリーを強化するために実行できる作業はたくさんあります。しかし、まったく新しいUXスタックに投資し、私たち全員が（クロスプラットフォームの話なしで）切り替えることを期待することは、かなり大きな賭けです。この習慣を打ち破って、Windows専用の新しいUXフレームワークを作成する必要があります。

ちょうど私の2セント。：財布：

：horse_racing ：： cowboy_hat_face： Lil Nas X-Old Town Road（Official Movie） ft。BillyRay

bchavez 2019年05月22日

👍6 ❤1

@bchavez

この習慣を打ち破って、Windows専用の新しいUXフレームワークを作成する必要があります。

- それだけでなく。 Windows独自の内部XAML移植性を壊す習慣さえあります。 WPF、Siliverlight、UWPはすべて独自のフォークで...この種のことは、私が個人的に今後も使い続けたいWindows開発ツール全般からますます多くの人々を遠ざけています。 Windows開発ツールからのプッシュバックが多ければ多いほど、関連するC＃はますます少なくなり、私にとっては、それに取り掛かるときに気になることです。

zezba9000 2019年05月22日

👍4 👎1

RE：クロスプラットフォームUI：
... WinUIはWindows用のネイティブUIプラットフォーム（_ネイティブアプリを含む_ 、. NETだけでなく）であり、最初の3.0バージョンでは、主にOSから独立させ、オープンソースの準備に取り組むことに重点を置いています。より速いリリースサイクルでの開発。今年プレビューを公開するのに十分な範囲が実現可能であることを確認したいと思います。

Fluent / FabricWebコントロールスタイルによりよく一致するように、WinUI 3.0で実行されているWinForms、MFC、WPFコントロールの視覚的な外観を更新するというアイデアに+1を追加します。

確かに異なるコントロールサイズ（WinRT XAML以外のものは、おそらくそれらのメトリックをUWPコントロールのコンパクトバージョンに一致させる必要があります）が、1つの一貫性のある一貫した洗練された外観です。

WinUI 3.0の依存関係をWinFormsに追加すると、コントロールが変更されます。

WinUI 3.0 WPFアプリは、Fluent.Light.xamlまたはFluent.Dark.xamlコントロールテーマを検出して使用します。

mdtauk 2019年05月22日

@weitzhandler私はあなたの感情を理解しています。このクロスプラットフォームのGUIを実行するために、javaScriptなどに触れる必要がないことを望んでいます。電子、角度、ダーツ、フラッターを使用してプロジェクトを開始することを考えることさえ嫌いです。
ユニバーサルXAMLの夢をもたらす、.NET5ですぐに解決策が得られることを願っています。 Microsoft XAMLは、WIN、Web、モバイル、デスクトップ、およびIoTに対応できます。
多くのユースケースで、Silverlightはほぼそれを実行しました。

TonyHenrique 2019年05月22日

❤8

この習慣を打ち破って、Windows専用の新しいUXフレームワークを作成する必要があります。

クロスプラットフォームのサポート（すべてのプラットフォームで必然的に妥協する）を待たなければならない場合、WinUI3.0がリリースされることはありません。 WinUIはWindowsの最低レベルのUIフレームワークである必要があり、クロスプラットフォーム機能が必要な場合は、その上に構築します（または、React Native、Xamarinなどを使用します）。

MarkIngramUK 2019年05月22日

👍4 👎2 ❤1

この習慣を打ち破って、Windows専用の新しいUXフレームワークを作成する必要があります。

WinUI3.0で新しいUIフレームワークを作成しようとしているのではないことを明確にしておきたいと思います。

私たちの最初の目標は次のとおりです。

既存の最新のネイティブテクノロジー（Windows 10 Xaml UIおよびコンポジター）をOSから切り離し、既存のアプリモデル（win32およびUWP）、言語、その他のフレームワーク（アイランド経由）、およびWindowsバージョン間で機能できるようにすることで、使用の障壁を取り除きます。
エンジニアリングプロセスをオープンソースに更新する

jesbis 2019年05月22日

👍10 ❤3 🎉1

クロスプラットフォームのサポート（すべてのプラットフォームで必然的に妥協する）を待たなければならない場合、WinUI3.0がリリースされることはありません。

男...あなたが本当にそれを信じているなら、あなたはFlutterのような成功したフレームワークが機能しないことを意味します...

私もダートは好きではありませんが、彼らは進化し、非常に速く牽引力を得ているかなり降下した製品をリリースしました。

WinUIがWindowsのものだけになることに不満を感じています...

.Netには、Blazorを使用したWeb（クライアント側とサーバー側）で得たのと同じように、.NetCoreクロスプラットフォーム機能の素晴らしさに一致するUIフレームワークが必要です。

今のところ、私たちはまだコミュニティ主導の努力に頼らなければならないと思います。

あなたのチームが@jesbisで何をしようとしているのか理解しています...私たちの多くは、.Net / C ++ / UWP / MFC / WindowsでUIを見るのにうんざりしています。（AppleとOSXを除く）は逆の方向に進んでおり、開発者にますます優れたクロスプラットフォームソリューションを提供しています。あなたがReactとRect-Nativeについて言及したように（記録のために私も好きではありません、ただそれらが進化していると言及するだけです）。

つまり、現在私たちが持っているのは、AvaloniaやUnoのようなコミュニティ主導のイニシアチブや、明らかな理由で非常にゆっくりと進化する他のフレームワーク（前述のように私が取り組んでいるFluSharpなど）です...

私の提案は、XAMLとコンポジターをWindowsコードベースから削除してWindows専用にするのではなく、複数のプラットフォームで機能するように取得して適切な抽象化を行うことです。当初はWindowsのみであった.NetCoreの場合と同じように、コミュニティ主導の取り組みにより、Linux、OSX、さらにはARMデバイスでも非常に高速に動作しました...

galvesribeiro 2019年05月22日

👍7 🚀2

（すべてのプラットフォームで必然的に妥協）クロスプラットフォームのサポート

クロスプラットフォームデザインがUWPのXAMLUIとFluentDesignの重要な側面であり、これまでもそうであったことを考えると、これが問題になるとは思いません。 Windowsのバージョン間でビジュアルデザインが異なるコントロールが確かにいくつかあります。これはシームレスに処理され、デバイスのOSに一致するネイティブUIを取得します。

たとえば、コントロールに組み込まれているアクリルとリビール、ピボットとナビゲーションビューのアクセントカラー-これらはCreator's Updateには表示されませんが、FCU以降では表示されます。変更は不要です。

明らかに、まったく異なるOSでUIをレンダリングすることは、舞台裏ではるかに複雑ですが、実際にUIを設計するという点では、これまで以上に考慮する必要のある新しい考慮事項はないと思います。 UWPとWinUIを使用します。

大きな懸念は、長期計画が本当に何であるかということだと思います。 @jesbisからの現時点では短期的なものにのみ焦点を当てているようであり、長期的な計画についてはまだ議論の余地があります。

それだけは理解できますが、そのようなプロジェクトの範囲は広大です。それが短期的な計画ではなく、終盤の計画であるかどうかは完全に理解できました。ここでは透明性が重要です。明確な未来がなければ、誰もプラットフォームをサポートしたくないことは明らかです。

MS全体がクロスプラットフォームに焦点を合わせていることは明らかです-これはFluentDesign（iOS、Android、およびWebの例があります）、他のプラットフォーム上の多数のMS製アプリで見られます-したがって、共有UIは本当に大きなミッシングリンクです。そしてそれがそれが起こらないのはとても残念な理由です-私は多くの人々がMS製のユニバーサルアプリプラットフォームのアイデアを好きだと思いますが、私たちが持っていなければサポートすることは意味がありませんそのための完全なソリューション。

KyleNanakdewa 2019年05月22日

重要なのは... material.ioやCupertinoと同様に、流暢なデザイン言語のフラッターに「テーマ」を設定することができます（そして、Googleがまだそうしていなくても驚かないでください！）。

そして、それが私のポイントです。真のクロスプラットUIフレームワークはそれを気にせず、Flutterのように機能するだけです...どこに妥協点があるのかわかりません...

galvesribeiro 2019年05月22日

👍1

@weitzhandlerネイティブアプリのHTMLも好きではありません。そうでなければ、私はReactでElectronを使用するでしょう😄

私はここで情熱的ではなく、代わりに合理的であるだけです。

galvesribeiro 2019年05月22日

😄3

私はWinUI3.0を本当に楽しみにしており、新しいC ++ / WinRTWindowsデスクトッププロジェクトにすぐに使用します。そして、3.0以降の次のメジャーバージョンで、WinUIアプリケーションをホストするためのポータブルランタイム（Flutterランタイムなど）が導入されることを願っています。かなりの数のLOBアプリケーションとPhotoshopのようなアプリケーションの場合、GUIは各プラットフォームで同じにすることができますが、重要なのはパフォーマンスとソースコードの再利用です。また、xlangプロジェクトは素晴らしいアイデアであり、将来的にいくつかの良いニュースを約束すると思います。

ekral 2019年05月22日

🎉1

ここのユーザーは、BUILD 2019の後で、Win UI、Xamarin Form、UNO、WebAssemblyをどのように組み合わせることができるかについてScottHunterに耳を傾けることをお勧めします。

.NET Core3以降とScottHunter @ .NET Rock

Xamarin Forms（XAML）とUNO（XAML）はどちらも、クロスプラットフォームのビジョンを持って作成されました。 UNOの場合（iOS、Android、XAML for Web through Web Assemblyに加えて）。

UWPは、Web、Android、iOSなどのMicrosoftエコシステムを超えるビジョンなしで作成されました。 UWPの採用が遅いため、印象的なFluentの設計作業はほとんど必要ありません。

@ Mike-EEが指摘したように、ドロイドとiOSには20億と15億があり、Win10には9億があります。そのほとんどの開発者は、WinFormとWPFからUWPにジャンプすることにまだ消極的です。

どうして？商用およびMicrosoftのUWPコントロールは不完全です!!!!! WinFormおよびWPFのものと比較して。その移行を支援するためのマイクロソフトによる努力はありません。開発者がwinFormとWPFからUWPに移行する必要があるため、 XAML Islandは、MICROSOFTがBLIND SPOTを持っている限り、これに対処しません。

これらのUWPコントロールが欠落しているため、現在、WinUIをReactNative forWebに導入することに多大な努力が払われています。 ?????? WinFormおよびWPFからUWPへの移行をロビー活動できるよう

そのようなコントロールの1つがダイアグラムコントロールです。すべてのデータ集約型ビジネスアプリには、UWPのダイアグラム制御が必要です。

==> UWPUIを分離する必要があることを理解しています。これは、フルーエントデザインのブランドをiOS、Android、Webなどの他のプラットフォームに広めることだけに意味があります。
==>より優れた3Dモデルコントロールとダイアグラムコントロール（2D / 3Dの両方）の提供に焦点を当ててください

HOLOLENSのクリエイティブな3DUIの未来を見たので、（monoがWindowsのネイティブとマージされ、Web Assemblyなどのために）からのすべてのBCLがNET5に留まって待つことは意味があります。

そのためには、UWP用の2d / 3Dダイアグラムコントロールと、単にモデルを表示するだけでなく、開発者が骨格/頂点アニメーションにアクセスできるようにする3Dモデルコントロールが必要です。

@jesbisUWPのWinUIのこれらのUSP（独自のセールスポイント）にもっと多くの人を参加させることをお勧めします。

GeorgeS2019 2019年05月23日

👍3 🎉1

@weitzhandler

この問題は、 WinUI3.0ロードマップについて説明するために作成されました。

@jesbisは明確な声明を出しました：

WinUIはWindows用のネイティブUIプラットフォーム（.NETだけでなくネイティブアプリを含む）であり、最初の3.0バージョンでは、主にOSから独立させ、より高速なリリースでオープンソース開発の準備を整えることに重点を置いています。サイクル。今年プレビューを公開するのに十分な範囲が実現可能であることを確認したいと思います。

最初の2つのコメントは話題になりました。

次の6つは、非生産的で蔑称的な組み合わせであり、 Microsoftオープンソースの行動規範を破る寸前です。

これは、マイクロソフトとの生産的で専門的な会話であり続けるはずです。

//私はこの会話をフォローしていないので、一日中誰かのベントを聞いています。

kmgallahan 2019年05月23日

👍7 😄2 ❤1 🎉1 👎1

ここには素晴らしいコメントがいくつかあると思いますが、2つの別々の議論があるようです。ほとんどが以前に言われたので、短くしておきます。

クロスプラットフォームとウェブ

.NETCoreは素晴らしいです。最終的に、優れたツールと優れた言語を使用して、すべてのプラットフォームとタッチポイントをターゲットにすることができます。
足りないのはBlazor以外のUIスタックだけです（HTML / CSSは最悪ですが）。最大限の比較可能性を得るには、デスクトップ開発者が同じスキル、ツール、言語（XamlとC＃）を使用してWeb以降に移行できるフレームワークがあると便利です。 Tbh、Silverlightはそこで素晴らしいことをしました-それはうまくいきました）。 WinUIがそのフレームワークである必要があるかどうかはわかりませんが、内部で問題を提起してください。基本的に.NET開発者向けのFlutterであり、Webをターゲットにすることが最大の利点になります。

Xamarinがそのプラットフォームである可能性があるかどうかはわかりませんが、そうである場合は、XamlがWinUIとXamarin間で可能な限り整列されていることを確認してください。

WinUI

これは起こる必要があります。 Windowsプラットフォームで可能な限り最高のエクスペリエンスを作成するには、一般的なXamlスタックが1つ必要です。理想的には、コントロールと機能の点でWPFから欠落しているギャップを埋める必要があります。

HoloLens以降

Liteが登場し、HoloLensなどの新しい非常にエキサイティングなフォーム要素が登場すると、UIの観点からUWPはその準備ができていないと主張することができます。はい、HoloLensで実行できます。これは素晴らしいことですが、完全なUnityを使用せずに、アプリを3D用に実際に最適化する方法を見つけたいと思います。

niels9001 2019年05月23日

👍8

WinUIはXamarinよりもはるかに進んでいます。しかし、MicrosoftTeamはXamarin4.0をプッシュするだけです...
私は個人的にXamarinが好きです。これは、クロスプラットフォームの最低額であり、将来的にはSaaS用のネイティブアプリの数が増える予定です。

Xamarin以外に、いくつかの代替手段があります。
1）UNOプラットフォームを採用し、SkiaSharpを使用してWebレンダリングを作成してみませんか？
2） @ zezba9000ゲームエンジンが最初に使用するような、不可知論的なレンダリングバックエンドが必要です。実はちょっと認めます…。

他のクロスプラットフォームソリューションとは異なり、内部に非オープンソースコードトレースがあるため、MicrosoftはWinUIをさらにプッシュする可能性があります：Xamarin、UNO、UNIXライブラリがある可能性があります...

とにかく、力があなたと共にありますように。
PS：GithubスポンサーはMicrosoftの出身なので、WPF / Winformsのクロスプラットフォームフォーク用の著名なMac / Linux開発者をスポンサーしてください。

meteorsnows 2019年05月23日

👍3

@ jkoritzinsky 、WinUIチームがWinUI 3.0の名前変更で注意する必要があることの1つ：.NETで投影されるタイプのいずれかの名前を変更すると、投影は機能しません（これ以上追加する予定はありません）。保守可能な拡張可能なシステムではないため）。投影するタイプのリストは次のとおりです： https ：
これらのタイプとは異なるタイプに変更を加える場合、ユーザーは、新しいインターフェイスを実装する新しいオブジェクトでオブジェクトをラップするか、データを新しいタイプにコピーする必要があります。特に、 INotifyPropertyChangedおよびINotifyCollectionChangedタイプは、XAMLアイランドおよびダウンストリームサポートの提供に関して重要です。

私は同意し、あなたがこの問題を提起してくれてうれしいですが、これらの予測は少し不幸な悪だと思うことを付け加えたいと思います。おそらくあるはずのすべてのAPIを投影するわけではないので（System.IO APIについて考えて）、それを修正するか、別の考え方をする必要があります。頭に浮かぶことの1つは、異なる名前空間の.NETタイプに、類似しているが異なるタイプを追加しないことです。代わりに、C ++開発者がSystem.ComponentModel.INotifyDataErrorInfoも使用できるようにする必要があります。これは、C ++ / CLIで行ったことのようなものですが、純粋なC ++アプリケーションのCLRをロードする必要はありません。それがもっと混乱するかどうかはわかりませんが、APIレイヤーでの.NETテクノロジーとWinRTテクノロジーの根本的および根本的な違いを漏らしているように感じます。

@ meir-pletinsky。 NETは、UWPXAMLを使用してアプリを作成するために使用できる唯一のフレームワークです。使用するフレームワークに関係なく、開発者がテキストフィールドの検証を利用できることを望んでいます。

これは正解です。私たちが気にかけているC ++開発者がいます。上で述べたように、これを実現するためだけに.NETコミュニティで混乱を引き起こさないようにしたいと思います。

@mdtauk 、いいえ、WinUIデスクトップ（以前のXamlデスクトップ）では、アイランドを使用せずに、Win32でXamlを直接使用できます。

@ meir-pletinskyは、何かが足りない場合を除いて、.NET / C ++を参照していたと思いますか？

@MarkIngramUKここでは2つの異なるプロジェクトについて話していると思います。 WinUIはWin32の代替品である必要があります。人々はクロスプラットフォームソリューションを求めていますが、これは合理的ですが、それが_this_プロジェクトであるべきではないと思います。

はい、私は完全に同意します！私にとって、WinUIとは、Windowsに最適な、最新のパフォーマンスの高いUIを定義することです。 Xamarinは、Microsoftのクロスプラットフォームのストーリーであり、WinUIの上に進化する必要があります。

stevenbrix 2019年05月23日

👍1

@mdtauk

Fluent / FabricWebコントロールスタイルによりよく一致するように、WinUI 3.0で実行されているWinForms、MFC、WPFコントロールの視覚的な外観を更新するというアイデアに+1を追加します。
確かに異なるコントロールサイズ（WinRT XAML以外のものは、おそらくそれらのメトリックをUWPコントロールのコンパクトバージョンに一致させる必要があります）が、1つの一貫性のある一貫した洗練された外観です。
WinUI 3.0の依存関係をWinFormsに追加すると、コントロールが変更されます。
WinUI 3.0 WPFアプリは、Fluent.Light.xamlまたはFluent.Dark.xamlコントロールテーマを検出して使用します。

MSがこれらのフレームワークに時間とリソースを投資してネイティブのWindows10アプリのように見せたいとは思っていません。そのため、WinUI3.0が登場します。 WPF / WinFormsアプリでWindows10のルックアンドフィールが必要ですか？ WinUI3.0を使用します。
MSは、古いフレームワークに再度アクセスするよりも、UWP / WinUIと対応するWin32の間の既存の（およびブロックする）ギャップを埋めるためにリソースを投資する必要があります。特に、WinUIがWindowsのプレゼンテーションフレームワークになることを目的としていることを考えると...

Felix-Dev 2019年05月23日

👍2

WinUIとMicrosoftのUI / UXに関する意図について説明を求めたいと思います。

WinUIは次のすべてを置き換えますか（仮想的に？）：Win32、ATL、MFC、WinForms、Silverlight（私は知っています）、WPF、UWP、および/またはXAMLアイランド？ 私は、これらのテクノロジーが引き続き存在し、無期限にサポートされ続けることを認識しています。これがマイクロソフトが「前進」と言っていることであり、たとえば、WinFormsとWPFはWin32やMFCと同じように考える必要があることを明確に理解したいと思います。
WinUIはUWPから派生していますか？（または、2つはどの程度類似していますか？）UWP、XAMLアイランド、またはWPFと比較してWinUIはどの程度類似（または異なる）ですか？

プロのC＃およびC ++開発者として、私はWinFormsでの作業を開始し、次にWPFに移行し、次にWinFormsでビジネス目的のUI / UXをWPFの約2倍の速度で設計できたという理由で、WinFormsに戻りました。 WPFは、はるかに柔軟性とパフォーマンスを提供し、見た目もはるかに優れていましたが、XAMLを手動で編集する代わりに、誰かがDesignerを介してインターフェイスに触れるとすぐに発生したXAMLマングリングはひどいものでした。場合によっては、WinForms（Designerを使用）は、同様のXAMLフォームまたはコントロールを手動で作成するよりも桁違いに高速だったと思います。

個人的には、Microsoftの製品全体で利用可能で同一のUIが欲しいです。 Win32または.NETで同様の方法で活用できるフレームワークは、すべてのMicrosoft開発者にとって一貫性のあるモダンな外観のアプリケーションを意味し、また、一般的な質問や問題は、単一のテクノロジを対象とするセッションで解決できることを意味します。コントロールについて質問する場合、Win32開発者または.NET開発者の回答は同じです（ほぼ同じではないにしても）。これにより、「WinUI」の学習が特定の開発者のどちらのスタックにも役立ち、開発先に関係なく、オンラインでの情報（StackOverflowなど）へのアクセスがはるかに価値のあるものになります。私はXamarinを使用していませんが、Xamarinをこれらの足跡をたどることができれば（WinUIの拡張として？）、上記のステートメントはWindows開発者だけでなく、Android、iOSなどを対象とする開発者にも適用できます。

WinUIを使用するのにどのようなアプリケーションに興奮しますか？

WinUIについての私の理解が正しく、Win32、MFC、Forms、WPFなどに取って代わる「前進」であり、同じフレームワークがネイティブまたは.NET開発に利用できる場合は、コンポジションを熱心に置き換えます。私がサポートするアプリケーションの_すべて_。プラットフォームやスタックに関係なく同じように機能する（そして動作する）最新の一貫したUI？それは私たち全員が望んでいることではありませんか？ WinFormsまたはWPFで完全に別個の方法でイベントを処理しながら、CreateWindowEx（）とメッセージループを実行してWin32でイベントをディスパッチする方法を覚えておきたいと思う人はいないと思います。それは「現代的」な何かの時です。それがWinUI（3.0）であることを心から願っています。

OSの互換性とダウンレベルのサポート

WinUIがOSからコンポジションを切り離すことに焦点を合わせているのは素晴らしいことだと思いますが、まだWindows10を使用していない顧客は非常にたくさんいます。それが問題点であることはわかっています。ターゲットオーディエンスが最新のものを実行していることを願っていますが、それは私たち全員が日常的に直面している本当の問題です。 WinUIを1703以降の古いプラットフォームで利用できるようにすることについて、どのような議論が行われていますか。これは、現在ターゲットにされている最も古いプラットフォームであると私は信じています。

WinUIを静的にリンク可能または埋め込み可能（.NET Core / 5など）にするオプションはありますか？ Windows 8.1、Windows 8、Windows 7、さらにはWindowsPEをターゲットにする必要があります。これらの要件でWinUIをどのように使用できますか？

Shidell 2019年05月23日

@shidell ：

WinUIはUWPから派生していますか？（または、2つはどの程度類似していますか？）UWP、XAMLアイランド、またはWPFと比較してWinUIはどの程度類似（または異なる）ですか？

WinUI 3.0は、ある意味で、Xamlプラットフォーム、構成、入力など、Windows 10 / UWPのUIプラットフォームコンポーネントの次のバージョンになります。それはそのコードベースから来ています。

ロードマップに記載されていることを除けば、Windows 10 / UWP XamlプラットフォームAPIと非常に似ている必要があります。つまり、ルート名前空間が異なり、他のテクノロジとの混合とマッチングのサポートが向上します（たとえば、UWPの代わりにwin32アプリモデルを使用します）。いくつかの新しい追加機能。

WinUIは次のすべてを置き換えますか（仮想的に？）：Win32、ATL、MFC、WinForms、Silverlight（私は知っています）、WPF、UWP、および/またはXAMLアイランド？私は、これらのテクノロジーが引き続き存在し、無期限にサポートされ続けることを認識しています。これがマイクロソフトが「前進」と言っていることであり、たとえば、WinFormsとWPFはWin32やMFCと同じように考える必要があることを明確に理解したいと思います。

WinUIは、Windows上のネイティブアプリUIの主なアクティブな開発と進歩です。これは、Windows自体とネイティブのMicrosoftアプリおよびデバイスが使用するものでもあります。

XamlアイランドはWinUIの一部になり、WinUIを使用して既存のアプリ（WPF、WinFormsなど）に新しいビューを作成できるようになります。

WinUIを1703以降の古いプラットフォームで利用できるようにすることについて、どのような議論が行われていますか。これは、現在ターゲットにされている最も古いプラットフォームであると私は信じています。
WinUIを静的にリンク可能または埋め込み可能（.NET Core / 5など）にするオプションはありますか？ Windows 8.1、Windows 8、Windows 7、さらにはWindowsPEをターゲットにする必要があります。これらの要件でWinUIをどのように使用できますか？

これに関するフィードバックを共有していただきありがとうございます。 3.0では、ロードマップ（1703以降、8.1でのサポートあり）のプラットフォームに焦点を当てています。開発者には他のバージョンの顧客もいることを私たちは間違いなく理解しており、それは私たちが今後評価することを計画しているものです。

jesbis 2019年05月23日

👍6

素晴らしい— WinUIは「前進」のように思えますが、この理解を考えると、私が興奮していると言うのは控えめな表現です。

特に、XAMLアイランドによって、開発者がWinUIをWPFやWinFormsなどの古いテクノロジに拡張できるようになるのは素晴らしいことだと思います。これは、古い（古い）プロジェクトに取り組んだり拡張したりする際の「前進」の素晴らしい架け橋です。

Shidell 2019年05月23日

素晴らしい— WinUIは「前進」のように思えますが、この理解を考えると、私が興奮していると言うのは控えめな表現です。
特に、XAMLアイランドによって、開発者がWinUIをWPFやWinFormsなどの古いテクノロジに拡張できるようになるのは素晴らしいことだと思います。これは、古い（古い）プロジェクトに取り組んだり拡張したりする際の「前進」の素晴らしい架け橋です。

WinForms、MFC、またはWPFプロジェクトがWinUI 3.0を含めて作成された場合、フォーム/ WPFウィンドウ/ HWNDウィンドウでXAMLアイランドを使用せずにXAMLページ/コンテンツ/ウィンドウをレンダリングできるかどうかを考えたいと思います。

純粋なXAMLを使用するか、アイランドを使用してXAMLをフレームワークが提供するサーフェスに配置する機能は、WinUI3.0を「すべてを支配する1つのUI」にするでしょう。

mdtauk 2019年05月24日

本当にWinUI3.0を「それらすべてを支配する1つのUI」にするだろう

... Windowsの場合。 😉

Mike-E-angelo 2019年05月24日

👍1

WinUI 3.0は、ある意味で、Xamlプラットフォーム、構成、入力など、Windows 10 / UWPのUIプラットフォームコンポーネントの次のバージョンになります。それはそのコードベースから来ています。

その点、 @ jesbis 、WPFとUWPの間で統合がどのように行われるかについて話していただけませんか。特に、UWPで長年求められてきたマークアップ拡張などの概念では、ほとんど成功していません。

もちろん、試みは行われましたが、開発に2年以上かかったにもかかわらず、WPFの実装にはほど遠いものでした。

さらに、WPFマークアップで利用可能だった多くのサービスは、UWPでも引き続き利用可能で実装されています。ここでの取り組みは、新しいUWPベースのWinUI 3.0マークアップがWPFに完全に忠実であることを保証するためのものですか？これがどこかで説明されている場合はお詫びしますが、メッセージを解析して確認することはまだできていません（そして、私の理解を修正/補足するためのリソースを歓迎します）。

Mike-E-angelo 2019年05月24日

👍2

本当にWinUI3.0を「それらすべてを支配する1つのUI」にするだろう
... Windowsの場合。 😉

少なくともWinUI3.0のリリースウィンドウでは。 XAMLレンダリングを他のプラットフォームに導入するプロセスの始まりになることを願っています...

mdtauk 2019年05月24日

🎉3

WPFとUWPの間で統合がどのように行われるかについて話していただけませんか。特に、UWPで長年求められてきたマークアップ拡張などの概念では、ほとんど成功していません。 [...]新しいUWPベースのWinUI3.0マークアップがWPFに完全に忠実であることを保証するためのここでの取り組みはありますか？

@ Mike-WPFでのEEEの完全な忠実度は、3.0の目標ではありません。ただし、時間の経過とともにギャップを埋めるためにいくつかの作業項目を追跡しており（たとえば、 ＃741マークアップ拡張の改善-これがニーズを満たすかどうかを確認してコメントを残してください！）、WPFを超えてWinUIを拡張し続けます（たとえば、 ＃ 686 3Dモデルのサポート）。

WinUIで使用したい/使用する必要のあるWPFの他の特定の機能がある場合は、それらの新しい機能提案の問題を開いてください。または、最近の「 WinRT XAMLに含まれるべきWPF機能」の問題＃719にコメントしてください。私たちには無限のリソースはありませんが、計画ではコミュニティの意見を確実に考慮に入れようとしています。すべてがオープンソースになると、誰もが機能の提供を支援できる可能性があります。

jesbis 2019年05月24日

❤2 👍1

それは励みになります、

私の最大の懸念は、完全なWPF忠実度が目標ではなく、WPF内でWinUIを利用することが目標である場合、優れた（そして元の）Xamlモデルを備えているため、WPFの採用との摩擦に直面することになると思います。

つまり、Xaml諸島に明確な価値提案がないのとほぼ同じように、WinUI3.0をWPFに組み込むための明確な価値提案はないようです。結局のところ、回帰/劣った/未開発のXamlモデルを確立された優れたXamlモデルに取り込もうとしているように見えますが、これはまったく意味がありません。

WinForms、MFCなどのユースケースの場合、はい、このアプローチはWinUI3.0に適しています。ただし、WPFを使用すると、優れたプレゼンテーションモデルと開発者/設計者のパラダイムがあり、MSFTや外部ベンダーによる他のイニシアチブとはまったく一致しません。

Mike-E-angelo 2019年05月24日

👍2

@ Mike-EEEは、 Scott Hunterの話に基づいていますが、間違っている可能性がありますが、「1つのBCLですべてを支配する」という目標は「1つのUIですべてを支配する」よりも優先されているようです。

Webアセンブリを介してWebでXamarinFormsXAMLおよびUNOXAMLの基盤となるMONOをAoCを含む共通のBCLに置き換えることにより、Xamarin Forms XAMLに基づくアプリ、Web上のUnoXAMLはすべてスピードパフォーマンスの恩恵を受けます。

このスピードパフォーマンスは、フラッター、リアクションなどの他のテクノロジーからの激しい競争を考慮して、クロスプラットフォーム用のC＃に投資するキャリアの将来を気にする人にとって重要です。

うまくいけば、 .NET5 =それらすべてを支配する共通のBCLに向けたこの旅では、XAML標準化がプロセスに沿って部分的または完全に処理されますが、.NET5の主な目標ではありません。

XAML標準化の必要性に加えて、もう1つの優先事項は、流暢な設計を通じてすべてのプラットフォーム（モバイル、デスクトップ、およびWeb）にMicrosoftブランドを広めることです。 [専門用語では、WinUI 3.0を介したデカップリング。これは、WinUI3.0ロードマップの目的に焦点を合わせるために何度も求められます]

結局のところ、Win UIが生み出すUWPが、.NET5がリリースされた2020年11月までにすべてを支配するこの1つのBCLで実際にどの程度の役割を果たすかは、私の見解では優先度の高い目標でもありません。

マーケティングの観点からは、残念ながら私たちが深く関心を持っているテクノロジーに翻訳されていませんが、流暢なデザインによるマイクロソフトのブランディングは至る所にあり、そのデザインを宣伝するアプリは高速です。

これは、モバイルプレゼンスの欠如による「市場シェアに追いつく」というマイクロソフトの長期戦略を私がどのように見ているかです。

これは明らかですが、Hololens2以降にはるかに大きな可能性があることがわかります。そのためには、WinUI3.0を搭載したUWPアプリに3Dダイアグラムコントロールと高度な3Dモデルビューアーが付属していることを確認する必要があります。

申し訳ありませんが、BEST OF THE BEST TECHNOLOGYの限られた時間を使いたいので、これを押し続けます。 :-)

GeorgeS2019 2019年05月24日

🎉3 👍2

WinUI3.0の移行期間について

マイクロソフトは、次の目的でWindows Community Toolkitメンテナー（一部はMSで機能します）と直接連携することをお勧めします。

ツールキットをWinUI3.0（サンプルアプリを含む）に再ターゲットする際に、予期しない障害がないかどうかをテストします。
Visual Studioまたは「別のツール」を使用して名前空間の自動名前変更をテストし、スムーズに実行されることを確認します。
プロセスがどのように進んだかを公開します（ブログ投稿/ GitHubの問題/好きなものは何でも）。
WinUI 3.0と、プロジェクトのメンテナがGitHub / Nuget /その他のReadmeに追加できるトランジションに関するテキストのコピーと貼り付けのチャンク、または少なくともそれに関する簡潔な情報を含むURLを提供します。これにより、これらのプロジェクトのすべてのユーザーがWinUI 3.0の速度をすばやく習得し、移行を完了するために何をする必要があるかを説明できます。
プロジェクト/ライブラリのメンテナが採用することを選択できる、提案された移行プロセスとタイムラインの概要を説明します。

最後の項目に関して、これは次のような提案をカバーする必要があります。

WinUI 3.0アプリ（WCT v6.0など）で使用することを示す新しいメジャーリリース番号を作成します。
オプションで（？）、WinUI3.0にまだ更新されていないプロジェクトをサポートするレガシーコードを含むブランチを作成します。
レガシープロジェクトのサポートが提供される期間（たとえば、3/6/12か月）を提供します（つまり、メインブランチからのバグ修正などをマージします）。これには、コミュニティプロジェクト/ライブラリ間でサポート期間を「同期」する特定の日付が含まれる可能性があります。

最後に、Windows10バージョン1507および1607LTSBをサポートする必要がある場合に何ができるかを特定することが重要だと思います。これらは、W10のサポートされている2つのバージョンのみであり、リリース時にはWinUI3.0と互換性がありません。

もともと、Windows 10 Calculatorは本番品質のオープンソースアプリであるため、プロセスをテストすることを提案していました。しかし、その後、このアプリは1507および1607 LTSBでさらに6〜7年間実行する必要があることに気付きました。特に小規模なコミュニティプロジェクトに関しては、これらのタイプのアプリのサポートに関して明らかにいくつかの論争があります。彼らが本当にこのサポートを必要としているのなら、そうする方法についての明確な長期戦略が提供されるべきです。

WinUI 4.0 / 3.x / vNextについて

ここでのコメントが示すように、コミュニティにはWinUIの将来のリリースに対する非常に長いウィッシュリストがあります。より長期的な計画のいくつかを公に文書化することによって、ここで構築されている勢いと熱意を実際に活用する必要があります。

これらの項目のほとんどはv3.0の範囲外であるため、WinUI 4.0 / 3.x / vNextでコミュニティのフィードバックの収集を開始するには、新しい問題を後で作成するのではなく、早めに作成する必要があると思います。どちらかといえば、これは、WinUIチームが検討している作業の種類と、WinUIの範囲外および/または他のMSチームの責任の両方を特定するのに役立ちます。

最後のポイントの例-私は本当にこれらのものを見たいです：

UWPプロジェクトに対する.NETCore 3.0のサポート（私が理解しているように、.NETチームの責任）
Visual Studio App CenterからのWindowsアプリ（UWPおよびWin32）の完全なサポート（明らかに、WinUIチームが担当するものではありません）
マテリアルデザインのドキュメントに記載されているものと同様の、より具体的なフルーエントデザインのガイドライン（ここでも、別のチームの責任）
同梱のW10アプリでのWinUI3.0とFluentデザインの使用（別々のチームとそれらのアプリの一部はLTSBバージョンをサポートする必要があります）

これらの範囲外の項目を特定することで、コミュニティを適切なフィードバックポイントにリダイレクトしたり、それらの領域で何が起こっているのかを説明したりできます。

これらのこと以外に、範囲内のウィッシュリストが集まり始め、コミュニティは、将来WinUIを最大限に活用したいことへのサポートを示し始めることができます。

kmgallahan 2019年05月24日

👍1

たとえば、C＃と同じプロジェクトテンプレートを使用するなど、F＃がC＃と同等のサポートを提供するのは素晴らしいことです。

edgarsanchez 2019年05月25日

👍6 ❤5 😕1

WinUI（UWP vNext）に、Top、Left、Width、Height、StartupPosition、IsTopMost、AllowTransparency、およびShow（）/ ShowDialog（）メソッドを備えたWPFのような適切なWindowオブジェクトが必要です。

（_携帯電話やIoTなどの小さな画面デバイスでこのウィンドウがどのように機能するか（または許可されるか）はわかりません_）

TonyHenrique 2019年05月25日

👍4

@TonyHenrique 1903年にUWP用の新しいウィンドウAPIがありますが、完成にはほど遠いです。

wbokkers 2019年05月25日

👍2

WinUI3.0の範囲内でのXAMLのレンダリングを再度検討しています。

WPFのレンダリングから一歩下がったと思うのは次のとおりです。

ClearTypeを使用せず、代わりにグレースケールアンチエイリアシングを優先するテキスト。
境界線のストロークなどのピクセル精度の欠如。

Windows Phone7とWindowsPhone 8がレンダリングシステムを共有しなければならなかった時期を理解できます。スクリーンテクノロジーの種類とレンダリングの速度が、パフォーマンスの向上に向かって進んでいました。しかし、WinUIが最初にデスクトップにピボットされ、より大きなディスプレイが使用されるようになりました。おそらく、これらの品質をXAMLレンダリングエンジンに復元するときです。

また、HololensやXboxのようなものに特別な配慮が必要な場合は、現在のようにレンダリングが必要なデバイスでプラットフォームレベルでオンにできるパフォーマンスモードを提供してみませんか？

mdtauk 2019年05月27日

👍5

f＃テンプレートはどうですか？

khoshroomahdi 2019年05月29日

👍2

.NET Framework 4.5以降を対象とする標準のWindowsフォームおよびWPFプロジェクトテンプレートでそのまま機能しない限り、WinUIライブラリを採用することはできません。

最新のWindows10リリースやUWPアプリケーションのみを必要とすることは、フルーエントデザインを採用するための最高の方法です。

jozefizso 2019年05月29日

MicrosoftがWindowsCommunity Toolkitメンテナーと直接連携することをお勧めします（そのうちのいくつかはMSで機能します）

@kmgallahan
素晴らしい提案です！これは間違いなく計画に含まれています。私たちのチームは、Windows Community Toolkitのメンテナーと緊密に連携することが多く、これをテストプロジェクトとして使用したいものの1つです。

WinUI3.0の範囲内でのXAMLのレンダリングを再度検討しています。

@mdtauk
レンダリングの変更は3.0の範囲外である可能性がありますが、今後のリリースのアイデアを再検討できるように、問題を開いてください。大きな焦点は間違いなく普遍的なパフォーマンスであり、ご存知のように、Windows8以降でいくつかのレンダリングの変更につながりました。パフォーマンスモードの切り替えは興味深いアイデアです。

f＃テンプレートはどうですか？

@ edgarsanchez 、@ khoshroomahdi
F＃に興味を持っているようです！ F＃が必要な理由について詳しく知りたいのですが、F＃の問題で、なぜ必要なのか、何に使用するのかについて、お気軽にコメントしてください：＃740

.NET Framework 4.5以降を対象とする標準のWindowsフォームおよびWPFプロジェクトテンプレートでそのまま機能しない限り、WinUIライブラリを採用することはできません。

@jozefizso
Xaml諸島を調べましたか？この機能を使用すると、WPFおよびWindowsフォームアプリケーションでWinRT Xamlを使用できるため、最新のXamlビュー/ページで拡張を開始できます。
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

WinUI 3.0にはアイランドが含まれ、少なくとも最新の5バージョンのWindowsであるCreatorsUpdate以降との下位互換性があることを計画しています。

WinUI3.0でCreatorsUpdate以降に取り組んでいるXamlIslandsは、あなたのニーズを満たすことができますか？

jesbis 2019年05月29日

👍1

レンダリングの変更は3.0の範囲外である可能性がありますが、今後のリリースのアイデアを再検討できるように、問題を開いてください。大きな焦点は間違いなく普遍的なパフォーマンスであり、ご存知のように、Windows8以降でいくつかのレンダリングの変更につながりました。パフォーマンスモードの切り替えは興味深いアイデアです。

完了＃768

mdtauk 2019年05月29日

XAMLアイランドにはWindows10バージョン1903が必要であり、 Windows CommunityToolkitライブラリにはプロジェクトがUWPである必要があります。それはダメです。

jozefizso 2019年05月29日

XAMLアイランドにはWindows10バージョン1903が必要であり、 Windows CommunityToolkitライブラリにはプロジェクトがUWPである必要があります。それはダメです。

WinUI3.0はWindows7 / 8 / 8.1に移行しませんが、これらのOSは間もなく保守終了になります。そして、今のところ、それらにはWPFとWinFormsを引き続き使用できます。これは、ユーザーがWindows10に移行した場合に使用します

mdtauk 2019年05月29日

この場合、プロジェクトはWindows 10用のUWPになるため、WPF / WinFormsをサポートしても意味がありません。これはただ円を描いて動き、開発者ツールを断片化しています。

jozefizso 2019年05月29日

@jozefizso UWPが変更されてWPFやWinFormsに近づき、XAMLUIがWPFおよびWinFormsプラットフォームに近づいていると言うのがより正確です。

制限のあるサンドボックスから抜け出し、WPFおよびWinFormsプラットフォームに接続できる最新のXAMLUIを備えたUWPアプリ。

これが私がそれを理解する方法です。

mdtauk 2019年05月29日

👍3

XAMLアイランドにはWindows10バージョン1903が必要です

この場合、プロジェクトはWindows10用のUWPになります

WinUI 3.0では、1703以降（はるか昔）に島を利用できるようにする予定です。

また、WinUIがUWP（非公式には「WinUIデスクトップ」と呼ばれます）ではなくWin32アプリモデルで使用できるように取り組んでいるため、必ずしもUWPアプリである必要はありません。

jesbis 2019年05月29日

👍8

また、WinUIがUWP（非公式には「WinUIデスクトップ」と呼ばれます）ではなくWin32アプリモデルで使用できるように取り組んでいるため、必ずしもUWPアプリである必要はありません。

これが私が最も興奮していることです。 Win32であろうとWindowsランタイムであろうと、利用可能なWindowsの完全なAPIを備えたネイティブアプリケーションは、Xamlを介してパフォーマンスの高いUIを持つことができます。

MarkIngramUK 2019年05月29日

👍4

また、WinUIがUWP（非公式には「WinUIデスクトップ」と呼ばれます）ではなくWin32アプリモデルで使用できるように取り組んでいるため、必ずしもUWPアプリである必要はありません。
これが私が最も興奮していることです。 Win32であろうとWindowsランタイムであろうと、利用可能なWindowsの完全なAPIを備えたネイティブアプリケーションは、Xamlを介してパフォーマンスの高いUIを持つことができます。

WinFormsアプリを使用して、コードビハインドを保持しますが、フォームをXAMLウィンドウに置き換え、すべてのブラシとXAMLコントロールにアクセスできるようにします。

WPFは、WinUI XAMLを適切に使用するだけでは少し複雑になりますが、少なくともWPFコントロールはWinUIコントロールと一致するようにスタイルを設定できます。

mdtauk 2019年05月29日

😄1

名前空間の名前を変更する必要があります。「Xaml」は、ネイティブUWPコンポーネントのマーケティング言語（頻繁に変更される）として誤って使用されているマークアップ言語を参照しているため、適切ではありません。「Xaml」は「WinUI」に置き換える必要があります。このスレッドでも、「Xaml」が.xaml言語を指しているのか、UIコンポーネントを指しているのかがはっきりしないことがよくあるため、どの程度の混乱が生じているかがわかります。
これにより、WPFとUWPが互いに近づく限り、これは問題ありません。それぞれに他にはない機能があり、2つを組み合わせた「WindowsUI」があるのは理にかなっています。機能が重複している可能性がありますが、これは移行パスWPF-> UWPの場合もあります。
Windowsバージョンからの分離は理にかなっていますが、この作業が終了したときにWin7がEOLをはるかに超えていることを考えると、比較的更新されたWin10を想定することもできます。

charlesroddie 2019年06月01日

👍5

XamlはUIフレームワークの名前です。したがって、Windows.UI.Xaml .. ..

MarkIngramUK 2019年06月01日

XamlはUIフレームワークの名前です

Xamlは、開発者がアプリケーション内のプレゼンテーションのシーンだけでなく、アプリケーション自体を強力に記述および構築できるようにするWPFのテクノロジでした。つまり、UI要素とPOCOを記述することができます。 .NETの場合は、Xamlで豊富に記述し、アプリケーションコンテキストにロードできます。

XamlはeXtendedApplication Markup Languageの略であり、.NET _application_コンポーネントをエレガントかつ効率的に記述できるマークアップ言語であることを忘れないでください（そして、私たちが持っているように聞こえます）。これは主にユーザーインターフェイス要素を説明するために使用されましたが、実際にはそのように降格または制約されていませんでした。

私は個人的にXamlを使用してアプリケーション構成全体を記述し、App.configを削除して置き換えました。もちろん、Web.configも複雑でしたが、絶対に必要な外部APIの場合を除きます。

XamlはUIではありません。これらはまったく異なる2つの概念ですが、残念ながら、UWPの下で何年にもわたって混同されてきました。私は、「Xaml」という用語がこれらの取り組みから解き放たれるのを見るのが大好きですが、そのような措置が検討されることはもちろん、実施されることも確信していません。

Mike-E-angelo 2019年06月01日

@charlesroddie名前が本当に恣意的であることに同意します。正直なところ、WUXaml名前空間に由来するもののスタックトレースを検査する場合、それは実際には名前空間DirectUIの内部にあります。別の話があったと思うので、当時ここに誰かがいたら、Win8の話を知りたいです。レイヤーを合成するためのDirectComp、スムーズなスクロールとラバーバンディングのためのDirectManipulation、そしてDirectUIを上にしてすべてをまとめるベクターグラフィックエンジンとしてのDirect2D / DirectWrite。その後、何らかの理由で、一部がWin7にバックポートされ、XamlビットのみがWinRTシステムを介して公開され、他のすべてのAPIは、サンプルで説明する必要のある奇妙なファクトリとパターンを持つ不可解なcomインターフェイスとして残されました。呼び出す。

実際、今考えてみると、WUCompositionがWinRTを介してDirectCompとDirectManipulationを公開したように（またはそれは書き直しである）、Direct2D / DirectWriteがここにも正式なホームを持っていれば本当に素晴らしいでしょう。それらはすべて連携して、さまざまなレベルのエスケープハッチと忠実度のタッチポイントを有効にします。 Win2Dは実際には半分焼き付けられており、優れたAPIでもありません。

eklipse2k8 2019年06月01日

Windows.UI.Compositionは、私が信じているDirectCompositionを書き直したものです。 APIは似ていますが、同じではありません。

MarkIngramUK 2019年06月01日

すべてのモニターがsRGBであると想定するのをやめます。
すべてのレガシーアプリの色をsRGBとして扱い、作成中に各モニターの変換を行います。

reli-msft 2019年06月03日

👍1

これは少しオフトピックであってもよいが、あなただけのインなしで使用コンプのように、最小限の依存でWinUIまたはコンプを使用する場合がありますので、あなたはUIシステムを近代化したい、あなたは既にC ++で書かれた大型のWin32 appliationを持っていると仮定かもしれませんボックスコントロールセット、またはXAMLなしでも。

reli-msft 2019年06月03日

👍2

これはすでに可能ですが、WinUI3.0を待つ必要はありません。

MarkIngramUK 2019年06月03日

ネーミングに関するフィードバックをありがとうございました。すでに述べたように、今日、「Xamlプラットフォーム」と「Xaml言語」（独自の仕様/方言）は区別されており、混乱を招く可能性があります。カードに大きなブランド変更はないと思いますが、名前空間と名前空間については間違いなく話し合っています。

XAMLを使用しないC ++ Win32アプリケーションでWindows.UI.Compositionを使用して、既存のアプリケーション（Photoshopなど）を最新化します。彼らはすでにUIアーキテクチャを持っています。

これは少し話題から外れているかもしれませんが、すでにC ++で記述された大規模なWin32アプリケーションがあると仮定して、UIシステムを最新化したいので、依存関係を最小限に抑えてWinUIまたはCompを使用することをお勧めします。ボックスコントロールセット、またはXAMLなしでも。

これについてのフィードバックに感謝します-これは、Windows.UI.Compositionを使用する「フレームワークレス」アプリと同様に、WinUI3で最終的に可能になると思います。 WinUI NuGetパッケージと依存関係を構造化する方法を決定するときは、これを念頭に置いておく必要があります。

すべてのモニターがsRGBであると想定するのをやめます。
すべてのレガシーアプリの色をsRGBとして扱い、作成中に各モニターの変換を行います。

@ reli-msft別の問題を開いて、それを追跡できますか？

jesbis 2019年06月03日

🎉3

@ jesbis👉＃67

reli-msft 2019年06月03日

👍2

Appleは本日SwiftUIを発表しました...

開発者がXAMLとコードビハインドの代わりにコードを使用してアプリを作成することを選択できるように、 XamlDirectにVisualStudioテンプレートを提供する場合はどうでしょうか。

mdtauk 2019年06月03日

👍6

カードに大きなブランド変更はないと思いますが、名前空間と名前空間については間違いなく話し合っています。

ありがとう@jesbisこのスレッドに参加していただきありがとうございます。通常、誰かがこのような投稿/アナウンスを作成し、それを死んだままにする（または他の人がまばらに管理する）ように思われるので、スレッドの作成者としてのあなたが従事しているだけでなく、注意を払っているのを見るのは励みになります他の人が言っていること。特にそれらの他のものが_me_であるとき。 😆

そして、あなたは正しいです：1）ユーザーインターフェースプラットフォームと2）言語/マークアップ/記述メカニズムがあります。私の批判的な発言の中で、私は（最初の）ユーザーインターフェイスプラットフォームに十分な信用を与えることは決してないと言います。これについては、Windowsチームによる多くの素晴らしい作業があったことを知っています。個人的には、それは私にとっては決して心配事ではありませんでした。これは、私の（そして他の人の）怒りと驚きを引き付ける2番目の領域であり、これは、長年にわたって発生しているUserVoiceの問題に見られます。

これはすべて、少なくともこれら2つの領域をより適切に分類するためのブランディングの取り組みをさらに検討するように依頼したいと思います（おそらく😅）。「XamlDirect」は、その名前が「マークアップ言語」を意味するため、ここでの混乱の頂点だと思います。名前のとおりです。 -しかし、実際の使用法にはそのようなものはありません。ひどく混乱し、誤解を招き、ブランドの境界的な乱用を申し出ます。

Xaml Directと言えば、@ mdtauk ：

開発者がXAMLとコードビハインドの代わりにコードを使用してアプリを作成することを選択できるように、XamlDirectにVisualStudioテンプレートを提供する場合はどうでしょうか。

CSharpForMarkupのようなもののように？

XamlDirectよりもはるかに優れた適切な名前だと思います。もちろん、_any_nameはそうなるでしょう。 😉

Mike-E-angelo 2019年06月03日

👍3

Xaml Directと言えば、@ mdtauk ：
開発者がXAMLとコードビハインドの代わりにコードを使用してアプリを作成することを選択できるように、XamlDirectにVisualStudioテンプレートを提供する場合はどうでしょうか。
CSharpForMarkupのようなもののように？
XamlDirectよりもはるかに優れた適切な名前だと思います。もちろん、_any_nameはそうなるでしょう。 😉

@ Mike-EEE https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

ミドルウェアがコードからXAMLUIを作成するように設計されていますが、XAMLファイルの代わりにそれを使用するテンプレートがあった場合はどうでしょうか。そこに出すことを考えただけです...

mdtauk 2019年06月03日

🎉4

@mdtaukはい！ SwiftUIはXamlに似ていますが、コードで実行されます。私は、Reactが行うように、コード内のすべてのアイデアが大好きです。デザインファイルを分割して、ある種のコードビハインドにリンクするのは一種の古い学校であり、保守が難しいと思います。

友人は、iPadProの120hzディスプレイで動作するためにSwiftUIレイアウトエンジンが必要だと言っていました。それが彼らが焦点を合わせてきたものです。本当に魅力的です。

eklipse2k8 2019年06月04日

👍3

SwiftUIに触発された変更についての議論が@ eklipse2k8に行くことができる新しい問題＃804を作成しました

mdtauk 2019年06月05日

VisualBasicのテンプレートを追加することを忘れないでください。😀

Berrysoft 2019年06月05日

❤2 👍2

WPFにWinUI3の下位層を構築させましょう！

reli-msft 2019年06月11日

@ reli-msft WPFを更新することでどのようなメリットが得られますか？

WinUIで確認したい特定のWPF機能がある場合は、「WinRT [WinUI]にあるべきWPF機能」スレッドで詳細をお聞きしたいと思います： https ：

jesbis 2019年06月11日

👍2

新しい固定された問題＃888を支持して閉じる

jesbis 2019年06月22日

本当に楽しみにしています。特にバージョン関連の多くの問題を解決します。

sumitsahoo 2019年08月13日

@weitzhandler [ 2019年5月16日
私にとって、すべての技術的な詳細はそれほど重要ではありません。
UWP、WPF、またはWindowsのみのフレームワークは、それが素晴らしいとは言え、すべてのプラットフォーム（少なくとも、Windows、Droid、iOS、およびWeb）で実行されない限り、十分ではなく、任意の画面サイズ。

WinUIとXAML全般と同様に、次の点で改善が見られることを望んでいます。その中には、煩わしく、作業が遅くなるものもあります。

より多くの組み込みコンバーター多数のコンバーターが必要であり、そのうちのいくつかは、冗長性を減らすためのマークアップ拡張機能としても使用する必要があります。これには、単純な算術アクションの否定、オブジェクトからブール値へのコンバーター（セマンティック値による偽、つまり、コンテキストごとの空の文字列、空のコレクション、非表示の可視性など）も含める必要があります。
上記と同じですが、動作があります。バインディングとイベント/アクションの間に簡単な移植があるはずです。それが組み込まれていて、テストされていないNuGetを使用する開発者が疑わしくない場合は、はるかに簡単になります。
一部のバインディングタイプ、マークアップ拡張機能、汎用ビューなど、WPFから欠落しているすべてのもの。

ありがとうございました！

weitzhandler 2019年09月18日

より多くの組み込みコンバーター

バベッジの分析エンジンとチューリングの普遍的な計算の理論以来、あらゆるコンピューターが実行できるあらゆるプログラムを実行できる単一のコンピューターが可能でした。計算を行うたびに新しいコンピューターを作成する必要がある時代に戻りたいと考えています。

コンバーター事業全体は、不用意に投棄されるべきです。

オブジェクトからブール値へのコンバーター

ブール値はブール値です。他のオブジェクトはブール値ではありません。また、オブジェクトからブール値への自然な変換はありません。 .Netではタイプが重要であり、タイプされていないシステムをユーザーに公開しないでください。

はい。バインディングなどの既存の型指定されていないシステムもダンプする必要があります。

charlesroddie 2019年09月18日

コンバーター事業全体は、不用意に投棄されるべきです。

私はあなたの選択肢は何ですか？
コンバーターに関する私の問題点は、コンバーターを自分で書き直すか、NuGetから選択する必要があることと、非常に冗長であることだけです。それに加えて、それらは柔軟性がなく、算術や否定などの式を許可しません。

ブール値はブール値です。他のオブジェクトはブール値ではありません。

その通りですが、UIに関しては、それほど重要ではありません。
従来のオブジェクトの状態に基づいてコンテンツを表示/非表示にします。すべてに専用の可視性プロパティがあるべきではありません。

バインディングのような既存の型指定されていないシステムもダンプする必要があります。

は？実はメリットがあると思います。 VとVMの間の緩い結合は良い場合があります。

weitzhandler 2019年09月18日

バインディングのような既存の型指定されていないシステムもダンプする必要があります。
VとVMの間の緩い結合は良い場合があります。

小さなプロジェクトの場合もありますが、コンパイラの支援を文字通りオフにするよりも、緩い結合の方が優れた抽象化があります。数十から数百のビューを持つ大規模なアプリケーションを維持する必要があり、複数のサイトで使用される可能性のあるものをリファクタリングしたい場合、コンパイラにバインディングパスの正確さを検証させないと、開発者のエクスペリエンスが大幅に低下します。私たちの言語に型システムがあるのには理由があります。大規模なプロジェクトは、プログラマーを支援するツールなしでは文字通り保守できません。現在、UI言語はかなり遅れています。

weltkante 2019年09月18日

👍1

コンパイルされたバインディングは、そのために大いに役立ちます。

simonferquel 2019年09月18日

@weitzhandlerつまり、あなたの選択肢は何ですか？
...すべてに専用の可視性プロパティが必要なわけではありません。
は？実際、[バインディング]には利点があると思います。 VとVMの間の緩い結合は良い場合があります。

優れたリアクティブフレームワークでは、 name:Mutable<string>ような観測可能な変数を（コードで）定義し、それらをlet visibility = name.map(fun s -> s <> "")マップしてから、それらをバインドしてvisibility.bind someView.set_IsVisibleまたはname.bind(fun s -> someView.IsVisible <- s <> "")プロパティを表示できます。

https://github.com/ReedCopsey/Gjallarhornを使用してい

次の点に注意してください。1。バインディングとは異なり、すべてが入力されます。 2.物事（関数、プロパティ、ビュー）は、文字列名を渡すことによってではなく、オブジェクトと呼ばれます。3。関数は単なる関数であり、コンバーターよりもはるかに扱いにくいです。4。単純なオブジェクトプロパティを追加する必要があるボイラープレートをバインドします。「バインド可能なプロパティ」などは削除できます。

ビューはXamlで記述できます。特に、単純でほとんど静的なレイアウトの場合は、どこにでもマジックストリングの欠点がありますが、デザイナーがライブビューを提供できるという利点があります。ライブビューを提供するコードを用意することをお勧めします。通訳で非常に可能です。

charlesroddie 2019年09月18日

リアクティブフレームワークと言えば、 Chain Reactiveをチェックして、オープンソースにする必要があるかどうかを教えてください。

HappyNomad 2019年09月19日

こんにちは、ms teamはuservoiceのすべてのバグ/機能を解決できますか？
もしそうなら、それはWinUI3.0よりも素晴らしいステップになるでしょう。

hupo376787 2019年09月20日

👎5 👍1

@ hupo376787これはWindows開発プラットフォームをより広く議論するためのスレッドではないため、投じたと思います。また、このレポでさえ、このプラットフォームの1つの側面にのみ焦点を当てているため、適切な場所ではない可能性があります。

しかし、マイクロソフトと開発者が参加できるWindows開発プラットフォームについてオープンに議論する場所がないことは問題であり、関連するマイクロソフトグループがフィードバックメカニズムを維持しておらず、更新も応答もしていないことが問題です。数年間のユーザーボイス。

charlesroddie 2019年09月30日

@charlesroddieええ、ユーザーの声は放棄されているようです。フィードバックHubに音声を送信します。おそらくmsはそれらを無視しますが、私は自分の仕事をします。

hupo376787 2019年09月30日

UserVoiceは今月完全に廃止されます。

特定の製品については、関連するエンジニアリングチームが積極的に使用しているため、GitHubリポジトリ（このような）はフィードバックに最適な場所です。

特定のレポの製品に関連しないフィードバックについては、FeedbackHubを使用してください。 APIと開発者ツールに関するフィードバック専用のさまざまなサブカテゴリを持つ「開発者プラットフォーム」カテゴリがあります。

現在UserVoiceには多くの履歴と以前のフィードバックがあることを知っていますが（これは引き続き追跡します）、GitHubとFeedback Hubの両方が、UserVoiceよりもエンジニアリングチームと作業項目の追跡へのより直接的なパスを提供します。ポジティブな変化であるはずです。現在、さまざまなサポートとフィードバックのリンクを更新中です。

私たちはどちらのチャネルからも入ってくるすべてを見て、フィードバックとバグレポートに本当に感謝しています！

jesbis 2019年09月30日

👍4

@jesbis OK、

hupo376787 2019年10月02日

WinFormsの場合、新しいWinUIプロジェクトテンプレートを使用すると、[プロパティ]ウィンドウは引き続き機能し、WinUIコントロールのプロパティを設定できますか？ HTMLは一日中問題なくコーディングできますが（通常はAsp.net MVC）、コントロールに使用できる設定が非常に多い場合、過去20年間プロパティウィンドウを使用して楽しんでいます。

Dean-NC 2019年10月21日

@ Dean-NC WinFoms / Windowsフォームではなく、XAMLデザイナーについて質問していると思いますよね？その場合、はい、XAMLデザイナでアイテムを選択すると、プロパティパネルはWinUIコントロールに対して引き続き機能します。

marb2000 2019年10月22日

@ marb2000 WinUI 3は、ほとんどシームレスであり、レガシーコントロールとWinUIコントロールの両方を備えたフォームを作成でき、プロパティウィンドウが機能するという意味で、新しいコントロールをWinFormsにもたらすと素朴に思っていたと思います。レガシーコントロールとWinUIコントロールの両方。

上記の投稿全体を読み、（WinForms開発者として）非常に興奮してこれをフォローしてきましたが、これがどのように機能するかについての高レベルのワークフローを誤解していると思います（ここでも、WinFormsの観点から））。

WinFormsは今後何年にもわたって素晴らしいものになる可能性があると長い間言ってきましたが、最大の弱点は、基本的なコントロールが古くなっていることです（テキストボックスではパディングが許可されないため、細い、小さなラジオとチェックボックスボタンに見えます）、 NS。）。 Win 10コントロール（テキストボックス、ラジオ、チェックボックス）の非常に基本的なものだけが、WinFormsに新しい命を吹き込むのに大いに役立ちます。
いくつかの記事がありますか、またはレガシーコントロールと新しいコントロールの両方を使用したい新しいWinFormsプロジェクトのワークフローがどのようになるかについて簡単に説明していただけませんか？
ありがとう。

Dean-NC 2019年10月22日

👍2

@ marb2000 WinUI 3は、ほとんどシームレスであり、レガシーコントロールとWinUIコントロールの両方を備えたフォームを作成でき、プロパティウィンドウが機能するという意味で、新しいコントロールをWinFormsにもたらすと素朴に思っていたと思います。レガシーコントロールとWinUIコントロールの両方。
上記の投稿全体を読み、（WinForms開発者として）非常に興奮してこれをフォローしてきましたが、これがどのように機能するかについての高レベルのワークフローを誤解していると思います（ここでも、WinFormsの観点から））。
WinFormsは今後何年にもわたって素晴らしいものになる可能性があると長い間言ってきましたが、最大の弱点は、基本的なコントロールが古くなっていることです（テキストボックスではパディングが許可されないため、細い、小さなラジオとチェックボックスボタンに見えます）、 NS。）。 Win 10コントロール（テキストボックス、ラジオ、チェックボックス）の非常に基本的なものだけが、WinFormsに新しい命を吹き込むのに大いに役立ちます。
いくつかの記事がありますか、またはレガシーコントロールと新しいコントロールの両方を使用したい新しいWinFormsプロジェクトのワークフローがどのようになるかについて簡単に説明していただけませんか？
ありがとう。

アプリプロジェクトを取得し、WinUIウィンドウとページを追加し、最新のXAMLUIを使用してUIを完全にまたは少しずつ置き換えることができる可能性が高くなります。

また、XAMLを既存のWinformおよびWPFUIに挿入するためのXAMLアイランドがあります

mdtauk 2019年10月23日

Blazorチームは、Unoと協力して、ホスティングモデルの一部をUno（特にサーバー側）に含めるか、Uno UI（したがって、WinUI 3）のレンダリング/ビジュアルレイヤーをBlazorで使用できるようにする必要があります。および/またはBlazorのXamlIslands？

monkeynoises 2019年11月09日

フィードバックのほとんどは、主にxamlスペースで作業する開発者からのものであるため、ここでは少し違和感を覚えます。彼らは一般的に、彼らがすでに持っているもののより良いバージョンを探しているようです。これは既存のユーザーにとっては良いことかもしれませんが、これまでUWPを避けてきた多くの開発者を引き込むかどうかはわかりません。

私のチームは1つのUWPアプリしか開発していません。これ以上開発することはありません。

克服できないハードルは、組み込みの表形式のレポートライターがないことです。 UWPをサポートしていると言う市場のサードパーティレポートライターをすべて試しました。残念ながら、それらのどれもUWPでうまく機能しません。彼らのUWPオファリングは通常、WPF / WinFormsバリアントの簡単なハックであり、正しく機能しません。

UWP製品ではStimulsoftReportsを使用しています。それは非常にバグが多く、UWPの取り込みが非常に少ないため、バグを修正しないと言われています。

リストにデータの視覚化があるようです。しかし、戦艦の灰色のアプリがまだ何百万もある理由は、多くの企業が内部アプリのビジュアルをあまり気にしていないためです。彼らは小計のある数字の列を望んでいます。

したがって、WinUIが最終的にデータ開発者を介してフォームを誘惑することを意図している場合は、組み込みの表形式のレポートライターが必要です。

これが視覚的な人々を怒らせないことを願っています:-)

VagueGit 2019年11月19日

私は完全に同意します。アプリと簡単に統合できるレポートシステムを使用せずに、最新のビジネスアプリを開発するにはどうすればよいでしょうか。それは、開発者の移動を阻止する巨大な峡谷です。

ビジネスユーザーは、表形式のデータを操作して、それを印刷したり、他の形式にエクスポートしたりできる必要があります。また、請求書、見積もり、明細書、その他の文書を作成できる必要があります。

ビジネス/エンタープライズが依然としてWindowsの最大の消費者であると私は理解しています。 Windowsエコシステムの基本的なものがUWP用に開発されていないのはなぜですか？

Elmarcotoro 2019年11月19日

@VagueGitと@Elmarcotoroのフィードバックに感謝します！現在、エンタープライズコントロールは私たちにとってギャップです。ただし、タイミングは良好です。DataGridコントロールの設計に関するフィードバックを収集しています。こちらを読んでフィードバックをお寄せください：＃1500。

jevansaks 2019年11月19日

同様に、正方形の表形式のデータコントロールに加えて、ダイアグラムコントロールを通じて複雑な関係を創造的に共有するために、オープンソースのUWPグラフコントロールが必要です。

GeorgeS2019 2019年11月19日

レポートシステムの場合、現在TelerikUIが最良の選択だと思います。「ある職業を専門とする人もいれば、他の職業を専門とする人もいる」という中国のことわざ。 Telerik、またはDevExpressまたは他の誰かは、報告が得意です。

さまざまなコントロールがないため、このチームのせいにするのではなく、MS戦略全体のせいにする必要があります。 Satyaがモバイルを放棄した当初から、彼らはiOSとAndroidをより好んでおり、彼らのような上司を引き起こしています。 UWPエコシステム全体がますます弱くなっています。

今のところ、ツイッターで「UWPは死んでいる」という議論がありますが、MSはこれを明確にして、uwpの道を宣言する必要があると思います。

hupo376787 2019年11月20日

今のところ、ツイッターで「UWPは死んでいる」という議論がありますが、MSはこれを明確にして、uwpの道を宣言する必要があると思います。

ロードマップスレッドに投稿しました...

MarkIngramUK 2019年11月20日

@jevansaksDatagridコントロールに関する情報をありがとう。これは、レポートの印刷やページ付け、エクスポートなどの問題には対応していません。これらは、対処する必要のある実際のビジネスシナリオであり、一部のボタンがアニメーション化されるかどうかではありません（これが可能な限り素晴らしく、クールです）。

@ hupo376787
「レポートシステムの場合、現在TelerikUIが最良の選択だと思います。」

私が見る限り、現在UWPのレポートを作成および表示するためのフルスタックを提供しているのはDev Expressだけであり、その価格設定はプレミアム側にあるようです。 Telerikを含む他のすべてのツールにはギャップがあり、UWPのレポートを作成できないことを意味します。私はこれについて修正されることを望んでいます（望んでいます）。

Elmarcotoro 2019年11月20日

レポートシステムの場合、現在TelerikUIが最良の選択だと思います。「ある職業を専門とする人もいれば、他の職業を専門とする人もいる」という中国のことわざ。 Telerik、またはDevExpressまたは他の誰かは、報告が得意です。

@ hupo376787投稿が正しくないことを示唆する前に、事実を確認するためにTelerik Reportingには、WPFとWinFormsのレポートデザイナーがありますが、UWPはありません。

DevExpressには、WinFormsとWPFのレポートデザイナーもありますが、UWPはありません。

ですから、永久に保存され、広く流通するエラーに自分自身をコミットする前に、あなたの事実を確認してください。ねえ、それはいつか古いことわざかもしれないように聞こえます😉

VagueGit 2019年11月22日

😕1

@ hupo376787投稿が正しくないことを示唆する前に、事実を確認するためにTelerik Reportingには、WPFとWinFormsのレポートデザイナーがありますが、UWPはありません。
DevExpressには、WinFormsとWPFのレポートデザイナーもありますが、UWPはありません。
ですから、永久に保存され、広く流通するエラーに自分自身をコミットする前に、あなたの事実を確認してください。ねえ、それはいつか古いことわざかもしれないように聞こえます😉

OK、私たちはレポーティングについて異なる理解を持っていると思います。 https://www.telerik.com/universal-windows-platform-uiとhttps://www.devexpress.com/products/net/controls/win10apps/を意味し

hupo376787 2019年11月22日

私は間違っていました、DevExpressはUWPのレポートを提供していません。サードパーティのツール開発者はそうしていません！ UWPのレポートを提供するためのロードマップがあるかどうかについて、チャットを通じてDevExpressに連絡しました。
彼らは言った、
「XtraReportsSuiteは、System.Drawingアセンブリによって提供される機能を使用しますが、ユニバーサルウィンドウアプリケーションに同じツールセットを実装できないのは、このアセンブリがそこで利用できないことです（https://stackoverflow.com/questions / 31545389 / windows-universal-app-with-system-drawing-and-possible-alternative）。したがって、この分野での将来の計画はまだ確立されていません。」

@ jevansaks 、MicrosoftUIチームとこれらのサードパーティツールプロバイダー間のコミュニケーションが不足しているようです。サードパーティのツールを使用できれば幸いですが、UWPプラットフォームでは、これらの企業が他のプラットフォーム用のツールをUWPに統合することが困難になっているようです。

彼らは私たちのレポート要件について[email protected]に連絡するように私に依頼しました。WinUI3.0チームが彼らと連絡を取り、彼らが実装を支援する方法であるかどうかを確認することが役立つ場合があります。適切なレポートツールがなければ、ユニバーサルプラットフォームでビジネス開発者を獲得する方法がわかりません。

https://www.devexpress.com/subscriptions/reporting/

Elmarcotoro 2019年11月22日

レポート：WinFormsの観点から、私はTelerikとDevExpressの両方（最新バージョンも）を使用しました。Telerikは優れていましたが、DevExpressは全体的なデザイナーとエクスペリエンスが優れているだけでなく、より多くの微妙な機能を備えていると思います。 Telerikよりも複雑なレイアウトを行うことができました。 DevExpressレンダリングテクノロジーはもっと進んでいると思います。

Dean-NC 2019年11月22日

Win UI 3.0チームが彼らと連絡を取り、彼らが実装を支援する方法であるかどうかを確認することは役立つかもしれません。

コールアウトをありがとう。彼らにも連絡を取ります。

jevansaks 2019年11月22日

コールアウトをありがとう。彼らにも連絡を取ります。

それらすべてと話し、ブロックが何であるかを確認する価値があるかもしれませんか？ Telerik、Grapecity、DevExpressなど。

Elmarcotoro 2019年11月22日

コールアウトをありがとう。彼らにも連絡を取ります。
それらすべてと話し、ブロックが何であるかを確認する価値があるかもしれませんか？ Telerik、Grapecity、DevExpressなど。

確かに、それは私たちの計画です。

jevansaks 2019年11月22日

私たちは、Windows用に構築しているほとんどの開発者とは少し異なります。私たちは主にキオスクアプリを開発しています（コンピューターの所有者以外のユーザーが実行することを目的としたアプリで、通常はフルスクリーンで、より広範なシステムにアクセスできません）。アプリは通常、顧客の特定の要件に合わせて構築されており、ストアまたは同等のものを通じて配布することを意図していません。

アプリはフルスクリーンで実行されるため、他のWindowsアプリのルックアンドフィールを維持する組み込みコントロールの価値は非常に限られています。代わりに、顧客ごとにブランドが高くなる傾向があります。標準のWindowsアプリからの多くの一般的な_動作_とコントロールが必要ですが、通常は、それぞれのコントロールテンプレートを多くカスタマイズするか、少なくともコアスタイルをオーバーライドします。非常に長い間、UI用のFlashフロントエンドが埋め込まれたWinFormsバックエンドとして多くのアプリを構築してきました。

大まかに言えば、私たちが作成するほぼすべてのアプリは、ある種のWebベースのバックエンドをある種のハードウェア（プリンター、バーコードスキャナー、磁気ストライプリーダー、RFIDスキャナー、カメラ、カード支払いハードウェア、販売スタイルの現金支払いなど）と統合します。コンポーネントなど）、およびこれらのコンポーネントの大部分は、歴史的にWin32 SDKが付属しており、UWPのものは付属していません。

これら2つの理由から、これまでのアプリのほとんどはWinFormsアプリであり、最新のアプリのほとんどはWPFアプリです。いくつかのUWPアプリを構築しました（主にWindowsの非常に優れた割り当てアクセス/キオスクモード機能の恩恵を受けるため）が、通常、WPFと比較して作業が面倒であり、互換性のあるハードウェアSDKを取得することは通常できません。。

ただし、最新のUIを使用してWin32互換アプリを作成できるようにするためにXAMLアイランドに非常に興味を持っています（ただし、標準のコントロールやMicrosoft固有のコントロールを使用していない場合は特に、WPFに対するUWPの利点は必ずしも明確ではありません。 Fluentなどの効果）。

特定の質問に答えるには：

どのテンプレートに最も興味がありますか？

.NET Coreを使用したC＃、WinUI3.0をオーバーレイしたWin32があれば便利です。

デスクトップアプリを最新化するためのXamlIslandsをご存知ですか？

はい。カスタムUI全体を決定するのと同じくらい、_single_コントロールを使用する可能性は低いですが、それらを試してみたときは比較的満足していました。

私がそれを知った主な理由は、Win32アプリのLottieサポートを取得するためでした。

Windows 10でのこの拡張された下位互換性により、Xamlアイランドはより便利になりますか？

あまり; ほとんどの場合、ターゲットPCを制御し、互換性のある最新のリリースを常に入手できるようにします。

Visual Studioまたは別のツールが名前空間を自動的に更新する場合に役立ちますか？

はい。

既存のUWPXamlコンポーネントとWinUI3.0アプリの間の完全な互換性はあなたにとってどれほど重要ですか？

非常に最小限です。互換性に関する主な問題は、コア要素のスタイルを設定するためのStaticResourceキーの変更です。

アプリコードと一緒に簡単に再コンパイルおよび更新できないUWPXamlコントロールライブラリまたはWinRTコンポーネントを作成または使用していますか？

はい、過去にSyncfusionUWPコントロールライブラリを使用

WinUI3でUWPXamlコンポーネントを使用するための好ましいソリューションは何ですか？

推奨される解決策は、外部ソース（ドキュメントビューアなど）に頼るのではなく、WinUI自体でより多くの標準コントロールを使用できるようにすることですが、これらの外部コンポーネントライブラリは通常、切り替え時よりもライブラリの更新に関してより進歩的であると思います。とにかくほとんどの部分でWinUI3。

上記およびロードマップで概説されている全体的な3.0計画についてどう思いますか？新規および既存のWindowsアプリにWinUIを使用できるようになりますか？

特にWinUIがオープンで設計および開発されているため、ハードウェアの互換性の理由で歴史的にロックアウトされてきたUWPアプリおよびセキュリティモデルからUWPコントロールがより明確に分離されているのを見るのが楽しみです。

マイクロソフトがアプリUIの構築をどのように推奨しているかについての明確なガイダンスがあれば、サポートできるバックエンドに関係なく、すべてのアプリが最終的にWinUIフロントエンドになると思います。

WinUI 3.0を使用するのに最も興奮しているのはどのようなアプリですか？新しいWin32アプリを作成し、MSIXでパッケージ化しますか？ WPFアプリに新しいビューを追加しますか？ FluentUIを使用してC ++ MFCアプリを最新化しますか？

主に、古いアプリでよりアクティブに維持されているコントロールのライブラリにアクセスすることについて、より優れた、より明白なドキュメント（または標準コントロールの基になるコードへのアクセスさえ）を使用すると、標準コントロールをいつ適応できるかをはるかに簡単に理解できます自分のユーザーコントロールをロールする必要があるとき。たとえば、WPFに組み込まれている最近のアプリでは、日付ピッカーが2つありました。そのコントロールをタッチでうまく機能させること、そしてサイズ、フォント、ポップアップアイコンなどをカスタマイズすることは非常に面倒でした。上記のロードマップを考えると、将来的には_default_までにその種のアプリにWinUIを使用する傾向があります。理由は次のとおりです。

少なくとも適度にタッチフレンドリーなネイティブの日付ピッカーコントロールがあることを合理的に確信できます
そのコントロールのネイティブ/すぐに使用できるテンプレートなどを簡単に調べて、顧客のルックアンドフィールのデザインプルーフと一致させるためにオーバーライドする必要があるものを簡単に確認できます（大まかに代表的な例として、入力テキストとは関係なく、TextBoxコントロールのヘッダーのタイプ（フォントサイズ、太さ、ファミリ）のスタイルを設定する最もクリーンな方法を見つけるために、標準のHeaderTemplateは、再定義できる魔法の静的リソースを使用しますか、それともテンプレート自体をオーバーライドする必要がありますか？テンプレートをオーバーライドした場合、デフォルトのテンプレートのマークアップはどのようになりますか？それは私が考慮していなかったものを実行/サポートしますか？）

kitgrose 2019年12月18日

これは終了したようですが、ユーザーから提起される問題がいくつかありますが、提起する価値はあります。これらは、大量のデータを処理するユーザーの生産性の向上です。

テキストボックス：
ユーザーがTextBoxを編集する必要がある場合は、最初にTextBoxをクリックしてクリアボタンを表示し、次にクリアボタンをクリックしてTextBoxをクリアする必要があります。大量のデータを処理する場合、これは非常に非効率的です。ユーザーがTextBoxをクリックまたはタブで移動したときに、テキストを強調表示して上書きできるようにするとよいでしょう。

Gridview / ListView：
GridviewとListViewでは、ユーザーがコレクションを効果的にタブ移動できないようです。
ListViewでは、Tabを同じ行のコントロールに移動できますが、次の行のコントロールにTabで移動することはできません。代わりに、ListViewはフォーカスを失い、Tabはビジュアルツリーの次のコントロールに移動します。

これらは、ユーザーが非常に迷惑なものとして提起した2つの問題です。

Elmarcotoro 2020年01月27日

👍1

@Elmarcotoro

あなたが言及した改善ごとに新しい問題を作成することをお勧めします。次に、WinUIチームは、実装する前にWinUI3をリリースする必要があるかどうかを判断するためにトリアージを行います。

この問題は主に、投稿の上部にある2つの「一般的な質問」に関するフィードバックを収集するために存在していました。

kmgallahan 2020年01月27日

WinUIでネイティブなBlazorホスティングモデルをサポートします。これにより、Blazorコントロールをクライアント/サーバーWebで直接使用したり、WinUIで直接使用したりできるようになります。 Blazorロードマップには、WebViewコントロールを使用せずにこの将来の概念があります。このようにして、コントロールのUIはネイティブで実行され、コードの.NetStandard部分もネイティブで実行されます。

RChrisCoble 2020年02月25日

🎉2 👍2

WinUIでネイティブなBlazorホスティングモデルをサポートする

Blazor側で議論された、FWIW：
https://github.com/dotnet/aspnetcore/issues/11082

Mike-E-angelo 2020年02月25日

確かに、それは私たちの計画です。

@jevansaksループに入るのも素晴らしいでしょう。

jbartlau 2020年03月05日

WinUI3.0とトレイメニュー/アイコンメニューの一貫性を高めたいのですが。すべてのアプリには異なる間隔があり、Win32アプリはフォントのレンダリング/間隔/テーマに一貫して従いません。すでに修正してください！

guilt 2020年03月17日

デスクトップのWinUiは、ウィンドウ管理の可能性がないため、私にはまったく役に立たない：ウィンドウの表示/非表示、ウィンドウの位置、ウィンドウのサイズ、ドック/ドッキング解除...

alexandrevk 2020年10月02日

@alexandrevkそれはまだプレビューです。ウィンドウAPIの設計を見ましたか？ https://github.com/microsoft/ProjectReunion/issues/157

dotMorten 2020年10月02日

👍1

ウィンドウアナウンスの投稿にリンクしてくれてありがとう@dotMorten ！

@ alexandrevk -WinUIコンテンツを使用してWin32とUWPの両方から、およびウィンドウで他のフレームワーク/スワップチェーンコンテンツを使用するときに、これらのタイプのウィンドウ操作を実行できるようにするReunionのAPIをまとめています。これらのウィンドウ機能の一部は、アクセスを容易にするためにWinUIウィンドウクラスに抽象化される場合がありますが、それはさらに先のことです。ウィンドウ領域の機能仕様はパイプにありますので、しばらくお待ちください。

rkarman 2020年10月02日

個人ユーザー（つまり、非企業/企業）およびc ++としてのみ厳密に言えば、私がただ一人の声で虚空に向かって叫んでいるとしても、これらの新しいUIシステムのいずれかがUWPとそれらが組み込まれているその恐ろしいパッケージングシステムに結び付けられているので、あなたが何をするにしても、それは常に暗闇の中にあるのではないかと心配しています。（WinRTの経験から言えば、WinUIはまだ試していませんが、私にはほとんど同じように見えます）。
確かに、実際にUWPアプリを使用している人はほとんどいないことを知っておく必要がありますか？（実際にはほとんどのafaikに嫌われています）したがって、それが「ネイティブ」と呼ばれるのであれば、なぜそれは本当に「ネイティブ」ではないのですか？つまり、いくつかの＃includes、.libまたは2つをリンクし、STANDARD c ++でアプリをビルドします。
クロスプラットが問題にならないときにQtのようなものに頼らなければならないのは、win32を1000回ラップするのを避けるためだけに、公平を期すために少し古くなってきています。
とにかく、毎日その言語を使用している人からの私の2セントだけですが、おそらくここにコメントする場所はありません。

nl-n 2020年10月19日

@ nl-n WinUIの大きな問題の1つは、UWPアプリとして実行する必要がないことです。実際、これはプレビュー2以降可能です。
_現在_それはmsixとしてパッケージ化する必要がありますが、msixは実際にはアプリを配布（および更新）するためのかなりまともな方法です。

dotMorten 2020年10月19日

👍1

@dotMortenこれは大きな問題の1つです。ストアを介したサイドローディング/インストールが必要です。 Windowsをインストールする前（またはインストールした直後）にストアを無効化/削除しない人を1人も知らないので、どのように配布するのでしょうか。
私はそれがいくぶん修辞的であることを知っていますが、それは要点を果たします。ビルドディレクトリを圧縮して配布（または必要に応じてインストーラー）できるはずです。
次に、互換性の問題があります。非常に多くの人がまだW10のインストールを拒否しているので、それもあります...
しかし、それが3.0の方向性であると聞くのは良いことですが、xamlが嫌いなのと同じくらい、それは歓迎すべき追加です。
たぶん、VSに50GBのUWPワークロード全体をインストールする必要なしにそれを取得できますか？ 🙏（私が知っている誇張ですが、それでも）

このスレッドの冒頭近くで@MarkIngramUKを引用

2019年です。高速なネイティブUIが必要です。また、 CreateWindowExW 、GDIなどを使用してユーザーインターフェイスを作成することを真剣に検討する必要はありません。

これは（おかしなことに）私は文字通り今やらなければならないことです、そしてそうです、それはそれが聞こえるのと同じくらい苦痛です:)

nl-n 2020年10月19日

@ nl-n誰が店について何か言いましたか？ MSIXは、MSIからのインストールとそれほど違いはありません。これは単なるアプリインストーラーです。ダブルクリックしてインストールします。店舗は必要ありません。（巨大な混乱を引き起こすMSIとは対照的に）100％クリーンなアンインストールも保証します

dotMorten 2020年10月19日

ストアを無効化/削除しない人は一人も知りません

しかし、それは一般的ではありません。

それらをどのように配布するのか

まず、ストアを無効にしないようにユーザーに通知する必要があります）

ビルドディレクトリを圧縮して配布できるはずです

MSIXはストアなしでインストールできます。最新のWindowsバージョンでは、ユーザーはそのために何も有効にする必要はありません。もちろん、パッケージが以前に信頼できる証明書で署名されている場合。しかし、ええ、ユーザーがPCからストアを削除した場合、MSIX / APPXAppInstallerも削除できます。その場合、彼らはおそらくアプリケーションのすべての変動性を望んでいません。

非常に多くの人々がまだW10のインストールさえ拒否しています。

それは彼らの選択です。言っ途切れる。

VSでも50GBのUWPワークロード全体

シングルSDKは約3GBです。 10240からすべてをダウンロードする必要はありません。

maxkatz6 2020年10月19日

@ nl-n誰が店について何か言いましたか？ MSIXは、MSIからのインストールとそれほど違いはありません。これは単なるアプリインストーラーです。ダブルクリックしてインストールします。店舗は必要ありません。（巨大な混乱を引き起こすMSIとは対照的に）100％クリーンなアンインストールも保証します

これは、ビジュアルスタジオが「マイクロソフトストア経由でサイドローディング/インストールするために」提供する説明からのもので、msixで見つけた他の情報はmsdnからのものだけです。これは、基本的に、msixパッケージはサンドボックス化/仮想化された「appx」アプリケーションです。、これは、winapiを直接操作するものにとってはかなりキラーです。そして、インストール可能にするためにも署名が必要ですか？...

それはまた、私が推測する交差したワイヤーである可能性があり、あまりにも異なるテミノロジーであり、私はUWPについてあまり知りません。

しかし、それは一般的ではありません。

あなたが思っているよりも一般的で、理由があります😄

とにかく、脱線するつもりはなかったので、とりあえずCreateWindowExWのものを書くことに戻ります🤣

nl-n 2020年10月19日

Microsoft-ui-xaml: WinUI 3.0ロードマップ-入力が必要です！

WinUI 3.0

これは、Windowsアプリとコンポーネントの構築にどのように影響しますか？

新しいアプリの作成

WinUI3.0を既存のWin32アプリに追加する

既存のUWPXamlアプリをWinUI3.0に更新する

一般的な質問

最も参考になるコメント

どのテンプレートに最も興味がありますか？

XAML諸島

Visual Studioまたは別のツールが名前空間を自動的に更新する場合に役立ちますか？

WinUI 3でUWPコンポーネントを使用するための好ましいソリューションは何ですか？

WinUI 3.0を使用するのに最も興奮しているのはどのようなアプリですか？

FluentUIを使用してC ++ MFCアプリを最新化しますか？

全てのコメント220件

どのテンプレートに最も興味がありますか？

XAML諸島

Visual Studioまたは別のツールが名前空間を自動的に更新する場合に役立ちますか？

WinUI 3でUWPコンポーネントを使用するための好ましいソリューションは何ですか？

WinUI 3.0を使用するのに最も興奮しているのはどのようなアプリですか？

FluentUIを使用してC ++ MFCアプリを最新化しますか？

新しいアプリの作成

WinUI3.0を既存のWin32アプリに追加する

既存のUWPXamlアプリをWinUI3.0に更新する

質問への回答

新しいアプリの作成

WinUI3.0を既存のWin32アプリに追加する

既存のUWPXamlアプリをWinUI3.0に更新する

全般的

既存のUWPXamlアプリをWinUI3.0に更新する

全般的

質問への迅速な回答

どのテンプレートに最も興味がありますか？

デスクトップアプリを最新化するためのXamlIslandsをご存知ですか？

Windows 10でのこの拡張された下位互換性により、Xamlアイランドはより便利になりますか？

既存のUWPXamlコンポーネントとWinUI3.0アプリの間の完全な互換性はあなたにとってどれほど重要ですか？

Visual Studioまたは別のツールが名前空間を自動的に更新する場合に役立ちますか？

WinUI 3でUWPコンポーネントを使用するための好ましいソリューションは何ですか？

UIプラットフォームの個人的な見た目

Xamlツールチェーン

より良いウィンドウモデル

データバインディングインターフェイス

Win32APIの考え

UIの一貫性

バイナリサイズ

1 MSはXAMLプロジェクトを支援する必要があります。そうしないと、人々はXAMLプロジェクトが失敗することを恐れます。

2クロスプラットフォームである必要があります。そうしないと、誰もが狂った肥大化したHTMLランタイムで立ち往生することになります。

.NET Core3以降とScottHunter @ .NET Rock

クロスプラットフォームとウェブ

WinUI

HoloLens以降

WinUI3.0の移行期間について

WinUI 4.0 / 3.x / vNextについて

関連する問題