Maui: UX multiplateforme pour .NET 5

J'aime cette idée. Cependant, en pratique, c'est quelque chose qui est plus susceptible d'être géré par l'équipe Xamarin.Forms.
Peut-être que l'équipe Core apporterait des constructions de bas niveau pour rendre le framework UX "meilleur" (comme ce que fait CoreFxLab).

Edit : WebAssembly pourrait-il également devenir une plate-forme prise en charge ?

J'aime l'idée. J'ai vu des gens (y compris moi-même) souffrir de plusieurs technologies d'interface utilisateur pour plusieurs environnements.

Je suis presque sûr que dans un avenir prévisible, nous verrons le noyau .net porté sur les appareils Android et iOS en utilisant l'application native en remplacement de corehost . Cela étant dit, des capacités d'interface utilisateur seront nécessaires.

Pour les bibliothèques de dessin 2D xplat (y compris le dessin accéléré), nous avons par exemple Skia.

Dans tous les scénarios, je pense que XAML-Standard sera une bonne chose à adopter afin de parvenir à un moyen standard de "décrire" l'interface utilisateur avec les directives de Fluent Design.

Cependant, je suis sceptique quant à l'intention de .Net Team d'investir du temps là-dessus plus que de simplement ramener quelques primitives xplat System.Drawing.X ...

@4creators Peut-être que cette discussion vous intéresse

@ vibeeshan025 WebAssembly ne remplace pas JavaScript, la plupart de vos commentaires n'ont donc aucun sens. Vous aurez toujours besoin de JavaScript pour connecter un WebAssembly au DOM. Donc, non, vous ne pouvez pas simplement compiler quelque chose dans wasm et vous attendre à ce qu'il remplace tout ce que vous avez fait auparavant avec JavaScript. Ce n'est pas comme ça que ça marche. Ce ne sera pas une technologie d'interface utilisateur.

Hé les gars, je veux juste mettre mon 5c ici.
System.Drawing.X est essentiel pour le développement .NET Core. (vient juste ici de https://github.com/dotnet/corefx/issues/20325)

À partir de l'interface utilisateur - demandez aux développeurs Web (frontaux). Ils utilisent beaucoup d'astuces modernes comme le rechargement à chaud.
Personnellement, j'aime la façon dont les choses progressent autour de React/ReactNative. Ce serait génial d'utiliser C # pour écrire React, puis d'utiliser divers moteurs de rendu pour différentes plates-formes.

FWIW, Mono adopte WebAssembly , donc si cela fonctionne en Mono, cela fonctionne (ou fonctionnera) dans WebAssembly. C'est l'idée/compréhension actuelle, du moins.

De plus, je dois faire écho au sentiment sur la probabilité que .NET/MSFT accomplisse cette tâche. Toute leur concentration / QI a été placée dans le noyau / les internes / le cadre / juste le faire fonctionner et je pense qu'il en sera ainsi pendant encore environ un an. Mais qui sait, je pourrais être (agréablement) surpris.

Mon point de vue à ce sujet est que certains efforts externes vont prendre de l'ampleur et être peut-être achetés par MSFT, ala Xamarin, mais plus axés sur l'interface utilisateur (par opposition à axés sur le cadre/l'outillage, qui est la principale force de Xamarin IMO). Ainsi, quelque chose comme Avalonia ou Noesis , qui offrent leur proposition de valeur via des canaux open source et payants, respectivement. Incidemment, les deux sont intégrés/supportent Mono.

Xaml Standard a un peu bougé avec la sortie de XAML Standard (Preview) pour Xamarin.Forms et une mise à jour attendue depuis longtemps sur l'avancement du projet . Il y a une discussion très intéressante dans PR dotnet/designs#111 sur les objectifs du projet qui semble aller dans le sens de cette proposition.

Silverilght est une excellente solution, le code existe déjà

1. Code Silverlight open source
2. Faire en sorte qu'il s'exécute au-dessus du runtime dotnet core
3. utiliser le clair de lune pour la distribution Linux
4. créer une alternative au noyau dotnet pour "Electron", il ira partout dans le monde (moins d'utilisation de la mémoire + amélioration considérable des performances + bonté xaml)
5. compilation native (si un jour le projet corert voit le jour)

Trouvé pertinent - http://platform.uno

@gulshan Intéressant, excellent projet, prend-il en charge la plupart des fonctionnalités UWP, comment ils ont pu mettre en œuvre un ensemble de fonctionnalités aussi riche en très peu de temps avec seulement 4 contributeurs.

@ vibeeshan025 ils ont une entreprise qui le finance IIRC...

Un autre avenir à explorer - HTML/CSS + .net (au lieu de JS/TS). Déjà essayé ici-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

Après des recherches, il semble que tcl/tk pourrait être une option graphique pour toutes les plates-formes. Vous ne savez pas si tcl/tk sous Windows invoque les éléments gdiplus réels, mais cela pourrait être une option pour apporter WPF et Winforms à Linux, Mac, Windows, Android ?, iOS ?, Et peut-être des formulaires Web ? Je ne sais pas si tcl/tk prend encore en charge ces 3 derniers. Si c'est le cas, cela rend l'enfer de l'interface graphique beaucoup plus facile à maintenir avec une base de code unique dessus.

Bibliothèques d'interface graphique possibles à utiliser :

• TclBridge (ne semble pas être gratuit ou open source)
• le Mono (probablement le meilleur peut-être)
• Eagle (je ne sais pas à quel point c'est bon)
• Peut-être d'autres aussi.

J'ai eu l'idée d'utiliser tcl/tk du module tkinner de cpython.

Vous ne savez pas non plus si .NET Core prend en charge le chargement de ressources à partir de * .resources (resx compilé) ou même à partir de * .resx pour le moment. Si c'est le cas, ce serait génial.

Microsoft.DesktopUI.App actuellement la v3.0.0-alpha-26921-3 est disponible avec les versions quotidiennes du SDK Windows .NET Core . Je suis curieux de savoir ce qui serait nécessaire pour le faire fonctionner sous Linux sous certaines couches de traduction pour GDC et DirectX.

Il faut bien plus qu'une UX multiplateforme, il doit s'agir d'un cadre de développement d'applications multiplateforme.
Le limiter au seul UX est une erreur. Il devrait au moins avoir toutes les fonctionnalités de SilverLight + RIA-Services.
Lorsque vous écrivez d'énormes systèmes personnalisés pour de grandes entreprises qui vivront pendant des décennies, vous devez garder toutes les options ouvertes car vous n'avez aucune idée des exigences qui seront ajoutées dans un an (ou dans 10 ans), donc un environnement fermé et limité comme UWP ne sera jamais pris en compte, de même avec quelque chose qui s'exécute dans un navigateur. Il doit y avoir un accès complet, illimité et natif à chaque fonctionnalité, API et service sur les différentes plates-formes.
Et lorsque vous développez un système dans lequel vous écrivez à la fois le serveur et le client, vous ne voulez pas utiliser REST ou quelque chose comme ça (qui est destiné à être utilisé lorsque vous écrivez le serveur et que quelqu'un d'autre écrit le client), au lieu de cela, cela devrait être dans l'esprit de RIA, où vous définissez l'API du serveur, puis l'appelez automatiquement depuis le client en utilisant les mêmes (===) classes et méthodes que celles du serveur. Tout doit être fortement typé. La validation des données commence par les limites strictes obtenues à partir des champs du serveur SQL (ou de la source de données que vous utilisez) et étendues par les DataAnnotations, qui sont automatiquement propagées jusqu'au client (en tenant compte de la localisation).

C'est ce qu'il faut, rien de moins n'est acceptable :
Créer un modèle de développement d'application client .NET ubiquitaire

Cela fait maintenant 20 ans que Visual Basic 6 est sorti, et nous sommes loin de la productivité que nous avions alors en 1998.Microsoft doit présenter sa vision sur la façon dont un système personnalisé plus grand devrait être fait dans un "monde Microsoft", et comment ils ramèneront la productivité que nous avions il y a 20 ans.

Microsoft doit se ressaisir et accepter la responsabilité qu'il a. Microsoft doit réaliser que tous ses clients, partenaires et développeurs qui ont investi massivement dans la technologie MS pendant des décennies sont profondément déçus et que leur confiance dans MS est très faible. Les MS doivent commencer à respecter leurs clients, partenaires et développeurs et reconstruire leur réputation et leur respect, mais vu ce qu'ils font maintenant avec Skype et comment ils traitent leurs clients et utilisateurs Skype, j'ai peu d'espoir que cela se produise.

Et oubliez Xamarin, Microsoft ne l'utilise même pas lui-même , et optez plutôt pour un framework mono-thread monopolisant la mémoire comme le framework ElectronJS (basé sur Chromium, Node.js, JavaScript et CSS), que d'utiliser Xamarin, qu'ils possèdent et avoir un contrôle total sur, et qui produirait un véritable code natif pour chaque plate-forme.

@Bartolomeus-649

Cela fait maintenant 20 ans que Visual Basic 6 est sorti, et nous sommes loin de la productivité que nous avions alors en 1998.

Et la diffusion de l'utilisation de l'ordinateur et d'Internet ainsi que la diversité des plates-formes (OS / mobilité / facteurs de forme) sont loin d'être aussi faibles qu'en 1998.

Ce que je sens que vous demandez, c'est "quelqu'un pour résoudre tous vos problèmes". Les raisons pour lesquelles cette diversité existe sont multiples, sinon nous utiliserions tous le même appareil avec le même système d'exploitation. Construire une "abstraction sur tout" est difficile et ne vous donne généralement que le plus petit ensemble de fonctionnalités possible. Xamarin a toujours la meilleure approche ici, vous permettant d'utiliser des API spécifiques à la plate-forme lorsque cela est possible. Mais même de bonnes abstractions pour les applications mobiles peuvent ne pas vous aider pour les applications de bureau à haute productivité.

Sur les autres points que vous soulevez, je pense qu'il s'agit principalement d'opinions ou d'observations personnelles qui s'appliquent à votre travail spécifique et non de déclarations généralement applicables.

J'espère que nous aurons de meilleures expériences multiplateformes, mais je ne pense pas que ce sera facile ou qu'il résistera à l'épreuve du temps. Même si les shells WebAssembly et Electron, les PWA et leurs amis évoluent vers la solution incontournable dans les 5 prochaines années, nous ferons peut-être quelque chose de complètement différent dans 20 ans (et nous nous plaindrons de la facilité des choses en 2018 😂 ).

Microsoft a répondu à nos attentes et à nos frameworks UX open source. Nous pouvons maintenant lancer des projets communautaires pour les porter sur d'autres plateformes. Malheureusement, MSFT a explicitement déclaré qu'il ne prévoyait de travailler sur aucun port, il semble donc que ce travail soit laissé à la communauté.

@richlander @karelz @AdamYoblick @llongley @kmahone

Ma question est de savoir si nous - la communauté pourrions travailler sur les ports Linux et macOS dans les référentiels existants, c'est-à-dire dans des branches distinctes ou devrions-nous créer des référentiels séparés pour prendre en charge de tels projets ? Il s'agit d'une décision très importante car l'utilisation des dépôts existants nous permettrait d'intégrer des ports à l'infrastructure MSFT CI qui, autrement, devraient être configurés à partir de zéro par la communauté.

Y a-t-il une raison pour laquelle Xamarin.Forms/Avalonia/Platform.Uno ne répond pas à vos besoins ? Il semble qu'une nouvelle tentative d'introduction de XAML multiplateforme apporte peu de valeur à la communauté dans son ensemble.

Pas 4creators, mais mes 2¢/impressions :

• Xamarin.Forms semble se concentrer principalement sur les scénarios mobiles.
• Idem pour Platform.Uno
• Avalonia n'est pas encore prêt pour le prime time. Trop bogué pour que je veuille lui faire confiance. (La dernière fois que je suis allé vérifier, l'application de démonstration ne serait même pas intégrée à la version stable actuelle, n'inspire pas vraiment confiance.)

Je ne dis pas qu'un port multiplateforme de WPF ou Winforms est la solution ici. (Un port multiplateforme compatible API de Winforms n'est même pas une bonne idée en premier lieu, IMO. Aucun commentaire sur WPF.) Cependant, je ne pense pas non plus que les solutions existantes conviennent au développement d'applications de bureau.

Bons points. Pourtant, nous devrions nous concentrer sur l'amélioration des solutions existantes au lieu d'en construire une autre, qui coûte beaucoup plus cher que la précédente.

Au fait, des problèmes avec NoesisGUI ?

la communauté pourrait fonctionner sur les ports Linux et macOS

@4creators Créez des fourches que vous possédez et sur lesquelles vous avez un contrôle total.

Infrastructure CI

L'infrastructure .NET Core CI évolue vers l'utilisation d'un Azure DevOps standard au lieu de la solution personnalisée actuelle basée sur Jenkins. Azure DevOps propose une offre gratuite pour les projets open source que vous pouvez exploiter.

Parlant uniquement pour dotnet/winforms :

Winforms utilise déjà AzureDevOps, et tout PR dans le maître exécutera automatiquement la build PR CI.

Cependant, je suis presque sûr que tout travail doit être fait dans une fourchette. Nous ne prévoyons pas d'accorder un accès en écriture à dotnet/winforms juste pour que les gens puissent créer leurs propres branches. Avec toutes les contributions publiques, cela polluerait pas mal notre repo. :)

Au fait, des problèmes avec NoesisGUI ?

D'une manière ou d'une autre, NeosisGUI a été épargné de mes notes que je conserve sur divers frameworks d'interface utilisateur, j'ai donc dû le revoir.

Je ne l'ai pas utilisé, même si j'avais l'intention de l'essayer. J'ai l'impression qu'il est destiné à prendre en charge l'interface utilisateur du jeu, il pourrait donc ne pas convenir aux outils. (Bien qu'en regardant la liste des contrôles, cela pourrait être une mauvaise hypothèse.) Pour l'interface utilisateur dans le jeu, nos besoins ne justifient pas le coût futur. Il ne prend pas non plus en charge la Nintendo Switch pour une raison quelconque. (Bien qu'apparemment c'est un travail en cours .)

@4creators Je pense que ce problème est mal intitulé, à cause de la confusion de deux problèmes.

Tout d'abord, permettre aux frameworks d'interface utilisateur .Net d'utiliser .Net Core au lieu d'autres runtimes .Net . WPF peut maintenant fonctionner sur .Net Core, et ils pourraient également exécuter Xamarin.iOS/Android/Mac/GTK sur .Net Core. Cela présente des avantages en termes de performances et de maintenance par rapport à l'utilisation de Mono ou de .Net Framework.

Cependant, cela ne crée pas un nouveau cadre d'interface utilisateur multiplateforme . Et les fils de discussion auxquels vous faites référence et la plupart des articles ici concernent la création d'un nouveau cadre d'interface utilisateur multiplateforme. L'exécution n'est pas le problème principal ici. Cependant, ces threads sont extrêmement confus car ils ne résolvent pas les difficultés réelles de mise en œuvre de l'interface utilisateur multiplateforme, que les implémentations réelles (Xamarin.Forms utilisant largement des contrôles natifs et Avalonia utilisant un rendu commun) ont résolues.

Il est préférable de travailler à l'amélioration des capacités du bureau Xamarin.Forms en ajoutant les contrôles de bureau pertinents (pas difficiles), ou de contribuer à rendre Avalonia stable si vous préférez. Toute nouvelle plate-forme (même si elle est basée sur une plate-forme existante) prendra des années de travail pour atteindre la qualité alpha, et la seule justification pour refaire Xamarin.Forms & Avalonia plutôt que d'y contribuer est qu'ils le font tous les deux tort.

Je suis d'accord sur la dernière partie. Cependant, l'équipe Xamarin a explicitement déclaré que le remplacement de Mono par .NET Core est irréalisable car ils sont optimisés pour différentes charges de travail et un travail d'intégration non trivial important devra être effectué.

Je pense que ce problème est mal intitulé, à cause de la confusion de deux problèmes.

@charlesroddie IMO, pas vraiment. Le but n'est pas d'avoir un framework UX disponible sur la plate-forme .NET Core mais plutôt l'UX qui fait partie de l'écosystème DotNet créé et maintenu conjointement avec d'autres parties. Les plans futurs de MSFT pour l'écosystème .NET sont basés sur .NET Core avec .NET Framework obsolète pour devenir un composant Windows hérité non recommandé pour le développement de nouvelles applications. Il n'est actuellement pas prévu de porter Xamarin.Forms vers .NET Core pour certaines raisons indiquées ci-dessus par @ Happypig375 et l'autre raison étant un manque de décision quant à la manière de procéder avec le support xplat sur mobile. Cependant, je suppose qu'en raison de l'effort de développement investi dans .NET Core, la future plate-forme xplat utilisée par MSFT sera basée sur .NET Core.

Mono n'est pas suffisamment optimisé pour de nombreuses charges de travail, même sous Linux, et il n'y a plus de nouvelles fonctionnalités majeures développées en plus de ce runtime. BCL est actuellement partagé entre Mono et .NET Core. Cela indique une forte probabilité de dépréciation de Mono à l'avenir.

Sur la base de ces hypothèses, je pense qu'il vaut la peine d'avoir une seule plate-forme UX basée sur .NET Core dans le cadre de son écosystème. Par conséquent, le titre du problème est exactement ce qu'il devrait être puisque je ne demande pas un framework UX basé sur xplat et la norme CLI, mais un framework UX qui fait partie de l'écosystème .NET Core conçu et pris en charge par l'équipe DotNet.

.Net Standard garantit que les différents runtimes de l'interface utilisateur peuvent faire partie du même écosystème sans problème. Bien que .Net Core présente des avantages par rapport aux autres runtimes, qui peuvent éventuellement être dépréciés, il n'est pas nécessaire de lier le runtime à la recherche de la bonne approche pour l'interface utilisateur multiplateforme. Cela complique juste la question.

C'est aller trop loin de dire qu'une plateforme UX est "basée sur" un runtime particulier. @ Happypig375 Il n'est pas actuellement dans les plans de Xamarin de passer à .Net Core (les plans étant plutôt de laisser Mono devenir plus similaire à .Net Core en partageant le code). Mais cela ne devrait pas être plus difficile que de déplacer WPF vers .Net Core.

(BTW, il n'est pas vrai que Mono n'a pas de nouvelles fonctionnalités car il est mis à jour pour prendre en charge .Net Standard 2.1, et le travail actuel sur l'assemblage Web est effectué dans Mono plutôt que .Net Core. Mais c'est un aparté car ce travail peut être porté à .Net Core.)

Feuille de route WinUI 3.0 - nous avons besoin de votre avis !

Il semble que cette proposition de développement pourrait ouvrir de nouvelles possibilités xplat une fois que tous les composants requis seront open source.

Ils devraient envisager de l'appeler MicrosoftUI 1.0 si tel est le cas, @4creators. 😆

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

Je pense que ce problème est résolu par ce dépôt.