Flutter: ☂UWPのサポートを追加する

おそらく今のところはありません。＃10881を参照してください。

この機能のリクエストに自分自身を含めたいと思います。FlutterがWindows10UWPをサポートしているのは素晴らしいことです。

これは、Xamarin / UWPでターゲットにできるXboxOneもカバーする必要があります

はい、お願いします。 Windowsのサポートは間違いなくゲームチェンジャーになるでしょう。

これは公式ではありませんが、このプロジェクトを確認できます。 https://github.com/google/flutter-desktop-embedding glfwはWindowsでも利用できるので、：wink：を試すことができます。

男...私は本当のxplatが欲しい:)

同じ機能リクエストを入力していました😉...これがある程度の牽引力になることを願っています！

私の家にいくつかのWindows、MacOS、およびChrome OSデバイスを持っているユーザーとして、最新モデルのSurface Proは、毎年一貫して私の毎日のドライバーになります。 SP4のリリース以来。 キャンパス内だけでなく、現在も非常に人気があるようです。 ただし、高品質のUWPアプリの数が少ないことは、私にとって最大の悩みの種であり続けています。

Flutterの優雅さと使いやすさは、開発者や企業が必要とするインセンティブを提供し、Win10をマルチプラットフォーム戦略に含めることができると信じています...そしてその過程で、FlutterをJavaと同様のステータス/人気に昇格させることができれば幸いです。 製品開発用のツールとプラットフォームを選択する際のIT幹部の考慮事項。

Xamarin、IonicなどにはUWPが含まれているのに、なぜFlutterなのですか？

これは非常に広範なアンブレラバグであるため、割り当てを削除します。 特定のサブタスクは個々のバグで追跡され、通常どおり特定の担当者とマイルストーンを取得します。

WindowMVPプロ​​ジェクトからの削除。 UWPはまだターゲットとして評価中であり、最終的にはサポートされる可能性がありますが、最初の焦点はWin32がスコープを制限できるようにすることです。

これは間違いだと思います。 uwpをサポートしていないすべてのプラットフォームは、2020年1月20日の時点でサポートされていません。つまり、準備が整うまでに。

現在、大規模な移行が積極的に行われているため、必要のないときにレガシープラットフォームをサポートすることは無意味です。

唯一の焦点はuwpであり、wpfは無視する必要があります。

uwpをサポートしていないすべてのプラットフォームは、2020年1月20日現在サポートされていません。

Win32 APIに最初に焦点を合わせるという決定は、ターゲットプラットフォームに基づくのではなく、技術的なものです。

wpfは無視する必要があります

現在、WPFを使用する予定はありません。

申し訳ありませんが、win32は無視する必要があります。

どうして？

win32はWindowsプラットフォームでのフラッターを制限するためです。 これを入手するまでに、uwpをサポートしないWindowsプラットフォームはサポートされないため、Uwpはサポートしませんが、win32（完全に再構築が必要なarm64）をサポートしないWindowsプラットフォームがあります。

明確にするために、UWPサポートに向けた取り組みに貢献することに関心のある人は誰でも歓迎され、そうすることをお勧めします。

それでも、win32（完全に再構築が必要なarm64）をサポートしないWindows上のプラットフォームがあります

ARM上のWindows10はWin32をサポートしており、UWPの場合と同様に、ARM64でアプリケーションをコンパイルするだけで済みます。

uwpをサポートしていないすべてのプラットフォームは、2020年1月20日の時点でサポートされていません。つまり、準備が整うまでに。

Windows8.1のサポートは2023年に終了します。UWPはサポートしていません。

@stuartmorganねえ私はUWPサポートに取り組むことに興味があります。

先ほど「UWPをターゲットとして評価中です」とおっしゃっていましたが、何を発見したのか知りたいです。

ありがとう、
-ジェイク

@ Kapranov98フラッターをWindows10ARMに移植する実験を終えたところです。 Win32 / UWPは最も問題の少ないものです。 Dart自体は、WinARMで実行するために大幅な変更が必要です。 dartのARM固有のコードは、posix'ishシステム（ios、android、linuxなど）以外で実行するようには設計されていません。 言うまでもなく、WinARMはThumb-2命令セットのみをサポートし、私が理解しているように、dart jitはARM命令セットを使用します（ただし、これを公式に検証する必要があります）。 ポートを機能させるには、かなりの労力が必要です。

@Jakesaysは、実験の一環として/ appcontainerを有効にしてみましたか？

先ほど「UWPをターゲットとして評価中です」とおっしゃっていましたが、何を発見したのか知りたいです。

すぐに情報を収集し、ここからリンクするための最初のドキュメントを開始します。 ただし、現時点では詳細はあまりありません（最初のドキュメントが存在するようになったら、ARM調査の結果などを追加として歓迎します）。 私が「まだ評価している」と言うとき、私たちはまだそれを将来サポートすることを計画していることを意味し、その一環として、すべてが何をする必要があるかを評価します。 最初のMVPの焦点では​​ないため、現在の活発な調査はあまりありません。

上記のコメントが指摘しているように、それぞれ独自の課題を持つ多くの異なる要素があるため、その一部には特定の側面の分解が含まれます。

Windows 10 Xが問題になった今、この会話は変わりますか？ Win32はWindows10 Xで実行できますが、UWPの方がはるかに適していると思います。 Flutterはデュアルスクリーンデバイスをサポートする予定ですか？ SurfaceDuoとSurfaceNeo？

@nerocui私が理解しているように、DuoはAndroidデバイスなので、Flutterは（少なくとも1つの画面で）問題なく動作すると思います。 Neoが実行しているCPUはわかりませんが、ARMの場合、Flutterは水中でほとんど死んでいます。 Dartは現在、winarmと互換性のあるアセンブリコードを生成しません（winarmはthumb-2命令のみを使用し、IIRC Dartはthumb-2とarm命令の両方を使用します）。 それを機能させるのは簡単なことではありません。

@JakeSaysNeoはIntelLakefieldを使用しているため、x86です。 ストーリーのUWP部分についてもっと心配しています。 Neoのようなモバイルデバイスでは、UWPアプリモデルのマネージドライフサイクルが役立ちます。 Win32はバッテリー寿命には理想的ではありません。 また、Neoのwin32アプリはコンテナーで実行されるため、パフォーマンスが低下します。 UWPをターゲットにすることは、実際には非常に賢明な方法です。 AndroidとiOSの両方がマネージドアプリモデルを実行しているため、UWPはより一貫性をもたらすはずです。 Windows 8はほとんど無視できますが、どの統計も意味のある市場シェアを示していません。

@nerocui OK、それならターゲットUWPにフラッターを取得することは可能であるはずです。 最大の問題は、UWPでのOpenGLサポートの欠如ですが、フラッターの下でANGLEを使用することで解決できるはずです。

UWPを調べていましたが、ターゲットはARM / WinIOTでした。

@JakeSays UWPはほとんどのデバイスで問題ないはずですが、ARM上のWindowsでは頭痛の種です。 皮肉なことに、UWP（もしあれば）フラッターはARMベースのWindowsデバイスでエミュレートされたままでなければなりません。 flutter / uwpポートでどのレベルの完了を達成しましたか？

@nerocui Dartの問題を発見すると、作業を停止しました。

UWPは間違いなく望まれていますが、Win32は間違いなくどこにも行きません。 Microsoftは最近、WindowsストアにWin32サポートを追加すると発表しました。 また、多くのゲームはWin32プラットフォームで開発され続けています。

はい、MicrosoftはストアでWin32アプリを受け入れており、UWPよりも世界中で広く使用されています。 Win32アプリは最高のパフォーマンスを発揮しますが、バッテリー消費量に制限があります。 Win32には、実行中または応答なし（フリーズ）の2つの状態しかありませんが、UWPには、バックグラウンドで実行中、一時停止など、より多くの状態（モバイルデバイスに適しています）があります。

https://docs.microsoft.com/en-us/windows/uwp/launch-resume/app-lifecycle

バッテリーは、ラップトップやWindows10xデバイスなどのモバイルデバイスにとって重要です

これは簡単な会話である必要があります。

1月14日の時点で、UWPをサポートしていないWindowsのサポートされているバージョンはありません。

ストアなどでWindows32アプリを展開することをサポートしていないメジャーバージョンのWindowsがあります。

Win32はレガシープラットフォームです。 古いシステムを維持しているのであれば、確かに、win32がそれです。 しかし、フラッターはすべて新しいコードです。 UWP用に記述でき、Windowsがサポートされているすべての場所でサポートできる場合、レガシーでarmでサポートされていないAPI用に記述する理由はありません。

しかし、フラッターはすべて新しいコードです。

これは実際には当てはまりません。 私は、既存のWin32アプリケーションでFlutterを採用できるようにするために、アプリに追加するシナリオに関心のある人々と話をしました。

UWP用に記述でき、Windowsがサポートされているすべての場所でサポートできる場合、レガシーでarmでサポートされていないAPI用に記述する理由はありません。

上記のコメントは、これらのデバイスのサポートはWin32とUWPの単純な問題ではないことをすでに説明しています。 同様に、一部の展開または配布モデルに必要なサンドボックスの制限は、グリーンフィールド開発ではなく大規模な既存のコードベースであるエンジンに適用されるため、そこにも複雑さがあります。

この議論はまた、サポートされているバージョンではなく、インストールベースを気にする新しいコードを開発している多くの人々がいるという事実を無視しています。 現実には、Windows 7は依然としてインストールベースの非常に重要な部分であり、近い将来に劇的に変化する可能性は低いです。

UWPをサポートするのには十分な理由があります。何度か言ったように、将来的にはUWPをサポートする予定です。 ただし、決定が単純であると主張するために関係するトレードオフを大幅に単純化しすぎても、そのプロセスは加速されません。 繰り返しになりますが、UWPのサポートについて強く感じている人は、UWP埋め込みの開発に貢献することを歓迎します。

@stuartmorganは、winarmのthumb 2のみの制限に対する解決策についての議論を知っていますか？

@stuartmorgan UWPは、win32 / Winforms / WPFアプリケーションで使用できます。 XAMLアイランドは単純で、十分にサポートされています。 Win32は、@ JakeSaysによって作成されたwinarmでは機能しません。 したがって、あなたの議論は意味がなく、レガシーアプリにフラッターを埋め込む場合のレガシーAPIをターゲットとするフラッターの正当化ではありません。

さらにすべての新しい開発のために：

Windows7のインストールベースは石のように落ちています。 WinARMは来年に大規模に爆発しそうです。 Windows 7は、現在のレートで7月までにWindows市場の5％未満（5000万台未満のデバイスで、ソフトウェアにお金を払っていないもの）になり、Windows XPとVistaで底を打っています（ほとんどの場合、組み込みシステムが原因です。サポートが不足しているため、OSを置き換えることなく新しいFlutterベースのアプリケーションを展開することはありません。

あなたの声明とWin32のこのアプローチ全体は、Windowsバージョンがどのように拡張してからドロップするかを理解できないことを示しています（Windows 10の無限のリビジョンの前は、すべてUWPがあるため、このフローは関係ありません）。

1. 新しいバージョンがリリースされました。新しいデバイスでの採用は非常に遅く、消費者向けのスペースでのみ採用されています。
2. （Win 7 => 10）消費者向けデバイスはより迅速に更新され、市場シェアは拡大します。
3. 成長は、新しいバージョンが古いバージョンよりも悪いと主張する変更を好まない技術オタクによって制限されています。
4. 新しいバージョンが消費者分野で過半数の市場シェアを獲得するにつれて、企業は引き続き傍観者になります。
5. マイクロソフトは、消費者が技術オタクを無視し始め、新しいバージョンが古いバージョンよりもはるかに優れていることに気付いたため、古いバージョンのWindowsのサポートとパッチの廃止日を発表しました。 採用率は約50％に達します。
6. 新しいバージョンを好むユーザーからのプレッシャーによるビジネス。 新しいバージョンでより適切に動作するソフトウェア。 そして、廃止の迫り来る締め切りは、交換用ハードウェアに新しいバージョンを展開し始めます。 採用は約60-65％に達します
7. 先見の明のあるITマネージャーは、グループごとに新しいバージョンの制御されたロールアウトを開始します。
8. 締め切りは数か月後に迫り、残りのITマネージャーは、問題を適切に計画していなかったために問題について悩み、問題についてWindows（これらは上からの技術オタクです）を非難します。 サポートの締め切りのラッシュが完了すると、市場シェアは6〜8か月で65％から90％になります。
9. 以前のOS用にハードウェアで設計されたこれらのシステムを交換するコストが高く、通常はハードウェアの交換が必要なため、セキュリティパッチに追加料金を支払うシステムが組み込まれています。
10. 組み込みシステムがハッキングされ始めるので、企業は費用対効果を享受し、ハードウェアの交換を開始します。
11. OSを使用したままになっている人だけが、他に何も使用できない第三世界の国であり、ハッキングされることは問題ではありません。

私たちは今＃8にいます。 開発者が新しいソフトウェアの対象としてWindows7をターゲットにしている場合、開発者は歴史を知らない。 Windows 10のロールアウトは、その前のWindows7のロールアウトの直後です。 ハードウェアリリース間でwin32アプリのフラッターが増加しても、主要なソフトウェアアップデートを展開しないため、＃9をターゲットにする理由はありません。

したがって：

1. XAMLアイランドは、引数の内側にフラッターを使用して、増分win32アプリに対応します。 そして、ソフトウェアを実際に購入する（そして盗まない）人の実質的に0％が、フラッターデスクトップが本番環境で十分に安定する今年の9月までに、XAMLアイランドを使用できないプラットフォームを使用するようになります。
2. 新しいアプリケーションのためにWindows7をターゲットにするための論理的な市場はありません。 歴史と、消費者と企業の間でデスクトップ市場がどのように機能するかを理解している人は、APIに絶対的なブロッカーがない限り、win32で新しいアプリケーションを作成することは絶対にありません（APIが現在ほとんどミラーリングされているかどうかは非常に疑わしいです）。 そして、たとえそうだったとしても、それはWindows 10で実行されているので、そのwin32アプリのフラッターにXAMLアイランドを使用できなかった理由はありません。

したがって、win32を使用するというフラッターの決定はばかげており、Windows市場を完全に理解していないことを示しています。 （悲しいことにGoogleから出てくるのは驚くことではありません）

@ JohnGalt1717私は間違っているかもしれませんが、winarmに関する私の問題はwin32とは何の関係もありませんでした。 また、これは単なる提案ですが、レトリックを少し下げたいと思うかもしれません。 無知のような用語を使用し、広範で根拠のない主張をすることは、あなたの主張を理解することを本当に妨げます。

このスレッドで何度か指摘されているように、Flutterをwinarmで実行するのは簡単な作業ではありません。 Flutterをwin32で実行することは、Flutter自体にほとんど変更を加える必要がないため、かなり簡単な作業です。 特に、FlutterとWindowsに関して私が見た関心のほとんどがデスクトップに関するものであることを考えると、ぶら下がっているフルーツ（win32）から始めるのは理にかなっています。 これは、win32とuwpの違いとはほとんど関係がなく、現在、多くのwin32システムが存在するという事実と関係があります。

@JakeSays WinArmでは、win32アプリをArmのストアに公開することはできません。 （Office以外）コンパイルの問題は別として。

私の主張のどの部分が立証されていませんか？ データは100％私の立場を裏付けています。 Flutter for DesktopがWindowsでリリースできるようになるまでに、UWPを実行できないWindowsマシンの5％以下と、win32アプリを展開できない大量のマシンが存在するようになります。 （つまり、DuoやNeoなどのすべてのARMデバイス、またはWindowsを実行しているもの、および増加しているすべてのサードパーティバージョン。）

WinArm、WinX64、およびWinX86で動作するUWPでフラッターを実行することは、win32よりも難しいことではありません。 また、テキストボックスなどでのスペルチェック、ヒロイックなしのDPIに基づく適切なスケーリング、および箱から出してすぐに使用できるより優れたカルチャサポートを利用できます。 （メディアの再生はwin32よりもはるかに優れており、簡単です。つまり、UWPで3行のコードを使用して、ワイドバインで再生可能なAES暗号化ビデオを簡単に再生できます。win32で同じことを行うのは大規模な取り組みです。キャプションについては言うまでもありません。 。

win32とUWPには、「ぶら下がっている果物」はありません。 UWPはデスクトップです。 それ以外はすべてレガシーデスクトップです。 （明らかにSilverlightを除く）彼らはUWPをバックポートしており、アプリを書き直さない企業をサポートするためのレガシープラットフォーム用のAPIです。 彼らは、既存のアプリケーション（およびその他のUWP）にFlutterを追加することについて概説したユースケースにぴったりのXAMLアイランドを追加しました。

「現在、たくさんのwin32システムがあります」。

9月の図は次のようになります。ウィンドウを実行している人の5％が9月までにロックアウトされます。 その5％のうち、履歴データに基づいてソフトウェアを購入する人はほとんどいません。 10月までに、Windowsユーザーの5％が何らかのARMでそれを使用し、Win32からロックアウトされます。

だからあなたの毒を選んでください。

ただし、そうしている場合は、UWPからロックアウトされているユーザーの数が継続的に少なくなり、Win32からロックアウトされているユーザーの数が継続的に増加することに注意してください。 したがって、MicrosoftはWindows 7のバグを修正する予定はなく、セキュリティのみを修正するため、UWPの代わりにwin32を使用して、とにかく効果的にサポートできない瀕死の市場で、12〜24か月で書き換えを効果的に保証します。それらの代金を支払う人のための更新。 （とにかくフラッター付きのアプリを使用しません）

また、DRMをWin32で動作させるために必要な大幅なリフトのために、Windowsバージョンのビデオプレーヤーが常に大幅に制限されることを保証します。インラインスペルチェッカーがなく、ソフトウェアタッチキーボードを使用している場合は自動修正されません。 、そして文化的なものを正しく理解するのははるかに難しいでしょう。

これは後方思考と呼ばれます。

無知という言葉が気に入らなければ、それは私の問題ではありません。 あなたが事実と歴史を知らなければ、定義上、あなたは無知です。 この場合、有害です。 禁止されていない社会的に正しい単語を使用したい場合は、それでいいのですが、私に何を使用してほしいかを教えてください。検索して置き換えます。

私が実際に間違っているところを教えてください。 そして、私の仮定と予測がわずかにずれている場合でも、時間の経過に伴う私の主張が正しくなく、害が少なく、作業がはるかに多く、バグがはるかに多く、同等に達するのがはるかに困難な代替案よりも少ないことを教えてくださいビデオやスペルチェックなどの時間の経過とともに他のプラットフォーム。どのようにスライスしても、来年のこの時期までに実質的に誰もWindows 7を使用しなくなります。つまり、Flutterはほぼすべての人が100％利用できるようになります。 Win32ではなくUWPで行われた場合の状況。 死んだOSに対応し、WinARMの新しく成長している市場からフラッター開発者を締め出すwin32とは対照的です。

例として、現在、UWPで、現在のビデオプレーヤーのすべての機能に加えて、キャプションとUWPのDRMを数分で作成し、Flutterがその一部として使用できる優れたドキュメントを作成できます。フラッタービデオライブラリ。 彼らが現在フラッタービデオプレーヤーのキャプションとDRMに取り組んでいるという事実を知っています。 そして、私はUWP呼び出し以外は何も知る必要はありません。 つまり、FlutterでUWPを使用して完全なビデオ機能を提供するのは簡単であり、ほとんどすべてのC＃でそれを実行できます。これは、C ++の使用方法、DirectXサーフェスの作成方法、メディアエンコーダー/デコーダー/トランスコーダーの作成方法を知っている人々と比べて、膨大な数の人々です。それをすべて接続します。 （はい、win32では、UWPですぐにサポートされるカスタムライブラリがないと、多くの形式を再生できません）UWP（C ++で記述されている場合でも）とwin32の間で同じ製品を作成するための労力は、約100分の1です。時間の長さ。

同じことがシリアル通信、Bluetooth、位置追跡などにも当てはまります（そして、位置追跡とセンサーAPIは、Windows 10 2020 / H1で、win32になり、以前のバージョンのWindowsでは機能しなくなりました。 10したがって、最新バージョンのWindows 10を使用しているすべての人がこの機能にアクセスできるようにするのに対し、Windows 10のユーザーの100％はこれらのAPIのUWP機能にアクセスできます。）当然のことと思う機能に名前を付けます。 Android / iOS用のフラッター用のプラグインを使用すると、同じことがわかります。それらの実装は、win32と比較してUWPで簡単です。したがって、win32でデスクトップ用のフラッターを作成する場合よりも、UWPで実装する可能性がはるかに高くなります。他のすべての問題。

@JakeSays私が言ったことで、あなたが無礼な（または間違った）何かを示すのをまだ待っています。 私の知る限り、あなたは私が正しく使った言葉が気に入らないだけです。 そして、最も重要なことは、私はそれを抽象的に使用したのであって、あなたや他の誰かに対して個人的に使用したのではありません。 それは広告同音異義語攻撃ではありませんでした。

@stuartmorganは、winarmのthumb 2のみの制限に対する解決策についての議論を知っていますか？

@JakeSays私はDartコンパイラのレベルでの議論をフォローしていません。 ARMのサポートに関する議論については知りませんが、それが起こっていないという意味ではありません。 まだ行っていない場合は、必ずDart機能リクエストを提出する必要があります。

最大の問題は、UWPでのOpenGLサポートの欠如ですが、フラッターの下でANGLEを使用することで解決できるはずです。

現在のWindows埋め込みはすでにANGLEを使用しており、Jamesはその埋め込みに関する作業の初期からUWPサポートの実験を行っているため、すでに順調に進んでいます。

@stuartmorganやります。
そして、ええ、私は窓の埋め込みがANGLEを使用していることを忘れていました。

@ JohnGalt1717 、行動規範を確認してください。 Flutterのコミュニティ基準では、専門的で敬意のある談話が必要であり、人々を歓迎していると感じられるように積極的に最善を尽くしています。

Flutterに取り組んでいる情熱的で才能のある人々がたくさんいて、特定の開発ラインを追求するかしないかについての多くの正当な理由があります。 FlutterをUWPで動作させることに情熱を注いでいると言えます。 他の人もそうです。 また、win32で動作させることに情熱を注いでいる人もいます。 これはオープンソースプロジェクトであり、それを実現するために必要なのは貢献だけです。 それまでの間、代替パスに取り組んでいる寄稿者が無知である、時間を無駄にしている、または後方思考に従事していると示唆することは避けてください。

最後のいくつかの投稿が、このコミュニティで私たちが目指している相互尊重のレベルに上がらない理由がわからない場合は、あまり積極的な役割を果たさないでください。

/ cc @timsneath @Hixie

@dnfieldは、私があなたの主張を理解できないようなことを何もしなかったことを考えれば。 私は事実の歴史と、これを書き直さなければならず、他のプラットフォームと同等にならないようにするための道筋について概説しました。

注意深く読んだ場合、私は誰も無知とは呼びませんでした（これは文字通り事実に気づいておらず、非道なものではなく、それ自体が事実の陳述です）。 （つまり、1月14日の時点で、死んでいてますます無関係な過去を受け入れながら、未来からあなたを切り離すレガシープラットフォームをターゲットにしています）

ですから、私が使用した一般性と同一視することを決定し、それを制御できない場合を除いて、誰かがどのように気分を害するのか理解できません。

あなたがあなたについてなされていない発言に腹を立てていると感じたら、あなたがそのように感じてすみません。 おそらく解決策は、私の立場を真剣に受け止め、論理的に考え、実際にこれらの事実を考慮に入れており、それらを無視していないことを実証することです。また、win32がWindowsでどのように機能するかについて長期的な計画があります。ストアとそのストアでは、win32armアプリの公開は許可されていません。 また、win32を使用するオーバーヘッドにより、この選択で可能な貢献者を90％以上削減できるため、Windowsが常に他のプラットフォームの背後にあることが保証されます。 そうすれば、あなたが無知でも後ろ向きな考えでもないことは明らかであり、したがって私が言ったことはあなたを怒らせてはなりません。

代わりに、私は「私は（私に向けられていない何かについて）気分を害しているので、あなたは間違っています」と言います。 これはどの議論においても議論の余地はありません。

どのように表現されても私の立場のいずれにも対処されていないことを考えると、フラッターがWindowsで実行可能なソリューションであり、iOS、Android、およびWindows用に作成されたアプリケーションの同等性を可能にする可能性が低いことは明らかです。 これにより、この決定の結果として少なくとも2つのフレームワーク（したがって少なくとも2つのプログラミング言語）を使用するように強制されるため、私のチームは次のプロジェクトで計画どおりにフラッターを使用しないようになります。より多くのオーバーヘッドがある場合でも、妥協するのではなく、卓越性の道。

Jamesは、その埋め込みに関する作業の初期からUWPサポートの実験を行ってきたため、すでに順調に進んでいます。

@stuartmorgan @clarkezone UWPでFlutterを実行する公開されている例はありますか？ 非常に早い段階でも試してみたいです。

現在、UWPサポートのプロトタイプに取り組んでいます。 それはまだ非常に早いです（例えば、私はまだピクセルを見ていません）が、私はそれを行う方法についての計画を持っています。 これは、以前に行ったAngleの変更に対するマイナーな修正に依存します。コード化されていますが、Angleにはまだ送信されていません。 免責事項：これは何かを出荷するという約束を構成するものではありませんが、それでも可能なことの探求です。 もう少し興味深い進歩（ピクセルなど）ができたら、ここに報告します。

迅速な対応ありがとうございます@clarkezone

あなたのFDEフォークでuwptestというブランチを見つけました。 それはあなたが実験しているものですか？ このルートであなたの最新情報をフォローしたいと思います。

NP、ええ、それはFDEブランチです。 短期的には、特定の理論を証明するために多くの一時的なハッキングが発生します。

こんにちは、@ clarkezone！ あなたの仕事はマイクロソフトに支えられていますか？ MicrosoftがWindowsアプリを作成するためにFlutterをサポートすることを期待できますか？ もしそうなら、UIファブリックをFlutterで利用できるようにする計画はありますか？

最近、従業員のエンゲージメント/満足度を向上させるために、美しい企業ソフトウェアを構築することにますます関心が集まっていると思います。 私は現在、そのようなプロジェクトの数に取り組んでいます。 つい最近、4大会計事務所の1つ向けにFlutterベースのAndroidアプリケーションをリリースしました。 これらの企業は、内部ソフトウェアにC＃とXamarinを使用する傾向がありますが、職場でのエクスペリエンスモバイルアプリに高品質のUIを期待しています。この場合、Flutterの方が優れたオプションであることがわかります。 同時に、Microsoftは、これらのFlutterアプリを実行できる企業環境で使用される優れたデバイスを製造しているため、これを実現するためにMicrosoftやGoogleからのサポートが増えることを期待しています。

こんにちはLukasz。 私の仕事はMSに支えられておらず、自由な時間に個人的に行われています。 確かにあなたの他の点に同意します。 FWIW私はかなり良い進歩を遂げました、私は出力/レンダリングのためにエンドツーエンドで動作するプロトタイプのFlutterランナーを持っています（まだ入力はありません）、私が現在取り組んでいる大きな/次のタスクは引っ張らずにすべてを正しくリンクすることですuser32 / gdi32などで。このステップは、XBOX、Windows 10xエミュレーターなどのデスクトップ以外のデバイスで実行されるプロトタイプを正常に確認できるようにするために必要であり、（別の）ヤクのひげそりであることが証明されています:-)

Windowsストアを追加してください!!!!

@ daniele777それは私が取り組んできたものです;-)ステータスの更新：84リンカーエラーから10にダウン

手伝ってもいい ？？ プロジェクトを推進する?? 私に仕事をさせることができますか？

@ daniele777は現時点ではありませんが、基本的なPoCは引き続き機能します。 リンカーエラーはクリアされますが、Dartの呼び出しでビルドパイプラインの無限ループに入るビルドの問題があります。 他にも問題があります。 私は数週間休暇をとる予定なので、戻ってPoCフェーズを終えると、少しの間進歩が見られない可能性があります。並列化可能なアイテムがあり、その結果としてここで報告します。

大丈夫大丈夫！

これが早くここに来るのを待つことはできません。 私は現在のwin32ベースのフラッターをWindowsで試しました。 OMGレンダリングは非常にピクセル化されているため、モダンなデザインのように見えますが、10年前のフレームワークを使用して実装されています。 これは、4K画面で見られるとは思われないものです。 UWPアプリや最新のWebアプリのテキストの滑らかなエッジに慣れているため、win32レンダリングは非常に古くなっているように見えます。

@ nerocui -Windowsでピクセル化されたレンダリングが表示されている場合は、UWPに移行しただけでは修正されない別のバグである可能性が非常に高くなります。 再現する手順（およびおそらくピクセル化のスクリーンショット）を使用して、それに関する新しい問題を提出できますか？

@dnfield画像がピクセル化されているわけではありません。 エッジが滑らかに見えないように、ハードウェアアクセラレーションなしでテキストと形状がレンダリングされるだけです（のように見えます）。 これは私が見る多くのwin32プログラムに起こります。 デフォルトのテンプレートページのテキストとボタンだけなので、複製手順はありません。

@nerocuiこれは、win32アプリがUWPと比較して適切なDPIスケーリングを備えていないためです。 win32テキストレンダリングを適切に機能させるために大量の作業を行うことは可能ですが、それは非常に困難です。

@ JohnGalt1717ありがとう、それがまさに私のポイントです。 Flutterは、美しいクロスプラットフォームアプリを構築することですが、win32がアプリを醜くしている唯一の要因です。 これにより、ウィンドウでのフラッターの実装が他のプラットフォームよりも劣って見えるようになります。

win32は、アプリを醜くしている唯一のものです

@dnfieldが言ったように、これが当てはまる可能性は非常に低いです。 フラッターテキストのレンダリングは、Skiaによって完全に（DPI用に適切にスケーリングされた）GLコンテキストで実行されています。 UWP APIを使用してGLコンテキストを作成しても、レンダリングは変更されません。

説明している問題を強調するスクリーンショットを使用してバグを報告してください。

たとえば、アンチエイリアスフラグを無視して埋め込むのと同じくらい簡単かもしれません。 しかし、再現するための手順がなければ、私たちにはわかりません。

https://github.com/flutter/flutter/issues/53308
問題を提出しました。 それが正確/十分な情報であるかどうかを確認してください。

DPIを150％以下に175％に設定し、テキストをロードすると、それが表示されると思います。

レンダリングの詳細については、ここに投稿するのをやめてください。 上記の私の説明によると、これはこの問題とは無関係であり、したがってトピックから外れています。

Windowsストアでのパブリッシュの準備はできていますか？ 連絡あった？

いいえ、ストアに公開する準備ができていません。 ピクセルと入力はXBOXとWindows10xで動作しています。 まだAPIを繰り返しています。 まだ多くの作業が残っています。

私は少し異なるアプローチを考えていました-私はまだ試していませんが、時間があればそうするかもしれません-デスクトップ上のSkia WASM（Blazorによってサポートされる可能性があります）でFlutter for Webを使用するのはどうですか？ I / Oへのアクセスが制限されていることは欠点の1つと考えることができますが、実際のUIレンダリングとイベント処理は期待どおりに機能するはずです。 WindowsはPWAを適切にサポートしているようです（Chrome OSも同様です）。このアプローチは、優れたパフォーマンスを実現しながら、実装が簡単な場合があります。

@lukaszciastkoいいえ、それはもう1つのElectronになります。 FlutterはネイティブWindowsウィンドウ（HWND）にレンダリングする必要があります。これにより、あらゆる種類のネイティブWindowsアプリ（win32、Winforms、wpf）に埋め込むことができます。
IMHO uwpは、Windowsアプリの主要な種類と見なすべきではありません。 MSでさえそうではありませんでした。

@clarkezone Windowsで実行されるアプリを使用できるように、プロジェクトに作業が組み込まれるのを待ちきれません。

そのため、Windowsで実行されるアプリを使用できます

WindowsでFlutterアプリを実行することはすでに可能であり、しばらくの間実行されてきました。 この問題は現在、特にUWPに関するものです。

タイトルを更新して、わかりやすくします。

そのため、Windowsで実行されるアプリを使用できます

WindowsでFlutterアプリを実行することはすでに可能であり、しばらくの間実行されてきました。 この問題は現在、特にUWPに関するものです。

タイトルを更新して、わかりやすくします。

スチュアート、私はWindowsでFlutterアプリを構築して実行する方法に関するドキュメントのどこにも見たことがありません。 この情報がどこにあるか教えていただけますか？

@steskaljaここにいくつかのドキュメントがありますhttps://github.com/flutter/flutter/wiki/Desktop-shells#create
履歴書では、 masterブランチにいて、次のコマンドを実行する必要があります。
flutter config --enable-windows-desktop

あなたがそれを試してみたいプロジェクトで：
flutter create . // Windowsフォルダーを追加しますが、androidおよびiosフォルダーの変更に注意してください。
flutter run -d windows

より具体的には、この開発者に関する私の考え。 プロジェクトユニオンと何らかの関係があることを願っています。 私はフラッターが大好きで、このSDKが重要であることにとても満足しています。 WindowsOSでのWin32アプリの将来について心配しています。

フラッターチームが持っている知識ベースは何ですか？

これが完了したら、C＃でFlutterプラグインを実装し、プラグインからUWPアプリで利用可能なAPI、SDK、NuGetパッケージを使用できるということですか？

@kinex私はあなたが2つが関連していると思う理由を知りたいです。 プラグインに.netサポートを追加するのは比較的簡単で、UWPは必要ありません。 ただし、フラッターの範囲外です。

@JakeSays私の理解から、実行環境（この場合はUWP）は、プラグインの作成方法とプラグインで使用できるものを定義します。 ですから、私の質問に対する答えは「もちろん」かもしれませんが、完全にはわかりません。

Androidプラグインでは、Kotlin（またはJava）と任意のAndroid API、SDK、およびパッケージを使用できます。 iOSプラグインでは、Swift（またはObjective-C）と任意のiOS API、SDK、ポッドを使用できます。 UWPでも同じことが期待でき、これは本当に素晴らしいものになります。

プラグインでC＃を使いやすくすることは、私たちがやろうとしていることですが、UWPのサポートとは直交しています。

UWPランナーは、プラグインでUWP固有のAPIを使用できることを意味しますが、実際にはUWP固有のAPIはほとんどないことを理解しています（たとえば、このドキュメントによると、「デスクトップアプリはユニバーサルWindowsプラットフォームを呼び出すことができるというのが一般的なルールです。 （UWP）API。 "）

@stuartmorganそれは実際には真実ではありません。 最終的にはプロジェクトの再会で真実になるでしょうが、それは今ではそうではなく、それでもレガシーソフトウェア用であり、フラッターの場合のように新しいアプリ用ではありません。 UWPなしでは実行できないことがたくさんあります（つまり、さまざまなビデオコーデック、DRMビデオプレーヤーなどのプラグインにアクセスする）ので、フラッターチームが採用しているアプローチに常に問題がありました。 。 市場でUWPを実行できない（したがって安全な）Microsoftによってサポートされているオペレーティングシステムはありません（つまり、Windows 7をターゲットにするのはばかげており、Flutterの目標ではなく、Windows 10のみをターゲットにする必要があります）。 したがって、これが初日からネイティブUWPであってはならない理由は0つあります。

さらに悪いことに、すべてのWindows 10 Sおよびバリアントはwin32アプリを実行できないため、フラッターはそれらからロックアウトされます。 また、UWPで実行しない限り、ARM / ARM64デバイスからもロックアウトされます。リモートデスクトップを使用してDockerコンテナーでwin32アプリを実行するWindowsXは、結果として、ネイティブUWPアプリよりも大幅に劣るエクスペリエンスになります。グラフィックパフォーマンス。

したがって、google / flutterがWindowsサポートを前向きに考えていた場合、C ++と.NET（Windows開発者の大多数はC ++ではなく.netを使用）を許可し、現在および将来のすべてのWindowsデバイスを最高の状態でサポートするのは初日から完全にUWPになります可能な対話性。 現在のwin32アプローチは、近視眼的であり、十分に研究されていません（これは、Windowsを実行する10億以上のデバイスを考えると、Google内の非常に大きな盲点を示しています）。

SkiaがすでにUWPで実行されていることを考えると、これが事実上の環境ではなく、WindowsでのGoogleの取り組みの100％の焦点とならない理由はほとんどありません。 （実際には、Microsoftと協力して、Xamarinリモートシミュレーター全体を取得し、Windows上のiOSデバイスに直接展開することもできます）

@ JohnGalt1717あなたはすでにこの問題でこの議論を数回行っています。 それを繰り返すことは建設的ではありません。 UWPサポートの開発を加速したい場合は、それに貢献することを歓迎します。

@stuartmorgan c＃の使用についてのあなたの考えを知りたいと思います。 私はそれを機能させる方法についていくつかのアイデアを持っています。

@kinexは、実際にはフラッタープラグインは基本的に単純なAPIを介してフラッターと対話する単なるCコードです。 それらをC＃で作成するには、基本的にCで作成された「.netプラグイン」が必要です。このプラグインはCLRをホストし、フラッターワールドとC＃をブリッジします。 理論的には、WindowsのJava、または言語環境がターゲットオペレーティングシステムで実行できる限り、任意の言語でフラッタープラグインを作成することが可能です。

@JakeSays私はhttps://github.com/flutter/flutter/issues/64958に、C＃に関する現在の考えを提出しました。これは、ここで提出したことがないようです。 C＃に関心のある人は、特にその問題に従う必要があります。

@JakeSaysわかりました、説明してくれてありがとう。 知識がなくても、次のようなものを想定していました。C＃プラグイン（おそらく.NETライブラリとして実装されていますか？）はUWPランナーによって読み込まれ、DartコードはUWPランナープロセスを介してそれらを呼び出すことができます。 この架空のアーキテクチャでは、これらのC＃プラグインは、UWPアプリによってホストされる任意の.NETライブラリと同じAPI、SDK、およびNuGetパッケージにアクセスできます。

とにかく、C＃サポートに関する計画があることを知っておくとよいでしょう。 C ++の代わりにC＃を使用できれば、プラグインの作成者が増え（=プラグインが速くなり）、プラグインがより安定すると思います。

@kinexは、c＃プラグインがライブラリの完全な.netセットとnugetパッケージにアクセスできるという点で正しいです。 c＃コードが実行されると、完全な.net環境（または場合によっては.netコア）で実行されます。

FFIは、プラグイン向けのはるかに軽量なソリューションです。 たとえば、 https：//pub.dev/packages/win32を参照してください。 しかし、これは、表面上はUWPベースのランナーの構築に関する問題のトピックからはほど遠いものです。

@timsneathffiとプラグインは2つの異なる問題を解決すると思います。 iirc ffiでできることには多くの制限があります（たとえば、同期です）。

繰り返しになりますが、C＃プラグイン用に＃64958を提出しました。 C＃に関する議論を続けてください。ただし、UWPについては議論を続けてください。

いいことが起こっている
誰かがマイクロソフトにここでも貢献するように言うべきです

@ airbus5717どういう意味ですか？ マイクロソフトは、ここでの議論に常に貢献しています。

私が取り組んできたFlutterUWP実験の状態に関する2020年9月の更新を共有する価値があると思いました。 これは私が夜と週末にのみ取り組んできた余暇/ベストエフォートプロジェクトであるため、進捗は私が望むよりも遅くなっています。 しかし、私は過去6か月かそこらでかなりの進歩を遂げ、いくつかのシナリオを機能させることができました。

• AppContainerサンドボックスで実行されているWinRT入力APIと組み合わせてCoreWindowを使用する概念実証WinRT Flutterエンベッダー： https ：//github.com/clarkezone/engine
• 対応するテストFlutterUWPランナー（c ++の115行のみ！）とFlutter Galleryを使用したFlutterエクスペリエンスのデモ： https ：//github.com/clarkezone/fluttergalleryuwp
• これらを使用して、MSIXパッケージバージョンのFlutter GalleryをMicrosoftストアに正常に公開し、ストア認定のWAC APIチェックに合格することができました（最終的に:-)）

これを本番環境に対応させるためにやるべきことはまだたくさんあり、どれくらいの時間がかかるかわかりませんが、FlutterUWPが実行可能であることを確かに示しています。

flutter createとのツール統合の方法、ホットリロードと天文台のサポートを機能させる方法など、解決すべき大きな問題がいくつか残っています。 詳細はこちら。

以下の例では、 https：//github.com/miickel/flutter_particle_clockからFlutter Particleクロックのソースを取得し、Windowsを対象としたリリースモードでビルドし、結果のapp.soバイナリを取得して、上記でFlutterGalleryに使用したものと同じFlutterRunnerを使用するUWPを使用して、Microsoft Storeに公開し、XBOXにインストールします。