Maui: .NET5用のクロスプラットフォームUX

私はこの考えが好きです。 ただし、実際には、Xamarin.Formsチームによって処理される可能性が高いものです。
たぶん、コアチームは、UXフレームワークを「より良く」するためにいくつかの低レベルの構造を提供するでしょう（CoreFxLabが行うことのように）。

編集：WebAssemblyもサポートされるプラットフォームになることができますか？

私はその考えが好きです。 私を含む人々が、複数の環境で複数のUIテクノロジーに苦しんでいるのを見てきました。

近い将来、 corehostの代わりにネイティブアプリケーションを使用して.netコアがAndroidおよびiOSデバイスに移植されることを確信しています。 そうは言っても、UI機能が必要になります。

2D xplat図面ライブラリ（加速描画を含む）には、たとえばSkiaがあります。

すべてのシナリオで、フルーエントデザインガイドラインと一緒にUIを「説明」する標準的な方法を実現するために、XAML-Standardに移行するのは良いことだと思います。

ただし、.Netチームから、xplat System.Drawing.Xプリミティブを戻すだけでなく、それに時間を費やす計画があるのではないかと疑っています...

@ 4creatorsおそらくこの議論はあなたにとって興味深いものです

@ vibeeshan025 WebAssemblyはJavaScriptに代わるものではないため、コメントのほとんどは実際には意味がありません。 WebAssemblyをDOMに接続するにはJavaScriptが必要です。 したがって、いいえ、何かをwasmにコンパイルして、以前に行ったことをJavaScriptに置き換えることを期待することはできません。 それはそれがどのように機能するかではありません。 UIテクノロジーではありません。

やあみんな、ここに私の5cを置きたいだけです。
System.Drawing.Xは、.NETCoreの開発に不可欠です。 （https://github.com/dotnet/corefx/issues/20325からここに来ました）

UIの時点で-Web（フロントエンド）開発者に質問してください。 彼らはホットリロードのような多くの現代的なトリックを使用しています。
私は個人的に、React / ReactNativeの周りで物事がどのように進んでいるかが好きです。 C＃を使用してReactを記述し、さまざまなプラットフォーム用のさまざまなレンダリングエンジンを使用するのは素晴らしいことです。

FWIW、 MonoはWebAssemblyを採用しているため、Monoで動作する場合は、WebAssemblyで動作します（または動作します）。 それが少なくとも現在の考え/理解です。

また、.NET / MSFTがこのタスクを実行する確率についての意見を反映する必要があります。 彼らの焦点/ IQはすべてコア/内部/フレームワーク/ジャストゲットイットワーキングに置かれています、そして私はそれがもう一年かそこらのためにこのようになると思います。 しかし、誰が知っているか、私は（喜んで）驚かれるかもしれません。

これについての私の見解は、外部の努力が勢いを増し、おそらくMSFT、ala Xamarinによって購入されるが、UIに焦点を当てている（XamarinのコアストレングスIMOであるフレームワーク/ツールに焦点を当てているのとは対照的）ということです。 つまり、 AvaloniaやNoesisのようなもので、それぞれオープンソースチャネルと有料チャネルを介して価値提案を提供します。 ちなみに、これらは両方とも組み込み/サポートMonoです。

Xaml Standardは、Xamarin.Forms用のXAML Standard（Preview）のリリースと、プロジェクトの進行状況に関する長い間延期された更新に伴い、少し移動しました。 PR dotnet / designs＃111には、この提案に利益をもたらす方向に進んでいると思われるプロジェクトの目標について非常に興味深い議論があります。

Silverilghtは、コードがすでに存在する優れたソリューションです

1. オープンソースのSilverlightコード
2. ドットネットコアランタイム上で実行されるMakte
3. Linuxディストリビューションにmoonlightを使用する
4. 「Electron」の代わりとなるdotnetコアを作成して世界を席巻します（メモリ使用量の削減+パフォーマンスの大幅な向上+ xamlの良さ）
5. ネイティブの賛辞（ある日のcorertプロジェクトが光を見る場合）

関連性があることがわかった-http：//platform.uno

@gulshan興味深い、すばらしいプロジェクトです。UWP機能のほとんどをサポートしていますか。わずか4人の貢献者で、非常に短い時間でこのような豊富な機能のセットを実装できました。

@ vibeeshan025彼らはIIRCに資金を提供している会社を持っています...

探求する価値のあるもう1つの未来-HTML / CSS + .net（JS / TSの代わりに）。 すでにここで試されています-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

調査したところ、tcl / tkはすべてのプラットフォームのGUIオプションである可能性があります。 Windowsでtcl / tkが実際のgdiplusのものを呼び出すかどうかはわかりませんが、WPFとWinformsをLinux、Mac、Windows、Android？、iOS ？、そしておそらくWebフォームに持ち込むオプションかもしれません。 tcl / tkがこれらの最後の3つをまだサポートしているかどうかはわかりません。 そうすれば、GUIを単一のコードベースで維持するのがはるかに簡単になります。

使用できるGUIライブラリ：

• TclBridge （無料またはオープンソースではないようです）
• モノのもの（おそらく最高かもしれません）
• イーグル（どれだけ良いかわからない）
• 多分他の人も。

私はcpythonのtkinnerモジュールからtcl / tkを使用するというアイデアを思いつきました。

また、.NETCoreが* .resources（compiled resx）から、または* .resxからのリソースのロードをまだサポートしているかどうかもわかりません。 もしそうなら、それは素晴らしいことです。

Microsoft.DesktopUI.App現在、v3.0.0-alpha-26921-3は、Windows .NET CoreSDKのデイリービルドで利用できます。 LinuxでGDCとDirectXのいくつかの変換レイヤーの下でそれを起動して実行するために何が必要になるのか興味があります。

クロスプラットフォームのUXをはるかに超える必要があり、クロスプラットフォームのアプリケーション開発フレームワークである必要があります。
UXだけに限定するのは間違いです。 少なくとも、SilverLight + RIA-Servicesのすべての機能を備えている必要があります。
何十年も存続する大企業向けの巨大なカスタムシステムを作成する場合、1年（または10年）に追加される要件がわからないため、すべてのオプションを開いたままにしておく必要があります。そのため、閉鎖された限られた環境になります。 UWPのように、ブラウザ内で実行されているものと同じように、考慮されることはありません。 さまざまなプラットフォーム上のすべての機能、API、およびサービスへの完全で無制限のネイティブアクセスが必要です。
また、サーバーとクライアントの両方を作成するシステムを開発する場合、RESTなど（サーバーを作成するときに使用することを目的としており、他の誰かがクライアントを作成する）を使用したくない場合は、代わりに、RIAの精神に基づいて、サーバーAPIを定義し、サーバー上のものと同じ（===）クラスとメソッドを使用してクライアントから自動的に呼び出す必要があります。 すべてを強く入力する必要があります。 データ検証は、SQLサーバー（または使用しているデータソース）のフィールドから取得されたハード制限から始まり、DataAnnotationsによって拡張されます。DataAnnotationsは、（ローカリゼーションを考慮して）クライアントに自動的に伝達されます。

これが必要なことであり、それ以下のものは受け入れられません。
ユビキタスな.NETクライアントアプリケーション開発モデルを作成する

Visual Basic 6がリリースされてから20年になりますが、1998年の生産性には程遠いものです。マイクロソフトは、「マイクロソフトの世界」でより大規模なカスタムシステムをどのように実行するか、そして20年前の生産性をどのように取り戻すかについてのビジョンを提示する必要があります。

マイクロソフトは彼らのたわごとをまとめて、ステップアップし、彼らが持っている責任を受け入れる必要があります。 マイクロソフトは、何十年にもわたってMSテクノロジに多額の投資を行ってきたすべての顧客、パートナー、および開発者が非常に失望しており、MSに対する信頼が非常に低いことを認識する必要があります。 MSは、顧客、パートナー、開発者を尊重し、評判と尊敬を再構築する必要がありますが、Skypeで現在何をしているのか、Skypeの顧客とユーザーをどのように扱っているのかを見ると、これが実現することはほとんど期待できません。

Xamarinのことは忘れてください。マイクロソフトはそれ自体を使用せず、所有しているXamarinを使用するよりも、ElectronJSフレームワーク（Chromium、Node.js、JavaScript、CSSに基づく）のようなシングルスレッドのメモリを大量に消費するフレームワークを使用します。完全に制御でき、プラットフォームごとに実際のネイティブコードを生成します。

@ Bartolomeus-649

Visual Basic 6がリリースされてから20年になりますが、1998年の生産性には程遠いものです。

また、コンピューターとインターネットの使用の広がり、およびプラットフォームの多様性（OS /モビリティ/フォームファクター）は、1998年ほど低くはありません。

あなたが求めているのは、「あなたのすべての問題を解決する誰か」です。 この多様性が存在する理由は複数あります。そうでない場合は、同じオペレーティングシステムで同じデバイスを使用することになります。 「すべてを抽象化する」ことを構築することは困難であり、通常は可能な限り最小の機能セットしか提供しません。 Xamarinは、ここでも最善のアプローチを採用しており、可能な場合はプラットフォーム固有のAPIを使用できます。 ただし、モバイルアプリケーションの優れた抽象化でさえ、生産性の高いデスクトップアプリケーションには役立たない場合があります。

あなたがしている他の点については、それらは主にあなたの特定の仕事に当てはまる個人的な意見や観察であり、一般的に当てはまる発言ではないと思います。

より良いクロスプラットフォーム体験が得られることを願っていますが、それが簡単になるとか、時の試練に耐えられるとは思いません。 WebAssemblyやElectronのようなシェル、PWA、および友人が今後5年間で頼りになるソリューションに進化したとしても、20年間でまったく異なることを行う可能性があります（そして、2018年の状況がいかに簡単であったかについて不満を言うでしょう😂 ）。

マイクロソフトは、私たちの期待とオープンソースのUXフレームワークに応えてきました。 これで、コミュニティプロジェクトを開始して、他のプラットフォームに移植できます。 残念ながら、MSFTは、どのポートでも動作する予定はないと明示的に述べているため、この作業はコミュニティに任されているようです。

@richlander @karelz @AdamYoblick @llongley @kmahone

私の質問は、コミュニティが既存のリポジトリ内のLinuxポートとmacOSポート、つまり別々のブランチで作業できるかどうか、またはそのようなプロジェクトをサポートするために別々のリポジトリを作成する必要があるかどうかです。 既存のリポジトリを使用すると、ポートをMSFT CIインフラストラクチャと統合できるため、これは非常に重要な決定です。そうでない場合は、コミュニティが最初からセットアップする必要があります。

Xamarin.Forms / Avalonia / Platform.Unoがニーズに合わない理由はありますか？ クロスプラットフォームのXAMLを導入する新しい試みは、コミュニティ全体にほとんど価値をもたらさないようです。

4creatorsではなく、私の2¢/インプレッション：

• Xamarin.Formsは、主にモバイルシナリオに焦点を当てているようです。
• Platform.Unoも同様
• アバロニアはまだプライムタイムの準備ができていません。 私がそれを信頼したいと思うにはあまりにもバギーです。 （前回チェックしたとき、デモアプリは現在の安定したリリースに組み込まれていませんでしたが、自信を刺激するものではありませんでした。）

ここでは、WPFまたはWinformsのクロスプラットフォームポートが解決策であると言っているのではありません。 （WinformsのAPI互換のクロスプラットフォームポートは、そもそも素晴らしいアイデアではありません、IMO。WPFについてのコメントはありません。）しかし、既存のソリューションもデスクトップアプリケーション開発に適しているとは思いません。

良い点。 それでも、前者よりもはるかにコストがかかる別のソリューションを構築するのではなく、既存のソリューションの改善に焦点を当てる必要があります。

ちなみに、NoesisGUIの悩みはありますか？

コミュニティはLinuxおよびmacOSポートで動作する可能性があります

@ 4creators自分が所有し、完全に制御できるフォークを作成します。

CIインフラストラクチャ

.NET Core CIインフラストラクチャは、現在のカスタムJenkinsベースのソリューションの代わりに通常のAzureDevOpsを使用する方向に進んでいます。 Azure DevOpsには、活用できるオープンソースプロジェクト向けの無料サービスがあります。

dotnet / winformsについてのみ話す：

WinformsはすでにAzureDevOpsを使用しており、マスターへのPRはPRCIビルドを自動的に実行します。

ただし、すべての作業はフォークで行う必要があると確信しています。 人々が独自のブランチを作成できるようにするためだけに、dotnet / winformsへの書き込みアクセスを許可する予定はありません。 すべての公的貢献により、それは私たちのレポをかなり汚染するでしょう。 :)

ちなみに、NoesisGUIの悩みはありますか？

どういうわけか、NeosisGUIは、さまざまなUIフレームワークで保持しているメモから免れたので、もう一度確認する必要がありました。

私はそれを試すつもりでしたが、私はそれを使用していません。 私の印象では、ゲーム内UIをサポートするためのものであるため、ツールには適していない可能性があります。 （コントロールのリストを見ても、これは悪い仮定かもしれません。）ゲーム内UIの場合、私たちのニーズは将来のコストを正当化するものではありません。 また、何らかの理由でNintendoSwitchをサポートしていません。 （どうやらそれは進行中の作業ですが。）

@ 4creators 2つの問題が混同されているため、この問題のタイトルは間違っていると思います。

まず、 .NetUIフレームワークが他の.Netランタイムの代わりに.NetCoreを使用できるようにします。 WPFは.NetCoreで実行できるようになり、Xamarin.iOS / Android / Mac / GTKを.NetCoreでも実行できるようになりました。 これには、Monoまたは.NetFrameworkを使用する場合と比較してパフォーマンスとメンテナンスの利点があります。

ただし、これを行っても、新しいクロスプラットフォームUIフレームワークは作成されません。 そして、あなたが参照するスレッドとここでのほとんどの投稿は、新しいクロスプラットフォームUIフレームワークの作成に関するものです。 ここでは、ランタイムは主な問題ではありません。 ただし、これらのスレッドは、実際の実装（Xamarin.Formsは主にネイティブコントロールを使用し、Avaloniaは一般的なレンダリングを使用）が対処したクロスプラットフォームUIの実装の実際の問題に対処していないため、非常に混乱しています。

関連するデスクトップコントロール（ハードではない）を追加してXamarin.Formsデスクトップ機能の改善に取り組むか、必要に応じてAvaloniaを安定させることに貢献することをお勧めします。 新しいプラットフォーム（既存の単一プラットフォームのプラットフォームに基づいている場合でも）は、アルファ品質に到達するまでに何年もの作業が必要です。Xamarin.FormsとAvaloniaに貢献するのではなく、やり直すことの唯一の理由は、両方がそれを実行していることです。違う。

後半に同意します。 ただし、 Xamarinチームは、Monoを.NET Coreに置き換えることは、さまざまなワークロード用に最適化されており、重要な重要な統合作業を行う必要があるため、実行不可能であると明確に述べています。

2つの問題が混同されているため、この問題のタイトルは間違っていると思います。

@charlesroddie IMO、そうではありません。 重要なのは、.NET CoreプラットフォームでいくつかのUXフレームワークを利用できるようにすることではなく、DotNetエコシステムの一部であるUXを他の部分と共同で作成し、維持することです。 .NETエコシステムのMSFTの将来の計画は、.NETFrameworkをベースにした.NETCoreであり、新しいアプリケーション開発には推奨されないレガシーWindowsコンポーネントとして非推奨になっています。 現在、Xamarin.Formsを.NET Coreに移植する計画はありません。その理由は、 @ Happypig375が上記に示した理由と、モバイルでのxplatサポートの進め方が決定されていないことです。 ただし、.NET Coreに投資された開発努力により、MSFTで使用される将来のxplatプラットフォームは.NETCoreベースになると思います。

Monoは、Linux上でも多くのワークロードに対して十分に最適化されておらず、そのランタイム上に開発された主要な新機能はもうありません。 BCLは現在、Monoと.NETCoreの間で共有されています。 これは、将来的にモノが非推奨になる可能性が高いことを示しています。

この仮定に基づいて、エコシステムの一部として.NETCoreに基づく単一のUXプラットフォームを持つことは価値があると思います。 したがって、xplatおよびベースのCLI標準であるUXフレームワークではなく、DotNetチームによって設計およびサポートされている.NET Coreエコシステムの一部であるUXフレームワークを要求するため、問題のタイトルは正確に同じです。

.Net Standardは、UIの異なるランタイムが問題なく同じエコシステムの一部になることを保証します。 .Net Coreには他のランタイムよりも利点があり、最終的には減価償却される可能性がありますが、ランタイムをクロスプラットフォームUIへの適切なアプローチを見つけることとリンクさせる必要はありません。 それは質問を複雑にしすぎます。

UXプラットフォームが特定のランタイムに「基づいている」とは言い過ぎです。 @ Happypig375現在、Xamarinが.Net Coreに切り替える計画はありません（代わりに、コードを共有することで、Monoを.Net Coreにより類似させる計画です）。 ただし、WPFを.NetCoreに移行することほど難しいことではありません。

（ところで、Monoには.Net Standard 2.1をサポートするように更新されているため、新しい機能がないというのは事実ではありません。WebAssemblyの現在の作業は、.Net CoreではなくMonoで行われています。ただし、この作業は移植できるため、それは別としてです。 .Net Coreへ。）

WinUI 3.0ロードマップ-入力が必要です！

必要なすべてのコンポーネントがオープンソースになると、この開発提案は新しいxplatの可能性を開く可能性があるようです。

@ 4creatorsの場合は、 MicrosoftUI 1.0と呼ぶことを検討する必要があります。 😆

> * https://github.com/Microsoft/microsoft-ui-xam
-------------------------------------------------^ missing l

この問題はこのリポジトリによって解決されていると思います。