Je pense que Xamarin fusionnera dans .NET 5 ;
Ce serait formidable s'ils adoptaient l'UWP XAML comme norme et travaillaient à partir de là, Microsoft et UNO en faisant le meilleur pour le bureau, le mobile, le navigateur Web (Azure) et l'IoT.
Ils pourraient l'appeler
UWP vNext (basé sur WinUI)/ Silverlight 6 (UNO)

Je pense que l'effort Blazor était une première étape apportant officiellement .NET au WebBrowser, en utilisant son rendu par défaut actuel, c'est-à-dire. le DOM HTML
Mais je crois que bientôt ils pourront même proposer un autre moteur de rendu, un complément léger pour WinUI, quelque chose en orbite autour de Silverlight, UNO Platform et Xamarin... comme Flutter / WPF

Ce serait formidable s'ils adoptaient l'UWP XAML comme norme et travaillaient à partir de là

Tout ce que vous voulez se produit déjà avec Uno. MS serait avisé de racheter ces gars-là et de les embaucher pour guider le développement final d'Uno.

Ce n'est probablement pas le bon endroit pour demander une fonctionnalité comme celle-ci. Autant je voudrais accepter tout dans cette demande, je pense que l'équipe WinUI et de nombreux développeurs seniors de la communauté Windows considèrent que WinUI est défini de manière très étroite.

Dans un monde idéal, WinUI serait comme Material Design. Il y aura des moyens de l'avoir sur n'importe quelle plate-forme avec toutes sortes de bibliothèques qui l'implémentent. Cependant, WinUI n'est pas un langage de conception, pas plus que Fluent Design. Microsoft n'étant pas dans l'espace modèle, son offre d'interface utilisateur est loin derrière la concurrence.

WinUI est une bibliothèque d'interface utilisateur pour les applications Windows, et c'est aussi clair que possible. Le langage de conception n'est pas séparé de l'implémentation, et l'implémentation est exclusive à la plate-forme car des fonctionnalités telles que la composition dépendent fortement de la dépendance à la plate-forme. C'est mauvais du point de vue d'un développeur mobile/multiplateforme, mais l'effort ici est vraiment pour les applications Windows.

C'est aussi pourquoi Uno Platform ne peut jamais vraiment être WinUI partout, à moins qu'il ne porte DX 11 sur chaque plate-forme.

Je vous suggère de vous pencher sur Comet (framework de développement multiplateforme basé sur .Net). C'est à ses débuts, mais le concept n'est pas sans rappeler Flutter. Il utilise également Skia (en option) pour dessiner l'interface utilisateur avec un modèle d'interface utilisateur composable/déclaratif, afin que les développeurs puissent implémenter des bibliothèques d'interface utilisateur comme Material Design et qu'il soit complètement identique sur chaque plate-forme.

Non, il ne devrait pas être multiplateforme. Cela s'appelle Windows UI pour une raison. Commençons par un système d'interface utilisateur qui fonctionne sur l'ensemble de Windows (plates-formes et langues) ? Cela n'a même pas encore été atteint. Nous sommes toujours divisés entre .net framework, .net core, uwp, puis l'histoire C++, qui a au moins uwp, mais aucun développeur de jeu ne l'utilise, car UWP/WinRT a encore quelques problèmes - distribution, barre des tâches forcée et fenêtres contextuelles de la barre de titre en plein écran (yikes).

Penser au multiplateforme serait un gaspillage colossal de ressources. Commencez par Windows, s'il vous plaît. Et sortez .net 5, corrigez UWP et l'histoire du fenêtrage, et mettez DirectX sur C#. Et réparer le GC. Il y a encore tant à faire dans le scénario étroit, juste sur Windows.

Et à l'OP.

• UWP est universel. Dire que ce n'est pas universel est une fausse affirmation (ils n'ont jamais voulu cibler Android, Dieu merci). La promesse initiale a été tenue. Tous les appareils Windows exécutent UWP. Windows Mobile était un système d'exploitation à part, ils devaient s'en débarrasser. Toutes les nouvelles plates-formes Windows seront Windows (10 ou 10X). Finalement basé sur CoreOS je suppose. Et ils exécuteront tous des applications Windows. Le simple fait que nous n'ayons pas de téléphone Windows pour le moment est accessoire. Nous avons tous les autres types d'appareils. Et nous aurons bientôt Neo et Duo.

• Restrictions du bac à sable - Ce sont de bonnes choses. L'accès à l'échelle du système de style Win32 doit être supprimé en général. Si vous avez une exigence spécifique, vous devez la présenter afin que nous puissions discuter de la manière dont cela pourrait/devrait être fait à l'intérieur d'un conteneur UWP et si vous devriez être autorisé à le faire comme vous le suggérez. Et déterminez si UWP a besoin de cette fonctionnalité. Parce que je peux penser à certaines applications avancées qui pourraient être écrites en UWP sans problème. Je peux avoir un programme ! Vous devez discuter des détails.

• .net natif est remplacé et l'histoire de la distribution changera avec .net 5. Je pense qu'il est juste de dire que Microsoft travaille là-dessus. Ils connaissent sûrement les problèmes. Mais vous devez signaler des problèmes spécifiques pour cibler les vrais problèmes sous-jacents ici.

• "Ne couplez pas WinUI à DirectX" - WTF ? Il doit absolument être couplé à DirectX, c'est-à-dire la pile graphique native de Windows. S'il vous plaît, ne considérez même rien d'autre. Je ne veux absolument pas tomber sur des surfaces de rendu OpenGL sous le capot. Cela romprait la compatibilité et causerait toutes sortes de dégâts.

@Gavin-Williams

Merveilleux, faisons une mise à niveau légèrement évolutive sur WPF.

UWP est universel

"Tous les appareils Windows exécutent UWP" ne signifie rien sans mobile. HoloLens est une niche, Surface Hub est une niche, Windows 10 IoT Core est une blague.

Il faut absolument le coupler avec DirectX

En tant que développeur, le couplage dur me donne la chair de poule. Existe-t-il une raison majeure pour laquelle la pile graphique ne peut pas être échangée ?

C'est ce qu'on appelle la "modularité". Microsoft a toujours lutté avec cela.

Les restrictions de bac à sable sont de bonnes choses

Oui, ils le sont, tant qu'ils ne limitent pas sévèrement la gamme d'applications qui peuvent être construites. Avez-vous essayé de redimensionner une partition depuis UWP ?

Je pense qu'il vaut la peine de mentionner et de rappeler que Google développe Flutter et qu'ils ne l'appellent pas GoogleUI ou AndroidUI. Il fonctionne partout, même sur le Web et sur le bureau. Je le dis car il semble y avoir une propension à "le faire fonctionner uniquement sur Windows", mais s'il existe une autre offre concurrente moins chère, plus rapide, plus facile à utiliser ET qui fonctionne sur Windows + tout le reste ... que feront les développeurs ( et marché correspondant) choisir ? Je peux vous dire en tant que propriétaire de petite entreprise que je sais où je place mon investissement compte tenu des deux choix.

Porter DirectX sur d'autres plates-formes semble un travail énorme, peut-être que la solution est d'utiliser OpenGL ou Vulkan au lieu de DirectX

@Gavin-Williams, je ne sais pas si vous connaissez UWP, mais lorsque vous créez/distribuez, vous ciblez une version spécifique (ou une plage de versions) de Windows. Cette idée est absolument couplée, et l'une des raisons pour lesquelles UWP n'est pas devenu aussi courant que WPF.
@nerocui, le but d'un langage d'interface utilisateur est de dissocier la conception de l'interface utilisateur du dessin brut dans un écran. C'est pourquoi vous voyez que HTML peut être rendu dans ARM/x64/x64.

XAML fournit une abstraction exceptionnelle des primitives/composition/animation de l'interface utilisateur, la demande est tout à fait logique en raison du coût de développement et de la portée de la plate-forme.

Je suis respectueusement en désaccord avec @SuperJMN. Certes, UWP n'a pas encore atteint la parité des fonctionnalités avec WPF. Malgré ses limites en tant que cadre pour la création d'outils au niveau du noyau, pour pratiquement toutes les autres tâches de développement de logiciels, avec les bonnes capacités spécifiées dans le manifeste de l'application, vous bénéficiez d'une bien meilleure expérience utilisateur sous plusieurs angles (sécurité, facilité de déploiement, installation/désinstallation expérience, etc). Le bac à sable de sécurité d'UWP est une fonctionnalité importante (essentielle). À bien des égards, UWP est maintenant bien en avance sur WPF.

Le compilateur UWP .Net élimine le besoin d'obscurcissement du code et l'instabilité que cela peut introduire dans WPF. Les performances ont la possibilité de s'améliorer au fil du temps sans modification du code à mesure que le compilateur est amélioré. UWP lui-même a une bien meilleure conception en termes d'exploitation de DirectX et d'autres ressources au niveau du système. Il a également un énorme avantage sur WPF lors de l'intégration avec d'autres langages, C++ en particulier. L'intégration de composants C++ hautes performances avec C# est triviale sous UWP. L'accès aux surfaces DirectX est également bien amélioré.

Les trous restants dans UWP peuvent facilement être bouchés. Je dirais que le plus gros problème a été l'échec de Microsoft à atteindre le niveau de qualité associé à WPF. WPF vient de fonctionner. Microsoft n'a pas non plus reconnu l'importance critique des exigences LOB comme une grille de données, INotifyDataErrorInfo, des contrôles qui comportent des états de validation et une base de données robuste prête à l'emploi. La plupart d'entre eux ont été résolus, mais cela a pris trop de temps. Les régions non rectangulaires manquent toujours.

L'autre échec critique concerne certains développeurs WPF qui ont choisi de rester à l'écart d'UWP. L'adoption est essentielle pour créer une dynamique. Cependant, la saga de l'adoption est compréhensible compte tenu du nombre de fois où Microsoft a manqué à ses initiatives. Il est évident que Microsoft hésite une fois de plus. Ressusciter WPF en lui permettant de se connecter aux services d'interface utilisateur UWP semble cool à première vue, mais cela empêche de rendre UWP solide.

Je suis entièrement d'accord avec l'affirmation de @ SuperJMN selon laquelle les développeurs ont perdu espoir que Microsoft fera ce qu'il faut. La bonne chose diffère selon le type de logiciel que vous construisez. S'il s'agit d'applications métier hautes performances qui doivent être créées rapidement et présentent un large éventail de fonctionnalités tout en étant sûres et faciles à installer, UWP est principalement là, sauf en termes de qualité. Cet écart de qualité est ce qui tue UWP plus que toute autre chose.

HTML+JS est la solution multiplateforme du jour. Nous n'avons pas besoin de le réinventer. Avoir un moteur de rendu XAML hautes performances sur IOS et Android est plus logique si l'intention est de rendre XAML plus portable.

Je suis tout à fait d'accord sur le fait que WinUI devrait viser à être multiplateforme à l'avenir. Voici quelques réflexions supplémentaires.

Priorités immédiates

Je suis d'accord avec certains des commentaires selon lesquels la priorité immédiate devrait être de s'assurer que WinUI 3 fonctionne sur Windows avec l'intégration de .Net 5 et que les bogues sont corrigés. Cependant, s'il n'est pas déjà trop tard, lors de la prise de décisions architecturales, l'objectif d'être multiplateforme à l'avenir devrait être pris en compte.

Pourquoi WinUI devrait être multiplateforme

Il y a les raisons évidentes et les plus importantes - les développeurs veulent cibler le plus large public possible sans réécrire le code, etc., et C# (ou C++ je suppose)/XAML est une belle combinaison. Sans une histoire multiplateforme, ils passeront à d'autres technologies comme Flutter.

Une autre raison est de s'assurer que WinUI continue d'être pris en charge par Microsoft. Microsoft ne continuera probablement à prendre en charge WinUI que si ses propres applications l'utilisent. Ils se concentrent de plus en plus sur la création de leurs propres applications multiplateformes. Il est vrai que certains frameworks multiplateformes tels que React Native et Xamarin utiliseront WinUI en dessous, mais que se passe-t-il si d'autres frameworks tels que Flutter ou le rendu basé sur un navigateur l'emportent ? Ensuite, WinUI deviendra redondant et passera en mode maintenance comme WPF.

Comment implémenter la multiplateforme

Bien qu'Uno soit un excellent projet, à mon avis, il est plus logique de rendre la couche de rendu (et d'entrée) multiplateforme et de s'appuyer sur cela, ce que font Flutter et AvaloniaUI, plutôt que d'encapsuler des contrôles natifs. L'approche consistant à rendre les couches de rendu et d'entrée multiplateformes présente plusieurs avantages. Il me semble que la surface API des couches de rendu et d'entrée est plus petite que celle des contrôles (mais je suppose que cela dépend si vous construisez des contrôles au-dessus de quelques contrôles de base, etc.). Deuxièmement, si vous comptez sur l'encapsulation des contrôles natifs, vous êtes à la merci de la plate-forme. S'ils changent leur API, vous devez changer la vôtre ou implémenter une solution de contournement. Si vous ne le faites pas assez rapidement lors des dépréciations, votre framework se cassera. Si vous souhaitez ajouter une nouvelle fonctionnalité à un contrôle, vous devrez peut-être l'implémenter pour chaque plate-forme. Vous ne pouvez pas vraiment avoir une « vision » de la manière dont vous souhaitez que votre framework évolue, car vous êtes lié aux frameworks de la plate-forme. De plus, les développeurs doivent tester en permanence sur chaque plate-forme, car l'apparence et le comportement des contrôles sont différents. De plus, il serait difficile/impossible d'implémenter des fonctionnalités plus puissantes comme le calque de composition. Rendre la couche de rendu multiplateforme résout tous ces problèmes, et si vous voulez un look différent sur chaque plate-forme, vous pouvez ajouter un style différent. (J'avoue que, certains comportements, vous garderiez différents sur différentes plateformes, comme le défilement sur un Mac !).

Étant donné que WinUI découple actuellement les contrôles et les couches de rendu et d'entrée de la plate-forme, il semble dans une position particulièrement bien placée pour le faire.

Une façon d'abstraire la couche de rendu serait d'utiliser Skia. Cependant, je ne voudrais pas que les performances souffrent en forçant cette abstraction. J'ai une suggestion alternative à examiner pour résumer la couche de rendu, qui est la proposition C++ pour les graphiques 2D - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r9.pdf . Ils ont évidemment beaucoup travaillé sur la surface de l'API et cela semble assez complet. Ils affirment que le "problème" des graphiques 2D a été essentiellement résolu il y a de nombreuses années et je dois convenir avec eux que leur surface API semble assez complète. Il y a beaucoup de gens contre cette proposition, mais même si elle n'est pas acceptée, je pense que la surface API pourrait être utilisée. Si vous écrivez un back-end Direct2D pour cette surface API, si la proposition est acceptée, cela évitera à l'équipe MSVC d'avoir à l'écrire. Peut-être que l'équipe WinUI pourrait utiliser cela comme justification pour être autorisée à travailler dessus ou à ajouter des membres supplémentaires à l'équipe. Aussi, peut-être que les auteurs de l'article seraient prêts à aider. Vous pouvez écrire le back-end pour les autres plates-formes en utilisant Skia ou quelque chose et si la proposition est finalement acceptée, passez aux implémentations natives lorsqu'elles sont faites.

Enfin, en regardant plus loin dans l'avenir, je voulais mentionner WASI - https://wasi.dev/ . Cela semble axé sur la programmation système pour l'instant, mais il pourrait avoir le potentiel de se transformer en un cadre d'application multiplateforme à part entière (il a une multiplateforme et une sécurité intégrées), la proposition C++ ci-dessus fournissant peut-être un candidat naturel pour l'API de la couche de rendu. (C'est probablement très loin cependant).

En regardant les preuves, des gens comme @SuperJMN ont beaucoup de crédibilité compte tenu du contenu de leurs référentiels. Je peux voir que @SuperJMN a probablement abandonné UWP alors qu'il mûrissait encore (compréhensible). Microsoft ferait bien de revoir les référentiels des personnes qui commentent ici. Certaines voix ne sont pas particulièrement crédibles en fonction du corpus d'œuvres qu'elles présentent au monde.

@Noemata J'étais un grand fan de XAML + MVVM. J'ai travaillé avec Silverlight, WPF, WindowsPhone, Metro (WinRT). J'ai brûlé quand il s'agissait d'UWP et de Xamarin ...

Il est difficile de voir ce qui sépare cette itération de toutes les autres fois où j'ai examiné une nouvelle pile XAML.

Microsoft a publié de fantastiques exemples d'applications UWP. Ils montrent vraiment bien ce qui est possible.

Voici une liste partielle :

https://github.com/Microsoft/Windows-appsample-customers-orders-database
https://github.com/microsoft/InventorySample
https://github.com/microsoft/VanArsdel
https://github.com/microsoft/BuildCast
https://github.com/microsoft/Windows-appsample-shopping

Il y a bien d'autres beaux exemples. Aucun n'est construit de manière à être facilement réutilisé ou structuré afin que les échantillons soient cohérents avec d'autres œuvres.

Je ne me souviens pas d'autant d'efforts avec les échantillons WPF correspondants. C'est surtout bon.

Le problème? Il a fallu trop de temps pour arriver là où nous en sommes maintenant avec UWP et XAML. Et maintenant, le message est à nouveau confus. Si Microsoft avait simplement fourni des modèles de projet décents avec Visual Studio lors de la première publication d'UWP, nous serions moins négatifs à propos d'UWP. Pour les meilleurs modèles VS, vous devez vous rendre ici :

https://github.com/microsoft/windowsTemplateStudio

Pas tout à fait prêt à l'emploi, bien qu'il s'agisse d'un ensemble très flexible et complet de blocs de construction pour les applications UWP. Comment trouvez-vous tout cela ? Aucune idée. Partir à la chasse au trésor pour faire son travail ne renforce pas la confiance. L'équipe Office refusant d'adopter WinRT n'a pas aidé. Ils pilotent une grande partie de ce qui entre dans le système d'exploitation, quelle que soit leur portée théorique. Ajoutez des problèmes de qualité, des bugs, l'échec de Windows Phone et des investissements incohérents ainsi que la messagerie et nous y sommes.

Microsoft a publié de fantastiques exemples d'applications UWP. Ils montrent vraiment bien ce qui est possible.

@Noemata Je suis d'accord, ce sont des échantillons vraiment sympas. Mais développer une application complexe est insensé, en utilisant UWP. C'est certainement possible, mais c'est beaucoup plus difficile. Oui, les moments "Ça marche, tout simplement" du WPF me manquent.

L'une des premières choses que MS devrait donner comme exemple est une simple application UWP que vous pouvez publier en dehors du magasin MS (et oui, ce n'est pas aussi facile que vous ne le pensez)

Une autre chose qui ne me convient pas est que l'UWP a été pensé avec le "mobile d'abord" à l'esprit, abandonnant la bonne expérience de bureau.

Corrigez-moi si je me trompe, mais la plupart des développeurs utilisent UWP pour développer des applications de bureau, et l'interface utilisateur ne correspond pas à cela. La première chose qui me vient à l'esprit est la barre de défilement - qui, dès le départ, est optimisée pour le pavé tactile. Mais pour les utilisateurs des ordinateurs de bureau, l'expérience de défilement est très mauvaise (note latérale : je pense que l'équipe WinUI travaille à résoudre ce problème). J'ai beaucoup cherché sur Google pour trouver une solution qui rendra à nouveau la barre de défilement "normale" - c'est tout simplement insensé que je ne puisse pas simplement appeler une fonction API pour le faire.

Idem, les boutons radio/boîtes combo ont une taille min également optimisée pour le mobile. La simple définition de la largeur d'un bouton radio est ignorée, vous devez en fait définir "MinWidth=0" pour qu'elle soit prise en compte.

Et la couleur du bouton de texte est blanche, puis noire sur le focus - qu'est-ce qui se passe avec ça ? Et le bouton de texte a un "x" que vous pouvez utiliser pour l'effacer - c'est le pavé tactile - pourquoi l'ai-je là quand il n'y a pas de pavé tactile ?

L'orthographe est activée dans la zone de texte par défaut. Pourquoi voudrais-je cela ?

Il y a d'autres problèmes, mais j'ai travaillé autour d'eux. Mais le plus gros problème est que les choses qui devraient prendre 10 minutes prennent généralement 2 heures ou plus. J'ai tout simplement perdu la capacité d'estimer - chaque fois que je dis que quelque chose me prendra une demi-journée, cela me prendra 2-3 jours.

Salutations à tous,
car il s'agit d'un problème de discussion générale et je ne sais pas où placer mes souhaits/demandes de fonctionnalités UWP ..... J'en profite dans ce fil :

• Meilleure prise en charge de l'intégration des applications uwp dans le menu contextuel de l'explorateur Windows
  
  
  
  • Veuillez nous soutenir ici https://aka.ms/AA6rmrk
  
  
• Extension de balisage UWP manquante IServiceProvider , et l'élément lui-même sur lequel l'extension de balisage est utilisée
• Déclencheur de style UWP manquant
• Problème de modèles de données implicites UWP. Voir par exemple ici
• pas d'impression automatique possible sans intervention de l'utilisateur (fonctionne uniquement pour les points de vente) voir ici

Toutes les fonctionnalités ou problèmes ci-dessus ont été résolus sur uservoice qui est maintenant abandonné. Est-ce que quelqu'un sait ce qui s'est passé avec ces problèmes? Doit-on les recréer sur feedbackhub ?

J'adore l'expression "Les développeurs oubliés". J'en connais beaucoup qui sont talentueux, expérimentés, passionnés par les technologies. Ce sont des développeurs .Net vétérans. Je ne doute pas qu'ils puissent, d'une manière générale, créer de meilleures applications que de nombreux enfants qui s'épanouissent dans le développement d'applications pour iOS et Android.
Si WinUI peut leur fournir un chemin agréable et robuste pour utiliser leur vaste expérience en C # + .Net + Xaml pour créer des applications pour Windows, Android, iOS et Web, beaucoup sauteront sur le wagon et le monde bénéficiera de leur haute- applications de qualité.
WinUI + Uno Platform pourrait être l'appel ultime.

Extension de balisage UWP manquant IServiceProvider, et l'élément lui-même sur lequel l'extension de balisage est utilisée

Vous êtes couvert ici @mfe- !

Vous êtes couvert ici @mfe- !

@Mike-EE Wow, c'est génial ! Je me souviens d'avoir rencontré cela lorsque j'ai voulu porter CalcBinding vers UWP. Ce que j'ai fini par faire est une solution de contournement dans laquelle j'ajoute des champs en lecture seule dans le modèle de vue.

"écrire une fois, courir partout".

Microsoft s'en est éloigné il y a quelque temps.

Beau travail à tous NOUS SOMMES CÉLÈBRES ! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

Les développeurs oubliés sont silencieux ou simplement ignorés

J'adore l'expression "Les développeurs oubliés".

Organisons-nous sous ce nom ! 💪

Je souhaite juste un cadre d'interface utilisateur multiplateforme développé et pris en charge par Microsoft. Il n'y a tout simplement rien pour l'écosystème .NET, à l'exception de _Uno Platform_ et _Xamarin.Forms_ (s'ils travaillent toujours sur le ciblage du bureau).

Et même si je décide d'écrire une application métier uniquement Windows à partir de zéro, je ne crois pas que Microsoft s'engage pleinement dans l'UWP. Corrigez-moi si je me trompe, mais n'ont-ils pas abandonné les applications Office UWP au profit des PWA Office Online ? Si MS abandonne son propre framework propriétaire, pourquoi devrais-je faire confiance à UWP ? _toux Silverlight_

Heureusement, WPF n'a pas encore été abandonné. Mais cela ne fait qu'ajouter à mes doutes.

Beau travail à tous NOUS SOMMES CÉLÈBRES ! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

Houx 🤭

Super! Étendons-nous à d'autres grands journaux, sites Web, etc. 😛

Pour ceux qui recherchent une solution multiplateforme pour développer des applications, vous n'avez pas besoin de chercher plus loin que Unity :

https://unity.com/

Comme toutes ces solutions, vous vous retrouvez avec un cadre qui englobe un mini système d'exploitation. Java était le système d'exploitation astucieusement déguisé en langage de programmation.

Un navigateur moderne est maintenant un mini OS. Je pense que nous en avons assez. WinUI/UWP est censé être l'interface utilisateur native pour Windows 10 et versions ultérieures. Il peut être judicieux d'avoir un moteur XAML qui s'exécute à plusieurs endroits. Je ne suis pas convaincu que cela volerait contre le vent contraire de choses comme Unity. Je préférerais voir un UWP raffiné et de haute qualité avant que Microsoft ne se lance et ne commence à réinventer Silverlight afin que nous puissions héberger XAML sur d'autres plates-formes. Nous savons tous à quel point cela a bien fonctionné. Si vous n'avez pas regardé Unity, vous manquez quelque chose. Cela dit, soyez prêt à faire beaucoup de codage et encore plus de débogage.

La semaine prochaine, je publierai un ensemble de modèles VS pour UWP qui vous permettront de créer des applications en quelques secondes. Cela a été utilisé pour des projets "internes". Cela prouvera que UWP peut être un framework RAD prêt à l'emploi si seulement VS avait les bons blocs de construction intégrés.

La semaine prochaine, je publierai un ensemble de modèles VS pour UWP qui vous permettront de créer des applications en quelques secondes. Cela a été utilisé pour des projets "internes". Cela prouvera que UWP peut être un framework RAD prêt à l'emploi si seulement VS avait les bons blocs de construction intégrés.

@Noemata Ça a l'air cool ! je suis assez curieuse !

Si vous voulez tous un framework d'interface utilisateur multiplateforme basé sur .Net qui peut s'adapter à n'importe quel langage de conception. Ne cherchez pas plus loin, c'est Comet.

https://github.com/Clancey/Comet

Si vous avez un peu de temps libre, allez contribuer car c'est encore à ses débuts.
Comet cible essentiellement toutes les plates-formes existantes et vous donne le choix de cibler le contrôle natif de chaque plate-forme ou d'utiliser Skia pour tout dessiner afin qu'ils soient tous cohérents (exactement comme Flutter le fait).

Il utilise une interface utilisateur déclarative et un modèle MVU. Il est développé par James Clancey, architecte principal de programme chez Microsoft. Bien qu'il ne soit pas encore officiellement pris en charge, mais avec suffisamment de traction communautaire, il peut l'être.

Dans Comet, l'interface utilisateur n'est qu'une bibliothèque, vous (ou peut-être Microsoft pouvez-vous) pouvez développer une bibliothèque WinUI, tout comme Comet a une bibliothèque Material Design.

Si vous voulez tous un framework d'interface utilisateur multiplateforme basé sur .Net qui peut s'adapter à n'importe quel langage de conception. Ne cherchez pas plus loin, c'est Comet.

@nerocui cela semble cool, mais au moins à le regarder, il n'y a pas de concepteur XAML. Construire des interfaces utilisateur complexes est probablement insensé à son stade actuel. Mais ça a l'air prometteur.

Si vous voulez tous un framework d'interface utilisateur multiplateforme basé sur .Net qui peut s'adapter à n'importe quel langage de conception. Ne cherchez pas plus loin, c'est Comet.

@nerocui cela semble cool, mais au moins à le regarder, il n'y a pas de concepteur XAML. Construire des interfaces utilisateur complexes est probablement insensé à son stade actuel. Mais ça a l'air prometteur.

Et il ne s'agit pas de glisser-déposer, il s'agit d'un aperçu en temps réel de l'interface utilisateur dans le concepteur lorsqu'une modification est apportée au code.

La semaine prochaine, je publierai un ensemble de modèles VS pour UWP qui vous permettront de créer des applications en quelques secondes. Cela a été utilisé pour des projets "internes". Cela prouvera que UWP peut être un framework RAD prêt à l'emploi si seulement VS avait les bons blocs de construction intégrés.

Est-ce que cela utilise NoesisGUI ? Si c'est le cas, il y a BEAUCOUP de fonctionnalités manquantes qui seraient nécessaires pour les applications LOB. Maintenant, WinUI ciblant Unity serait génial.

J'ai créé un dépôt pour documenter l'état actuel de XAML et j'espère que les gens aideront et contribueront avec des idées et des extraits de code réels qui répertorient comment accomplir des tâches dans les différentes saveurs de XAML.

https://github.com/gatewayprogrammingschool/XAML-Standardization

Problème simple, allez au-delà du bac à sable d'aujourd'hui et adoptez ce qui est requis pour la multiplateforme. Je le fais déjà pour tous les autres aspects de Windows/OS, pourquoi pas l'interface utilisateur.

Prenez la plate-forme croisée du bac à sable.

De : anthonyadame [email protected]
Envoyé : samedi 29 février 2020 20:00:13
À : microsoft/microsoft-ui-xaml [email protected]
Cc : Le ninja pointu [email protected] ; Commentaire [email protected]
Objet : Re : [microsoft/microsoft-ui-xaml] Discussion : WinUI devrait être multiplateforme (#2024)

Problème simple, allez au-delà du bac à sable d'aujourd'hui et adoptez ce qui est requis pour la multiplateforme. Je le fais déjà pour tous les autres aspects de Windows/OS, pourquoi pas l'interface utilisateur.

—
Vous recevez ceci parce que vous avez commenté.
Répondre à cet e - mail directement, voir sur GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024?email_source=notifications&email_token=AD3GCLAISGPMJCQ4AYDPDLLRFG6S3A5CNFSM4K3JAUQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMOWIY#issuecomment-593029923 ou désabonnement https://github.com/ notifications/unsubscribe-auth/AD3GCLDKTTDCWIJ2ED3OKC3RFG6S3ANCNFSM4K3JAUQA .

L'intégration de composants C++ hautes performances avec C# est triviale sous UWP. L'accès aux surfaces DirectX est également bien amélioré.

@Noemata Sauf que ce qui m'importe, c'est de ne pas avoir à écrire en C++ pour commencer, WinDev continue de bâcler toutes les tentatives qui rendraient les langages .NET égaux en ce qui concerne les API C++, Managed Direct X, XNA, la bonne compilation AOT de .NET code, fonctionnalités COM, ....

Rendre WinUI 3.0 multiplateforme sera cet argument pour porter les applications .NET/Forms existantes vers WinUI.

Pour commencer, il suffira de supporter macOS, et ce n'est pas un problème lorsqu'il n'a pas les mêmes performances que sur Windows, ou pas toutes les fonctionnalités comme les animations.

Windows est la plateforme de référence ; bien sûr, il doit être couplé à DirectX pour de meilleures performances.

À mon avis, cela n'a aucun sens d'essayer de réécrire de grandes applications C # en HTML + JS uniquement pour prendre en charge macOS. Et aussi pour les nouvelles applications de bureau, C # est le meilleur choix.

Pour les applications de bureau, C# et XAML sont beaucoup plus fiables que HTML+JS.

Rendre WinUI 3.0 multiplateforme garantit l'avenir de .NET, C# et XAML.

Salut tout le monde

Je suis un développeur de contrat WPF travaillant à Londres. Je construis des interfaces utilisateur complexes et performantes avec WPF pour un certain nombre d'institutions financières depuis 2006. Voici mon point de vue :

1) Je surveille de près le marché du travail au Royaume-Uni. 100 % des emplois WPF annoncés depuis 2006 (dont il y en a eu des milliers) concernent la création d'applications de bureau de trading financier hautes performances pour le secteur financier. Il n'y a pas encore eu d'annonce d'emploi pour un développeur UWP pour n'importe quelle industrie.

2) Ces applications de trading de bureau ne peuvent pas utiliser UWP ou le futur WinUI - ce n'est tout simplement pas assez bon par rapport à WPF pour de nombreuses raisons complexes. De plus, le design Fluent n'est pas quelque chose qui intéresse ces utilisateurs - il doit juste ressembler à une grille Excel - pas d'animations, pas de style - juste des données et des performances incroyables.

3) Ces clients ne sont pas du tout intéressés par les solutions multiplateformes. Personne n'utilise un Mac, et le mobile n'est pas quelque chose qui les intéresse.

4) Ces équipes de développement WPF ont de gros investissements (temps et argent) dans des bibliothèques de contrôle WPF tierces, ou ont fait développer des suites de contrôle personnalisées complexes et performantes par des personnes comme moi. Ils ne vont pas s'éloigner de WPF à moins qu'il n'y ait un avantage très important (ce qui n'est pas prévisible)

5) Pour ces institutions financières, toute application qui n'a pas besoin d'être écrite explicitement pour le bureau / WPF est écrite avec les technologies Web et Javascript. Ils ne sont pas intéressés par quelque chose de plus exotique que cela - pas de flottement, pas de blazor, etc.

C'est donc la situation au Royaume-Uni. Des centaines de développeurs WPF ne cherchent pas à se lancer dans quelque chose de nouveau de si tôt. Zéro développeurs UWP (à l'exception peut-être d'une poignée de groupes individuels développant des applications pour le magasin - ce qui est douteux compte tenu de l'état du magasin)

De plus, je ne comprends pas toute l'hystérie à propos du multiplateforme. La multiplateforme qui couvre à la fois le mobile et le bureau est une course de dupes. Ça ne sera jamais intéressant. Microsoft a essayé cela avec des applications UWP qui s'exécutaient sur un ordinateur de bureau et un téléphone - c'était un désastre - en limitant les applications aux interfaces utilisateur les plus simples qui ne pouvaient rien faire de complexe ou d'intéressant. Les appareils de bureau et mobiles sont conçus pour différentes tâches et cas d'utilisation, et ont besoin d'applications différentes - nous le savons tous.

Pour moi, je veux voir beaucoup plus d'investissements directs de mon Microsoft dans WPF, sans sacrifier la rétrocompatibilité. Je veux voir WPF prendre en charge le développement de contrôle en c++ non géré afin que nous puissions travailler plus près du métal. Je veux voir une meilleure technologie de liaison, une meilleure modélisation des données, une meilleure fonctionnalité de modèle de contrôle, y compris l'héritage partiel. Je veux voir de meilleurs outils de débogage et des analyseurs d'arbres visuels. Je veux voir le débogage XAML s'étoffer davantage. Je souhaite une meilleure prise en charge du multithreading dans l'interface utilisateur. Je veux beaucoup, beaucoup de choses, tout comme mes collègues sous-traitants britanniques WPF.
La feuille de route actuelle de Microsoft ne me donne aucune des choses que je veux, et toutes les choses dont je ne me soucie pas.

Si Microsoft ne soutient pas cette vision (ce qu'ils ne font clairement pas pour le moment), alors le plan B sera la communauté qui moulera WPF dans la plate-forme dont elle a besoin via des contributions open source - en supposant que Microsoft accepte une touche plus légère lorsqu'il s'agit d'autoriser de nouveaux du code et des idées pour faire partie du framework WPF.

@deanchalk Je pense que la plupart de ces éléments auraient peut-être été mieux placés dans le référentiel WPF pour leur montrer qu'il y a un intérêt pour WPF, le publier ici indique principalement que vous n'êtes pas intéressé par ce qui est fait dans le référentiel WinUI / discuté dans ce numéro. Bien que ce soit une entrée valide, cela ne mènera probablement pas à quelque chose de constructif au-delà de la discussion vide.

@weltkante @deanchalk Il y a un problème dans le référentiel demandant la "prise en charge du contrôle hérité" dans WinUI : https://github.com/microsoft/microsoft-ui-xaml/issues/1833
Au moins le point 4) correspond à ce problème et devrait probablement y être republié pour justifier un investissement de Microsoft.

@deanchalk , je suis toujours un grand fan de WPF. C'est un outil formidable qui, heureusement, commence à être apprécié par Microsoft. La manière dont Microsoft a choisi d'abandonner WPF en premier lieu était des plus regrettables. UWP étant le nouveau jouet brillant, n'aurait pas dû empêcher la poursuite des investissements dans WPF.

UWP était à bien des égards la bonne voie à suivre. Malheureusement, les premières itérations ont ignoré certaines des exigences les plus critiques pour les personnes qui utilisaient WPF et auraient pu envisager de migrer. L'état plutôt surprenant de la fragmentation XAML dans les murs d'une seule organisation n'est pas le moindre. WPF != Silverlight != UWP != Xamarin. Wow!

Je suis moins sympathique aux développeurs WPF qui ont choisi de se retrancher dans WPF en 2020. Les choses ont considérablement évolué. Les îlots XAML avec la possibilité d'utiliser l'API WinRT vous offrent un chemin assez simple pour démarrer votre migration vers UWP. Et UWP ne manque plus si vous avez choisi de faire une conversion en gros.

Le plus gros problème reste le manque de clarté de Microsoft sur la suite. Tous ceux qui espéraient XAML Nirvana ont abandonné avec le fiasco Silverlight qui se rejoue une fois de plus avec UWP.

WinUI est si évidemment un UWP rebaptisé, c'est pénible à voir. Et il est tout aussi évident que Microsoft espère que nous oublierons tous ce qu'est/était UWP.

Pourtant, la main gauche de Microsoft n'est pas toujours en phase avec ce que fait la main droite. WindowsX a fait de Win32 et de tout ce qui l'accompagne (WPF/Winforms/etc.) une perspective ténue pour les applications qui "pourraient" s'exécuter dans son bac à sable aux performances inférieures. UWP est et reste actuellement l'interface utilisateur native pour Windows 10, WindowsX et au-delà. L'API WinRT est une grande amélioration par rapport à Win32. Donc, je suppose que vous devez choisir si vous voulez passer aux années 2020 ou tenir le coup dans les années 2010.

WinUI est si évidemment un UWP rebaptisé, c'est pénible à voir. Et il est tout aussi évident que Microsoft espère que nous oublierons tous ce qu'est/était UWP.

@Noemata WinUI est un nouveau produit basé sur les API UWP (XAML, Composition, Input,...). Le nom a du sens car vous pourrez l'utiliser pour créer une interface utilisateur pour les applications Windows, quel que soit le modèle d'application sous-jacent.

Je suis confus. Vous mentionnez vous-même 10X dans le dernier paragraphe. Le modèle d'application UWP lui-même est poussé avec Windows 10X. Maintenant, seul le temps pourra dire si 10X réussira. Mais MS a été clair dans son message : UWP est la plate-forme native de 10X (aux côtés du Web), comme vous l'avez souligné.

@Noemata jusqu'en 2020 rattrape les fonctionnalités disponibles en 2010, beaucoup d'entre nous sont obligés de rester en 2010.

Beaucoup d'entre nous viennent juste de se lasser du train de réécriture qui a commencé avec l'abandon de Silverlight, XNA et de voir comment la main de MS agite les réécritures nécessitant pour .NET Core, WinUI, tout en abandonnant des fonctionnalités dans le processus, ne gagne pas le cœur de beaucoup de nos clients, avec des applications entièrement fonctionnelles qui ne voient pas pourquoi ils devraient payer des réécritures pour récupérer moins de fonctionnalités.

À l'heure actuelle, grâce à l'intelligence d'avoir des tablettes Android et Windows 10 X, Xamarin et les PWA sont ce que nous attendons, pas WinUI.

@pjmlp , peut-être. Je suis curieux de savoir quelle fonctionnalité vous manque? J'ai porté certaines applications WPF assez volumineuses sur UWP. Le plus gros casse-tête était le bac à sable de sécurité et apprendre à travailler avec plutôt que de le combattre. Auparavant, il manquait des pièces, comme la grille de données, la connectivité DB, une API décente pour les communications à haut débit, etc. Il manque très peu maintenant. Il y a beaucoup de choses que je ne pourrais pas faire aussi facilement dans WPF. Pour être juste, à l'heure actuelle, il n'y a rien que je ne puisse faire dans WPF en tirant parti de l'accès à l'API WinRT, sauf que j'aurais des performances inférieures car UWP se compile en code machine de manière plus optimale et utilise une meilleure pile de rendu DirectX. De plus, vous devez obscurcir votre code WPF (le rendre plus fragile) si vous avez l'intention de protéger votre adresse IP ou d'empêcher les intrus.

Les téléphones/tablettes sont d'excellents appareils pour les applications de type solution ponctuelle. Je ne voudrais pas marquer une symphonie sur un téléphone ou concevoir un gratte-ciel, et je préfère pouvoir cibler une partie des solutions ponctuelles de mon application de bureau sur mobile, plutôt que d'essayer de faire fonctionner le mobile sur mon bureau.

@Felix-Dev Je comprends ce qu'est WinUI. Je me demande pourquoi un autre fork était nécessaire simplement parce que les développeurs WPF, Winforms et MFC/Win32 ne l'achèteraient pas. La meilleure stratégie aurait été de rendre la migration soit plus attrayante, soit moins pénible, soit les deux.

Microsoft a bien fait beaucoup de choses avec UWP. Il existe une multitude d'exemples d'applications couvrant toutes sortes de cas d'utilisation. Ils sont arrivés en retard, tout comme les fonctionnalités manquantes. Est-ce vraiment trop tard ?

@Noemata WinUI se serait probablement produit dans les deux sens (avec ou sans WinUI Desktop) car le découplage de la pile UWP UI du système d'exploitation est une étape absolument nécessaire. Il aurait été préférable que WinUI ait déjà existé lors de la première sortie de Windows 10, mais il y a des raisons pour lesquelles ce n'était pas le cas.

Quant à savoir s'il est trop tard ... nous avons eu de nombreuses discussions de ce type sur le canal discord de la communauté UWP et également d'innombrables échanges passionnés ici. Certains d'entre nous pensent que le navire a déjà navigué tandis que d'autres pensent encore qu'il y a une chance que la plate-forme UWP/WinUI puisse grandir et mûrir pour devenir une plate-forme de développement majeure. Beaucoup de gens avec beaucoup d'idées à quoi pourrait ressembler la meilleure approche pour la SEP (c'est-à-dire passer à xplatform ou pas ?). Le fait est que l'équipe travaille actuellement d'arrache-pied sur WinUI 3 et sa sortie marquera le début du vrai défi : faire avancer WinUI - avec l'aide de la communauté - afin qu'il devienne le cadre de choix pour les développeurs ciblant Windows. .

@Noemata , tout d'abord la compatibilité avec les bibliothèques de composants tiers existantes telles que Telerik, Component One, ...

Ensuite, sans avoir à réécrire quoi que ce soit pour commencer, comme mentionné, nous en avons assez des réécritures.

En ce qui concerne DirectX, non seulement les classes de modélisation 3D de WPF ne sont pas prises en charge, mais on s'attend à ce que nous écrivions C++, car Microsoft ne se soucie pas de créer des projections Runtime pour DirectX, et le dialecte C++/CX quelque peu agréable a été remplacé par le verbeux moins capable, mais mieux conforme, C++/WinRT.

En plus de cela, non seulement nous devons jeter le code WPF parfaitement fonctionnel, nous devons faire de même avec le code WCF, EF6.

Je crois toujours que UWP est une bien meilleure API que Win32, en quelque sorte ce que Longhorn aurait dû être, mais la façon dont cela se déroule a juste coupé trop de ponts, car Microsoft a brûlé le budget de réécriture de nombreuses organisations.

@pjmlp , ce sont tous de bons points avec des contre-arguments plutôt doux, donc je n'essaierai même pas. L'absence de prise en charge de l'API WPF 3D a été un coup dur pour moi personnellement. Avoir à apprendre une nouvelle approche n'était pas amusant et beaucoup moins performant compte tenu des options de liaison WPF pour la 3D. Les alternatives C # pour la 3D sous UWP sont là, mais beaucoup moins utiles une fois que vous avez expérimenté les avantages de la liaison sur un modèle 3D.

C++/CX était un autre problème qui a mis trop de temps à être résolu par C++/WinRT, qui pourrait être stable la semaine prochaine (il est toujours en train de changer).

WCF est mort (désolé, les nouvelles options sont bien meilleures). EF6 aurait dû avoir une bien meilleure histoire de migration. Vous avez absolument raison sur le fiasco du budget de réécriture @pjmlp , c'est clairement quelque chose que Microsoft avait l'habitude d'obtenir et ne se soucie plus d'envisager étant donné le roulement fou / incohérent de la technologie.

@Felix-Dev, vous aussi faites des remarques tout à fait valables. Le découplage de l'interface utilisateur aurait dû être là depuis le début. Les personnes demandant une interface utilisateur xplatform basée sur XAML devraient reformuler leur demande et demander un moteur de rendu XAML sur la plate-forme de leur choix avec un mini système d'exploitation pour répliquer la surface de l'API (une autre plate-forme Java/Silveright/Uno/Unity/Quoi qu'il en soit… éventuellement se terminant par du HTML que les applications proches du métal ne peuvent pas commencer à envisager). Je ne suis pas au courant des dernières initiatives internes de MS pour le moment. En regardant à l'extérieur, WinUI est le drapeau flottant indiquant que le navire est à nouveau redressé (combien de fois de plus ?). Défendre Microsoft est devenu impossible avec la mort de Silverlight. Je ne reprendrai plus cette épée. Je suppose que ce que je fais vraiment, c'est déplorer la mort d'UWP :-( ... douloureux. https://www.youtube.com/watch?v=uBiewQrpBBA

Charlie == Microsoft

Multiplateforme ? Microsoft devrait simplement acheter UNO et en finir avec tit.

Multiplateforme ? Microsoft devrait simplement acheter UNO et en finir avec tit.

J'espère que quelle que soit la solution qui se présentera, elle ne reposera pas sur un navigateur Web ou une vue Web quelconque. Affichez l'interface utilisateur dans la fenêtre native ou la surface de l'interface utilisateur de la plate-forme, mais ayez l'air identique à ce qu'elle serait sous Windows.

Multiplateforme ? Microsoft devrait simplement acheter UNO et en finir avec tit.

J'espère que quelle que soit la solution qui se présentera, elle ne reposera pas sur un navigateur Web ou une vue Web quelconque. Affichez l'interface utilisateur dans la fenêtre native ou la surface de l'interface utilisateur de la plate-forme, mais ayez l'air identique à ce qu'elle serait sous Windows.

C'est ainsi que UNO le fait, sauf sur Windows 7. Windows 7 est la seule exception car il utilise le navigateur Web.

Pour les développeurs WPF qui ont besoin d'une solution de bureau multiplateforme, Wine peut être une option viable pour vous. J'ai eu beaucoup de succès en portant de grandes applications WPF (.NET Core WPF principalement) pour fonctionner sur Linux avec Wine. J'ai un article qui peut vous aider à démarrer :
https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html

J'ai également commencé à porter certaines applications WinForms sur Linux. Jusqu'à présent, je n'ai rencontré aucun problème.

Wine devrait également vous permettre de fonctionner sur Mac, Chrome OS et Android. Je n'ai essayé que Linux.

Pour moi, cela montre que l'utilisation de DirectX comme couche d'abstraction fonctionne et est un modèle viable à suivre. Je soupçonne que cela fonctionnerait même bien sur le Web avec WebGL une fois que .NET WASM sera plus mature.

Faire en sorte que Microsoft aide avec Wine (au moins en s'assurant qu'ils ne le cassent pas) aiderait beaucoup. Ils pourraient aider à créer une solution vraiment native avec WineLib et compte tenu de leur expertise, je ne pense pas que ce serait trop d'effort.

AvaloniaUI est déjà multiplateforme. Pourquoi ne pas demander aux personnes du projet de l'aide et des commentaires pour améliorer WinUI ?

Eh bien, pas autant qu'Uno Platform. Uno Platform fonctionne également sur le Web (WASM). Avalonia n'a pas cette capacité.

Avalonia utilise également son propre dialecte XAML, ce qu'Uno essaie d'éviter.

De : Shimmy [email protected]
Envoyé : vendredi 27 mars 2020 04:09:30
À : microsoft/microsoft-ui-xaml [email protected]
Cc : Le ninja pointu [email protected] ; Commentaire [email protected]
Objet : Re : [microsoft/microsoft-ui-xaml] Discussion : WinUI devrait être multiplateforme (#2024)

AvaloniaUI est déjà multiplateforme. Pourquoi ne pas demander aux personnes du projet de l'aide et des commentaires pour améliorer WinUI ?

Eh bien, pas autant qu'Uno Platform. Uno Platform fonctionne également sur le Web (WASM). Avalonia n'a pas cette capacité.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024#issuecomment-604893750 ou désabonnez-vous https://github.com/notifications/unsubscribe-auth/ AD3GCLE3TEC3DZO74OXKX73RJRUMVANCNFSM4K3JAUQA .

La plupart de la technologie de WinUI provient de Sliverlight, et Sliverlight a en fait atteint la multiplateforme. Ainsi, la multiplateforme WinUI dépend de la stratégie, pas de la technologie.

Honnêtement ... c'est en fait tellement pathétique que Microsoft essaie maintenant de rattraper son retard ... ils ne se soucient que de la "grosse" part de marché, ils ne regardent pas ce que leurs clients/fans de produits veulent.

Microsoft est la raison pour laquelle le développement DESKTOP APP est passé au développement Web obsolète, même lorsque le Web est si horrible.

Je suis sûr que tous les développeurs XAML conviennent que HTML/CSS est tellement nul.

Mais quand même... HTML, CSS, DOM... avec des frameworks comme React, Angular, Vue qui essaient d'en faire quelque chose de plus agréable. Les gens se concentraient toujours sur ce Web obsolète, pas sur la nouvelle plate-forme Windows à source fermée de Microsoft qui meurt tous les 2 à 4 ans pour une nouvelle.

La plate-forme Win-app basée sur XAML aurait dû être open-source il y a des ANNÉES. Il devrait avoir écrit une fois déployé sur WEBSITE, Windows, Mac, Linux, Android (toute plate-forme souhaitée par le client). Le Windows Store aurait dû être multiplateforme avec un moteur de rendu d'application XAML/UWP. (similaire à la façon dont Google Chrome est multiplateforme avec moteur de rendu HTML/CSS).

Pendant l'âge d'or de Microsoft, une application multiplateforme basée sur XAML aurait pu détruire le Web, nous n'aurions alors pas eu à gérer ces CSS, HTML, DOM et d'innombrables frameworks.

Mais non, l'obsession de Microsoft pour les logiciels propriétaires les a fait perdre face au Web.

Pendant ce temps, Flutter de Google devient ce que j'ai toujours voulu pour XAML.

Je m'attends à ce que WinUI 3 soit une plate-forme cible dans MAUI. La plate-forme Uno a déjà annoncé que WinUI 3 Preview était pris en charge.
Donc, @jeromelaban / Microsoft, ce dont nous avons probablement vraiment besoin, c'est de l'unification Uno/MAUI ? MAUI est moins utile IMO que Flutter ou Uno sans cible Web (navigateur).

Veuillez également laisser vos commentaires dans le référentiel MAUI .

WPF (Silverlight) partout !

Porter DirectX sur d'autres plates-formes semble un travail considérable, peut-être que la solution consiste à utiliser OpenGL ou Vulkan au lieu de DirectX

Google a ANGLE qui permet d'exécuter OpenGL ES de manière native sur n'importe quelle plate-forme en traduisant les appels et les shaders en API native (desktop gl [éventuellement fourni par le moteur de rendu logiciel swiftshader], vulkan, directx, metal). C'est également une partie essentielle de Chrome et Flutter, aux côtés de Skia.

Microsoft pourrait créer un petit sous-ensemble (peut-être juste comme point de départ) de DirectX pour les applications GUI et le traduire en API natives, tout comme ANGLE le fait.

En ce qui concerne le problème de "différents supports de distribution Linux", les utilisateurs de Linux sont souvent suffisamment qualifiés pour résoudre eux-mêmes l'incompatibilité, et même dans ce cas, il existe Flatpak qui unifie l'emballage pour les ordinateurs de bureau, tout comme Docker le fait pour les serveurs.

Mentionné dans le chat de Lonje https://www.lonje.com/message/1968439855/

Je pense vraiment que WinUI devrait également prendre en charge les thèmes natifs sur Mac et Linux tout en prenant en charge les thèmes personnalisés.
Je ne suis pas sûr des utilisateurs de Mac, mais la communauté Linux aime contrôler l'apparence de leur bureau.
Ils ont déjà Gtk, ce qui, je pense, serait une bonne chose à intégrer au framework WinUi

Je pense vraiment que WinUI devrait également prendre en charge les thèmes natifs sur Mac et Linux tout en prenant en charge les thèmes personnalisés.
Je ne suis pas sûr des utilisateurs de Mac, mais la communauté Linux aime contrôler l'apparence de leur bureau.
Ils ont déjà Gtk, ce qui, je pense, serait une bonne chose à intégrer au framework WinUi

C'est certainement difficile à faire car WinUI est un langage de style, et les frameworks XAML sous-jacents vous obligent à créer vous-même des thèmes, tandis que des thèmes par défaut sont également fournis.

J'ai suggéré par le passé que le projet soit structuré de manière à permettre à la communauté de développer un Metal Renderer pour macOS et iOS - et éventuellement un moteur de rendu Skia pour Android.

Les mêmes styles et modèles par défaut peuvent être utilisés sur toutes les plates-formes, ou des modèles et ressources par défaut de style Android et macOS peuvent être créés.