Flutter: ☂ Unterstützung für UWP hinzugefügt

Wahrscheinlich noch nicht, siehe #10881.

Ich möchte mich dieser Feature-Anfrage anschließen, es wäre großartig, dass Flutter Windows 10 UWP unterstützt.

Dies sollte auch die Xbox One abdecken, auf die Sie in Xamarin/UWP abzielen können

Ja bitte. Windows-Unterstützung wäre definitiv ein Game-Changer.

Dies ist nicht offiziell, aber Sie können dieses Projekt überprüfen. https://github.com/google/flutter-desktop-embedding Ich denke, glfw ist auch unter Windows verfügbar, also kannst du es versuchen :wink:

Mann ... ich will echtes xplat :)

Ich habe gerade die gleiche Feature-Anfrage geschrieben 😉 ... Ich hoffe, das kommt an!

Als Benutzer mit mehreren Windows-, MacOS- und Chrome OS-Geräten in meinem Zuhause ... wird das neueste Modell Surface Pro jedes Jahr konsequent mein täglicher Fahrer; seit der Veröffentlichung des SP4. Scheint auf dem Campus und auch bei der Arbeit jetzt sehr beliebt zu sein. Die spärliche Auswahl an hochwertigen UWP-Apps ist für mich jedoch nach wie vor der größte Wundpunkt.

Ich glaube, dass die Eleganz und Leichtigkeit von Flutter potenziell den Anreiz für Entwickler/Konzerne bieten könnte, Win10 in ihre Multi-Plattform-Strategie einzubeziehen … und Flutter dabei hoffentlich zu einem ähnlichen Status/Beliebtheit wie Java zu befördern; für IT-Führungskräfte bei der Auswahl von Tools und Plattformen für die Produktentwicklung.

Xamarin, Ionic etc. beinhalten UWP, also warum Flutter?

Zuweisung entfernen, da dies ein sehr weit verbreiteter Umbrella-Bug ist. Spezifische Teilaufgaben werden in einzelnen Fehlern verfolgt, die wie üblich bestimmte Beauftragte und Meilensteine ​​erhalten.

Entfernen aus dem Windows MVP-Projekt. Wir evaluieren UWP immer noch als Ziel und werden es wahrscheinlich irgendwann unterstützen, aber der anfängliche Fokus liegt darauf, Win32 zu ermöglichen, den Bereich einzuschränken.

Ich denke, das ist ein Fehler. Alle Plattformen, die uwp nicht unterstützen, werden seit dem 20. Januar 2020 nicht mehr unterstützt, dh bis dies fertig ist.

Es ist sinnlos, eine Legacy-Plattform zu unterstützen, wenn dies nicht erforderlich ist, da die Massenmigration derzeit aggressiv stattfindet.

Der einzige Fokus sollte auf uwp liegen und wpf sollte ignoriert werden.

Alle Plattformen, die UWP nicht unterstützen, werden seit dem 20. Januar 2020 nicht mehr unterstützt

Die Entscheidung, sich zunächst auf Win32-APIs zu konzentrieren, ist technischer Natur und basiert nicht auf Zielplattformen.

wpf sollte ignoriert werden

Derzeit gibt es keine Pläne, WPF zu verwenden.

Tut mir leid, win32 sollte ignoriert werden.

Wieso den?

Weil Win32 das Flattern auf Windows-Plattformen begrenzt. Uwp nicht, denn bis Sie dies herausgebracht haben, werden keine Windows-Plattformen unterstützt, die uwp nicht unterstützen, aber es gibt Plattformen unter Windows, die win32 nicht unterstützen (arm64, das eine vollständige Neuerstellung erfordern würde).

Um es klar zu sagen, jeder, der daran interessiert ist, einen Beitrag zur UWP-Unterstützung zu leisten, ist immer noch willkommen und ermutigt, dies zu tun.

Es gibt jedoch Plattformen unter Windows, die win32 nicht unterstützen (arm64, das einen vollständigen Neuaufbau erfordern würde).

Windows 10 auf ARM unterstützt Win32, Sie müssen die Anwendung nur unter ARM64 kompilieren, wie es bei UWP der Fall ist.

Alle Plattformen, die uwp nicht unterstützen, werden seit dem 20. Januar 2020 nicht mehr unterstützt, dh bis dies fertig ist.

Die Unterstützung für Windows 8.1 endet 2023. UWP wird nicht unterstützt.

@stuartmorgan Hey, ich interessiere mich für die Arbeit an der UWP-Unterstützung.

Sie erwähnten oben „Wir evaluieren UWP immer noch als Ziel“ – ich würde gerne wissen, was Sie entdeckt haben.

Danke,
-Jake

@Kapranov98 Ich habe gerade mit dem Portieren von Flattern auf Windows 10 ARM experimentiert. Win32/UWP ist das geringste Problem. Dart selbst erfordert erhebliche Änderungen, um auf WinARM ausgeführt zu werden. Der ARM-spezifische Code in Dart wurde nie entwickelt, um auf anderen als posixen Systemen (ios, android, linux usw.) zu laufen. Ganz zu schweigen davon, dass WinARM nur den Thumb-2-Befehlssatz unterstützt, und wie ich es verstehe, verwendet der Dart-Jit den ARM-Befehlssatz (obwohl ich dies offiziell bestätigen muss). Den Port zum Laufen zu bringen, wird eine ziemlich beträchtliche Anstrengung sein.

@Jakesays hast du versucht, /appcontainer als Teil deiner Experimente zu aktivieren?

Sie erwähnten oben „Wir evaluieren UWP immer noch als Ziel“ – ich würde gerne wissen, was Sie entdeckt haben.

Ich werde bald ein erstes Dokument starten, um Informationen zu sammeln und von hier aus zu verlinken. Zu diesem Zeitpunkt gibt es jedoch nicht viele Einzelheiten (und sobald das ursprüngliche Dokument vorliegt, wären Dinge wie die Ergebnisse Ihrer ARM-Untersuchung als Ergänzungen sehr willkommen). Wenn ich sage „immer noch prüfend“, meine ich, dass wir immer noch planen, es in der Zukunft zu unterstützen, und als Teil davon evaluieren, was alles getan werden muss. Da dies nicht unser Fokus für ein erstes MVP ist, gibt es derzeit nicht viele aktive Untersuchungen.

Ein Teil davon wird darin bestehen, bestimmte Aspekte aufzuschlüsseln, da es, wie die obigen Kommentare zeigen, eine Reihe verschiedener Elemente gibt, die jeweils ihre eigenen Herausforderungen haben.

Ändert sich diese Konversation jetzt, da Windows 10 X eine Sache ist? Win32 wird unter Windows 10 X laufen können, aber ich denke, UWP wird viel besser passen. Plant Flutter überhaupt Dual-Screen-Geräte zu unterstützen? Surface Duo und Surface Neo?

@nerocui So wie ich es verstehe, ist das Duo ein Android-Gerät, also stelle ich mir vor, Flutter würde gut funktionieren (zumindest auf einem Bildschirm). Ich bin mir nicht sicher, auf welcher CPU der Neo läuft, aber wenn es ARM ist, dann ist Flutter ziemlich tot im Wasser. Dart generiert derzeit keinen kompatiblen Assembler-Code für Winarm (Winarm verwendet ausschließlich Thumb-2-Anweisungen und IIRC Dart verwendet sowohl Thumb-2- als auch Arm-Anweisungen). Es wäre ein nicht triviales Unterfangen, es zum Laufen zu bringen.

@JakeSays Neo verwendet Intel Lakefield, also ist es x86. Ich mache mir mehr Sorgen um den UWP-Teil der Geschichte. Auf einem mobilen Gerät wie Neo ist der verwaltete Lebenszyklus vom UWP-App-Modell praktisch. Win32 ist nicht ideal für die Akkulaufzeit. Außerdem werden Win32-Apps auf Neo in einem Container ausgeführt, was sich nachteilig auf die Leistung auswirkt. Das Targeting von UWP ist eigentlich ein wirklich kluger Schachzug. Sowohl Android als auch iOS führen ein verwaltetes App-Modell aus, UWP sollte mehr Konsistenz bringen. Windows 8 kann so gut wie ignoriert werden, keine der Statistiken zeigt einen nennenswerten Marktanteil.

@nerocui Ok, dann sollte es möglich sein, Flattern zum Zielen von UWP zu bekommen. Das größte Problem ist die fehlende OpenGL-Unterstützung in UWP, aber das sollte durch die Verwendung von ANGLE unter Flattern lösbar sein.

Ich habe nach UWP gesucht, aber mein Ziel war ARM/WinIOT.

@JakeSays UWP sollte für die meisten Geräte in Ordnung sein, aber es bereitet Windows auf ARM Kopfschmerzen. So ironisch es auch ist, UWP-Flattern (falls jemals kommt) muss auf ARM-basierten Windows-Geräten emuliert bleiben. Welchen Fertigstellungsgrad haben Sie für den Flutter/UWP-Port erreicht?

@nerocui Ich habe aufgehört, daran zu arbeiten, als ich das Dart-Problem entdeckte.

Während UWP definitiv erwünscht ist, geht Win32 definitiv nirgendwo hin. Microsoft hat kürzlich angekündigt, dass sie Win32-Unterstützung zum Windows Store hinzufügen. Außerdem werden weiterhin viele Spiele unter der Win32-Plattform entwickelt.

Ja, Microsoft akzeptiert die Win32-App im Store und wird weltweit häufiger verwendet als UWP. Die Win32-App bietet die beste Leistung, hat jedoch eine Begrenzung des Batterieverbrauchs. Win32 hat nur 2 Zustände Running oder Reagiert nicht (Freeze), aber UWP hat mehr Zustände (freundlicher für mobile Geräte) wie Running in background, Suspended.

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

Der Akku ist wichtig für mobile Geräte wie Laptops oder Windows 10x-Geräte

Dies sollte ein einfaches Gespräch sein:

Seit dem 14. Januar gibt es 0 unterstützte Windows-Versionen, die UWP nicht unterstützen.

Es gibt Hauptversionen von Windows, die keine Win32-Apps unterstützen, die ihnen im Store oder anderweitig bereitgestellt werden.

Win32 ist eine Legacy-Plattform. Wenn Sie ein älteres System gewartet haben, ist es sicher win32. Aber Flattern ist ganz neuer Code. Es gibt keinen Grund, es für eine API zu schreiben, die veraltet ist und auf Arm nicht unterstützt wird, wenn es für UWP geschrieben und überall dort unterstützt werden kann, wo Windows unterstützt wird.

Aber Flattern ist ganz neuer Code.

Dies ist nicht wirklich der Fall; Ich habe mit Leuten gesprochen, die an Add-to-App-Szenarien interessiert sind, um die Übernahme von Flutter in bestehende Win32-Anwendungen zu ermöglichen.

Es gibt keinen Grund, es für eine API zu schreiben, die veraltet ist und auf Arm nicht unterstützt wird, wenn es für UWP geschrieben und überall dort unterstützt werden kann, wo Windows unterstützt wird.

Die obigen Kommentare haben bereits erklärt, dass die Unterstützung dieser Geräte keine einfache Frage von Win32 vs. UWP ist. In ähnlicher Weise würden Sandboxing-Einschränkungen, die für einige Bereitstellungen oder Verteilungsmodelle erforderlich sind, für die Engine gelten, bei der es sich um eine große, vorhandene Codebasis und nicht um eine Entwicklung auf der grünen Wiese handelt, sodass auch hier Komplexitäten bestehen.

Dieses Argument ignoriert auch die Tatsache, dass es viele Leute gibt, die neuen Code entwickeln, die sich um die Installationsbasis und nicht um die unterstützten Versionen kümmern. Die Realität ist, dass Windows 7 immer noch einen sehr wesentlichen Teil der Installationsbasis ausmacht, und das wird sich in naher Zukunft wahrscheinlich nicht dramatisch ändern.

Es gibt gute Gründe, UWP zu unterstützen, und wie ich bereits mehrfach gesagt habe, planen wir, es in Zukunft zu unterstützen. Die beteiligten Kompromisse erheblich zu vereinfachen, um zu behaupten, dass die Entscheidung einfach ist, wird diesen Prozess jedoch nicht beschleunigen. Auch hier ist jeder, dem die UWP-Unterstützung am Herzen liegt, sicherlich willkommen, zur Entwicklung einer UWP-Einbettung beizutragen.

@stuartmorgan sind Ihnen irgendwelche Diskussionen über eine Lösung für die Einschränkungen von Winarm nur für Daumen 2 bekannt?

@stuartmorgan UWP kann in win32/Winforms/WPF-Anwendungen verwendet werden. XAML-Inseln sind unkompliziert und werden gut unterstützt. Win32 funktioniert nicht auf Winarm, wie von @JakeSays angegeben. Daher macht Ihr Argument 0 Sinn und ist keine Rechtfertigung für Flattern, das auf eine Legacy-API abzielt, wenn Flattern in Legacy-Apps eingebettet wird.

Weiterhin für alle NEUentwicklungen:

Die Installationsbasis von Windows 7 fällt wie ein Stein. WinARM wird im nächsten Jahr massiv nach oben schießen. Windows 7 wird bis Juli zu aktuellen Preisen < 5 % des Windows-Marktes ausmachen (weniger als 50 Millionen Geräte und keiner von denen, die für Software bezahlen) und genau dort mit Windows XP und Vista (fast ausschließlich aufgrund von eingebetteten Systemen) auf dem Boden liegen Sie würden niemals eine neue Flutter-basierte Anwendung einführen, ohne das Betriebssystem aufgrund mangelnder Unterstützung damit zu ersetzen.

Ihre Aussagen und dieser gesamte Ansatz von Win32 zeigen, dass Sie nicht verstehen, wie Windows-Versionen erweitert und dann gelöscht werden (vor endlosen Revisionen von Windows 10, die alle UWP haben, sodass dieser Fluss irrelevant ist):

1. Neue Version veröffentlicht, sehr langsame Annahme nur auf neuen Geräten und nur im Verbraucherbereich.
2. (Win 7 => 10) Verbrauchergeräte werden schneller aktualisiert und der Marktanteil wächst.
3. Das Wachstum wird von Technikfreaks begrenzt, die keine Änderungen mögen und behaupten, dass die neue Version schlechter als die alte Version ist, obwohl sie es nicht ist.
4. Unternehmen sitzen weiterhin an der Seitenlinie, während die neue Version den Mehrheitsmarktanteil im Verbraucherbereich gewinnt.
5. Microsoft gibt das Einstellungsdatum des Supports und der Patches für die alte Version von Windows bekannt, da die Verbraucher anfangen, Technikfreaks zu ignorieren und feststellen, dass die neue Version erheblich besser ist als die alte. Die Akzeptanz erreicht etwa 50%.
6. Unternehmen durch den Druck von Benutzern, denen die neue Version viel besser gefällt; Software, die mit der neuen Version besser funktioniert; und eine sich abzeichnende Frist für den veralteten Beginn der Bereitstellung einer neuen Version auf Ersatzhardware. Akzeptanz erreicht etwa 60-65%
7. Vorausschauende IT-Manager beginnen mit kontrollierten Rollouts neuer Versionen auf Gruppenbasis.
8. Die Frist droht Monate, und der Rest der IT-Manager rammt es einfach herunter, meckert über Probleme, weil sie es nicht richtig geplant haben, und schlägt Windows (das sind die Technikfreaks von oben) für ihre Probleme. Der Marktanteil steigt in 6-8 Monaten von 65 % auf 90 %, wenn der Ansturm auf die Frist für den Support abgeschlossen ist.
9. Die einzigen verbleibenden Systeme sind eingebettete Systeme, die aufgrund der hohen Kosten für den Ersatz dieser Systeme, die Hardware waren, die für das vorherige Betriebssystem entwickelt wurde und die im Allgemeinen einen Hardwareaustausch erfordern, für Sicherheitspatches extra bezahlen.
10. Eingebettete Systeme werden gehackt, sodass Unternehmen Kostenvorteile erzielen und Hardware ersetzen.
11. Die einzigen Menschen, die das Betriebssystem verwenden, sind Dritte-Welt-Länder, die nichts anderes verwenden können, und gehackt zu werden, ist kein Problem.

Wir sind gerade auf Platz 8. Wenn Entwickler Windows 7 für neue Software ins Visier nehmen, kennen sie die Geschichte nicht. Die Einführung von Windows 10 folgt genau der Einführung von Windows 7 davor. Es gibt keinen Grund, auf Nr. 9 abzuzielen, da sie keine größeren Software-Updates herausbringen, selbst wenn Win32-Apps zwischen Hardware-Releases inkrementell schwanken.

Daher:

1. XAML-Inseln adressieren Ihre inkrementellen Win32-Apps mit dem Flatter-Argument. Und praktisch 0 % der Leute, die tatsächlich Software kaufen (und nicht stehlen), werden bis September dieses Jahres eine Plattform verwenden, die XAML Island nicht verwenden kann, genau dann, wenn Flatter-Desktop stabil genug für die Produktion ist.
2. Es gibt keinen logischen Markt dafür, Windows 7 für eine neue Anwendung anzusprechen. Absolut niemand mit einem Verständnis der Geschichte und der Funktionsweise des Desktop-Marktes zwischen Verbrauchern und Unternehmen würde eine neue Anwendung in win32 schreiben, es sei denn, es gäbe einen absoluten Blocker auf einer API (was höchst zweifelhaft ist, dass die APIs jetzt weitgehend gespiegelt sind). Und selbst wenn sie es täten, würde es unter Windows 10 laufen und somit kein Grund, warum sie XAML Islands nicht für Flattern in dieser Win32-App verwenden könnten.

Daher ist die Flatterentscheidung, win32 zu verwenden, lächerlich und zeigt ein völliges Unverständnis für den Windows-Markt. (was leider nicht überraschend von Google kommt)

@ JohnGalt1717 Ich kann mich irren, aber mein Problem mit winarm hatte nichts mit win32 zu tun. Auch, und das ist nur ein Vorschlag, aber vielleicht möchten Sie die Rhetorik ein wenig zurücknehmen. Die Verwendung von Begriffen wie ignorant und allgemeine, unbegründete Behauptungen erschweren es wirklich, Ihren Standpunkt zu vermitteln.

Flutter auf Winarm zum Laufen zu bringen, ist kein trivialer Aufwand, wie bereits mehrfach in diesem Thread betont wurde. Flutter auf win32 zum Laufen zu bringen ist ein ziemlich triviales Unterfangen, da es nur wenige Änderungen erfordert, um selbst zu flattern. Es ist sinnvoll, mit niedrig hängenden Früchten (Win32) zu beginnen, insbesondere angesichts der Tatsache, dass das meiste Interesse, das ich in Bezug auf Flutter und Windows gesehen habe, sich auf den Desktop bezog. Das hat wenig mit win32 vs. uwp zu tun und mehr mit der Tatsache, dass es JETZT VIELE win32-Systeme gibt.

@JakeSays WinArm lässt nicht zu, dass Win32-Apps im Store auf Arm veröffentlicht werden. (außer Office) Abgesehen von den Problemen beim Kompilieren.

Welcher Teil meiner Behauptungen ist nicht belegt? Die Daten unterstützen zu 100% meine Position. Bis Flutter für den Desktop für die Veröffentlichung unter Windows bereit ist, wird es 5 % oder weniger der Windows-Computer geben, die UWP nicht ausführen können, und eine Tonne, auf der Sie keine Win32-App bereitstellen können. (dh alle ARM-Geräte, einschließlich Duo oder Neo oder was auch immer Windows ausführt, und alle Versionen von Drittanbietern, die hochgefahren werden.)

Flattern unter UWP zum Laufen zu bringen, das auf WinArm und WinX64 und WinX86 funktioniert, sollte nicht schwieriger sein als Win32. Außerdem erhalten Sie eine Rechtschreibprüfung in Textfeldern usw., eine ordnungsgemäße Skalierung basierend auf DPI ohne Heldentaten und eine bessere Kulturunterstützung von Anfang an. (Ganz zu schweigen davon, dass das Abspielen von Medien wesentlich besser und einfacher ist als Win32. Das heißt, ich kann Widevine, Playready, AES-verschlüsseltes Video trivial mit 3 Codezeilen in UWP abspielen. Dasselbe in Win32 zu tun, ist ein gewaltiges Unterfangen. Ganz zu schweigen von Untertiteln .

Es gibt keine "tief hängenden Früchte" mit win32 im Vergleich zu UWP. UWP ist Desktop. Alles andere ist Legacy-Desktop. (außer Silverlight natürlich) Sie portieren UWP und seine APIs für Legacy-Plattformen zurück, um Unternehmen zu unterstützen, die ihre Apps nicht neu schreiben. Sie haben XAML-Inseln genau für den beschriebenen Anwendungsfall hinzugefügt, Flutter zu bestehenden Anwendungen (und allen anderen UWP) hinzuzufügen.

"Es gibt JETZT VIELE Win32-Systeme".

So sieht das Diagramm im September aus: 5 % der Windows-Benutzer würden bis September ausgesperrt sein. Von diesen 5 % kauft praktisch keiner von ihnen Software, die auf historischen Daten basiert. Bis Oktober werden 5 % der Windows-Benutzer es auf irgendeiner Art von ARM verwenden und von Win32 ausgeschlossen werden.

Also wähle dein Gift.

Beachten Sie dabei jedoch, dass die Anzahl der von UWP gesperrten Personen kontinuierlich kleiner wird, während die Anzahl der von Win32 gesperrten Personen kontinuierlich größer wird. Sie garantieren also effektiv eine Neufassung in 12 bis 24 Monaten, wenn Sie win32 anstelle von UWP verwenden, und das alles für einen sterbenden Markt, den Sie sowieso nicht effektiv unterstützen können, da Microsoft keine Fehler in Windows 7 beheben wird, sondern nur Sicherheit Updates für diejenigen, die dafür bezahlen. (die sowieso keine App mit Flattern verwenden wird)

Es stellt auch sicher, dass die Windows-Version des Videoplayers immer stark eingeschränkt ist, da der massive Lift erforderlich ist, um DRM unter Win32 zum Laufen zu bringen, es wird keine Inline-Rechtschreibprüfung oder Autokorrektur für Benutzer einer Software-Touch-Tastatur geben , und Kultursachen werden viel schwieriger zu bekommen sein.

Das nennt man Rückwärtsdenken.

Wenn Sie das Wort ignorant nicht mögen, ist das nicht mein Problem. Wenn Sie die Fakten und die Geschichte nicht kennen, dann sind Sie per Definition unwissend. In diesem Fall schädlich. Wenn Sie ein sozial korrektes Wort verwenden möchten, das nicht verboten wurde, sagen Sie mir, was ich verwenden soll, und ich werde es suchen und ersetzen.

Sag mir, wo ich eigentlich falsch liege. Und selbst wenn meine Annahmen und Prognosen etwas daneben liegen, sagen Sie mir, dass meine Behauptung im Laufe der Zeit nicht richtig und weniger schädlich und weniger Arbeit ist als die Alternative, die viel mehr Arbeit, viel mehr Fehler und eine viel schwierigere Zeit zum Erreichen der Parität bedeutet andere Plattformen im Laufe der Zeit für Dinge wie Video, Rechtschreibprüfung usw. Egal, wie Sie es aufteilen, nächstes Jahr um diese Zeit wird praktisch niemand Windows 7 verwenden. Und das bedeutet, dass Flutter für praktisch jeden zu 100 % verfügbar sein wird Situation, wenn es in UWP und nicht in win32 gemacht wird. Versus win32, das für ein totes Betriebssystem sorgt und Flutter-Entwickler aus dem neuen und wachsenden Markt für WinARM ausschließt.

Als Beispiel kann ich gerade jetzt in UWP einen Videoplayer mit allen Funktionen des aktuellen Videoplayers, plus Untertiteln plus DRM in UWP in wenigen Minuten mit ausgezeichneter Dokumentation erstellen, die von Flutter als Teil des konsumiert werden kann Flattern Videothek. Ich weiß genau, dass sie gerade an Untertiteln und DRM für den Flatter-Videoplayer arbeiten. Und ich muss nichts außer UWP-Aufrufen wissen. Das bedeutet, dass es trivial ist, die volle Videofunktionalität in Flutter mit UWP bereitzustellen, und fast jedes C# kann dies tun, was eine riesige Gruppe von Menschen im Vergleich zu denen darstellt, die wissen, wie man C++ verwendet, DirectX-Oberflächen erstellt und Medien-Encoder/Decoder/Transcoder erstellt und schließe alles an. (Ja, in Win32 können Sie ohne benutzerdefinierte Bibliotheken, die von UWP standardmäßig unterstützt werden, nicht viele Formate wiedergeben.) Der Aufwand, dasselbe Produkt zwischen UWP (auch wenn es in C++ geschrieben ist) und Win32 zu erstellen, beträgt etwa 1/100 Zeitraum.

Dasselbe gilt für serielle Kommunikation, Bluetooth, Standortverfolgung usw. usw. usw. (und Standortverfolgung und Sensor-APIs kommen gerade jetzt, in Windows 10 2020/H1, zu win32 und funktionieren nicht in früheren Versionen von Windows 10, also verlassen Sie sich darauf, dass jeder, der die neueste Version von Windows 10 verwendet, überhaupt Zugriff auf diese Funktionalität hat, im Gegensatz zu 100 % der Benutzer in Windows 10, die Zugriff auf die UWP-Funktionalität für diese APIs haben.) Nennen Sie Ihre Funktionalität, die Sie für selbstverständlich halten mit Plugins für Flutter für Android/iOS und Sie werden dasselbe sehen: Ihre Implementierung ist in UWP im Vergleich zu Win32 trivial und daher ist es viel wahrscheinlicher, dass Sie sie in UWP implementieren, als wenn Sie nebenbei Flutter für den Desktop in Win32 schreiben alle anderen Themen.

@JakeSays Ich warte immer noch darauf, dass du irgendetwas respektloses (oder falsches) mit dem demonstrierst, was ich gesagt habe. Soweit ich das beurteilen kann, magst du nur ein Wort nicht, das ich richtig verwendet habe. Und, was am wichtigsten ist, ich habe es abstrakt verwendet, nicht gegen Sie oder irgendjemand anderen persönlich. Es war kein Ad-Homonym-Angriff.

@stuartmorgan sind Ihnen irgendwelche Diskussionen über eine Lösung für die Einschränkungen von Winarm nur für Daumen 2 bekannt?

@JakeSays Ich habe keine Diskussionen auf der Ebene des Dart-Compilers verfolgt. Mir sind keine Diskussionen über die ARM-Unterstützung bekannt, aber das bedeutet nicht, dass sie nicht stattfinden. Sie sollten auf jeden Fall eine Dart-Feature-Anfrage einreichen, falls Sie dies noch nicht getan haben.

Das größte Problem ist die fehlende OpenGL-Unterstützung in UWP, aber das sollte durch die Verwendung von ANGLE unter Flattern lösbar sein.

Die aktuelle Windows-Einbettung verwendet bereits ANGLE, und James hat seit den frühen Tagen seiner Arbeit an dieser Einbettung mit der UWP-Unterstützung experimentiert, also ist das bereits in vollem Gange.

@stuartmorgan Das werde ich tun.
Und ja, ich hatte vergessen, dass der Windows-Embedder ANGLE verwendet.

@ JohnGalt1717 , lesen Sie bitte unseren Verhaltenskodex . Die Community-Standards von Flutter erfordern einen professionellen und respektvollen Diskurs und das aktive Tun unseres Besten, damit sich die Menschen willkommen fühlen.

Es gibt viele leidenschaftliche und talentierte Leute, die an Flutter arbeiten, und viele gute Gründe, eine bestimmte Entwicklungslinie zu verfolgen oder nicht. Ich kann sagen, Sie sind begeistert davon, dass Flutter an UWP arbeitet. Andere auch. Einige sind auch leidenschaftlich daran interessiert, es unter win32 zum Laufen zu bringen. Dies ist ein Open-Source-Projekt, alles, was es braucht, um es zu verwirklichen, sind Beiträge. In der Zwischenzeit vermeiden Sie es bitte, zu behaupten, dass Mitwirkende, die an alternativen Wegen arbeiten, ignorant sind, Zeit verschwenden oder rückwärts denken.

Wenn Sie nicht verstehen können, warum Ihre letzten Posts nicht das Maß an gegenseitigem Respekt erreichen, das wir in dieser Community anstreben, übernehmen Sie bitte eine weniger aktive Rolle.

/cc @timsneath @Hixie

@dnfield , da ich keines dieser Dinge getan habe, verstehe ich Ihren Standpunkt nicht. Ich habe die Tatsachengeschichte skizziert und einen Weg beschritten, der sicherstellt, dass dies neu geschrieben werden muss und nicht die Parität mit anderen Plattformen erreicht.

Wenn Sie sorgfältig lesen, habe ich zu keinem Zeitpunkt jemanden als ignorant bezeichnet (was wörtlich bedeutet, sich der Tatsachen nicht bewusst zu sein und keine abfällige Feststellung ist, selbst eine Tatsachenfeststellung), noch habe ich jemandem Rückwärtsdenken vorgeworfen. (d. h. auf eine Legacy-Plattform abzielen, die Sie von der Zukunft abschneidet, während Sie ab dem 14. Januar eine tote und zunehmend irrelevante Vergangenheit annehmen)

Ich kann also nicht verstehen, wie jemand beleidigt sein könnte, wenn er sich nicht mit der von mir verwendeten Allgemeingültigkeit identifizieren würde, und ich kann das nicht kontrollieren.

Wenn Sie sich durch Aussagen beleidigt fühlen, die nicht über Sie gemacht wurden, dann tut es mir leid, dass Sie sich so fühlen. Vielleicht besteht die Lösung darin, meine Position ernst zu nehmen und logisch darüber nachzudenken und zu demonstrieren, dass Sie diese Fakten tatsächlich berücksichtigt haben und sie nicht ignorieren, und dass Sie einen langfristigen Plan haben, wie win32 unter Windows funktionieren wird, für die dies erforderlich ist Store und dieser Store erlaubt keine Veröffentlichung von Win32-Arm-Apps. Und dass der Overhead der Verwendung von win32 sicherstellt, dass Windows immer hinter anderen Plattformen zurückbleibt, da Sie mit dieser Wahl Ihre möglichen Mitwirkenden um über 90 % reduzieren. Dann wäre klar, dass Sie weder unwissend noch rückwärts denkend sind und Sie das, was ich gesagt habe, nicht beleidigen sollte.

Stattdessen bekomme ich "Ich bin beleidigt (über etwas, das nicht an mich gerichtet ist), also liegen Sie falsch". Was in keiner Debatte ein Argument ist.

Angesichts der Tatsache, dass keiner meiner Standpunkte angesprochen wurde, egal wie er formuliert wurde, ist es klar, dass Flattern in absehbarer Zeit keine praktikable Lösung für Windows sein und die Parität einer Anwendung ermöglichen wird, die für iOS, Android und Windows geschrieben wurde. Das stellt sicher, dass mein Team Flutter bei unserem nächsten Projekt nicht wie geplant verwenden wird, da Sie uns als Ergebnis dieser Entscheidung zwingen, mindestens 2 Frameworks (und damit mindestens 2 Programmiersprachen) zu verwenden, also könnte ich mich genauso gut für eines entscheiden Pfad der Exzellenz statt Kompromisse, auch wenn es mehr Overhead gibt.

James hat seit den frühen Tagen seiner Arbeit an dieser Einbettung mit UWP-Unterstützung experimentiert, also ist das bereits in vollem Gange.

@stuartmorgan @clarkezone Gibt es ein öffentlich verfügbares Beispiel für die Ausführung von Flutter auf UWP? Ich würde das gerne ausprobieren, auch wenn es noch in einem sehr frühen Stadium ist.

Ich arbeite derzeit an einem Prototyp der UWP-Unterstützung. Es ist noch sehr früh (z. B. habe ich noch keine Pixel gesehen), aber ich habe einen Plan, wie ich es machen soll. Es wird von einer geringfügigen Änderung an einer früheren Angle-Änderung abhängen, die ich vorgenommen habe. Ich habe das codiert, aber Angle noch nicht übermittelt. Haftungsausschluss: Dies stellt keine Verpflichtung dar, etwas zu versenden, es ist immer noch eine Erforschung dessen, was möglich ist. Ich werde hier berichten, wenn ich etwas interessantere Fortschritte gemacht habe (zB Pixel).

Vielen Dank für die prompte Antwort @clarkezone

Ich habe in Ihrem FDE-Fork einen Zweig namens uwptest gefunden . Ist es der, an dem Sie experimentieren? Ich würde gerne Ihre Updates auf dieser Route verfolgen.

NP, ja, das ist die FDE-Zweigstelle. Kurzfristig wird es eine Menge Temp-Hacking geben, um bestimmte Theorien zu beweisen.

Hallo @clarkezone! Darf ich fragen, wird Ihre Arbeit von Microsoft unterstützt? Können wir erwarten, dass Microsoft Flutter bei der Erstellung von Windows-Apps unterstützt? Wenn ja, gibt es Pläne, UI Fabric für Flutter verfügbar zu machen?

Ich denke, in letzter Zeit gab es immer mehr Interesse daran, schöne Unternehmenssoftware zu entwickeln, um das Engagement und die Zufriedenheit der Mitarbeiter zu verbessern. Ich arbeite derzeit an einer Reihe solcher Projekte. Erst kürzlich haben wir eine Flutter-basierte Android-Anwendung für eines der Big Four-Finanzunternehmen veröffentlicht. Während diese Unternehmen dazu neigen, C# und Xamarin für ihre interne Software zu verwenden, erwarten sie eine höhere Qualität der Benutzeroberfläche für ihre mobilen Apps für die Arbeitsplatzerfahrung – in diesem Fall erweist sich Flutter als bessere Option. Gleichzeitig produziert Microsoft großartige Geräte, die in der Unternehmensumgebung verwendet werden und auf denen diese Flutter-Apps ausgeführt werden könnten. Daher wäre es großartig, mehr Unterstützung von Microsoft und/oder Google zu sehen, um dies zu erreichen.

Hallo Lukasz. Meine Arbeit wird nicht von MS unterstützt, sondern auf persönlicher Basis in meiner Freizeit. Stimme deinen anderen Punkten auf jeden Fall zu. FWIW Ich habe einige ziemlich gute Fortschritte gemacht, ich habe einen Flutter-Runner-Prototypen, der End-to-End für Ausgabe/Rendering arbeitet (noch keine Eingabe), die große/nächste Aufgabe, an der ich derzeit arbeite, ist, alles richtig zu verknüpfen, ohne zu ziehen in user32/gdi32 usw.. Dieser Schritt ist erforderlich, um den Prototypen erfolgreich auf Nicht-Desktop-Geräten wie XBOX, Windows 10x-Emulator ausführen zu können, und erweist sich als (eine weitere) Yak-Rasur :-)

Bitte Windows Store hinzufügen !!!!

@daniele777 daran habe ich gearbeitet;-) Statusaktualisierung: von 84 Linker-Fehlern auf 10

Kann ich helfen ?? Projekt verbessern ?? kann mir aufgabe machen?

@ daniele777 nicht an diesem Punkt, immer noch den grundlegenden PoC zum Laufen bringen. Linker-Fehler werden gelöscht, aber es gibt ein Build-Problem beim Aufruf von Dart, der in eine Endlosschleife in der Build-Pipeline gerät. Es gibt auch andere Probleme. Ich werde für ein paar Wochen im Urlaub sein, daher ein bisschen kein Fortschritt, aber sobald ich zurück bin und wir die PoC-Phase hinter uns haben, gibt es möglicherweise parallelisierbare Elemente, über die ich in diesem Fall hier berichten werde.

alles klar alles gute!

Ich kann es kaum erwarten, dass dies früher hier ist. Ich habe das aktuelle Win32-basierte Flattern unter Windows ausprobiert. OMG, das Rendering ist so pixelig, dass es wie ein modernes Design aussah, aber mit einem 10 Jahre alten Framework implementiert wurde. Es ist nicht etwas, was man auf einem 4k-Bildschirm erwarten würde. Gewöhnt an die glatten Kanten von Text in UWP-Apps und modernen Web-Apps, sieht das Win32-Rendering extrem veraltet aus.

@nerocui - Wenn Sie unter Windows pixeliges Rendering sehen, ist dies sehr wahrscheinlich ein anderer Fehler, der nicht nur durch die Migration zu UWP behoben wird. Könnten Sie dazu ein neues Problem mit Schritten zum Reproduzieren (und vielleicht einem Screenshot der Pixelierung) einreichen?

@dnfield Es ist nicht so, dass Bilder verpixelt sind. Nur der Text und die Form werden (scheinbar) ohne Hardwarebeschleunigung gerendert, sodass die Kanten nicht glatt aussehen. Dies passiert mit vielen Win32-Programmen, die ich sehe. Es gibt keine Reproduktionsschritte, da es sich nur um den Text und die Schaltfläche auf der Standardvorlagenseite handelt.

@nerocui Das liegt daran, dass Win32-Apps im Vergleich zu UWP keine richtige DPI-Skalierung haben. Es ist mit einer MENGE Arbeit MÖGLICH, dass das Win32-Text-Rendering richtig funktioniert, aber es ist SEHR schwierig.

@ JohnGalt1717 Danke, das ist genau mein Punkt. Bei Flutter sollte es darum gehen, schöne plattformübergreifende Apps zu erstellen, aber win32 ist das einzige, was die Apps hässlich macht. Dadurch sieht die Flatter-Implementierung unter Windows minderwertig aus als auf anderen Plattformen.

win32 ist das Einzige, was die Apps hässlich macht

Wie @dnfield sagte, ist es äußerst unwahrscheinlich, dass dies der Fall ist. Das Flutter-Text-Rendering wird vollständig von Skia in einem (für DPI richtig skalierten) GL-Kontext durchgeführt. Das Erstellen des GL-Kontexts mit UWP-APIs wird das Rendering nicht ändern.

Bitte melden Sie einen Fehler mit Screenshots, die die von Ihnen beschriebenen Probleme hervorheben.

Es kann so einfach sein, dass zum Beispiel irgendwo ein Anti-Alias-Flag ignoriert wird. Aber ohne Schritte zur Reproduktion können wir das nicht sagen.

https://github.com/flutter/flutter/issues/53308
Eingereichtes Problem. Bitte sehen Sie, ob es genaue/ausreichende Informationen sind.

Ich würde vermuten, dass Sie es sehen werden, wenn Sie Ihre DPI auf 150% oder schlimmer 175% einstellen und etwas Text laden.

Bitte hören Sie hier auf, Details zum Rendern zu posten; Es hat gemäß meiner obigen Erklärung nichts mit diesem Problem zu tun und ist daher nicht zum Thema.

Bereit für die Veröffentlichung im Windows Store? irgendwelche Neuigkeiten?

Nein, nicht bereit für die Veröffentlichung im Store. Pixel und Eingabe funktionieren auf XBOX und Windows 10x. Ich iteriere immer noch auf der API. Es bleibt noch viel Arbeit.

Ich habe über einen etwas anderen Ansatz nachgedacht - ich habe es noch nicht ausprobiert, könnte es aber tun, wenn ich etwas Freizeit finde - wie wäre es mit Flutter for Web mit Skia WASM auf dem Desktop (das von Blazor unterstützt werden könnte)? Ich kann mir vorstellen, dass ein eingeschränkter Zugriff auf E/A ein Nachteil ist, aber das eigentliche UI-Rendering und die Ereignisbehandlung sollten wie erwartet funktionieren. Windows scheint eine gute Unterstützung für PWAs zu haben (ebenso Chrome OS), und dieser Ansatz ist möglicherweise einfacher zu implementieren und erzielt dennoch eine gute Leistung.

@lukaszciastko nein, das wird ein weiteres Elektron sein. Flutter sollte in ein natives Windows-Fenster (HWND) gerendert werden, das wiederum in jede Art von nativer Windows-App (win32, Winforms, wpf) eingebettet werden kann.
IMHO sollte uwp nicht als Haupttyp von Windows-App betrachtet werden. Sogar MS tat es nicht.

@clarkezone Ich kann es kaum erwarten, Ihre Arbeit in das Projekt einfließen zu sehen, damit wir Apps entwickeln können, die unter Windows laufen

So können wir Apps, die unter Windows laufen

Es ist bereits möglich, Flutter-Apps unter Windows auszuführen , und das schon seit einiger Zeit. In diesem Problem geht es jetzt speziell um UWP.

Ich werde den Titel aktualisieren, um das klarer zu machen.

So können wir Apps, die unter Windows laufen

Es ist bereits möglich, Flutter-Apps unter Windows auszuführen, und das schon seit einiger Zeit. In diesem Problem geht es jetzt speziell um UWP.

Ich werde den Titel aktualisieren, um das klarer zu machen.

Stuart, ich habe nirgendwo in der Dokumentation gesehen, wie Flutter-Apps unter Windows erstellt und ausgeführt werden. Können Sie mir bitte sagen, wo ich diese Informationen finden kann?

@steskalja Sie haben hier ein Dokument https://github.com/flutter/flutter/wiki/Desktop-shells#create
Im Lebenslauf müssen Sie sich im Zweig master befinden und Folgendes ausführen:
flutter config --enable-windows-desktop

In dem Projekt, das Sie ausprobieren möchten:
flutter create . // Fügt den Windows-Ordner hinzu, seien Sie vorsichtig mit Änderungen in Android- und iOS-Ordnern,
flutter run -d windows

Genauer gesagt, meine Gedanken zu diesem dev. ist zu hoffen, dass es eine Beziehung zu Project Union gibt. Ich liebe Flattern und bin so glücklich, dass es dieses SDK gibt. Ich mache mir Sorgen um die Zukunft von Win32-Apps im Windows-Betriebssystem.

Über welche Wissensbasis verfügt das Flutter-Team?

Wenn Sie damit fertig sind, bedeutet das, dass wir Flutter-Plug-ins in C# implementieren und von Plug-ins alle APIs, SDKs und NuGet-Pakete verwenden können, die für UWP-Apps verfügbar sind?

@kinex Ich bin neugierig zu wissen, warum Sie denken, dass die beiden verwandt sind. Das Hinzufügen von .net-Unterstützung für Plugins wäre relativ einfach und würde kein UWP erfordern. Es ist jedoch irgendwie außerhalb des Bereichs für Flattern.

@JakeSays Nach meinem Verständnis definiert die Ausführungsumgebung (in diesem Fall UWP), wie die Plugins erstellt werden und was für Plugins verfügbar ist. Vielleicht lautet die Antwort auf meine Frage "natürlich", aber ich bin mir nicht ganz sicher.

In Android-Plugins können Sie Kotlin (oder Java) und alle Android-APIs, SDKs und Pakete verwenden. In iOS-Plugins können Sie Swift (oder Objective-C) und alle iOS-APIs, SDKs und Pods verwenden. Ich würde dasselbe mit UWP erwarten und es würde das wirklich großartig machen.

Wir beabsichtigen, die Verwendung von C# in Plugins zu vereinfachen, stehen aber orthogonal zur UWP-Unterstützung.

Ein UWP-Runner würde bedeuten, UWP-spezifische APIs in Plugins verwenden zu können, aber meines Wissens sind nur sehr wenige APIs tatsächlich UWP-spezifisch (z. B. laut dieser Dokumentation „Die allgemeine Regel lautet, dass eine Desktop-App eine universelle Windows-Plattform aufrufen kann (UWP)-API.")

@stuartmorgan Das stimmt eigentlich nicht. Irgendwann mit der Wiedervereinigung des Projekts WIRD das wahr sein, aber es ist jetzt nicht der Fall, und selbst dann ist es für Legacy-Software, nicht für neue Apps, wie es bei Flattern der Fall wäre. Es gibt eine riesige Menge Dinge, die Sie ohne UWP nicht tun können (dh Zugriff auf die Plugins für verschiedene Video-Codecs, den DRM-Videoplayer usw.), weshalb ich immer ein Problem mit dem Ansatz des Flutter-Teams hatte . Es gibt 0 von Microsoft unterstützte (und damit sichere) Betriebssysteme auf dem Markt, die UWP nicht ausführen können (dh Windows 7 als Ziel zu haben, ist lächerlich und sollte kein Ziel von Flutter sein, nur Windows 10 sollte ein Ziel sein). Daher gibt es 0 Gründe, warum dies nicht vom ersten Tag an natives UWP sein sollte.

Schlimmer noch, alle Windows 10 S und Varianten KÖNNEN KEINE Win32-Apps ausführen, sodass Flattern von diesen gesperrt wird. Sie werden auch von ARM/ARM64-Geräten gesperrt, es sei denn, sie laufen auf UWP und Windows X, das Win32-Apps in einem Docker-Container mit Remote Desktop ausführt, wird daher eine deutlich schlechtere Erfahrung machen als native UWP-Apps, insbesondere wenn es darum geht Grafikleistung.

Wenn Google/Flutter also mit Windows-Unterstützung vorausschauend denken würden, wäre es vom ersten Tag an vollständig UWP, das C++ und .NET zulässt (die überwiegende Mehrheit der Windows-Entwickler verwendet .net, nicht C++) UND alle aktuellen UND zukünftigen Windows-Geräte optimal unterstützt mögliche Interaktivität. Der aktuelle Win32-Ansatz ist sowohl kurzsichtig als auch schlecht erforscht (was auf einen wirklich großen blinden Fleck innerhalb von Google hinweist, der angesichts der Milliarden von Geräten, auf denen Windows ausgeführt wird, besorgniserregend ist).

Angesichts der Tatsache, dass Skia bereits auf UWP läuft, gibt es kaum einen Grund, warum dies nicht die De-facto-Umgebung und der Fokus von 100 % der Bemühungen von Google auf Windows sein sollte. (und wirklich, die Zusammenarbeit mit Microsoft, um die gesamten Xamarin-Remotesimulatoren und die direkte Bereitstellung auf iOS-Geräten unter Windows zum Laufen zu bringen)

@JohnGalt1717 Sie haben dieses Argument bereits mehrmals in dieser Ausgabe vorgebracht; es zu wiederholen ist nicht konstruktiv. Wenn Sie die Entwicklung der UWP-Unterstützung beschleunigen möchten, können Sie gerne dazu beitragen.

@stuartmorgan Ich wäre neugierig, Ihre Gedanken zur Verwendung von c# zu erfahren. Ich habe einige Ideen, wie das funktioniert.

@kinex Flutter-Plugins sind im Wesentlichen nur C-Code, der über eine einfache API mit Flutter interagiert. Um sie in C# zu schreiben, wäre im Grunde ein in C geschriebenes ".net-Plugin" erforderlich, das die CLR hostet und die Flutter-Welt und C# überbrückt. Theoretisch wäre es möglich, Flutter-Plugins in Java unter Windows oder in jeder Sprache zu schreiben, solange die Sprachumgebung auf dem Zielbetriebssystem ausgeführt werden kann.

@JakeSays Ich habe https://github.com/flutter/flutter/issues/64958 mit meinen aktuellen Gedanken zu C# abgelegt, da ich sie hier anscheinend noch nie abgelegt hatte. Jeder, der sich speziell für C# interessiert, sollte diesem Thema folgen.

@JakeSays Ok danke für die Klarstellung. Ohne besseres Wissen habe ich so etwas angenommen: C#-Plugins (vielleicht als .NET-Bibliotheken implementiert?) würden vom UWP-Runner geladen und der Dart-Code könnte sie über den UWP-Runner-Prozess aufrufen. In dieser imaginären Architektur könnten diese C#-Plugins auf dieselben APIs, SDKs und NuGet-Pakete zugreifen wie jede .NET-Bibliothek, die von einer UWP-App gehostet wird.

Wie auch immer, gut zu wissen, dass es Pläne zur C#-Unterstützung gibt. Ich glaube, es wird mehr Plugin-Autoren (= mehr Plugins schneller) und stabilere Plugins geben, wenn C# anstelle von C++ verwendet werden kann.

@kinex Sie haben Recht damit, dass C#-Plug-ins Zugriff auf den vollständigen Satz von .net-Bibliotheken sowie auf Nuget-Pakete haben. Wenn der C#-Code ausgeführt wird, läuft er in einer vollständigen .net-Umgebung (oder .net Core, je nach Fall).

FFI ist eine weitaus leichtere Lösung für Plugins. Siehe zum Beispiel https://pub.dev/packages/win32 . Dies ist jedoch weit vom Thema entfernt für ein Problem, bei dem es angeblich um das Erstellen eines UWP-basierten Runners geht.

@timsneath Ich denke, ffi und Plugins lösen zwei verschiedene Probleme. iirc gibt es viele Einschränkungen bei dem, was Sie mit ffi machen können (zum Beispiel ist es synchron).

Auch hier habe ich #64958 für C#-Plugins eingereicht; Bitte setzen Sie dort alle Diskussionen fort, die sich mit C#, aber nicht mit UWP befassen.

nette Sachen gehen
jemand sollte Microsoft sagen, dass er auch hier einen Beitrag leisten soll

@ airbus5717 was meinst du? Microsoft beteiligt sich hier ständig an der Diskussion.

Ich dachte, es würde sich lohnen, im September 2020 ein Update zum Stand des Flutter-UWP-Experiments zu veröffentlichen, an dem ich gearbeitet habe. Der Fortschritt war langsamer, als mir lieb war, da dies ein Freizeit-/Best-Effort-Projekt ist, an dem ich nur abends und am Wochenende gearbeitet habe. Ich war jedoch in der Lage, in den letzten sechs Monaten oder so anständige Fortschritte zu machen und einige Szenarien zum Laufen zu bringen, nämlich:

• ein Proof-of-Concept-WinRT-Flutter-Embedder, der CoreWindow in Verbindung mit WinRT-Eingabe-APIs verwendet, die in der AppContainer-Sandbox ausgeführt werden: https://github.com/clarkezone/engine
• ein entsprechender Test-UWP-Runner für Flutter (nur 115 Zeilen c++!) mit einer Demo-Flutter-Erfahrung mit Flutter Gallery : https://github.com/clarkezone/fluttergalleryuwp
• Mit diesen konnte ich eine MSIX-gepackte Version von Flutter Gallery erfolgreich im Microsoft Store veröffentlichen und die WAC-API-Prüfungen für die Store-Zertifizierung bestehen (endlich :-))

Es ist noch eine Menge zu tun, um dies produktionsreif zu machen, und ich habe keine Ahnung, wie lange das dauern wird, aber es zeigt auf jeden Fall, dass Flutter UWP realisierbar ist.

Es gibt noch ein paar größere Probleme zu lösen, wie z. B. wie man die Werkzeugintegration mit flutter create durchführt, wie man Hot Reload und Observatory Support zum Laufen bringt und mehr. Näheres hier .

Im folgenden Beispiel konnte ich die Quelle der Flutter-Partikeluhr von https://github.com/miickel/flutter_particle_clock nehmen, sie im Release-Modus für Windows erstellen, die resultierende app.so -Binärdatei nehmen und packen UWP mit demselben Flutter Runner wie oben für Flutter Gallery verwendet, im Microsoft Store veröffentlichen und auf meiner XBOX installieren: