Flutter: ☂ Ajouter le support pour UWP

Probablement pas pour le moment, voir #10881.

Je voudrais m'inclure dans cette demande de fonctionnalité, ce serait génial que Flutter prenne en charge Windows 10 UWP.

Cela devrait également couvrir Xbox One, que vous pouvez cibler dans Xamarin/UWP

Oui s'il vous plaît. La prise en charge de Windows changerait certainement la donne.

ce n'est pas officiel, mais vous pouvez vérifier ce projet. https://github.com/google/flutter-desktop-embedding Je pense que glfw est également disponible sur Windows, vous pouvez donc essayer :wink:

Mec ... je veux du vrai xplat :)

J'étais en train de taper la même demande de fonctionnalité 😉... J'espère que cela aura du succès !

En tant qu'utilisateur de plusieurs appareils Windows, MacOS et Chrome OS chez moi... le dernier modèle de Surface Pro finit toujours par être mon pilote quotidien chaque année ; depuis la sortie du SP4. Semble être extrêmement populaire sur le campus et au travail maintenant aussi. Cependant, la faible sélection d'applications UWP de haute qualité continue d'être le plus gros point sensible pour moi.

Je crois que l'élégance et la facilité de Flutter pourraient potentiellement fournir l'incitation dont les développeurs/corps ont besoin pour inclure Win10 dans leur stratégie multiplateforme... et dans le processus, espérons-le, promouvoir Flutter à un statut/popularité aussi similaire que Java ; à prendre en compte par les responsables informatiques lors de la sélection d'outils et de plates-formes pour le développement de produits.

Xamarin, Ionic etc. incluent UWP, alors pourquoi Flutter ?

Suppression de l'affectation, car il s'agit d'un bogue parapluie très large. Les sous-tâches spécifiques sont suivies dans des bogues individuels, qui recevront des cessionnaires et des jalons spécifiques, comme d'habitude.

Suppression du projet Window MVP. Nous évaluons toujours UWP en tant que cible et le prendrons probablement en charge éventuellement, mais l'objectif initial est de permettre à Win32 de limiter la portée.

Je pense que c'est une erreur. Toutes les plates-formes qui ne prennent pas en charge uwp ne sont plus prises en charge à compter du 20 janvier 2020. C'est-à-dire au moment où cela sera prêt.

Il est inutile de prendre en charge une plate-forme héritée lorsque vous n'y êtes pas obligé, car la migration de masse se produit actuellement de manière agressive.

Le seul objectif doit être uwp et wpf doit être ignoré.

Toutes les plates-formes qui ne prennent pas en charge uwp ne sont plus prises en charge depuis le 20 janvier 2020

La décision de se concentrer d'abord sur les API Win32 est technique et non basée sur les plates-formes cibles.

wpf doit être ignoré

Il n'est actuellement pas prévu d'utiliser WPF.

Désolé, win32 doit être ignoré.

Pourquoi?

Parce que win32 limite le flottement sur les plates-formes Windows. Uwp ne le fait pas car au moment où vous l'aurez, il n'y aura plus de plates-formes Windows prises en charge qui ne prennent pas en charge uwp, mais il existe des plates-formes Windows qui ne prennent pas en charge win32 (arm64 qui nécessiterait une reconstruction complète)

Pour être clair, toute personne intéressée à contribuer aux efforts de soutien UWP est toujours la bienvenue et encouragée à le faire.

pourtant, il existe des plates-formes sur Windows qui ne prennent pas en charge win32 (arm64 qui nécessiterait une reconstruction complète)

Windows 10 sur ARM supporte Win32, il suffit de compiler l'application sous ARM64, comme c'est le cas avec UWP.

Toutes les plates-formes qui ne prennent pas en charge uwp ne sont plus prises en charge à compter du 20 janvier 2020. C'est-à-dire au moment où cela sera prêt.

La prise en charge de Windows 8.1 se termine en 2023. Il ne prend pas en charge UWP.

@stuartmorgan Hé, je suis intéressé à travailler sur le support UWP.

Vous avez mentionné ci-dessus "Nous évaluons toujours UWP comme cible" - j'aimerais savoir ce que vous avez découvert.

Merci,
-Jake

@ Kapranov98 Je viens de terminer l'expérimentation du portage du flottement sur Windows 10 ARM. Win32/UWP est le moindre des problèmes. Dart lui-même nécessite des modifications substantielles pour fonctionner sur WinARM. Le code spécifique ARM dans dart n'a jamais été conçu pour fonctionner sur autre chose que des systèmes posix'ish (ios, android, linux, etc.). Sans oublier que WinARM ne prend en charge que le jeu d'instructions Thumb-2, et si je comprends bien, le dart jit utilise le jeu d'instructions ARM (bien que je doive obtenir une vérification officielle de cela). Faire fonctionner le port représentera un effort assez conséquent.

@Jakesays avez-vous essayé d'activer /appcontainer dans le cadre de votre expérimentation ?

Vous avez mentionné ci-dessus "Nous évaluons toujours UWP comme cible" - j'aimerais savoir ce que vous avez découvert.

Je vais commencer un premier document pour collecter des informations bientôt et le lier à partir d'ici. Il n'y a cependant pas beaucoup de détails à ce stade (et une fois que le document initial existe, des éléments tels que les résultats de votre enquête ARM seraient les bienvenus en tant qu'ajouts). Quand je dis "toujours en cours d'évaluation", je veux dire que nous prévoyons toujours de le soutenir à l'avenir, et dans ce cadre, nous évaluerons ce qui doit être fait. Comme ce n'est pas notre objectif pour un MVP initial, il n'y a pas beaucoup d'enquêtes actives en cours.

Une partie de cela impliquera de décomposer des aspects spécifiques, car, comme le montrent les commentaires ci-dessus, il existe un certain nombre d'éléments différents, chacun avec ses propres défis.

Cette conversation change-t-elle maintenant que Windows 10 X est une chose ? Win32 pourra fonctionner sur Windows 10 X mais je pense que UWP sera bien mieux adapté. Est-ce que Flutter prévoit de prendre en charge les appareils à double écran ? Surface Duo et Surface Neo ?

@nerocui Si je comprends bien, le Duo est un appareil Android, donc j'imagine que Flutter fonctionnerait très bien (au moins sur un écran). Je ne sais pas quel processeur le Neo utilise, mais si c'est ARM, Flutter est à peu près mort dans l'eau. Dart ne génère actuellement pas de code d'assemblage compatible pour winarm (winarm utilise exclusivement les instructions pouce-2, et IIRC Dart utilise à la fois les instructions pouce-2 et bras). Ce serait une entreprise non négligeable de le faire fonctionner.

@JakeSays Neo utilise Intel Lakefield donc c'est x86. Je suis plus préoccupé par la partie UWP de l'histoire. Sur un appareil mobile comme Neo, le cycle de vie géré du modèle d'application UWP sera utile. Win32 ne sera pas idéal pour la durée de vie de la batterie. De plus, les applications win32 sur Neo s'exécuteront dans un conteneur, ce qui est mauvais pour les performances. Cibler UWP est en fait une décision très intelligente. Android et iOS exécutent un modèle d'application géré, UWP devrait apporter plus de cohérence. Windows 8 peut à peu près être ignoré, aucune des statistiques ne montre une part de marché significative.

@nerocui Ok, alors obtenir un flutter pour cibler UWP devrait être possible. Le plus gros problème est le manque de prise en charge d'OpenGL dans UWP, mais cela devrait être résolu en utilisant ANGLE sous le flottement.

Je cherchais UWP mais ma cible était ARM/WinIOT.

@JakeSays UWP devrait convenir à la plupart des appareils, mais c'est un casse-tête pour Windows sur ARM. Aussi ironique soit-il, le flottement UWP (si jamais il arrive) devra rester émulé sur les appareils Windows basés sur ARM. Quel niveau d'achèvement avez-vous atteint pour le port flutter/uwp ?

@nerocui J'ai arrêté de travailler dessus une fois que j'ai découvert le problème Dart.

Bien que UWP soit définitivement souhaité, Win32 ne va certainement nulle part. Microsoft a récemment annoncé qu'il ajoutait la prise en charge de Win32 au Windows Store. En outre, de nombreux jeux continuent d'être développés sous la plate-forme Win32.

Oui, Microsoft accepte l'application Win32 sur Store et l'utilise largement dans le monde que UWP. L'application Win32 offre les meilleures performances, mais sa consommation de batterie est limitée. Win32 n'a que 2 états Running ou Not Responding (Freeze), mais UWP a plus d'états (plus convivial avec les appareils mobiles) tels que Running in background, Suspended.

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

La batterie est importante pour les appareils mobiles comme les ordinateurs portables ou les appareils Windows 10x

Cela devrait être une simple conversation :

Au 14 janvier, 0 versions de Windows prises en charge ne prennent pas en charge UWP.

Il existe des versions majeures de Windows qui ne prennent pas en charge les applications win32 qui leur sont déployées dans le magasin ou autrement.

Win32 est une plate-forme héritée. Si vous entreteniez un système plus ancien, bien sûr, win32 l'est. Mais le flutter est un tout nouveau code. Il n'y a aucune raison de l'écrire pour une API héritée et non prise en charge sur arm, alors qu'elle peut être écrite pour UWP et prise en charge partout où Windows est pris en charge.

Mais le flutter est un tout nouveau code.

Ce n'est pas réellement le cas; J'ai parlé à des personnes intéressées par des scénarios d'ajout à l'application pour permettre l'adoption de Flutter dans les applications Win32 existantes.

Il n'y a aucune raison de l'écrire pour une API héritée et non prise en charge sur arm, alors qu'elle peut être écrite pour UWP et prise en charge partout où Windows est pris en charge.

Les commentaires ci-dessus ont déjà expliqué que la prise en charge de ces appareils n'est pas une simple question de Win32 vs UWP. De même, les restrictions de bac à sable qui sont nécessaires pour certains déploiements ou modèles de distribution s'appliqueraient au moteur, qui est une grande base de code existante, et non un développement sur site vierge, il y a donc également des complexités.

Cet argument ignore également le fait que de nombreuses personnes développant un nouveau code se soucient de la base d'installation et non des versions prises en charge. La réalité est que Windows 7 représente toujours une partie très importante de la base d'installation, et il est peu probable que cela change radicalement dans un avenir immédiat.

Il y a de bonnes raisons de soutenir UWP, et comme je l'ai dit à plusieurs reprises, nous prévoyons de le soutenir à l'avenir. Toutefois, une simplification excessive des compromis impliqués afin de prétendre que la décision est simple n'accélérera pas ce processus. Encore une fois, toute personne qui s'intéresse fortement à la prise en charge d'UWP est certainement la bienvenue pour contribuer au développement d'une intégration UWP.

@stuartmorgan êtes-vous au courant de discussions sur une solution aux restrictions du pouce 2 uniquement de winarm?

@stuartmorgan UWP peut être utilisé dans les applications win32/Winforms/WPF. Les îlots XAML sont simples et bien pris en charge. Win32 ne fonctionne pas sur winarm comme indiqué par @JakeSays. Ainsi, votre argument n'a aucun sens et ne justifie pas le flutter ciblant une API héritée dans le cas de l'intégration du flutter dans les applications héritées.

Plus loin pour tout NOUVEAU développement :

La base d'installation de Windows 7 tombe comme une pierre. WinARM est sur le point de se développer massivement l'année prochaine. Windows 7 représentera moins de 5 % du marché de Windows (moins de 50 millions d'appareils et aucun de ceux qui paient pour les logiciels) d'ici juillet aux taux actuels) et rebondit là-bas avec Windows XP et Vista (presque uniquement en raison des systèmes embarqués où ils ne déploieraient jamais une nouvelle application basée sur Flutter sans remplacer le système d'exploitation par elle en raison d'un manque de support.

Vos déclarations et toute cette approche de Win32 démontrent une incapacité à comprendre comment les versions de Windows se développent puis tombent (avant les révisions sans fin de Windows 10, qui ont toutes UWP, donc ce flux n'est pas pertinent):

1. Nouvelle version publiée, adoption très lente sur les nouveaux appareils uniquement et uniquement dans l'espace grand public.
2. (Win 7 => 10) Les appareils grand public sont mis à jour plus rapidement et la part de marché augmente.
3. La croissance est limitée par les geeks de la technologie qui n'aiment pas le changement en affirmant que la nouvelle version est pire que l'ancienne même si ce n'est pas le cas.
4. Les entreprises continuent de rester à l'écart alors que la nouvelle version gagne une part de marché majoritaire dans l'espace grand public.
5. Microsoft annonce la date de retrait du support et des correctifs pour l'ancienne version de Windows alors que les consommateurs commencent à ignorer les geeks de la technologie et réalisent que la nouvelle version est bien meilleure que l'ancienne. L'adoption atteint environ 50 %.
6. Les entreprises sous la pression des utilisateurs qui aiment mieux la nouvelle version ; un logiciel qui fonctionne mieux sur la nouvelle version ; et une échéance imminente pour l'obsolescence commence à déployer une nouvelle version sur du matériel de remplacement. L'adoption atteint environ 60-65%
7. Les responsables informatiques avant-gardistes commencent à effectuer des déploiements contrôlés de la nouvelle version, groupe par groupe.
8. La date limite se profile dans des mois, et le reste des responsables informatiques se contente de l'enfoncer, de râler sur les problèmes parce qu'ils ne l'ont pas planifié correctement et de critiquer Windows (ce sont les geeks de la technologie d'en haut) pour leurs problèmes. La part de marché passe de 65 % à 90 % en 6 à 8 mois à mesure que la ruée vers la date limite de prise en charge se termine.
9. Les seuls systèmes restants sont les systèmes embarqués qui paient un supplément pour les correctifs de sécurité en raison du coût élevé du remplacement de ces systèmes qui étaient du matériel conçu pour le système d'exploitation précédent et nécessitent généralement un remplacement de matériel.
10. Les systèmes embarqués commencent à être piratés, de sorte que les entreprises réalisent des économies et commencent à remplacer le matériel.
11. Seules les personnes qui utilisent encore le système d'exploitation sont des pays du tiers monde qui ne peuvent rien utiliser d'autre et se faire pirater n'est pas un problème.

Nous sommes actuellement au n°8. Si les développeurs ciblent Windows 7 pour de nouveaux logiciels, ils ignorent l'histoire. Le déploiement de Windows 10 suit exactement le déploiement de Windows 7 avant lui. Il n'y a aucune raison de cibler le numéro 9, car ils ne déploient pas de mises à jour logicielles majeures, même avec un flottement incrémentiel dans les applications win32 entre les versions matérielles.

Ainsi:

1. Les îlots XAML adressent vos applications win32 incrémentielles avec un flottement à l'intérieur de leur argument. Et pratiquement 0 % des personnes qui achètent réellement (et ne volent pas) des logiciels utiliseront une plate-forme qui ne peut pas utiliser l'île XAML d'ici septembre de cette année, à peu près au moment où Flutter Desktop sera suffisamment stable pour la production.
2. Il n'y a pas de marché logique pour cibler Windows 7 pour une nouvelle application. Absolument personne ayant une compréhension de l'histoire et du fonctionnement du marché des ordinateurs de bureau entre les consommateurs et les entreprises n'écrirait une nouvelle application dans win32 à moins qu'il n'y ait un bloqueur absolu sur une API (ce qui est très douteux, les API sont largement reflétées maintenant). Et même s'ils le faisaient, il fonctionnerait sur Windows 10 et donc aucune raison pour laquelle ils ne pourraient pas utiliser les îles XAML pour le flottement dans cette application win32.

Ainsi, la décision flottante d'utiliser win32 est ridicule et montre un échec complet à comprendre le marché Windows. (ce qui n'est pas surprenant en sortant de Google malheureusement)

@ JohnGalt1717 Je me trompe peut-être, mais mon problème avec winarm n'avait rien à voir avec win32. De plus, et ce n'est qu'une suggestion, mais vous voudrez peut-être baisser un peu la rhétorique. Utiliser des termes comme ignorant et faire des affirmations générales et non fondées empêche vraiment de faire passer votre message.

Faire fonctionner Flutter sur winarm n'est pas un effort trivial, comme cela a été souligné à plusieurs reprises dans ce fil. Faire fonctionner Flutter sur win32 est une entreprise assez triviale car elle nécessite peu de changements pour se flotter. Il est logique de commencer avec des fruits à portée de main (win32), d'autant plus que la plupart de l'intérêt que j'ai vu concernant Flutter et Windows concernait le bureau. Cela a peu à voir avec win32 vs uwp et plus à voir avec le fait qu'il existe BEAUCOUP de systèmes win32 MAINTENANT.

@JakeSays WinArm n'autorise pas la publication d'applications win32 dans le magasin sur Arm. (autre qu'Office) Mis à part les problèmes de compilation.

Quelle partie de mes affirmations n'est pas étayée ? Les données soutiennent à 100% ma position. Au moment où Flutter pour ordinateur de bureau sera prêt à être publié sur Windows, il y aura 5 % ou moins de machines Windows qui ne pourront pas exécuter UWP et une tonne sur lesquelles vous ne pourrez pas déployer une application win32. (c'est-à-dire tous les appareils ARM, y compris Duo ou Neo ou tout ce qui exécute Windows, et toutes les versions tierces qui s'accélèrent.)

Faire fonctionner Flutter sous UWP qui fonctionne sur WinArm et WinX64 et WinX86 ne devrait pas être plus difficile que win32. Il vous permet également de vérifier l'orthographe dans les zones de texte, etc., une mise à l'échelle appropriée basée sur le DPI sans héroïsme et une meilleure prise en charge de la culture prête à l'emploi. (sans parler de la lecture multimédia est beaucoup mieux et plus facile que win32. C'est-à-dire que je peux lire une vidéo cryptée Widevine, prête à l'emploi, AES trivialement avec 3 lignes de code dans UWP. Faire la même chose dans win32 est un effort énorme. Pour ne rien dire sur les légendes .

Il n'y a pas de "fruit à portée de main" avec win32 contre UWP. UWP est un ordinateur de bureau. Tout le reste est un ordinateur de bureau hérité. (autre que Silverlight évidemment) Ils sont de retour pour porter UWP et ses API pour les plates-formes héritées pour aider les entreprises à ne pas réécrire leurs applications. Ils ont ajouté des îlots XAML pour exactement le cas d'utilisation décrit de l'ajout de Flutter aux applications existantes (et à toute autre chose UWP).

"Il existe BEAUCOUP de systèmes win32 MAINTENANT".

Voici à quoi ressemble le diagramme en septembre : 5 % des utilisateurs de Windows seraient bloqués d'ici septembre. Sur ces 5 %, pratiquement aucun d'entre eux n'achète de logiciel basé sur des données historiques. D'ici octobre, 5 % des utilisateurs de Windows l'utiliseront sur ARM d'une manière ou d'une autre et seront exclus de Win32.

Alors choisissez votre poison.

Notez cependant que lorsque vous le faites, le nombre de personnes verrouillées hors d'UWP diminuera continuellement, tandis que le nombre de personnes verrouillées hors de Win32 augmentera continuellement. Donc, vous garantissez effectivement une réécriture dans 12 à 24 mois si vous optez pour win32 au lieu d'UWP pour un marché mourant que vous ne pouvez de toute façon pas prendre en charge efficacement, car Microsoft ne va pas corriger les bogues dans Windows 7, seulement la sécurité mises à jour pour ceux qui les paient. (qui n'utilisera pas une application avec flutter de toute façon)

Cela garantit également que la version Windows du lecteur vidéo sera toujours massivement limitée en raison de l'énorme ascenseur nécessaire pour que DRM fonctionne sur Win32, il n'y aura pas de correcteur orthographique en ligne ou de correction automatique pour ceux qui utilisent un clavier tactile logiciel , et les choses culturelles seront beaucoup plus difficiles à maîtriser.

C'est ce qu'on appelle la pensée à l'envers.

Si vous n'aimez pas le mot ignorant, ce n'est pas mon problème. Si vous ne connaissez pas les faits et l'histoire, alors par définition vous êtes ignorant. Dans ce cas, c'est dommageable. Si vous voulez utiliser un mot socialement correct qui n'a pas été interdit, qu'il en soit ainsi, dites-moi ce que vous aimeriez que j'utilise et je ferai une recherche et un remplacement.

Dites-moi où je me trompe réellement. Et même si mes hypothèses et projections sont légèrement erronées, dites-moi comment mon affirmation au fil du temps n'est pas correcte et moins nocive et moins de travail que l'alternative qui est beaucoup plus de travail, beaucoup plus de bugs et un temps beaucoup plus difficile pour atteindre la parité avec d'autres plates-formes au fil du temps pour des choses comme la vidéo, la vérification orthographique, etc. Peu importe comment vous le découpez, à cette époque l'année prochaine pratiquement personne n'utilisera Windows 7. situation si c'est fait dans UWP et non win32. Versus win32 qui s'adresse à un système d'exploitation mort et exclut les développeurs flottants du nouveau marché en pleine croissance de WinARM.

À titre d'exemple, je peux, dès maintenant, dans UWP créer un lecteur vidéo avec toutes les fonctionnalités du lecteur vidéo actuel, plus des sous-titres plus DRM dans UWP en quelques minutes avec une excellente documentation qui peut être consommée par Flutter dans le cadre du vidéothèque flottante. Je sais pertinemment qu'ils travaillent actuellement sur les sous-titres et les DRM pour le lecteur vidéo flottant. Et je n'ai pas besoin de savoir autre chose que les appels UWP. Cela signifie qu'il est trivial de fournir une fonctionnalité vidéo complète dans Flutter avec UWP et presque n'importe quel C # peut le faire, ce qui représente un groupe énorme de personnes par rapport à ceux qui savent utiliser C++, créer des surfaces DirectX et créer des encodeurs/décodeurs/transcodeurs multimédias et accrochez le tout. (oui, dans win32, vous ne pouvez pas lire de nombreux formats sans bibliothèques personnalisées prises en charge par UWP) L'effort pour créer le même produit entre UWP (même s'il est écrit en C++) et win32 est d'environ 1/100e quantité de temps.

Il en va de même pour les communications série, le Bluetooth, le suivi de la localisation, etc. etc. etc. (et les API de suivi de la localisation et de capteur ne sont que maintenant, dans Windows 10 2020/H1, à venir sur win32 et ne fonctionneront pas dans les versions précédentes de Windows 10, vous comptez donc sur tous ceux qui utilisent la toute dernière version de Windows 10 pour avoir même accès à cette fonctionnalité, contre 100 % des utilisateurs de Windows 10 ayant accès à la fonctionnalité UWP pour ces API.) Nommez votre fonctionnalité que vous prenez pour acquise avec des plugins pour flutter pour Android/iOS et vous verrez la même chose : les implémenter est trivial dans UWP par rapport à win32 et donc vous êtes beaucoup plus susceptible de les faire implémenter dans UWP que si vous écrivez flutter pour le bureau dans win32 à part tous les autres problèmes.

@JakeSays J'attends toujours que vous démontriez quoi que ce soit d'irrespectueux (ou de faux) avec ce que j'ai dit. D'après ce que je peux dire, vous n'aimez tout simplement pas un mot, que j'ai utilisé correctement. Et, plus important encore, je l'ai utilisé dans l'abstrait, pas contre vous ou quelqu'un d'autre personnellement. Ce n'était pas une attaque d'homonyme.

@stuartmorgan êtes-vous au courant de discussions sur une solution aux restrictions du pouce 2 uniquement de winarm?

@JakeSays Je n'ai pas suivi les discussions au niveau du compilateur Dart ; Je ne suis pas au courant de discussions autour du support ARM, mais cela ne signifie pas qu'elles ne se produisent pas. Vous devez absolument déposer une demande de fonctionnalité Dart si vous ne l'avez pas déjà fait.

Le plus gros problème est le manque de prise en charge d'OpenGL dans UWP, mais cela devrait être résolu en utilisant ANGLE sous le flottement.

L'intégration Windows actuelle utilise déjà ANGLE, et James expérimente le support UWP depuis les premiers jours de son travail sur cette intégration, donc c'est déjà bien avancé.

@stuartmorgan Je vais le faire.
Et oui, j'avais oublié que l'intégrateur Windows utilise ANGLE.

@JohnGalt1717 , veuillez consulter notre Code de conduite . Les normes communautaires de Flutter exigent un discours professionnel et respectueux, et font activement de notre mieux pour que les gens se sentent les bienvenus.

Il y a beaucoup de personnes passionnées et talentueuses qui travaillent sur Flutter, et beaucoup de bonnes raisons de poursuivre ou non une ligne de développement particulière. Je peux dire que vous êtes passionné par le travail de Flutter sur UWP. Les autres aussi. Certains sont également passionnés par le fait de le faire fonctionner sur win32. Il s'agit d'un projet open source, tout ce qu'il faut pour le réaliser, ce sont des contributions. En attendant, veuillez éviter de suggérer que les contributeurs travaillant sur des voies alternatives sont ignorants, perdent du temps ou sont engagés dans une réflexion à rebours.

Si vous ne voyez pas pourquoi vos derniers messages ne parviennent pas à atteindre le niveau de respect mutuel auquel nous aspirons dans cette communauté, veuillez jouer un rôle moins actif.

/cc @timsneath @Hixie

@dnfield étant donné que je n'ai fait aucune de ces choses, je ne vois pas votre point de vue. J'ai décrit l'histoire factuelle et un chemin emprunté qui garantit que cela devra être réécrit et n'atteindra pas la parité avec d'autres plates-formes.

Si vous lisez attentivement, à aucun moment je n'ai appelé quelqu'un d'ignorant (ce qui signifie littéralement inconscient des faits et n'est pas désobligeant, en soi une déclaration de fait), ni n'ai accusé un individu de penser à l'envers. (C'est-à-dire cibler une plate-forme héritée qui vous coupe du futur tout en embrassant un passé mort et de moins en moins pertinent à partir du 14 janvier)

Donc, je ne comprends pas comment quelqu'un pourrait être offensé à moins qu'il ne décide de s'identifier à la généralité que j'ai utilisée et je ne peux pas contrôler cela.

Si vous vous sentez offensé par des déclarations qui n'ont pas été faites à votre sujet, je suis désolé que vous ressentiez cela. Peut-être que la solution est de prendre ma position au sérieux et d'y réfléchir logiquement et de démontrer que vous avez effectivement pris en compte ces faits et que vous ne les ignorez pas et que vous avez un plan à long terme sur la façon dont win32 va fonctionner sur Windows qui nécessite le store et ce magasin n'autorise pas la publication d'applications arm win32. Et que les frais généraux liés à l'utilisation de win32 garantiront que Windows est toujours en retard sur les autres plates-formes, car vous réduisez vos contributeurs potentiels de plus de 90 % avec ce choix. Il serait alors clair que vous n'êtes ni ignorant ni rétrograde et donc ce que j'ai dit ne devrait pas vous offenser.

Au lieu de cela, je reçois "Je suis offensé (à propos de quelque chose qui ne m'est pas destiné), donc vous avez tort". Ce qui n'est un argument dans aucun débat.

Étant donné qu'aucune de mes positions n'a été abordée, quelle que soit la manière dont elle a été formulée, il est clair que le flottement ne sera probablement pas une solution viable sur Windows et permettra la parité d'une application écrite pour iOS, Android et Windows. Ce qui garantit que mon équipe n'utilisera pas le flutter comme prévu sur notre prochain projet puisque vous nous obligez à utiliser au moins 2 frameworks (et donc au moins 2 langages de programmation) à la suite de cette décision donc autant choisir un chemin de l'excellence au lieu du compromis même s'il y a plus de frais généraux.

James expérimente le support UWP depuis les premiers jours de son travail sur cette intégration, donc c'est déjà bien avancé.

@stuartmorgan @clarkezone Existe-t-il un exemple publiquement disponible d'exécution de Flutter sur UWP ? J'adorerais essayer cela même si c'est à un stade très précoce.

Je travaille actuellement sur un prototype de support UWP. C'est encore très tôt (par exemple, je n'ai pas encore vu de pixels) mais j'ai un plan pour le faire. Cela dépendra d'un amendement mineur à un changement d'angle précédent que j'ai fait. J'ai cela codé mais pas encore soumis à Angle. Avis de non-responsabilité : cela ne constitue pas un engagement à expédier quelque chose, c'est toujours une exploration de ce qui est possible. Je reviendrai ici quand j'aurai fait des progrès un peu plus intéressants (pixels par exemple).

Merci pour la réponse rapide @clarkezone

J'ai trouvé dans votre fork FDE une branche appelée uwptest . Est-ce celui que vous expérimentez ? J'aimerais suivre vos mises à jour sur cet itinéraire.

NP, oui, c'est la branche FDE. À court terme, il y aura beaucoup de piratage temporaire pour prouver certaines théories.

Salut, @clarkezone ! Puis-je demander si votre travail est soutenu par Microsoft ? Pouvons-nous nous attendre à ce que Microsoft prenne en charge Flutter pour créer des applications Windows ? Si oui, est-il prévu de rendre UI Fabric disponible pour Flutter ?

Je pense que, récemment, il y a eu de plus en plus d'intérêt pour la création de beaux logiciels d'entreprise pour améliorer l'engagement/la satisfaction des employés. Je travaille actuellement sur un certain nombre de projets de ce type. Tout récemment, nous avons lancé une application Android basée sur Flutter pour l'une des quatre grandes sociétés financières. Alors que ces entreprises ont tendance à utiliser C # et Xamarin pour leurs logiciels internes, elles s'attendent à une meilleure qualité d'interface utilisateur pour leurs applications mobiles d'expérience de travail - auquel cas, Flutter s'avère être une meilleure option. Dans le même temps, Microsoft produit d'excellents appareils utilisés dans l'environnement d'entreprise qui pourraient exécuter ces applications Flutter, il serait donc formidable de voir plus de soutien de Microsoft et/ou Google pour que cela se produise.

Salut Lucasz. Mon travail n'est pas soutenu par la SEP, il est fait à titre personnel pendant mon temps libre. D'accord sur vos autres points à coup sûr. FWIW J'ai fait de très bons progrès, j'ai un prototype de coureur Flutter qui fonctionne de bout en bout pour la sortie/le rendu (pas encore d'entrée), la grande / prochaine tâche sur laquelle je travaille actuellement est de tout relier correctement sans tirer dans user32/gdi32 etc.. cette étape est nécessaire pour pouvoir voir le prototype fonctionner avec succès sur des appareils non de bureau tels que XBOX, l'émulateur Windows 10x et s'avère être (un autre) rasage de yak :-)

Veuillez ajouter Windows Store !!!!

@ daniele777 c'est ce sur quoi j'ai travaillé ;-) Mise à jour du statut : de 84 erreurs de lien à 10

Puis-je aider ?? pour améliorer le projet ?? peut me faire tâche?

@ daniele777 pas à ce stade, toujours en train de faire fonctionner le PoC de base. Les erreurs de l'éditeur de liens sont effacées, mais il existe un problème de génération dans l'appel de Dart entrant dans une boucle infinie dans le pipeline de génération. Il y a aussi d'autres problèmes. Je vais être en vacances pendant quelques semaines, donc pas de progrès pendant un moment, mais une fois que je suis de retour et que nous avons traversé la phase PoC, il peut y avoir des éléments parallélisables dont je ferai rapport ici dans cette éventualité.

bien tout le meilleur!

Je ne peux pas attendre que cela arrive ici plus tôt. J'ai essayé le flutter basé sur win32 actuel sur Windows. OMG, le rendu est tellement pixélisé qu'il ressemblait à un design moderne mais mis en œuvre à l'aide d'un cadre vieux de 10 ans. Ce n'est pas quelque chose que l'on s'attendrait à voir sur un écran 4k. Étant habitué aux bords lisses du texte dans les applications UWP et les applications Web modernes, le rendu win32 semble extrêmement daté.

@nerocui - si vous voyez un rendu pixélisé sur Windows, il s'agit très probablement d'un bogue différent qui ne sera pas corrigé simplement en migrant vers UWP. Pourriez-vous déposer un nouveau numéro à ce sujet avec des étapes à reproduire (et peut-être une capture d'écran de la pixellisation) ?

@dnfield Ce n'est pas comme si les images étaient pixélisées. C'est juste que le texte et la forme sont rendus (semble) sans accélération matérielle, de sorte que les bords ne semblent pas lisses. Cela arrive à beaucoup de programmes win32 que je vois. Il n'y a pas d'étapes de reproduction, car c'est juste le texte et le bouton sur la page de modèle par défaut.

@nerocui C'est parce que les applications win32 n'ont pas une mise à l'échelle DPI appropriée par rapport à UWP. Il est POSSIBLE avec une tonne de travail pour que le rendu de texte win32 fonctionne correctement, mais c'est TRÈS difficile.

@ JohnGalt1717 Merci, c'est exactement mon point. Flutter devrait consister à créer de belles applications multiplateformes, mais win32 est la seule chose qui rend les applications laides. Cela rend l'implémentation du flottement sur Windows inférieure à celle des autres plates-formes.

win32 est la seule chose qui rend les applications laides

Comme @dnfield l' a dit, il est extrêmement peu probable que ce soit le cas. Le rendu du texte Flutter est entièrement réalisé par Skia, dans un contexte GL (correctement mis à l'échelle pour DPI). La création du contexte GL avec les API UWP ne va pas changer le rendu.

Veuillez signaler un bogue avec des captures d'écran mettant en évidence les problèmes que vous décrivez.

Cela peut être aussi simple que l'incorporation en ignorant un drapeau anti-alias quelque part par exemple. Mais sans étapes pour reproduire, nous ne pouvons pas dire.

https://github.com/flutter/flutter/issues/53308
Problème classé. S'il vous plaît voir si c'est précis/assez d'informations.

Je suppose que si vous réglez votre DPI sur 150% ou pire 175% et que vous chargez du texte, vous le verrez.

Veuillez arrêter de publier ici des détails sur le rendu ; ce n'est pas lié à ce problème, selon mon explication ci-dessus, et donc hors sujet.

prêt à être publié sur Windows Store ? des nouvelles?

Non, pas prêt à publier dans la boutique. Les pixels et l'entrée fonctionnent sur XBOX et Windows 10x. Itération toujours sur l'API. Encore beaucoup de travail restant.

J'ai pensé à une approche légèrement différente - je ne l'ai pas encore essayée mais je pourrais le faire si je trouve du temps libre - qu'en est-il de l'utilisation de Flutter pour le Web avec Skia WASM sur ordinateur (qui pourrait être soutenu par Blazor) ? Je peux penser qu'un accès limité aux E/S est un inconvénient, mais le rendu réel de l'interface utilisateur et la gestion des événements devraient fonctionner comme prévu. Windows semble avoir un bon support pour les PWA (tout comme Chrome OS), et cette approche pourrait être plus facile à mettre en œuvre tout en obtenant de bonnes performances.

@lukaszciastko non, ce sera un électron de plus. Flutter doit être rendu dans une fenêtre Windows native (HWND), qui à son tour peut être intégrée à n'importe quel type d'application Windows native (win32, Winforms, wpf).
IMHO uwp ne doit pas être considéré comme un type principal d'application Windows. Même MS ne l'a pas fait.

@clarkezone J'ai hâte de voir votre travail intégré au projet afin que nous puissions utiliser des applications qui s'exécutent sous Windows

afin que nous puissions les applications qui s'exécutent sur Windows

Il est déjà possible d'exécuter des applications Flutter sur Windows , et ce depuis un certain temps. Ce problème concerne désormais spécifiquement UWP.

Je mettrai à jour le titre pour que cela soit plus clair.

afin que nous puissions les applications qui s'exécutent sur Windows

Il est déjà possible d'exécuter des applications Flutter sur Windows, et ce depuis un certain temps. Ce problème concerne désormais spécifiquement UWP.

Je mettrai à jour le titre pour que cela soit plus clair.

Stuart, je n'ai vu nulle part dans la documentation comment créer et exécuter des applications Flutter sous Windows. Pouvez-vous s'il vous plaît me dire où je peux trouver cette information?

@tesskalja Vous avez un document ici https://github.com/flutter/flutter/wiki/Desktop-shells#create
En résumé, vous devez être dans la branche master et lancer :
flutter config --enable-windows-desktop

Dans le projet que vous voulez essayer :
flutter create . // Ajoutera le dossier windows, soyez prudent avec les changements dans les dossiers android et ios,
flutter run -d windows

Plus précisément, ma réflexion autour de ce dev. est d'espérer qu'il existe une relation avec Project Union. J'adore le flutter et je suis tellement heureux que ce SDK soit une chose. Je suis préoccupé par l'avenir des applications Win32 dans le système d'exploitation Windows.

Quelle est la base de connaissances dont dispose l'équipe Flutter ?

Lorsque vous avez terminé, cela signifie-t-il que nous pouvons implémenter des plugins Flutter en C # et utiliser à partir de plugins toutes les API, SDK et packages NuGet disponibles pour les applications UWP ?

@kinex Je suis curieux de savoir pourquoi vous pensez que les deux sont liés. L'ajout de la prise en charge de .net pour les plugins serait relativement simple et ne nécessiterait pas UWP. C'est un peu hors de portée pour le flottement cependant.

@JakeSays D'après ce que j'ai compris, l'environnement d'exécution (UWP dans ce cas) définit comment les plugins sont créés et ce qui est disponible pour les plugins. Alors peut-être que la réponse à ma question est "bien sûr", mais je ne suis pas tout à fait sûr.

Dans les plugins Android, vous pouvez utiliser Kotlin (ou Java) et toutes les API, SDK et packages Android. Dans les plugins iOS, vous pouvez utiliser Swift (ou Objective-C) et toutes les API, SDK et Pods iOS. Je m'attendrais à la même chose avec UWP et cela rendrait cela vraiment génial.

Faciliter l'utilisation de C # dans les plugins est quelque chose que nous avons l'intention de faire, mais c'est orthogonal au support UWP.

Un exécuteur UWP signifierait pouvoir utiliser des API spécifiques à UWP dans les plugins, mais je crois comprendre que très peu d'API sont réellement spécifiques à UWP (par exemple, selon cette documentation "La règle générale est qu'une application de bureau peut appeler une plate-forme Windows universelle API (UWP).")

@stuartmorgan Ce n'est pas vraiment vrai. Finalement, avec la réunion du projet, cela SERA vrai, mais ce n'est pas le cas pour le moment et même dans ce cas, c'est pour les logiciels hérités, pas pour les nouvelles applications comme ce serait le cas avec le flutter. Il y a une quantité énorme de choses que vous ne pouvez pas faire sans UWP (c'est-à-dire accéder aux plugins pour divers codecs vidéo, le lecteur vidéo DRM, etc.) c'est pourquoi j'ai toujours eu un problème avec l'approche que l'équipe flutter adopte . Il existe 0 systèmes d'exploitation pris en charge par Microsoft (et donc sécurisés) qui ne peuvent pas exécuter UWP sur le marché (c'est-à-dire que cibler Windows 7 est ridicule et ne devrait pas être un objectif de Flutter, seul Windows 10 devrait être une cible). Ainsi, il y a 0 raisons pour lesquelles cela ne devrait pas être UWP natif dès le premier jour.

Pire encore, tous les Windows 10 S et les variantes NE PEUVENT PAS exécuter les applications win32, donc le flottement sera verrouillé de celles-ci. Ils seront également verrouillés sur les appareils ARM / ARM64, à moins qu'ils ne s'exécutent sur UWP et Windows X qui exécute des applications win32 dans un conteneur docker à l'aide de Remote Desktop aura une expérience nettement pire que les applications UWP natives, en particulier en ce qui concerne performances graphiques.

Donc, si google/flutter était avant-gardiste avec la prise en charge de Windows, ce serait entièrement UWP dès le premier jour qui autorise C++ et .NET (la grande majorité des développeurs Windows utilisent .net, pas C++) ET prend en charge tous les appareils Windows actuels ET futurs avec le meilleur interactivité possible. L'approche win32 actuelle est à la fois myope et mal documentée (ce qui indique un angle mort vraiment énorme au sein de Google, ce qui est préoccupant compte tenu du milliard d'appareils qui exécutent Windows).

Étant donné que Skia fonctionne déjà sur UWP, il y a très peu de raisons pour que ce ne soit pas l'environnement de facto et le centre de 100% des efforts de Google sur Windows. (et vraiment, travailler avec Microsoft pour que l'ensemble des simulateurs à distance Xamarin et le déploiement direct sur les appareils iOS sous Windows fonctionnent également)

@ JohnGalt1717 Vous avez déjà avancé cet argument à plusieurs reprises dans ce numéro ; le répéter n'est pas constructif. Si vous souhaitez accélérer le développement du support UWP, vous êtes invités à y contribuer.

@stuartmorgan Je serais curieux de connaître votre avis sur l'utilisation de c#. J'ai quelques idées sur la façon de faire fonctionner cela.

@kinex en fait, les plugins flutter ne sont essentiellement que du code C qui interagit avec flutter via une simple API. Pour les écrire en C #, il faudrait essentiellement un "plugin .net" écrit en C qui hébergerait le CLR et relierait le monde flutter et C #. Théoriquement, il serait possible d'écrire des plugins flutter en Java sur Windows, ou n'importe quel langage tant que l'environnement de langage peut fonctionner sur le système d'exploitation cible.

@JakeSays J'ai déposé https://github.com/flutter/flutter/issues/64958 avec mes réflexions actuelles sur C #, puisque je ne l'avais apparemment jamais déposée ici. Toute personne intéressée par C # en particulier devrait suivre ce problème.

@JakeSays Ok merci pour la clarification. Sans une meilleure connaissance, j'ai supposé quelque chose comme ceci : les plugins C# (peut-être implémentés en tant que bibliothèques .NET ?) seraient chargés par le coureur UWP et le code Dart pourrait les appeler via le processus du coureur UWP. Dans cette architecture imaginaire, ces plugins C# pourraient accéder aux mêmes API, SDK et packages NuGet que n'importe quelle bibliothèque .NET hébergée par une application UWP.

Quoi qu'il en soit, il est bon de savoir qu'il existe des plans concernant la prise en charge de C#. Je pense qu'il y aura plus d'auteurs de plugins (= plus de plugins plus rapidement) et des plugins plus stables si C# peut être utilisé à la place de C++.

@kinex , vous avez raison de dire que les plugins c# auraient accès à l'ensemble complet des bibliothèques .net, ainsi qu'aux packages nuget. Lorsque le code c# est exécuté, il s'exécute dans un environnement .net complet (ou .net core selon le cas).

FFI est une solution beaucoup plus légère pour les plugins. Voir https://pub.dev/packages/win32 , par exemple. Mais c'est loin d'être le sujet d'un problème qui concerne apparemment la construction d'un exécuteur basé sur UWP.

@timsneath Je pense que ffi et les plugins résolvent deux problèmes différents. iirc il y a beaucoup de limitations avec ce que vous pouvez faire avec ffi (par exemple c'est synchrone).

Encore une fois, j'ai déposé #64958 pour les plugins C# ; veuillez poursuivre toute discussion concernant C # mais pas UWP.

il se passe de belles choses
quelqu'un devrait dire à Microsoft de contribuer ici aussi

@airbus5717 que voulez-vous dire ? Microsoft contribue à la discussion ici tout le temps.

J'ai pensé qu'il serait utile de partager une mise à jour de septembre 2020 sur l'état de l'expérience Flutter UWP sur laquelle j'ai travaillé. Les progrès ont été plus lents que je ne le souhaiterais, car il s'agit d'un projet de temps libre / de mon mieux sur lequel je travaille uniquement le soir et le week-end. Cependant, j'ai pu faire des progrès décents au cours des six derniers mois environ et faire fonctionner certains scénarios, à savoir:

• un intégrateur WinRT Flutter de preuve de concept utilisant CoreWindow en conjonction avec les API d'entrée WinRT s'exécutant dans le bac à sable AppContainer : https://github.com/clarkezone/engine
• un test Flutter UWP runner correspondant (seulement 115 lignes de c++ !) avec une démo Flutter expérience utilisant Flutter Gallery : https://github.com/clarkezone/fluttergalleryuwp
• en les utilisant, j'ai pu publier avec succès une version packagée MSIX de Flutter Gallery sur le Microsoft Store, en passant les vérifications de l'API WAC pour la certification du magasin (enfin :-))

Il reste encore une tonne à faire pour que cela soit prêt pour la production et je n'ai aucune idée du temps que cela prendra, mais cela montre certainement que Flutter UWP est viable.

Il reste quelques problèmes importants à résoudre, tels que l'intégration d'outils avec flutter create , comment faire fonctionner le rechargement à chaud et le support de l'observatoire, etc. Plus de détails ici .

Dans l'exemple ci-dessous, j'ai pu prendre la source de l' horloge Flutter Particle de https://github.com/miickel/flutter_particle_clock , la construire en mode release ciblant Windows, prendre le binaire résultant app.so , l'empaqueter pour UWP utilisant le même Flutter Runner que celui utilisé ci-dessus pour Flutter Gallery, publier sur le Microsoft Store et installer sur ma XBOX :