Ce sont mes premières réflexions sur les questions que vous avez posées dans le contenu du numéro.

Je viens du point de vue de la conception et de l'utilisateur, avec seulement une petite expérience en développement, qui s'est beaucoup intéressé au développement de Silverlight/Windows Phone 7 à l'époque et qui se sent maintenant un peu brûlé.

Quels modèles vous intéresseraient le plus ?

Je pense qu'avant de demander une liste d'idées de modèles, il doit y avoir une sorte d'audit des applications les plus importantes et les plus utilisées dans chaque framework, donc WPF, UWP, WinForms, MFC, etc.

Examinez la "silhouette" de ces applications et découvrez les scénarios UX courants.

Au dessus de ma tête, il y a :

• Menu principal (Tous les frameworks)
• MDI (plusieurs documents dans une seule fenêtre) (MFC principalement)
• Onglets et grille de données (WPF, WinForms, MFC)
• Ruban (applications Win32 Office, 3ds max, peinture, wordpad, explorateur de fichiers, etc.)
• Utilitaires de la barre d'état système (MFC, WinForms)
• Navigateurs
• Assistants (WPF, MFC)
• Applications MDI complexes (logiciel Adobe, Visual Studio)
• Lecteurs multimédias
• Data Visualisation LoB (WPF et Web)
• Applications sociales (React Native, PWA - Skype, Facebook, Twitter)

Tous ou certains d'entre eux pourraient bénéficier de l'intégration du système WinRT/UWP avec Notifications/Action Center.

Tous ces nouveaux modèles de projet doivent éviter les espaces de noms Windows.Xaml intégrés, le thème de contrôle WPF et les styles visuels WinForms au profit de nouveaux modèles et styles visuels qui correspondent aux conceptions de contrôle FabricWeb/Fluent.

Il devrait également y avoir un moyen facile pour les développeurs avec les applications WPF et WinForms existantes d'ajouter une dépendance WinUI 3.0 qui leur donne les nouvelles conceptions de contrôle avec une simple instruction d'utilisation ou une entrée de manifeste

Îles XAML

Comme Xaml Islands devient plus facile à rendre possible - remplacer les anciens contrôles Webview, les sélecteurs de couleurs, les dialogues basés sur XAML pourrait être aussi simple qu'ajouter un nouveau... et choisir un dialogue, ou un contrôle standard dans lequel le code C# et C++ existant peut appeler, et ils ont leur propre code derrière.

Les modèles d'applications et de pages modernes comme les applications Xbox Next, NavigationView, Master/Details, Hubs, Modern Ribbon, NavigationViewTop et Pivot - pourraient tous être mis à disposition pour toutes les plates-formes de présentation Windows - avec des îles XAML en place et des exemples de contenu.

Tous ces scénarios qui ne sont actuellement pas possibles dans UWP XAML doivent être dotés de contrôles et de modèles pour les rendre plus faciles.

Cela aiderait-il si Visual Studio ou un autre outil mettait automatiquement à jour les espaces de noms pour vous ?

Cela devrait être une question posée lorsque quelqu'un ouvre son projet sur la dernière version de Visual Studio avec un SDK Windows 10 actuel. Appuyez sur le bouton et il remplace les espaces de noms et l'utilisation, ou les marque s'il ne s'agit pas d'un contrôle avec lequel il est familier.

Sur les nouveaux projets, ce devrait être la valeur par défaut et le package nuget installé avec les futures versions du SDK Windows.

Quelle serait votre solution préférée pour utiliser les composants UWP avec WinUI 3 ?

Comme pour la réponse de mise à jour automatique, les nouvelles pages et projets doivent l'inclure par défaut et un message leur demandant s'ils souhaitent passer automatiquement à WinUI | Ajouter des commentaires ToDo pour mettre à jour les espaces de noms | Ne passez pas à WinUI .

Pour quel type d'applications seriez-vous le plus enthousiaste à l'idée d'utiliser WinUI 3.0 ?

En tant qu'utilisateur, je souhaite que toutes les applications fonctionnant sous Windows partagent une interface utilisateur et une expérience utilisateur communes, quel que soit le framework utilisé.

Je veux que les applications soient installées sans déranger le registre et sans laisser de déchets. (donc centenaire)

Je veux que toutes les applications soient installables depuis le magasin ou depuis un installateur de type Centennial. Virtualisez les dossiers système et Windows pour chaque application.

Moderniser une application C++ MFC avec Fluent UI ?

L'acrylique doit être disponible pour les applications WPF, WinForms et MFC, et inclus dans les nouveaux modèles par défaut via une dépendance ou un manifeste WinUI 3.0. Les CommonControls et les styles de fenêtre doivent utiliser des barres de titre acryliques et étendues (qui peuvent être remplacées pour revenir aux valeurs par défaut actuelles)

Les applications Win32 non UWP de Microsoft doivent toutes être recompilées avec WinUI 3.0 afin qu'elles utilisent toutes des cadres de fenêtre en acrylique, des menus principaux, des thèmes, des menus contextuels , des champs de texte, des barres de progression, etc.

Et puis les applications existantes ont besoin d'une solution simple à déposer dans WinUI 3.0+ qui met ensuite à jour l'apparence de tous les contrôles - ou la possibilité de l'appliquer de manière sélective une boîte de dialogue à la fois, jusqu'à ce que l'ensemble de l'interface utilisateur soit mis à jour.

re: espaces de noms, je m'attendrais à ce qu'ils changent simplement en fonction de la cible, même si cela nécessite des espaces de noms conditionnels.

Voici mes réponses :

Création d'une nouvelle application

Quels modèles vous intéresseraient le plus ?

• J'adorerais voir c++/winRT win32+xaml et .net core+xaml en premier, les modèles UWP venant en second, l'application win32 packagée ne devrait pas être un modèle, car les modèles de package d'application actuels devraient simplement fonctionner comme ils le font déjà avec applications win32/.Net.
• De plus, j'aimerais voir des modèles d'éléments tels que "Nouvelle fenêtre XAML" avec un code passe-partout pour l'afficher dans une application d'application principale win32 ou .net existante (par exemple : créer une application système existante à la Docker Desktop, capable d'afficher un nouvelle fenêtre Xaml de niveau supérieur)

Ajout de WinUI 3.0 aux applications Win32 existantes

• la non compatibilité descendante est la raison exacte pour laquelle je n'ai jamais utilisé d'îles xaml sur un vrai projet (je l'ai utilisé pour le plaisir sur des trucs personnels cependant). Le découplage du cadre d'interface utilisateur de l'API Windows est l'une des plus grandes choses annoncées avec la feuille de route WinUI 3.0 (avec la possibilité pour les applications de ciblage non packagées / non uwp de l'exploiter)

Mise à jour de votre application UWP Xaml existante vers WinUI 3.0

Cela peut sembler dur, mais j'ai l'impression que l'application UWP xaml est une niche (depuis la chute du téléphone Windows, il n'y a plus de traction vers UWP en tant que plate-forme cible), et même si l'outillage / l'interopérabilité serait bien d'avoir, je ne Je ne pense pas que cela devrait être l'objectif principal de WinUI 3.0.
Ainsi, les outils de mise à jour de l'espace de noms (qui peuvent être effectués à l'aide d'une recherche et remplacement globaux) et le mélange de xaml UWP et xaml WinUI ne me semblent pas essentiels.

Aussi, je veux juste mentionner qu'il s'agit d'une décision très bienvenue, et que l'ensemble du framework d'interface utilisateur open source sur Github est génial ! Merci beaucoup d'avoir fait ça !

Tout d'abord, c'est une belle initiative ! Malheureusement, je ne peux pas négliger le fait que je me sens un peu blessé par la façon dont Microsoft a traité les quelques derniers développeurs sur sa plate-forme. Pour le moment, je n'utilise UWP que pour les applications destinées aux

1. WPF est bien plus mature que WinUI (validation, contrôles existants, etc.), donc pour les entreprises, WPF convient mieux
2. UWP est idéal pour plusieurs catégories d'appareils (mobile, tablette, ordinateur de bureau, etc.), c'est là que se trouvent les consommateurs

C'est formidable de voir que le point 1 pourrait être abordé avec WinUI, ce qui me rend enthousiaste quant aux progrès de WinUI. Malheureusement 2 n'est plus applicable (plus d'appareils sympas, juste des ordinateurs de bureau). On se demande, au moment où ce produit est livré (1 an plus tôt ?), de quoi les développeurs auraient-ils besoin à ce stade.

Je pense que les produits de consommation ne font plus partie de l'équation, ce navire a navigué avec la "stratégie" de retranchement. Donc, la seule chose pour laquelle cela pourrait être bon, ce sont les applications d'entreprise.

En général, je serais plus intéressé par une bonne stratégie de migration de WPF vers WinUI pour essayer de migrer notre énorme base de code WPF vers Windows 10. L'inconvénient de devoir mettre à jour les applications destinées aux consommateurs (actuellement UWP) est qu'elles dépendent fortement sur les développeurs de composants externes (par exemple, win toolkit, etc.). Je pense qu'il n'y a plus d'option viable pour les mettre à jour puisque la plupart des développeurs (à ma connaissance) ont perdu tout intérêt pour le développement de clients grand public / Windows.

Réponses aux questions

Création d'une nouvelle application

Quels modèles vous intéresseraient le plus ?

J'adorerais voir .net core / xaml / C# ici, car je pense que c'est la combinaison de langues la plus utilisée. Mais peut-être qu'un modèle de migration serait mieux ici (essayez de faire participer tout le monde le plus rapidement possible, plus cela prendra de temps, plus cela deviendra douloureux).

Ajout de WinUI 3.0 aux applications Win32 existantes

Je pense que c'est extrêmement bien, et nous l'utiliserions beaucoup (mais en réalité, c'est dans au moins un an puisque les clients d'entreprise sont toujours sur Windows 7, même lorsque le support MS se termine, les entreprises seront sur Windows 7). Ensuite, nous pouvons migrer lentement WPF vers WinUI 3.

Connaissez-vous les îles Xaml pour la modernisation des applications de bureau ?

Oui, mais trop de clients utilisent (ou étaient) Windows 7, ce n'était donc pas une option pour les développeurs d'entreprise. Et pour les consommateurs, vous pouvez de toute façon utiliser UWP.

Cette compatibilité ascendante étendue sur Windows 10 rend-elle les îles Xaml plus utiles pour vous ?

C'est un bon début car au moment de la livraison de ce produit, il fonctionnerait sur toutes les versions prises en charge de Windows 10 dans l'entreprise.

Mise à jour de votre application UWP Xaml existante vers WinUI 3.0

Les applications grand public pour MS sont terminées, tout cela à cause des choix faits par MS, il n'y a plus de place pour cela. Je voudrais simplement sauter toute cette option et l'oublier. C'est triste parce que j'ai mis des milliers d'heures dans les applications UWP, mais je pense que nous devons rendre cette mort rapide pour la rendre moins douloureuse.

Toute l'histoire promise était toujours à jour, prend en charge tous les appareils. Je pense que nous savons tous dans quel sens cette promesse s'est déroulée.

Cela aiderait-il si Visual Studio ou un autre outil mettait automatiquement à jour les espaces de noms pour vous ?

S'il ne s'agit que d'espaces de noms, une recherche/remplacement devrait également faire l'affaire.

Quelle importance accordez-vous à la compatibilité totale entre les composants UWP Xaml existants et les applications WinUI 3.0 ?

Ce n'est plus important, je suis prêt à perdre des milliers d'heures de développement, il n'y a plus d'utilisateurs de toute façon.

Créez-vous ou utilisez-vous des bibliothèques de contrôle UWP Xaml ou des composants WinRT que vous ne pouvez pas facilement recompiler et mettre à jour avec le code de l'application ?

Nan.

Quelle serait votre solution préférée pour utiliser les composants UWP avec WinUI 3 ?

Îles UWP (sorte de composants hébergés)

Général

Que pensez-vous du plan global 3.0 décrit ci-dessus et dans la feuille de route ? Cela vous permettrait-il d'utiliser WinUI pour vos applications Windows nouvelles et existantes ?

Il a probablement besoin de mûrir, mais je me vois utiliser ce truc dans 1 à 2 ans pour le développement d'entreprise. Selon la difficulté de migrer, nous choisirons soit WinUI, soit Web (selon la façon dont Windows lui-même "évolue").

Pour quel type d'applications seriez-vous le plus enthousiaste à l'idée d'utiliser WinUI 3.0 ? Créer une nouvelle application Win32 et l'emballer avec MSIX ? Ajouter de nouvelles vues à une application WPF ? Moderniser une application C++ MFC avec Fluent UI ?

Probablement en ajoutant simplement de nouvelles vues à une application WPF et en commençant lentement la migration.

J'aime beaucoup cette feuille de route. UWP doit être libéré de ses chaînes, et c'est un excellent moyen de le faire.

Mise à jour de votre application UWP Xaml existante vers WinUI 3.0

C'est très important pour mon employeur. Nous avons une application de bureau UWP complexe dans le magasin. Nous avons maintenant besoin de Desktop Bridge pour accéder aux API win32 qui ne sont pas prises en charge par .NET Native.

je voudrais

• accès direct à toutes les API win32 ;
• en utilisant un ancien modèle d'exécution win32. Je suis d'accord avec certains sandboxing de type Desktop Bridge (par exemple, la virtualisation du registre) ;
• mettre notre application dans le magasin (msix) telle qu'elle est actuellement ;
• continuer à utiliser WNS (notifications push) ;
• une expérience de mise à jour indolore d'UWP vers un nouveau type d'application Xaml Desktop. Cela ne me dérange pas de faire du travail manuel. Peut-être que je préfère une bonne documentation à l'outillage ici.

Quelle importance accordez-vous à la compatibilité totale entre les composants UWP Xaml existants et les applications WinUI 3.0 ?

Les styles existants devraient toujours fonctionner. Je peux vivre avec quelques changements visuels mineurs. Mais pas avec des changements de comportement.

Créez-vous ou utilisez-vous des bibliothèques de contrôle UWP Xaml ou des composants WinRT que vous ne pouvez pas facilement recompiler et mettre à jour avec le code de l'application ?

Non.

Quelle serait votre solution préférée pour utiliser les composants UWP avec WinUI 3 ?

S'ils ne peuvent pas être recompilés (tierce partie) : approche de type Xaml Islands. Sinon, il devrait être possible de les porter facilement sur WinUI 3.

Général

Pour quel type d'applications seriez-vous le plus enthousiaste à l'idée d'utiliser WinUI 3.0 ? Créer une nouvelle application Win32 et l'emballer avec MSIX ? Ajouter de nouvelles vues à une application WPF ? Moderniser une application C++ MFC avec Fluent UI ?

• Applications de bureau win32, fournies avec MSIX.
• Uno applications multiplateformes ;)

Veuillez ne pas introduire de nouveaux espaces de noms pour des éléments tels que _INotifyDataErrorInfo_ - ils doivent être utilisés dans les modèles de vue qui sont généralement multiplateformes et ne doivent pas dépendre de WinUI. Il doit être défini où se trouvent d'autres éléments de ce type (c'est-à-dire _INotifyPropertyChanged_ ou _INotifyCollectionChanged)_

Je voudrais juste savoir si le but ultime est de créer une pile d'interface utilisateur multiplateforme. Comprendre cela pourrait ne pas être complètement compris comment nous y arrivons. Cependant, si c'est l'intention... il serait préférable de marquer cela sans les références Win au début de cet effort. Ce sera moins de maux de tête à long terme si vous le faisiez.

Serait-il préférable d'étiqueter comme XamlUI ou similaire ? Les espaces de noms Microsoft.UI.* sont corrects , il suffit de marquer le XamlUI 3.0 ou similaire.

Merci d'avoir tendu la main. Attendez avec impatience ce qui va arriver dans cet espace :sourire:

Pour moi, tous les détails techniques sont moins importants.
UWP, WPF ou tout autre framework Windows, aussi génial soit-il, ne suffira pas tant qu'il ne fonctionnera pas sur toutes les plates-formes (au moins Windows, Droid, iOS et Web) et est convivial avec n'importe quelle taille d'écran.

TBH m'a déçu lors de la dernière Build pour découvrir que MS n'a pas l'intention de rendre UWP ou XAML multiplateforme. Uno n'a obtenu aucune reconnaissance officielle autre qu'un discours. Encore plus frustrant, je dirais blessant, a été de découvrir que MS accorde encore tant d'amour aux frameworks React Native et HTML/JS (WinJS), tout en négligeant les développeurs de la pile .NET responsables.
Je voudrais voir MS créer officiellement une pile d'interface utilisateur multiplateforme comme Uno, et fournir les bons outils, modèles et support intégré.

Et BTW, je travaille avec XF depuis son acquisition par MS, et j'aurais aimé qu'il y ait une alternative, pour les raisons suivantes : a. Pas de support Web, b. Très mobile, pas d'amour pour les ordinateurs de bureau c. Sa hiérarchie de bibliothèque semble bâclée, certainement par rapport à la bibliothèque de contrôle WPF/UWP d. N'utilise pas MS XAML.
Voici la demande de fonctionnalité que j'ai publiée sur la communauté des développeurs Microsoft : .NET UI Standard .

Merci à tous !

Nous avons besoin d'une interface utilisateur XAML qui s'exécute également sur le Web (Assembly). Au moins un sous-ensemble de UWP.
Pourquoi ne pas adopter la plate-forme UNO et faire le rendu Web à l'aide de SkiaSharp ?
Pourrait être Silverlight 6 , l'homologue Web de WinUI

Réponses rapides aux questions

Quels modèles vous intéresseraient le plus ?

Projets de style SDK .NET core, ou un format de projet MSVC simplifié.
Les anciens fichiers de projet sont trop compliqués à modifier manuellement, et il existe des tonnes de problèmes d'interaction entre l'ancien et le nouveau système de projet. Nous devrions totalement abandonner l'ancien système de projet pour de tout nouveaux projets.

Connaissez-vous les îles Xaml pour la modernisation des applications de bureau ?

Non. Je réécris mon application avec un changement complet du modèle de données, il n'y a donc pas de migration progressive.

Cette compatibilité ascendante étendue sur Windows 10 rend-elle les îles Xaml plus utiles pour vous ?

Il y a encore beaucoup d'utilisateurs sur Windows 7 et les îles Xaml ne peuvent pas aider.

Quelle importance accordez-vous à la compatibilité totale entre les composants UWP Xaml existants et les applications WinUI 3.0 ?

Non. Tous mes composants sont auto-écrits, ou issus de MUX et WCTK, je peux donc effectuer une migration manuelle rapide.

Cela aiderait-il si Visual Studio ou un autre outil mettait automatiquement à jour les espaces de noms pour vous ?

Non, car mon projet n'est pas grand (~20 pages et ~10 contrôles personnalisés pour l'instant).

Quelle serait votre solution préférée pour utiliser les composants UWP avec WinUI 3 ?

J'aimerais qu'il y ait une version livrée avec le système d'exploitation, pour permettre de créer de très petits outils et de les expédier en KB . L'outil ne fonctionne tout simplement pas sur un système d'exploitation inférieur, car l'utilisateur supposé peut immédiatement me contacter (par exemple via un logiciel de discussion).

Pour quel type d'applications seriez-vous le plus enthousiaste à l'idée d'utiliser WinUI 3.0 ? Créer une nouvelle application Win32 et l'emballer avec MSIX ? Ajouter de nouvelles vues à une application WPF ? Moderniser une application C++ MFC avec Fluent UI ?

Création d'une nouvelle application Windows 10 uniquement et livraison sans le magasin.
La signature de confiance est coûteuse pour les développeurs individuels, et le téléchargement vers le magasin ne s'applique pas aux applications spécifiques à un domaine et non à long terme.

Mon look personnel pour la plate-forme d'interface utilisateur

Chaîne d'outils Xaml

Le langage xaml n'est en quelque sorte pas sérieux, et je suis confronté à de nombreux problèmes tels que "comment dois-je représenter cela". WPF xaml et UWP xaml ne sont pas entièrement compatibles, je dois donc me souvenir de leurs différences. Xaml n'est pas entièrement compatible avec les fonctionnalités .NET, j'ai donc parfois besoin d'écrire des astuces laides dans mon modèle et une classe d'aide.

Avec x:Bind , les choses deviennent encore pires. Les scénarios simples sont faciles à utiliser, mais c'est très compliqué de faire des choses qui sont plus qu'un accès à la propriété. Par exemple, il ne prend pas en charge la surcharge de méthode, je dois donc compiler pour vérifier quelle surcharge est choisie pour cette expression de liaison. Je ne peux même pas faire un simple commutateur ou une conversion "visible lorsqu'une propriété est fausse", et une méthode d'assistance est requise. La documentation ne dit rien sur ces scénarios détaillés, donc je pense qu'il devrait y avoir une place pour une discussion sur la conception du langage xaml et faire de xaml un langage conçu sérieusement comme C#.

L'éditeur xaml est également difficile à utiliser. Il est raisonnable pour le concepteur d'essayer d'exécuter du code pour montrer les effets réels, mais l'éditeur de texte doit simplement être conscient des métadonnées. L'ouverture d'un fichier xaml dans la vue source est lente car elle active le concepteur et génère des exceptions d'interaction pour un xaml totalement parfait, comme NullReferenceException et Cannot convert __ComObject to some type . Il touche ProjectReference via des bibliothèques construites et entraîne une erreur compliquée même lors d'une simple modification dans une zone api non publique dans la bibliothèque de dépendances, généralement l'implémentation du modèle de données. Je pense donc qu'il devrait y avoir un compilateur xaml entièrement intégré à Roslyn, tenant compte des métadonnées et du code source.

Un meilleur modèle de fenêtrage

Il est courant pour les applications pleines d'informations et d'états d'utiliser un modèle multi-fenêtres au lieu de naviguer dans le modèle. Actuellement dans UWP, la création d'une nouvelle fenêtre à l'aide de ApplicationView est pénible car il y a des problèmes de threading. Le nouveau AppWindow partage le thread d'interface utilisateur, et je ne suis pas sûr de ses performances d'interface utilisateur.

La réécriture de Visual Studio dans WinUI à un moment donné peut prouver qu'il s'agit d'un système d'interface utilisateur mature.

Interfaces de liaison de données

Nous sommes très fatigués de créer des modèles implémentant INotifyPropertyChanged . J'ai écrit une tâche MSBuild personnalisée pour convertir un XML en accesseurs de propriété étendus, mais cela n'aide pas lorsque je veux faire quelque chose de personnalisé dans le setter lorsque la propriété change.

Et il y a des problèmes de filetage. Mes données proviennent entièrement d'un serveur réseau en arrière-plan, donc la capture de contexte pour await ne peut pas m'aider. Dans WPF et Binding , c'est tel quel car Binding résout le threading lui-même. Lors du passage à x:Bind , je dois le résoudre dans le déclencheur d'événements, car x:Bind opère simplement sur le thread appelant. Les choses deviennent encore pires lorsque j'ai plusieurs vues d'application touchant les mêmes données, ce qui signifie qu'il n'y a pas de répartiteur d'interface utilisateur global disponible, et la seule solution consiste à capturer SynchronizationContext.Current lors de l'inscription à l'événement. Pour les collections, ItemsSource n'est pas non plus thread-safe et la même solution de contournement est requise.

Il devrait certainement y avoir une chaîne d'outils pour résoudre les problèmes de modélisation, de threading et d'extension pour les modèles pouvant être liés mutables. Et une solution générique intégrée pour la collection pouvant être liée devrait fournir un mécanisme pour « la propriété spécifiée de tout enfant modifié ».

IObservableVector<T> est un faux type générique qui ne peut utiliser que object , INotifyCollectionChanged n'est pas générique. Il ne suffit pas de l'implémenter pour une collection intégrée comme ObservableCollection<T> , en particulier pour les scénarios compliqués, orientés ISupportIncrementalLoading / IItemsRangeInfo . La plate-forme doit fournir une implémentation abstraite par défaut avec les meilleures pratiques, permettant à l'utilisateur d'implémenter simplement une méthode de remplissage de données abstraite.

@shaggygi @weitzhandler @TonyHenrique

S'il doit y avoir un avenir multiplateforme pour UWP/XamlUI3.0, l'abstraction de la syntaxe XAML, du moteur de rendu Windows et du reste de Windows Runtime serait un moyen de le gérer.

S'il pouvait y avoir une mentalité presque plug-in avec le projet, il pourrait y avoir un moteur de rendu Android ou iOS/AppKit, et un module Android/iOS AppKit Shim pour transmettre les API ART en C# et VB, ainsi que le langage C++, C existant Support.
Xamarin pourrait aider ici.

Microsoft n'a pas besoin d'être celui qui travaille sur ces moteurs de rendu de plate-forme alt.

Mais en se concentrant sur Windows pour l'instant... WinUI 3.0 pourrait englober Fabric Web / React Native / WPF / WinForms / MFC. Les PWA seront également un citoyen de première classe pour le développement d'applications, il existe donc des histoires multiplateformes pour les applications qui ne sont pas directement conçues pour Windows/.NET/UWP.

Ce qui est nécessaire maintenant, c'est de fournir une histoire aux développeurs C#/.NET/UWP pour apporter leurs applications et leurs investissements au paysage plus large des plates-formes.

Mes 2 cents : je suis un développeur Xamarin.Forms et (comme beaucoup d'autres) je souhaite voir tous les dialectes XAML fusionnés en un seul qui fonctionne partout, y compris l'espace mobile. Je ne sais pas comment cela se passerait, mais c'est du moins mon souhait à ce sujet.

À partir de WinUI 3.0 peut-être - mais il y a trop d'applications WPF pour s'attendre à ce qu'elles réécrivent et traduisent tout ce XAML. Les nouveaux projets WPF pourraient utiliser le dialecte WinRT XAML plus moderne. Vous pouvez introduire l'équivalent d'un DocType en XAML afin que différents dialectes puissent coexister dans le même projet.

Plus facile à dire qu'à faire bien sûr.

@mdtauk Je pense qu'une fois que la plate-forme Xaml sera réellement open-source, nous aurons une meilleure compréhension de ce sur quoi elle repose en bas de la pile (nous savons déjà que les principales dépendances spécifiques à la plate-forme sont DirectX11, Direct2D et Windows Media Foundation, mais qui sait quelle partie du SDK Windows y est utilisée) et comment elle est superposée (afin que nous puissions avoir une idée réelle de la faisabilité de tout portage).
De plus, nous devons encore voir sous quel type de licence le code source sera distribué. Je ne sais pas si c'est encore décidé.

Android utilise Vulkan et je pense qu'il prend en charge OpenGL
iOS et macOS utilisent Metal

En ce qui concerne les codecs multimédias, il peut être possible d'utiliser des API natives basées sur C pour les remplacer.

@simonferquel Cela deviendra plus clair lorsque le code sera

Je pense que changer l'espace de noms était une approche raisonnable lorsque winui était une collection de contrôles. Cependant, maintenant qu'il remplace fondamentalement la plate-forme, je pense que cela n'est plus justifié. Cela fonctionne déjà de la même manière pour WPF/Winforms, où le code peut être déplacé de .net Framework vers .net core sans modifier les espaces de noms dans le code. La plate-forme devrait automatiquement pouvoir charger les versions winui des dll nécessaires lorsqu'elle est activée. De cette façon, la compatibilité source et binaire (j'ai utilisé avec succès les bibliothèques de framework .net dans les applications de base .net) peut être préservée.

Je voulais juste remercier tout le monde pour les commentaires jusqu'à présent! L'équipe WinUI examine attentivement toutes les réponses et tous les points.
Nous allons également probablement séparer certains problèmes ciblés pour parler de points spécifiques qui ont été soulevés (par exemple, la compatibilité avec les frameworks et composants UWP existants) une fois que nous aurons organisé nos pensées.

Je veux juste remercier MS d'avoir écouté davantage et d'avoir donné aux développeurs .net des outils impressionnants, mais je ne peux m'empêcher d'être déçu de l'avenir d'UWP Xaml après la conférence de construction.
En lisant ce blog et de nombreux articles sur le net, vous avez le sentiment que UWP devient exclusivement « entreprise » et même cela est discutable car de nombreuses entreprises deviennent de plus en plus indépendantes du système d'exploitation, permettant aux travailleurs d'utiliser par exemple des MacBook Pro.

Permettez-moi d'être clair que je suis fortement investi dans UWP natif et Xamarin Forms (Android, iOS) et que j'aime la plate-forme, mais après que MS a annoncé la prise en charge native de React, je suis sur le point de quitter le navire.

Je sais que je dois rendre mon application UWP plus indépendante de la plate-forme sur le bureau. J'espérais donc pouvoir créer une "application hybride" avec mon application uwp actuelle en tant que shell et en incorporant de plus en plus de technologies Web front-end en utilisant React dans le mix . Quelque chose comme la fonctionnalité "Ensembles" proposée que je comprends est maintenant retardée en raison de priorités plus élevées dans Edge, aurait été idéal pour ma solution actuelle car elle brouille totalement les frontières entre UWP native et les technologies Web en exécutant la technologie native ainsi que la technologie Web dans « fenêtres/onglets de bord ». Cette approche « hybride » me permettra d'intégrer lentement la technologie Web dans ma plate-forme actuelle, mais donnera également aux « applications natives » un onglet dans le « navigateur » pour ainsi dire. (du point de vue du consommateur) Cela me fournit également une issue de secours si les «applications uwp natives» échouent à long terme sur le bureau.

La raison de la réflexion ci-dessus est que UWP ne me fournit pas de trappe d'évacuation car il peut facilement devenir la prochaine victime de Silverlight s'il n'y a pas de capacité multiplateforme bientôt. MS couvre ses paris en s'assurant qu'ils ne perdent pas la tendance PWA ou que leur main se tourne vers la prise en charge native de React sur Windows. Le problème est que j'ai pris un pari en espérant qu'à ce moment-là, il y aura un "chemin" pour UWP/c#/.net dans le navigateur ou la plate-forme croisée et que je pourrai réutiliser la plupart de mon investissement dans ces plates-formes.

Je me souviens quand tous les développeurs ont crié d'acheter Xamarin, il a fallu une éternité à MS pour le faire. Je pense que la plupart des développeurs familiarisés avec l'assemblage Web savent qu'ils ont récemment réussi à exécuter une "version complète" de Windows Server en assemblage Web diront d'acheter la plate-forme Uno et de la rendre énorme avec un investissement important. Si un système d'exploitation complet peut fonctionner sur un assemblage Web, MS devrait donner à chaque développeur .net un chemin de migration vers une capacité multiplateforme afin de protéger leurs investissements existants.

Vous pourriez dire que Blazor est là, mais franchement, avant d'investir plus de temps dans une nouvelle plate-forme, je préfère apprendre React ou vous pourriez dire que nous avons des ressources limitées pour tout cela. Certes, lorsque vous payez 7,5 milliards de dollars pour Github, tout devient relatif.

Je pense qu'il est essentiel que MS comprenne les dommages à la réputation causés par l'échec d'un chemin de migration vers une capacité multiplateforme pour les investissements UWP/Win32 existants. La capacité multiplateforme devrait être synonyme de .NET 5 et ce n'est pas le cas. Je ne suis pas sûr que de petits pas pour traverser la plate-forme dans ce cas fonctionneront pour MS et croyez-moi, j'ai toujours été un grand fan de xaml/.net/c#

Quels modèles vous intéresseraient le plus ?

Voulez-vous aussi parler de modèles de projet ou de modèles d'élément ?

Cela aiderait-il si Visual Studio ou un autre outil mettait automatiquement à jour les espaces de noms pour vous ?

S'agirait-il simplement d'une recherche et d'un remplacement (moins de valeur) ou incorporerait-il également la mise à jour des dépendances vers la nouvelle version (plus utile mais pas sûr de savoir comment vous pourriez le dire)

Re: Rétrocompatibilité pour les nouvelles fonctionnalités

La rétrocompatibilité avec Creators Update (15063) sera-t-elle un point de référence fixe ou le plan à l'avenir sera-t-il de prendre en charge la version actuelle et un nombre X de versions antérieures ?

Qu'est-ce que cela signifie pour toute personne créant une extension ou son propre contrôle ou fonctionnalité qu'elle souhaite partager publiquement ? Auront-ils également besoin de prendre en charge ce niveau de compatibilité descendante ? Même à Windows 8.1 ?

Re : Migration d'espaces de noms

Sera-t-il possible de migrer un UWP existant par étapes (je pense aux pages) ou sera-t-il nécessaire de mettre à jour l'ensemble de l'application d'un coup ? Si c'est l'ensemble de l'application en une seule fois, cela ralentira l'adoption.

Qu'en est-il de la migration des applications WPF ? - La stratégie de migration utilise-t-elle des îles XAML qui pourraient utiliser WinUI 2.x ou 3.x ? Les deux peuvent-ils être utilisés dans la même application ?

Oui, diviser ce problème en plusieurs problèmes plus ciblés aidera à saisir les idées plus clairement et à éviter les tangentes.

Veuillez remplacer toutes les instances de UWP par les noms appropriés, car ce à quoi vous faites référence n'est pas clair.

@mrlacey :

Voulez-vous aussi parler de modèles de projet ou de modèles d'élément ?

Les modèles d'éléments ou de bibliothèques sont également intéressants ! Jusqu'à présent, les réponses présentent d'excellents points concernant la fourniture d'un code passe-partout et d'un code de démarrage supplémentaires, ce que nous pourrions envisager d'ajouter au fil du temps, peut-être comme Windows Template Studio .

S'agirait-il simplement d'une recherche et d'un remplacement (moins de valeur) ou incorporerait-il également la mise à jour des dépendances vers la nouvelle version (plus utile mais pas sûr de savoir comment vous pourriez le dire)

Bonne question : quel type de mise à jour des dépendances le rendrait plus précieux ? Par exemple, trouver de nouvelles versions de package NuGet compatibles ?

La rétrocompatibilité avec Creators Update (15063) sera-t-elle un point de référence fixe ou le plan à l'avenir sera-t-il de prendre en charge la version actuelle et un nombre X de versions antérieures ?

Nous prévoyons que la gamme de versions d'assistance changera au fil du temps en fonction de l'utilisation. Plutôt que de nous limiter à un nombre spécifique de versions, nous continuerons probablement à examiner les données d'utilisation et à prendre en charge les versions de Windows 10 les plus actives sur le marché.

Qu'est-ce que cela signifie pour toute personne créant une extension ou son propre contrôle ou fonctionnalité qu'elle souhaite partager publiquement ? Auront-ils également besoin de prendre en charge ce niveau de compatibilité descendante ? Même à Windows 8.1 ?

Nous n'envisageons actuellement pas d'imposer des exigences supplémentaires ou une « certification » pour les contrôles personnalisés. La gestion des versions dépendrait de vous. L'histoire globale de la gestion des versions à travers la mise à jour de mai 2019, WinUI 3.0 et les futures versions de WinUI est certainement un sujet sur lequel nous voulons approfondir bientôt.

Sera-t-il possible de migrer un UWP existant par étapes (je pense aux pages) ou sera-t-il nécessaire de mettre à jour l'ensemble de l'application d'un coup ? Si c'est l'ensemble de l'application en une seule fois, cela ralentira l'adoption.

Excellente question - merci de l'avoir noté. C'est aussi un sujet que nous voulons approfondir prochainement.

Veuillez remplacer toutes les instances de UWP par les noms appropriés, car ce à quoi vous faites référence n'est pas clair.

@riverar : y a-t-il une utilisation ou une section spécifique qui n'est pas claire ?

Nous utilisons le terme « UWP Xaml » pour désigner la plate-forme Xaml livrée avec Windows 10 et le SDK UWP, afin de la distinguer des autres plates-formes basées sur Xaml (par exemple, WPF).

Nous nous référons également au « modèle d'application UWP » (empaquetage et installation, gestion des données et de l'état, cycle de vie d'exécution, etc.), par opposition à un modèle d'application Win32.

Même sur les ordinateurs de bureau Windows, les utilisateurs passent beaucoup de temps à naviguer sur le Web.
Je pense que nous avons besoin d'un moyen de développer des applications Web décentes, en utilisant le (sous-ensemble du ) UWP vNext XAML + .NET (C#/F#/VB.NET)

J'ai développé en WPF + ClickOnce pendant de nombreuses années, puis j'ai commencé à m'intéresser à UWP. J'aime UWP, mais il (ou la version suivante) doit pouvoir exécuter un EXE autonome, de meilleures API de fenêtre (permettre de créer une application de style fenêtre Winamp même personnalisée si nous le voulons), plus d'API d'impression, une interopérabilité facile avec C dll , OCX, au moins un sous-ensemble des composants doit s'exécuter sur le Web.

Quand j'ai vu UNO, je me suis dit : Microsoft pourrait racheter cette société, et rejoindre ces développeurs avec les équipes d'UWP et de Xamarin. Je serais heureux si la prochaine version UWP devenait une chose Azure, qui fonctionne sur le Web, Windows, Mobile et IoT. OMI, même le portail Azure pourrait être écrit en UWP vNext.

Microsoft peut le faire. Vous l'avez fait avec Silverlight, vous avez fait WPF, vous avez fait UWP, vous avez fait Xamarin. Il est maintenant temps pour le framework GUI XAML ultime. Et, à mon avis, le Web doit être pris en charge, au moins un sous-ensemble de la fonctionnalité.

_INotifyDataErrorInfo_

Veuillez ne pas introduire de nouveaux espaces de noms pour des éléments tels que _INotifyDataErrorInfo_ - ils doivent être utilisés dans les modèles de vue qui sont généralement multiplateformes et ne doivent pas dépendre de WinUI. Il doit être défini où se trouvent d'autres éléments de ce type (c'est-à-dire _INotifyPropertyChanged_ ou _INotifyCollectionChanged)_

À propos de ce sujet. Windows.UI.Xaml.Interop a déjà une interface INotifyCollectionChanged et Windows.UI.Xaml.Data a INotifyPropertyChanged. Ces deux seront déplacés vers les espaces de noms Microsoft. Peut-être que les assemblys System.Runtime.WindowsRuntime peuvent effectuer un mappage de WinUI vers .Net

La seule chose que je veux ajouter s'il n'a pas déjà été ajouté, c'est que je prends en charge à 100% le modèle de package MSIX/Appx et Win10 a fait un travail fantastique pour réparer la merde qui était l'installation et la suppression au cours de la durée de vie de Windows. Cependant, j'ai toujours eu du mal à créer une application "UWP" en raison du sous-ensemble étrange de choix d'API disponibles qui ont été faits dans le bac à sable AppContainer. En tant que développeur C++, c'était frustrant et chaque année, vous voir ouvrir davantage le bac à sable pour permettre l'ensemble complet de l'API Win32 a été un soulagement.

Donc, si WinUI 3.0 me permet de créer une application avec un accès à 100% de la pile Win32, alors ce sera de l'or ! J'ai essayé d'utiliser XamlIslands en ce moment, et c'est une issue de secours fantastique, mais cela a été instable pour moi et il me reste du travail avant de franchir vraiment la ligne d'arrivée.

Obtenir des modèles de projet qui me permettent de créer une application Win32, sans être bourré dans un processus AppContainer, et me permettre d'accéder à toutes les avancées que vous avez réalisées avec l'interface utilisateur, alors WinUI 3 me conviendra parfaitement.

@ eklipse2k8 Il doit toujours y avoir un système d'autorisation pour accéder aux fichiers et aux appareils d'un utilisateur, même dans un bac à sable détendu. De plus, je pense qu'il devrait y avoir des règles à conserver dans l'espace utilisateur et éviter l'élévation à l'accès administrateur et au noyau - sans une sorte de test officiel et d'exigences de signature de code.

Bonjour Microsoft,

Je ne sais pas dans quelle mesure cet article influencera le sujet du rendu des ClearType , de DirectWrite et de l'avenir de l'interface utilisateur Windows, mais je suis l'un des rares mais passionnés à avoir de sérieux griefs avec les sous-systèmes de rendu des polices dans Les fenêtres.

Il est bien documenté un peu partout sur les frustrations (ou satisfaction) des internautes concernant l'interface utilisateur Windows et le rendu des polices. Vous trouverez des personnes qui aiment le lissage des polices, et vous en trouverez d'autres qui le détestent absolument.

Je ne suis pas ici pour discuter si l'un est meilleur que l'autre. Je ne suis pas non plus ici pour discuter des hacks de registre, des « tuners de polices » ou de la façon dont je peux modifier les paramètres du système d'exploitation pour améliorer l'apparence des polices. Croyez-moi, j'ai tout fait; allant même jusqu'à faire des recherches pour écrire un pilote en mode noyau pour corriger les fonctions DirectWrite en mode noyau.

Je suis ici parce que j'ai un problème de santé optique très courant appelé myopie/myopie . Je peux voir les choses clairement de près. Mais juste à portée de main, ma vision est juste à la limite de mon acuité visuelle et là où le texte commence à devenir flou.

Au-delà de la distance des bras, je dois porter des verres correcteurs. :lunettes: Je suis sûr que nous sommes tous au courant, les écrans d'ordinateurs de bureau sont à peu près à distance de bras. D'où le problème.

• Les polices qui ont l'air lisses, me semblent floues.
• Les polices avec des bords nets (collés au pixel) me semblent plus claires.

Lorsque les polices sont converties en pixels, les bords nets sont un signal visuel à mon cerveau que ma vision est claire et nette . Cependant, lorsque je rencontre un texte fluide, ce signal visuel trompe mon cerveau en lui faisant croire que ma vision est floue.

En tant que collègue développeur qui passe de longues périodes de temps à écrire du code et à regarder du texte, c'est frustrant et ça fait très mal. C'est la principale raison pour laquelle j'utilise toujours Windows 7 et non Windows 10 . Presque toute l'interface utilisateur principale de Metro de Windows 10 utilise le lissage des polices partout.

Pour illustrer ce problème de lissage des polices, examinons le composant logiciel enfichable services.msc MMC sous Windows 7 :

Voyez-vous un texte flou qui semble flou ? Ici. Zoomons un peu plus près...

Mon Dieu, gracieux, j'ai l'impression de regarder du texte avec les yeux croisés dans un autostéréogramme .

Il s'avère, dans ce cas spécifique, en fouillant dans la hiérarchie des contrôles de cette fenêtre, que le composant logiciel enfichable MMC héberge un contrôle Internet Explorer DHTML/ActiveX qui rend le texte flou dans le panneau "sélectionnez un élément pour afficher sa description". Le menu « Aide » et la liste des services nets (ajustés en pixels) sont rendus avec les primitives USER32 et GDI32 normales.

Ce petit exemple met en évidence l'un des plus gros problèmes avec le rendu des polices dans Windows. Il s'avère qu'IE8 respectera le paramètre global du système d'exploitation qui désactive ClearType et le lissage des polices. Cependant, si vous installez IE9 ou une version ultérieure, IE9+ ignorera volontiers tous les efforts visant à désactiver le lissage des polices. IE9+ ne s'en soucie tout simplement pas et oblige tous les utilisateurs à afficher le texte sur les sites Web (et dans les contrôles ActiveX) avec un texte lissé par la police.

Le problème s'aggrave pour les utilisateurs comme moi car au fil du temps, la naissance de Windows 8 et Windows 10, Metro Apps, WPF et UWP ont tous adopté la même approche que IE9+. Toutes ces technologies d'interface utilisateur sous le capot ignorent les paramètres globaux du système d'exploitation qui doivent être respectés sur nos machines. Si nous désactivons ClearType et le lissage des polices au niveau du système d'exploitation, nous nous attendons à ce que les API ClearType et DirectWrite (et par conséquent, les applications Metro, WPF et UWP) ne dessinent avec aucun lissage des polices.

Je sais que je ne suis pas le seul à avoir ce problème.

Il y a quelque temps, Google Chrome a fait la même chose avec sa version v31 et a essayé de suivre l'approche IE9+ et a basculé tout le rendu des polices sur DirectWrite en ignorant les paramètres globaux du système. Ce changement a mis Internet en rage. Voir le numéro de chrome 319429 . Enfin, après de nombreux grincements de dents, Google a fait marche arrière et a corrigé le problème dans Chrome 37 pour les utilisateurs ayant une déficience visuelle myope et respecte désormais le paramètre à l'échelle du système d'exploitation qui désactive le lissage des polices.

Grâce aux pouvoirs en place et aux forces du marché, Microsoft a perdu la guerre des navigateurs et adopte maintenant le moteur de rendu Chromium, mais je retiens avec impatience que l'équipe Edge respectera les paramètres de lissage des polices désactivés.

Je suis ici uniquement pour défendre le fait que Microsoft a besoin d'un paramètre global qui doit être respecté , pour toutes les applications du système d'exploitation, dans toutes les piles d'interface utilisateur , pour ceux qui ont des problèmes d'acuité visuelle.

Et pour rappel amical, il s'agit d'un problème d'accessibilité pour l'interface utilisateur Windows en général, et non de préférence visuelle.

Sur la base de la prévalence mondiale de la myopie, on peut estimer que plus de 22% de la population mondiale actuelle, soit 1,5 milliard de personnes sont myopes. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

Merci,
Brian

:walking_man: :walking_woman: Personnes disparues - Walking in LA

Cela signifie que le framework Xaml complet serait développé sur GitHub et expédié hors bande en tant que packages

NuGet est génial, mais la prise en charge de vcpkg (et CMake ) serait également appréciée (pour ceux d'entre nous qui possèdent de grandes bibliothèques multiplateformes existantes).

Quels modèles vous intéresseraient le plus ?

Par ordre de préférence :
Win32 + Xaml Desktop + WinUI
Win32 + Îles Xaml + WinUI
UWP + WinUI

Connaissez-vous les îles Xaml pour la modernisation des applications de bureau ?Cette compatibilité ascendante étendue sur Windows 10 rend-elle les îles Xaml plus utiles pour vous ?

Oui, les îles Xaml sont intéressantes, mais comme nous ciblons les consommateurs, et non les entreprises, la compatibilité ascendante étendue n'est pas un obstacle - la plupart des clients sont raisonnablement heureux de mettre à jour leur système d'exploitation (et compte tenu des délais pour la mise en œuvre des changements basés sur le nouveau WinUI Xaml, le verrouiller jusqu'en 1903 signifierait probablement qu'il est déjà sorti depuis un an).

L'espace de noms racine pour les API Xaml, de composition et d'entrée dans WinUI sera différent de l'espace de noms racine du SDK Windows UWP :

Cela aiderait-il si Visual Studio ou un autre outil mettait automatiquement à jour les espaces de noms pour vous ?

Cela ne m'affecte pas, car nous n'avons pas d'application UWP (nous utilisons actuellement WPF pour les ventes directes et WPF + Desktop Bridge pour le magasin), mais changer les espaces de noms est une chose unique, et même dans les plus grandes bases de code, une recherche et un remplacement global de Windows::UI::Xaml n'est pas si intimidant (nous utilisons tous le contrôle de version, n'est-ce pas .. ?).

Le chemin le plus rapide pour publier WinUI 3.0 serait de ne pas prendre en charge le mixage :

Cela me convient, ils doivent être traités comme des bibliothèques incompatibles distinctes. Vous ciblez soit UWP Xaml, soit WinUI Xaml. Comme mentionné ci-dessus, la conversion unique ne devrait pas être si difficile.

Cependant, l'une de nos plus grandes préoccupations concerne les problèmes de compatibilité et le travail que pourraient créer les applications UWP et les bibliothèques de composants existantes, en particulier si vous créez ou utilisez des bibliothèques de contrôle UWP Xaml.
Par exemple, les versions existantes de la boîte à outils de la communauté Windows ne seraient pas utilisables dans les applications WinUI 3.0, de sorte que la boîte à outils et toutes les applications l'utilisant devraient être mises à jour avant d'utiliser WinUI 3.0.

Microsoft doit choisir une technologie et s'y tenir. Pendant des années, on nous a promis les derniers et les meilleurs frameworks d'interface utilisateur de bureau (Win32, ATL, WTL, MFC, WinForms, WPF, UWP Xaml et maintenant WinUI Xaml). Bien que le choix soit vaste, il entraîne une fragmentation des fonctionnalités et des connaissances des développeurs. Il est beaucoup plus facile d'avoir une session / une page Web / une réponse stackoverflow lors de la mise en œuvre d'une fonctionnalité dans Windows, par rapport à 7 différentes selon la technologie. Si WinUI Xaml est l'avenir, la boîte à outils communautaire doit être mise à jour pour en tirer parti.

Quelle importance accordez-vous à la compatibilité totale entre les composants UWP Xaml existants et les applications WinUI 3.0 ?

J'ai refusé de faire quoi que ce soit avec UWP Xaml parce que la fonctionnalité n'est tout simplement pas là (par rapport à Win32 / WPF), et je suppose que je ne suis pas le seul à cet égard. En tant que tel, la compatibilité totale n'est pas un problème.

Créez-vous ou utilisez-vous des bibliothèques de contrôle UWP Xaml ou des composants WinRT que vous ne pouvez pas facilement recompiler et mettre à jour avec le code de l'application ?

Non.

Quelle serait votre solution préférée pour utiliser les composants UWP Xaml avec WinUI 3 ?

N / A

1. Que pensez-vous du plan global 3.0 décrit ci-dessus et dans la feuille de route ? Cela vous permettrait-il d'utiliser WinUI pour vos applications Windows nouvelles et existantes ?

Il n'y a aucune mention de Xaml Desktop dans la feuille de route. Cela relève-t-il de la compétence de WinUI ?
J'ai déjà mentionné cela aux gens de //Build/, mais la raison pour laquelle nous n'avons pas adopté UWP Xaml auparavant est qu'il était impossible de créer une application utilisant les bibliothèques C++ existantes. Par exemple, lorsqu'un utilisateur choisit un fichier avec FileOpenPicker , le résultat est livré en tant que IStorageFile , et il n'y a aucun moyen de le transmettre à une bibliothèque tierce existante à ouvrir (par exemple libpng , libjpeg , etc.). C'est pourquoi nous avons dû nous en tenir à WPF, donc si Xaml Desktop ou Win32 + Xaml Islands nous permet de vivre sans ces restrictions, alors oui, cela nous permettrait d'utiliser WinUI pour une nouvelle application.

1. Pour quel type d'applications seriez-vous le plus enthousiaste à l'idée d'utiliser WinUI 3.0 ? Créer une nouvelle application Win32 et l'emballer avec MSIX ? Ajouter de nouvelles vues à une application WPF ? Moderniser une application C++ MFC avec Fluent UI ?

Création d'une nouvelle application Win32 avec WinUI (et packaging avec MSIX).

Si vous avez des questions, n'hésitez pas à me le faire savoir, je serai ravi d'en discuter davantage.

En fait, j'espère qu'il existe un moyen d'appeler Compact Overlay à partir de WPF/WinForms.
Nous avons juste besoin d'un système d'autorisation d'administrateur comme "Autorisation de dessiner sur d'autres applications" dans Android.

Espérons que ce modèle d'application + emballage (UWP + AppX, Win32 + MSIX) le permette (Abstraction complète dans Sandbox)

Windows n'est-il pas censé offrir les possibilités les plus avancées et illimitées, avec la meilleure sécurité ?
Non par fonction paralysée pour la sécurité.

Merci de vous être ouvert à la communauté pour des commentaires concernant la feuille de route.

Quelle importance accordez-vous à la compatibilité totale entre les composants UWP Xaml existants et les applications WinUI 3.0 ?

Sur le fait, nous avons actuellement un certain nombre d'applications UWP utilisées pour les clients d'entreprise, et j'espère que le chemin de migration ne sera pas si difficile. S'il y a des changements importants, ce serait très bien d'avoir un outil de migration similaire au .Net Framework à .Net Core qui génère la compatibilité de notre chemin de migration, cela devrait signaler tout ce qui pourrait avoir besoin d'être modifié ( par exemple des API qui pourraient être obsolètes ou se comporter différemment) et une option pour changer automatiquement l'espace de noms si possible. De cette façon, le chemin de migration d'UWP vers WInUI ne sera pas aussi volatile pour nous, les développeurs d'entreprise.

Connaissez-vous les îles Xaml pour la modernisation des applications de bureau ?
Cette compatibilité ascendante étendue sur Windows 10 rend-elle les îles Xaml plus utiles pour vous ?

Oui, mais ce n'était pas vraiment un problème car à l'avenir, toutes nos applications de bureau nouvellement développées utilisent la communication UWP via un backend API, et la plupart de nos clients exécutent déjà Windows10.

Que pensez-vous du plan global 3.0 décrit ci-dessus et dans la feuille de route ? Cela vous permettrait-il d'utiliser WinUI pour vos applications Windows nouvelles et existantes ?

L'équipe de bureau est déjà enthousiasmée par les nouvelles de WinUI 3, mais comme indiqué ci-dessus, elle redoute la migration de toutes nos applications UWP vers elle si le chemin n'est pas aussi fluide.

En ce qui concerne le XAML général, puisque l'ensemble du framework d'interface utilisateur XAML vivra découplé de Windows, comme d'autres l'ont exprimé, il est possible d'échanger les moteurs de rendu. Cela ouvrira la possibilité d'exécuter WinUI XAML sur d'autres plates-formes, ce qui est un énorme facteur déterminant de nos jours lorsque les gens choisissent une pile avec laquelle s'en tenir, comme en témoigne la popularité des frameworks Electron et JS qui en profitent pour les petites entreprises qui n'ont pas la main-d'œuvre pour développer spécifiquement des bases de code natives pour chaque plate-forme.

Ajoutez également qu'à partir de WinUI 3, le dialecte XAML devrait également être amélioré, peut-être introduire un espace de noms de version / Doctype pour spécifier quelle version de XAML est utilisée afin de conserver la compatibilité descendante pour les anciennes applications. Il y a beaucoup à faire pour rendre XAML moins verbeux ou en morceaux, comme avoir à écrire INotifyPropertyChanged avec des setters privés pour un au lieu d'être juste un simple attribut de propriété, disons NotifyPropertyChangedAttribute et laissez le l'étape de construction injecte l'implémentation pour éviter la surcharge d'exécution ou DependencyProperties pour les contrôles personnalisés afin de simplifier la création de composants. Peut-être aussi prendre certaines des améliorations de l'équipe Razor pour certaines des bonnes pièces dont ils disposent.

Ces demandes peuvent être réalisables ou non, mais j'adore XAML et j'aimerais qu'il continue de s'améliorer. Je vais donc énoncer certains des problèmes (mais toujours utilisables) que moi-même et certains membres de notre équipe avons rencontrés lors du développement pour eux.

@mdtauk Je ne suis pas opposé à la sécurité des fichiers, mais le noyau sous-jacent devrait vous empêcher d'écrire dans des endroits où vous n'êtes pas autorisé au lieu d'utiliser un tout nouvel ensemble d'API et d'abandonner l'API de fichier win32. De plus, je sais que cela s'éloigne du sujet, mais les API StorageFile/StorageFolder sont des remplacements horribles, sans même tenir compte de la sécurité des fichiers. Ils sont lents et vous êtes toujours proxy via le courtier de fichiers d'exécution. De plus, il n'aurait jamais dû être une restriction que les applications sandbox aient besoin d'une autorisation spéciale approuvée par MS pour écrire dans le dossier des documents de l'utilisateur. Juste par exemple, à quel point l'histoire du fichier pour l'effort AppContainer était merdique, il était impossible de créer une base de données sqlite n'importe où, sauf dans le dossier LocalData caché de l'utilisateur. Pour un système de bureau où les utilisateurs veulent créer, enregistrer et ouvrir des fichiers, et enregistrer sous, yadda yadda, cela a imposé aux développeurs de logiciels la charge dont ils avaient besoin pour former leurs utilisateurs à la gestion du contenu des utilisateurs.

En ce qui concerne l'accès administrateur, la version d'octobre 2018 a ajouté "allowsElevation" en tant que droit, ce qui est logique. Une application peut permettre à un utilisateur de s'exécuter en tant qu'administrateur s'il a besoin d'un accès large au niveau du système pour un ensemble de fonctionnalités. Nous ne construisons pas tous de jolis petits éditeurs de photos et des applications d'organigramme.

@MarkIngramUK Merci pour vos commentaires, juste une précision. Le concept Xaml Desktop qui a été présenté dans un aperçu de //Build 2019 a été renommé en WinUI Desktop. Ce nouveau projet Visual Studio utilisera un modèle d'application Win32, avec WinUI comme framework de présentation, et il peut être natif ou géré (à l'aide de .NET Core 3).

Merci @ marb2000 - est-ce dans le délai de WinUI 3.0 ?

@ marb2000 par WinUI Desktop, vous voulez dire des applications Win32 avec Xaml Islands ? Dans quelle session de construction cela a-t-il été affiché ?

Une chose à laquelle l'équipe WinUI doit faire attention avec le renommage de WinUI 3.0 : si vous renommez l'un des types projetés dans .NET, les projections ne fonctionneront pas (et nous ne prévoyons pas d'en ajouter d'autres car ce n'est pas un système extensible maintenable). Voici une liste des types que nous projetons : https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Toute modification apportée à des types différents de ces types obligera les utilisateurs à envelopper leurs objets dans de nouveaux objets qui implémentent les nouvelles interfaces ou à copier leurs données dans les nouveaux types. En particulier, les types INotifyPropertyChanged et INotifyCollectionChanged sont intéressants en ce qui concerne les îles XAML et fournissent un support en aval.

INotifyDataErrorInfo

Veuillez ne pas introduire de nouveaux espaces de noms pour des éléments tels que INotifyDataErrorInfo - ils doivent être utilisés dans des modèles de vue qui sont généralement multiplateformes et ne doivent pas dépendre de WinUI. Il doit être défini où se trouvent d'autres éléments comme celui-ci (c'est-à-dire INotifyPropertyChanged ou INotifyCollectionChanged)

À propos de ce sujet. Windows.UI.Xaml.Interop a déjà une interface INotifyCollectionChanged et Windows.UI.Xaml.Data a INotifyPropertyChanged. Ces deux seront déplacés vers les espaces de noms Microsoft. Peut-être que les assemblys System.Runtime.WindowsRuntime peuvent effectuer un mappage de WinUI vers .Net

Merci pour la réponse, mais pourquoi en avez-vous besoin dans l'espace de noms Microsoft si .NET Standard l'a déjà dans System.ComponentModel ? https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@meir-pletinsky. NET n'est qu'un framework que vous pouvez utiliser pour créer des applications avec UWP XAML. Ils veulent que la validation des champs de texte soit disponible pour les développeurs, quel que soit le framework qu'ils utilisent

@mdtauk , non, WinUI Desktop (anciennement Xaml Desktop) vous permet d'utiliser directement Xaml avec Win32, sans utiliser l'îlot.

@ marb2000 Ce serait formidable si le projet d'empaquetage d'applications vous permettait de créer un AppX avec une fenêtre Win32 et d'inclure des composants WinRT de la même manière qu'un projet UWP. Il y a beaucoup de choses qui ne fonctionnent pas sans modifier manuellement les fichiers vcxproj, comme l'ajout de ressources et le compilateur cppwinrt générant les en-têtes à partir des composants WinRT inclus.

Un autre projet important pour cette nouvelle interface utilisateur est le _PropertyChanged.Fody_ de Simon Cropp qui permet l'implémentation automatique INotifyPropertyChanged (j'ai essayé avec C# / F#). Voir https://github.com/Fody/PropertyChanged

Il permet un code simple comme celui-ci :

[AddINotifyPropertyChanged]
public class Person
{
    public string Name { get; set; }
    public string FamilyName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged;
}

que nous pouvons utiliser pour se lier à l'interface utilisateur.

Une chose que j'aimerais voir dans WinUI 3.0 : actuellement, le compilateur UWP XAML ( genxbf.dll ) ne peut être invoqué directement par MSBuild que lorsqu'il est référencé à partir d'un fichier csproj, vbproj ou vcxproj. En effet, aucun outil de ligne de commande ne peut être utilisé pour appeler cette fonctionnalité. Cela me semble une décision très étrange, car rien d'autre dans le téléchargement du SDK Windows 10 ne nécessite Visual Studio. (Le module complémentaire WDK inclut également des cibles Visual Studio, mais ces cibles appellent toutes des outils de ligne de commande qui sont utilisables indépendamment de VS.) J'apprécierais grandement l'ajout, par exemple, de XbfCompiler.exe et XbfCodeGen.exe dans le répertoire bin du SDK. (Le premier EXE compilerait les fichiers XAML en fichiers XBF, et le dernier générerait les fichiers code-behind nécessaires pour référencer les types XAML à partir du code.) Cela serait principalement utile dans les projets C++ qui utilisent CMake ou un autre, non visuel Outil de construction Studio, mais peut également être utilisé pour les projets C# et VB.NET si nécessaire. Merci!

@MarkIngramUK savez-vous où je pourrais en savoir plus sur WinUI Desktop. Ces sessions Build 2019 ne peuvent pas être visionnées en ligne. Cela ressemble à des informations importantes qui devraient être liées dans ce référentiel

@mdtauk Cela a été mentionné dans un soi-disant Sneak Peek, qui est réservé aux participants de Build. Afaik, il n'y a pas d'enregistrement. Je n'y étais pas non plus, mais il y a une diapositive - peut-être la meilleure :-) - disponible sur Twitter : https://twitter.com/RudyHuyn/status/1126273995366490113

@mdtauk La feuille de route WinUI 3 contient les dernières informations et diagrammes qui sont encore plus à jour que ce qui a été montré lors de l'aperçu de Build. Il n'y a rien de tel que "XAML Desktop" ni "WinUI Desktop"... c'était juste un choix de mot déroutant sur une diapositive qui a été photographiée. Le concept communiqué (et la feuille de route essaie de l'expliquer plus clairement) est que pour WinUI 3, nous travaillons pour que vous puissiez avoir un modèle de projet qui crée une nouvelle application traditionnelle de modèle Desktop/Win32 en utilisant WinUI 3 pour son interface utilisateur (tout comme aujourd'hui, il existe des modèles pour les frameworks d'interface utilisateur tels que WinForms, WPF, MFC, etc. en plus du modèle Desktop/Win32 traditionnel) en plus d'un modèle de projet d'application UWP/WinRT mis à jour qui utilise WinUI 3. Est-ce que cela aider à clarifier?

La feuille de route 3.0 semble tout à fait raisonnable pour la stratégie suivante : permettre à n'importe quelle application cliente Windows d'utiliser XAML et les contrôles WinUI "modernes".

Cependant, cette stratégie semble à courte vue si l'on considère la réalité du marché d'aujourd'hui : pour beaucoup de développement d'applications, Android et iOS sont les cibles principales, et Windows est un bon choix. Pour le développeur .NET, Xamarin vous offre une prise en charge Android et iOS décente, mais leur prise en charge Windows est inférieure à la normale. Ainsi, pour les applications mobiles/de bureau natives, Win UI 3.0 ne simplifie en rien le développement multiplateforme pour les développeurs .NET.

Ce que j'aimerais vraiment voir, c'est un dialecte XAML avancé avec des aspirations vraiment universelles. Je devrais pouvoir écrire une application .NET en utilisant XAML et exécuter cette application sur Windows, iOS et Android. L'application doit être vraiment de première classe sur chaque plate-forme et avoir accès aux éléments natifs selon les besoins. Comme mentionné, Xamarin est un bon début, mais son dialecte de XAML est très différent, il a une mauvaise prise en charge de Windows et aucun des travaux que vous effectuez n'aide.

Donc, tldr, c'est bien que vous continuiez à fournir une plate-forme d'interface utilisateur moderne pour Windows. C'est bien que vous le rendiez plus facile à utiliser à partir de différents types d'applications. Dommage que vous n'aspiriez pas à un support multiplateforme.

Désactivez ou désactivez éventuellement les comportements du cycle de vie des applications mobiles héritées, tels que suspension + tombstone.

La réalité est que UWP est un environnement de bureau et au moins pour les jeux, l'utilisateur peut souvent minimiser l'application, ce qui conduit généralement à la suspension/l'écrasement de l'application. C'est une expérience choquante et très différente de toute application ou jeu de bureau win32. Demander un report prolongé, qui expirera probablement encore, ne suffit pas pour régler ce problème de manière transparente.

Bien que ce cycle de vie soit pratique pour certaines applications, il est préjudiciable à d'autres. Idéalement, une application de bureau ou un jeu devrait pouvoir déclarer une capacité permettant à l'application de se retirer du modèle de cycle de vie suspend+tombstone, ce qui l'empêcherait d'être finalement suspendue lorsqu'elle est minimisée.

@natemonster

Par : https://docs.microsoft.com/windows/uwp/launch-resume/run-minimized-with-extended-execution

Sur les appareils de bureau, les sessions d'exécution étendues créées avec ExtendedExecutionReason.Unspecified ont une limite de temps pour la batterie. Si l'appareil est connecté à l'alimentation murale, il n'y a pas de limite à la durée de la période d'exécution prolongée. Si l'appareil fonctionne sur batterie, la période d'exécution prolongée peut aller jusqu'à dix minutes en arrière-plan.

Un utilisateur de tablette ou d'ordinateur portable peut obtenir le même comportement de longue durée - au détriment de la durée de vie de la batterie - lorsque l'option Autoriser l'application à exécuter les tâches en arrière-plan est sélectionnée dans Utilisation de la batterie par les paramètres de l'application.

@TonyHenrique lorsque vous mentionnez Fody , est-ce parce que vous voulez en faire prendre conscience, ou dites-vous qu'il devrait être intégré à WinUI?

Les modèles d'éléments ou de bibliothèques sont également intéressants ! Jusqu'à présent, les réponses présentent d'excellents points concernant la fourniture d'un code passe-partout et d'un code de démarrage supplémentaires, ce que nous pourrions envisager d'ajouter au fil du temps, peut-être comme Windows Template Studio.

@Jesbis Je suis un contributeur principal de Windows Template Studio et je regarde la feuille de route WinUI en vue de ce que nous ferons à l'avenir et de la manière dont nous introduisons la prise en charge de WPF. ;)

quel type de mises à jour de dépendances le rendrait plus précieux ? Par exemple, trouver de nouvelles versions de package NuGet compatibles ?

Être capable de détecter les mises à jour NuGet serait plus utile, mais il existe d'autres problèmes de compatibilité potentiels avec la prise de mises à jour. Je ferais de la détection des nouvelles versions et de la conversion automatique une faible priorité. Il y a tellement de considérations que ce serait un gros projet à part entière et je préférerais voir du temps investi dans la plate-forme qu'un outil comme celui-ci.

@mrlacey J'ai mentionné Fody parce que je pense que c'est une solution intéressante et nous avons besoin d' un meilleur moyen d'éviter le code passe-partout _INotifyPropertyChanged_. Il serait bon d'avoir une solution prise en charge par MS à ce concept d'objet réactif qui déclenche automatiquement un événement lorsque certaines propriétés changent.
Cela fonctionne sur les classes C# et même sur les enregistrements F# (mais a eu quelques difficultés).
Donc, sur la feuille de route WinUI, il devrait également y avoir cela.

Remarque : ce serait bien si nous pouvions également utiliser les enregistrements F# pour définir nos entités de données et les lier ensuite directement à l'interface utilisateur XAML. Ce serait cool si nous pouvions utiliser F# Records + Fody + DataBinding sans problème.

[<PropertyChanged.AddINotifyPropertyChangedInterfaceAttribute>]
[<CLIMutable>]
type Person =
    {
        ID: Guid

        mutable Name: string
        mutable Addresses: ObservableCollection<Address>
    }

Ce serait plus familier pour les gens venant de C#.
Une autre approche serait la méthode Elmish. Je pense que les deux sont intéressants et pourraient être soutenus.

@tonyhenrique / @mrlacey Je pense que les trucs Fody (OAP) devraient être hors de portée. L'équipe WinUI en a déjà assez dans son assiette, et je pense qu'il est préférable d'avoir le tissage dans des projets séparés (cycles de publication beaucoup plus rapides en cas d'améliorations).

Et je pense qu'il s'agit en fait d'un détail d'implémentation .NET (IL) des modèles, qui n'a rien à voir avec WinUI (bien qu'il puisse écouter les événements de changement). Ma suggestion est de les garder séparés. Par exemple, j'utilise Catel et il a ses propres tisserands Fody pour s'assurer que tout est tissé correctement.

Ce que j'aimerais vraiment voir, c'est un dialecte XAML avancé avec des aspirations vraiment universelles. Je devrais pouvoir écrire une application .NET en utilisant XAML et exécuter cette application sur Windows, iOS et Android. L'application doit être vraiment de première classe sur chaque plate-forme et avoir accès aux éléments natifs selon les besoins.

Il existe une proposition de longue date pour aller dans cette direction : Cross platform UX pour .NET 5 - titre original Cross platform UX for .NET Core 3.0 . Le soutien écrasant de la communauté est évident et nous pouvons espérer que MSFT se rendra compte que c'est la meilleure direction pour développer n'importe quel framework d'interface utilisateur fonctionnant sur .NET. Il n'y a pratiquement aucune raison de conserver des bases de code distinctes pour différents groupes de plates-formes et de créer de force des ensembles de compétences de développeur distincts basés sur différents frameworks UX pris en charge par .NET.

En créant une UX unique pour toutes les plates-formes, nous annulons toutes les inefficacités dans le développement de framework et abaissons les obstacles à l'adoption par les développeurs.

@mfeingol / @4creators , je me contenterais de

L'application doit être vraiment de première classe sur chaque plate-forme

sous Windows pour commencer...

Nous sommes en 2019, je veux une interface utilisateur native rapide et je ne veux pas avoir à envisager sérieusement de créer une interface utilisateur avec CreateWindowExW , GDI, etc.

Maintenant qu'avec WinUI3.0 et au-dessus, le code est découplé de Windows 10, est-il prévu à l'avenir que WinUI fonctionne sur Linux et Mac ?

Les interactions @jesbis Touch seront conservées dans WinUI 3.0 ?

Merci pour la clarification, j'avais supposé que la façon dont la 3.0 fonctionnerait était d'inclure les îles Xaml dans WinUI, plutôt que d'utiliser la boîte à outils communautaire.

En devenant XAML plus Win32, cela a plus de sens, en particulier avec la réécriture de Windows Core OS, son shell en XAML.

Si je comprends bien maintenant, ce riche accès à l'API Win32 est en C et C++ | avec n'importe quoi en C# s'appuyant sur .NET (que ce soit maintenant .NET Core).

Peut-être devrait-il exister un moyen sûr et simple d'accéder à ces API Win32, ainsi que davantage de points d'entrée pour afficher l'interface utilisateur d'une application ?

• Flyout XAML de la barre d'état système pour les applications WinUI 3

• Interfaces utilisateur simples de sélection pour Hololens/Xbox/Surface Hub/IoT, etc.

• mises à jour des boîtes de dialogue de fichiers communs personnalisables XAML et des sélecteurs de dossiers

• accès simple C# .NET aux API Win32

• paramètre compact pour tous les éléments XAML, qui correspondent au dimensionnement des contrôles Win32 et WPF (cela aidera les frameworks à s'asseoir confortablement ensemble)

• correspondance des styles de contrôle/polices/pinceaux d'accent/acrylique lors de l'utilisation de WinUI

• définition claire des appareils nécessitant le cycle de vie WinRT/Mobile

• Styles de contrôle Xbox Next intégrés pour le développement et les tests d'applications Xbox sur Windows

• Stockage et emballage et téléchargement exe/MSI/APPX pris en charge par défaut, AUCUN INSTALLATEUR, virtualisation du système de fichiers de type centenaire par défaut

• WinForms WinUI 3.0 - interface utilisateur simple, accès au MFC, à la souris et au clavier uniquement

• WPF WinUI 3.0 - interface utilisateur dense, rendu 3D, prise en charge DPI, tactile simulé et prise en charge d'encre de base

• Xaml WinUI 3.0 - tactile complet, MR, manette de jeu, encrage, voix, souris, clavier. Interfaces utilisateur denses et simples. Nouveau support de fenêtrage. Rendu 3D MR. Cycle de vie géré facultatif ou cycle de vie du poste de travail. Le meilleur de tous les mondes par défaut pour les applications shell et de boîte de réception retravaillées, avec les versions Win32 des applications de boîte de réception telles que le bloc-notes, charmap, paint, l'explorateur de fichiers - open source et disponibles dans le magasin.

Les interactions tactiles seront-elles conservées dans WinUI 3.0 ?

@r7dev oui, le plan est de garder le même niveau de support tactile.

F# est ignoré sur la feuille de route WinUI 3.0. Microsoft ignore encore une fois l'un de ses produits.

Réflexions sur l'API Win32

Une chose à laquelle j'ai également pensé est la raison pour laquelle win32 est également resté. Je pense qu'il y a une hypothèse selon laquelle cela est dû à des projets hérités, mais c'est en fait bien plus profond que cela. L'ABI Win32 est super facile à connecter avec le langage de votre choix, nodejs, python, rouille, go, ruby, c#, c++, etc. etc. Si mon projet principal est en rouille par exemple, et je veux générer une fenêtre pour gérer la sortie, en tant que développeur rust, il est super puissant d'accéder à l'ensemble d'API win32 et de créer un front-end dans le même langage.

Sur OS X, pour accéder à AppKit, il vous suffisait de relier l'API objc_msgSend C et d'accéder à l'ensemble de l'infrastructure obj-c. Toutes ces langues ci-dessus ont fait un très bon travail pour combler cela et il a été facile d'écrire dans la langue de votre choix et de produire quelque chose de convaincant.

Donc, si vous voulez faire de WinUI 3.x la véritable voie à suivre pour accéder à l'interface utilisateur Win32 à faible latence, faible mémoire et haute qualité, vous devez considérer la facilité avec laquelle les autres mainteneurs de langage peuvent exploiter l'infrastructure.

Cohérence de l'interface utilisateur

Si vous envisagez vraiment de découpler l'interface utilisateur du système, quel est le plan pour que l'interface utilisateur reste cohérente avec chaque mise à niveau du système d'exploitation ? Lorsqu'Apple apporte des modifications aux ombres et aux dégradés dans AppKit ou iOS, les applications qui reposent sur les infrastructures système héritent de toutes ces modifications et restent cohérentes. Il vous sera également difficile d'ajouter des expériences à l'échelle du système, car les applications verrouillées sur les infrastructures d'interface utilisateur il y a 3 ans peuvent ne pas fonctionner correctement avec un nouveau service système, elles auront donc une autre couche de compatibilité au fil du temps.

Il y aura toujours des fonctionnalités qui doivent être activées, je peux penser au mode sombre comme quelque chose que si l'application n'était pas conçue pour cela, il n'aurait vraiment aucun sens de l'offrir en option, mais il y a toujours des ajustements aux composants du système qui changeraient avec le temps.

Taille binaire

Quelle est l'histoire prévue pour livrer toutes ces UI.dlls avec nos projets ? Ces éléments représenteront-ils 40 Mo de temps d'exécution qui doivent être livrés avec nos projets ? Que se passera-t-il si un projet est abandonné, commencera-t-il à paraître obsolète parce qu'il utilise d'anciens frameworks d'interface utilisateur ?

L'un des avantages de C++ est qu'il a une quantité minimale de surcharge de bibliothèque en fonction de la base de code. Certes, si chaque application à partir de maintenant nécessite WinUI 3.x, cela représentera 40 Mo x le nombre d'applications.

Taille binaire

WinUI est déjà une dépendance, tout comme .NET. C'est déjà une bibliothèque à l'échelle du système. :)
Vous n'avez pas de dll en double, et vous ne l'aurez pas.
https://www.microsoft.com/store/productId/9N00JJ7S3L39

@eklipse2k8

"Je pense aussi à la raison pour laquelle win32 est resté aussi. Je pense qu'il y a une hypothèse selon laquelle c'est à cause de projets hérités, mais c'est en fait assez plus profond que cela. L'ABI Win32 est très facile à connecter avec la langue de votre choix , nodejs, python, rust, go, ruby, c#, c++, etc. etc. Si mon projet principal est en rouille par exemple, et que je veux générer une fenêtre pour gérer la sortie, en tant que développeur de rouille, c'est super puissant pour accéder à l'ensemble d'API win32 et créer un frontal dans le même langage."

Il s'agit d'un sac mélangé, car tout en implémentant la prise en charge de WinRT pour un nouveau langage est un énorme obstacle à surmonter, une fois que vous l'avez fait, vous vous retrouvez avec des liaisons typées générées automatiquement vers toutes les nouvelles API. J'ai récemment travaillé sur un projet Rust qui relie Win32 et WinRT (en utilisant les API de composition dans une fenêtre Win32), et les parties Win32 ont définitivement été plus pénibles dans l'ensemble, même si j'ai dû maladroitement contourner le reste manque de prise en charge de Rust pour certaines fonctionnalités de WinRT comme l'héritage de classe. (Cela aide certainement que l'utilisation de Composition dans Win32 est désormais possible, car elle permet d'améliorer progressivement la prise en charge de cette fonctionnalité au lieu d'avoir à s'attaquer à l'ensemble du modèle d'application en même temps)

Le plus gros problème est probablement que la documentation pour les détails de bas niveau de l'ABI WinRT est un peu désorganisée, et qu'il y a très peu de compréhension ou de sensibilisation à leur sujet dans le monde/la communauté, j'espère que cette situation s'améliorera avec le projet xlang.

Quels modèles vous intéressent le plus ?

Actuellement, je préfère partir d'un projet Blank App (Universal Windows). J'aime aussi les modèles avec un framework préconfiguré, mais uniquement lorsque je veux essayer quelque chose rapidement. Un modèle "Menu principal" et un modèle MDI pour UWP seraient également bien (car ces modèles existent également pour WinForms)

Connaissez-vous les îles Xaml pour la modernisation des applications de bureau ?
Est-ce que cette compatibilité ascendante étendue sur Windows 10 rend les îles Xaml plus utiles pour vous

Oui, je connais l'île de Xaml. Si je peux, j'essaierai de m'en tenir à une application pure WPF ou pure UWP. Je n'étais pas dans une situation où j'aurais besoin d'une telle fonctionnalité.

Cela aiderait-il si Visual Studio ou un autre outil mettait automatiquement à jour les espaces de noms pour vous ?

Oui, bien sûr si cela fonctionne de manière fiable ! Je suis surpris par les nombreux commentaires qui n'apprécient pas une fonctionnalité aussi intéressante. Cette fonctionnalité peut également vérifier si une mise à jour de WinUI 3.0 est faisable, adopter le code XAML, ajuster les espaces de noms et installer les nugets WinUI requis.

Quelle importance accordez-vous à la compatibilité totale entre les composants UWP Xaml existants et les applications WinUI 3.0 ?

Je m'attendrais à ne changer que les espaces de noms du contrôle pour qu'ils fonctionnent pleinement avec WinUI 3.0. Je ne veux pas investir beaucoup de temps dans la mise à niveau vers WinUI 3.0

Créez-vous ou utilisez-vous des bibliothèques de contrôle UWP Xaml ou des composants WinRT que vous ne pouvez pas facilement recompiler et mettre à jour avec le code de l'application ?

J'utilise des bibliothèques de contrôle UWP Xaml tierces (comme Windows Community Toolkit, https://github.com/kakone/VLC.MediaElement ). Je pense que je serais capable de mettre à niveau moi-même des contrôles simples à partir de bibliothèques tierces comme un Dockpanel vers WinUI 3.0.

Quelle serait votre solution préférée pour utiliser les composants UWP Xaml avec WinUI 3 ?

• Créez un modèle de projet « Blank App with WinUI 3.0 » dans Visual Studio pour UWP. La dépendance WinUI 3.0 sera installée en tant que nuget (comme dans WinUI 2.0).

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] . Je préférerais absolument une telle solution tant que j'obtiens tous les contrôles de base. Je m'attendrais à ce que toutes les classes de Windows.UI aient une classe équivalente dans l'espace de noms Microsoft.UI.

Le sujet principal de WinUI 3.0 concernait les contrôles et la compatibilité Windows 10 qui peuvent être utilisés à partir d'UWP et WPF ou de WinForms via XAML Island, si je ne me trompe pas. Y a-t-il des chances que le balisage UWP XAML obtienne des fonctionnalités supplémentaires?

• Déclencheurs de style manquants
• Style `BasedOn={StaticResource {x:Type TextBlock}} manquant
• Les DataTemplates définis avec les DataTypes ne sont pas appliqués automatiquement comme dans WPF (uniquement via Key)
• Pourquoi chaque deuxième contrôle Windows.UI.Xaml.Controls (TextBlock, Border,...) est-il déclaré scellé ?! Veuillez ne pas le faire dans WinUI 3.0 avec UWP.
• Extensions de balisage pour la parité WPF
• Cela a déjà été mentionné, mais je vais le mentionner une fois de plus. Il est triste qu'UWP n'utilise pas System.ComponentModel.IDataErrorInfo. De cette façon, je ne peux pas partager mon projet de modèle avec la solution UWP.
• ReportControl (pour les applications d'entreprise)

J'attends avec impatience WinUI 3.0 et sa rétrocompatibilité !

F# est ignoré sur la feuille de route WinUI 3.0

Y a-t-il des chances que le balisage UWP XAML obtienne des fonctionnalités supplémentaires?

@Happypig375 , @mfe- :

La feuille de route ne couvre que la version 3.0 initiale, et pour la version initiale, nous nous concentrons principalement sur la parité et la compatibilité descendante pour les fonctionnalités existantes, avec un petit nombre de nouvelles fonctionnalités.

Si vous pensez que d'autres nouvelles fonctionnalités telles qu'une meilleure prise en charge de F# ou de nouvelles capacités de balisage sont importantes, veuillez

Pourquoi un contrôle Windows.UI.Xaml.Controls sur deux (TextBlock, Border,...) est-il déclaré scellé ?! Veuillez ne pas le faire dans WinUI 3.0 avec UWP.

Le descellage des commandes est en fait l'une des quelques nouvelles fonctionnalités que nous espérons inclure dans la version 3.0 😊

En ce qui concerne les langues, ce serait bien de mélanger et assortir (ce qui devrait être bien si tout est compilé avant l'emballage)

F# utilisé pour une certaine logique back-end - C# pour la liaison de données et le code d'interface utilisateur - C++ pour les contrôles et peut-être quelques hooks Win32 bas de gamme ou même pour lancer une boîte de dialogue WinForms.

Tous les langages de code sont égaux, interchangeables, avec WinUI 3.0 gérant toute l'interface utilisateur

C'est xlang

C'est xlang

@MarkIngramUK Hmm, je pensais que c'était un pont entre les langues, qui fait abstraction de chaque langue, plutôt que d'autoriser les fichiers de code de plusieurs langues dans un seul projet.

J'ai eu du mal à comprendre le but de xlang - passer sous silence les mises à jour qui se sont produites dans le référentiel (mais l'ai toujours dans ma liste de surveillance)

Est-ce que xlang fonctionne avant ou après la compilation ? Est-ce son propre langage abstrait qui peut être projeté, ou se trouve-t-il simplement entre des fichiers de code existants ?

Oui, vous ne pouvez pas mélanger les langues dans un même projet. C'est un pont, mais toujours utile à ces fins.

@MarkIngramUK Je suppose que si son code peut être compilé, alors inclus.

Ce serait bien de pouvoir utiliser C# pour accéder aux fonctionnalités natives de Win32, sans PInvokes et autres astuces .NET

@jesbis Je suis honnêtement plus intéressé par les aspects multiplateformes de ce projet...

Je pense qu'au début, vous devriez le renommer en quelque chose de plus _générique_ et pas strictement en "Windows".

J'ai compris que la mise en œuvre initiale devrait être strictement axée sur Win32 et les applications UWP/Xamarin et Windows, mais juste l'OSS et le faire dès le début appelé comme un framework "Windows uniquement", n'obtiendra définitivement pas beaucoup de traction tout comme UWP ne l'a pas fait et les développeurs d'autres plates-formes ne s'y intéresseraient jamais.

Si la cible sur .Net 5 doit être "One .Net Everywhere", ce qui est fondamentalement ce à quoi tout le monde s'est toujours attendu depuis .Net 1.0, les fondations du framework "Anything but Win UI" devraient commencer sur plusieurs plates-formes.

Un très bon exemple sur la façon de faire les choses correctement est Google Flutter. Flutter en est à ses tout débuts, mais a BEAUCOUP de traction en raison du fait que son noyau (alias Flutter Engine) est 100% multiplateforme et fonctionne partout (y compris IoT, Win, OSX, et maintenant même Web !).

C'est juste mon 2c. J'adorerais me remettre au travail sur Xaml mais s'il reste sur la même ligne que sur UWP, je crains que cela n'obtienne pas la bonne traction et que ce soit une autre tentative de réécriture de WPF qui nécessitera éventuellement une autre tentative dans l'avenir et ainsi de suite.

S'il vous plaît, ne me prenez pas en colère et ne prenez pas mon commentaire comme une mauvaise critique. Je souhaite juste que les efforts sur l'interface utilisateur sur le monde .Net obtiennent quelque chose comme Flutter, .Net Core 3.0/.Net 5, et même Blazor.

Pour mémoire, j'ai lancé un projet de réécriture/portage du moteur Flutter entièrement sur C# et .Net Core en raison du manque d'options sur .Net World...

BTW, CoreUI est un bon nom...

Bravo à Jake Helfert pour cette suggestion

??

BTW, CoreUI est un bon nom...

Bravo à Jake Helfert pour cette suggestion

??

CoreUI peut être confondu avec .NET Core

WinUI est très axé sur Windows, mais le framework XAML qu'il contient pourrait obtenir des moteurs de rendu pour Metal (iOS et macOS) ou Vulkan (Android) - et FabricWeb pourrait être le moyen PWA/ChromeOS de gérer les autres plates-formes.

Si jamais l'équipe choisit d'apporter la plate-forme de présentation, Xland ou Xamarin pourrait gérer le runtime pour les applications multiplates-formes.

À propos de la migration de l'interface utilisateur UWP de la boîte de réception vers WinUI 3.0, je citerai un récent article de blog de @dotMorten ( https://www.sharpgis.net/post/2019/05/14/The-future-UWP ):

Note de fond amusante : ce qui arrive à UWP, ce n'est pas qu'il soit tué : Microsoft pivote pour apporter les meilleures pièces là où nous en avons besoin. Cela s'est déjà produit auparavant, mais cela n'a malheureusement pas été utilisé comme une opportunité d'effectuer un pivot. Vous vous souvenez de Silverlight ? Devinez d'où vient le CLR multiplateforme de .NET Core. Et beaucoup de code de Silverlight s'est également retrouvé dans UWP. S'ils avaient seulement pivoté et dit « Oui, nous convenons que Silverlight n'a pas de sens dans la pièce de rechange grand public, mais il prospère dans l'espace de l'entreprise, alors construisons sur cela et nous allons le faire évoluer vers .NET Core et Windows Store ». Malheureusement, cela ne s'est pas si bien passé, et beaucoup de gens souffrent encore du SSPT et se méfient de tout ce que Microsoft fait qui semble tuer toute technologie.

Je pense vraiment qu'il est important de se rappeler que le fait d'être perçu comme l'élimination ou la réinitialisation des frameworks existants sans donner aux développeurs et aux bases de code une bonne voie à suivre n'affecte pas seulement les développeurs sur le framework existant - cela peut jeter un nuage sur les efforts futurs car tout le monde se demande pourquoi le nouveauté ne connaîtra pas le même sort. Il ne s'agit pas d'une remarque sur une approche de migration spécifique proposée, mais plutôt d'une réponse aux commentaires selon lesquels la migration n'a pas d'importance car peu de personnes utilisent le cadre d'interface utilisateur de la boîte de réception existant. Ce n'est pas la seule considération !

@weitzhandler WinUI 3.0 consiste à combiner divers frameworks Win32, .NET Core et UWP avec un seul framework XAML et à interagir avec WPF, WinForms et MFC++

XAML sous Windows est rendu en Direct X.

Si vous vouliez utiliser ce même XAML, combiné avec .NET Core, et le faire fonctionner sur d'autres plates-formes. Vous auriez besoin d'écrire de nouveaux moteurs de rendu pour ces plates-formes. iOS et macOS utilisent Metal comme équivalent Direct X. Android utilise Vulkan. Aucune idée de la façon dont Linux gère le rendu, je suppose que c'est juste Open GL.

Microsoft ne voudra pas le faire lui-même car cela n'a pas de sens pour eux. Mais WinUI 3.0 sera open source - donc d'autres pourraient choisir d'essayer de l'amener sur plusieurs plates-formes

@mdtauk

Merci d'avoir clarifié cela. Flutter est probablement l'avenir pour moi.

C'est juste ma compréhension, je peux me tromper.

Flutter est censé obtenir le support de Windows à l'avenir. Et la prise en charge de React Native arrive également sur Windows. De plus, il existe des PWA si vous êtes investi dans ce monde Web HTML et Javascript.

Pour moi, toute l'histoire de WinUI peut avoir plus de sens s'ils prennent également en considération le fait qu'au moins un sous-ensemble de base de celui-ci s'exécute sur plusieurs plates-formes (macOS, iOS, Android), y compris le Web, et offre également une meilleure prise en charge de F# et des modèles de projet (y compris Liaison bidirectionnelle XAML aux enregistrements F #, et également une manière elmish plus fonctionnelle)

XAML doit être indépendant de l' Vous avez besoin d'un backend de rendu agnostique comme les moteurs de jeu l'utilisent pour commencer.

Aucun si ce XAML axé sur UWP résout tous les problèmes que mon entreprise ou moi-même avons rencontrés depuis des années avec XAML... et c'est la portabilité. TBH MS se trompe complètement sur l'interface utilisateur et cela n'ira nulle part rapidement (cela fait perdre beaucoup de temps précieux pour beaucoup de gens). Ce piratage UWP XAML ne convient tout simplement pas aux personnes à qui je le montre... ce qui est triste car cela signifie simplement une poussée sans fin contre l'adoption de XAML et je n'ai plus d'arguments à ce stade.

À mon avis, la seule façon de sauvegarder XAML est :

• Créez une nouvelle base de framework agnostique/portable pour .NET Core et C/C++.
• Créez une couche d'abstraction de rendu agnostique que tout le monde peut étendre via des pull-requests.
• Tout comme HTML, gardez le XAML concentré sur les concepts d'application à fenêtre unique (comme dans les jeux également) MAIS autorisez des fonctionnalités de bureau étendues pour plusieurs fenêtres, etc. (Cela permet à l'application de s'exécuter dans presque tous les contextes, tout comme l'interface utilisateur des jeux)

En termes simples, deux conditions doivent être combinées en une seule avant que l'adaptation XAML ne soit exclue.

1 MS doit soutenir le projet XAML ou les gens craignent qu'il ne tombe.

2 Il doit être multiplateforme ou tout le monde sera coincé avec des runtimes HTML gonflés et fous.

Quoi qu'il en soit, ce sont mes deux cents et si WinUI 3.0 est conçu correctement, le portage sera peut-être possible. À ce stade, je ne sais pas quoi ressentir.

Il y a quelques commentaires sur le fait d'être multiplateforme ici, et je ne suis pas sûr que WinUI aurait besoin d'être multiplateforme pour réussir. De toute façon, cela ne fonctionnerait pas bien sur Mac ou Linux, car il est suffisamment différent pour ne pas sembler natif sur l'une ou l'autre de ces plates-formes. Ce projet appartient à une équipe qui possède une vaste connaissance du fonctionnement des composants internes de Windows.

Aussi... Courir sur Mac semblerait maladroit, il suffit de regarder iTunes, Apple a dû porter l'intégralité de son système d'interface utilisateur sur Windows, et cela ne semble vraiment pas à sa place. Le rendu des polices est différent, les courbes et les ombres d'animation et les choix de couleurs semblent tellement déplacés dans Win10. Je veux dire, c'est bien et utilisable, mais je préfère Spotify qui n'essaie pas d'émuler une interface utilisateur de bureau et utilise simplement un navigateur Web sous le capot. Sur Mac, voir le projecteur de révélation avec des composants carrés dans un bureau plein de coins arrondis et sans effet de révélation serait si difficile à affronter.

Non, je pense que ce projet devrait se concentrer sur l'offre du meilleur moyen de créer des logiciels Windows natifs, pour les développeurs qui souhaitent/ont besoin de créer des logiciels Windows. Laissez les équipes d'Electron/Typescript résoudre les problèmes multiplateformes.

Il y a quelques commentaires sur le fait d'être multiplateforme ici, et je ne suis pas sûr que WinUI aurait besoin d'être multiplateforme pour réussir. De toute façon, cela ne fonctionnerait pas bien sur Mac ou Linux, car il est suffisamment différent pour ne pas sembler natif sur l'une ou l'autre de ces plates-formes. Ce projet appartient à une équipe qui possède une vaste connaissance du fonctionnement des composants internes de Windows.
Aussi... Courir sur Mac semblerait maladroit, il suffit de regarder iTunes, Apple a dû porter l'intégralité de son système d'interface utilisateur sur Windows, et cela ne semble vraiment pas à sa place. Le rendu des polices est différent, les courbes et les ombres d'animation et les choix de couleurs semblent tellement déplacés dans Win10. Je veux dire, c'est bien et utilisable, mais je préfère Spotify qui n'essaie pas d'émuler une interface utilisateur de bureau et utilise simplement un navigateur Web sous le capot. Sur Mac, voir le projecteur de révélation avec des composants carrés dans un bureau plein de coins arrondis et sans effet de révélation serait si difficile à affronter.
Non, je pense que ce projet devrait se concentrer sur l'offre du meilleur moyen de créer des logiciels Windows natifs, pour les développeurs qui souhaitent/ont besoin de créer des logiciels Windows. Laissez les équipes d'Electron/Typescript résoudre les problèmes multiplateformes.

Je ne pense pas que quiconque veuille vraiment une conception Fluent complète sur d'autres plates-formes, mais plutôt être capable de maximiser le code commun entre les plates-formes.

C'est quelque chose qui a déjà été abordé par l'équipe de conception de Microsoft. Le site Web de Fluent dit explicitement "concevoir et créer des applications personnalisées nativement iOS tout en restant uniquement Fluent". La documentation Fluent montre que le style de contrôle natif doit être utilisé.
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

Ce qu'il faut éviter, c'est d'avoir à concevoir et à maintenir des interfaces utilisateur complètement séparées pour chaque plate-forme. Cela ne signifie pas qu'il doit avoir l'air identique en surface, mais qu'il doit partager une disposition commune et que les concepteurs d'interface utilisateur doivent pouvoir réutiliser autant que possible. Le style réel n'a pas (et ne devrait pas) besoin de correspondre au style du système Windows 10.

Essentiellement, ce qui est recherché, c'est un moyen simple de faire fonctionner les applications Windows sur d'autres plates-formes, sans avoir à refaire l'ensemble de l'interface utilisateur - sans apporter la conception Fluent à d'autres plates-formes. Cela permettrait aux gens d'écrire d'abord pour Windows, puis d'apporter leur application sur d'autres plates-formes sans trop de travail.

@KyleNanakdewa Eh bien, s'ils le font en open source, laissez certains fans de Xaml partir et créer les bits de la plate-forme sous-jacente. Je pense que c'est probablement suffisamment complexe sur le plan architectural et tire suffisamment parti de Win32 pour que je soupçonne que le portage serait une entreprise énorme.

Je pense que ce projet devrait se concentrer sur l'offre du meilleur moyen de créer des logiciels Windows natifs

Cet argument pourrait être convaincant si Microsoft ne possédait pas déjà une boîte à outils XAML multiplateforme existante qui offre simplement un dialecte XAML très différent de celui de WinUI.

De plus, il existe des PWA si vous êtes investi dans ce monde Web HTML et Javascript.

Oui... "ce monde" qui remplace rapidement tout ce que nous savons sur le développement natif OS/Store/Hébergé. ??

https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097

Considérez que "ce monde" existe sur _tous_ les appareils modernes avec un moteur de rendu HTML5 :

• Apple avec 1,4 milliard
• Droïde avec 2,5 milliards
• Windows 10 avec 800 millions

Vous remarquerez que Windows détient désormais la plus petite part de marché, ce qui signifie que toute offre qui s'adresse spécifiquement à cette plate-forme sera celle qui atteindra le plus petit marché. Cela ne fait que réduire la portée maximale du marché potentiel d'une application, ce qui, à son tour, abaisse son plafond de revenu potentiel maximal.

Comparez cela avec Flutter, qui avec _une_ base de code atteint _tous_ les marchés susmentionnés, ainsi que le Web , qui, comme mentionné, est composé de l'ensemble des trois - maximisant ainsi la portée du marché et les revenus potentiels pour les développeurs d'applications tout en réduisant les coûts nécessaires de création applications pour le faire.

Bien que je sois un grand fan des efforts déployés ici pour ouvrir la source, collaborer et solliciter les commentaires de la communauté , je n'ai encore rien vu de ces discussions (que j'apprécie également 😁) qui me signale en toute confiance que les efforts ici seront compétitif - et donc _rentable_ - par rapport aux goûts de Flutter (qui d'ailleurs se prépare également pour les PWA ).

Le contrôle des diagrammes est essentiel dans toute expérience de bureau moderne axée sur les données qui sera bientôt officielle NET CORE 3 (septembre 2019) et éventuellement. NET 5 (novembre 2020)

Je considère le contrôle open source Networkview fourni comme un cas d'utilisation efficace sur la façon de travailler avec Xaml pour porter le contrôle WPF vers Win UI. Cette interface utilisateur Win portée servira de bonne guilde pour que d'autres puissent porter d'autres contrôles WPF légèrement plus complexes vers l'interface utilisateur Win.

Nous voyons un cas d'utilisation 2 en 1 où notre application doit prendre en charge le mode tablette dans le futur système d'exploitation Windows Core. Nous soupçonnons que Winform in. NET Core 3 n'aidera pas.

Si vous pensez que d'autres nouvelles fonctionnalités telles qu'une meilleure prise en charge de F# ou de nouvelles capacités de balisage sont importantes, veuillez

On dirait que @migueldeicaza prend les choses en main : https://github.com/microsoft/microsoft-ui-xaml/pull/736

Je veux faire écho aux réflexions de @ eklipse2k8 sur le multiplateforme. Lors de la création d'une bibliothèque d'interface utilisateur multiplateforme, vous devrez toujours faire des compromis. WinUI ne doit pas faire de compromis - il doit être le remplacement moderne de l'interface utilisateur Win32 (je ne veux plus appeler CreateWindowExW !) et il doit être une vitrine de ce que vous pouvez faire sous Windows. WinUI sur macOS ou Android offrirait toujours une expérience qui ne pourrait jamais correspondre à l'expérience native. Nous écrivons des applications multiplateformes et nous écrivons une interface utilisateur native sur chaque plateforme. De cette façon, les clients obtiennent la meilleure expérience sur leur choix de plate-forme. Si les gens veulent une solution multiplateforme, c'est bien, ils devraient se tourner vers une autre bibliothèque à cette fin - peut-être une qui enveloppe WinUI sur la plate-forme Windows.

Et en ce qui concerne les PWA, ceux-ci ne représentent pas la pleine utilisation du système d'interface utilisateur Windows, recommander de se concentrer sur les "applications à fenêtre unique" exclurait immédiatement tout logiciel professionnel (à l'exception des jeux). Il existe déjà des solutions pour PWA et multiplateforme - nous n'en avons pas besoin d'une autre.

XKCD obligatoire :
https://xkcd.com/927/

@MarkIngramUK Je pense que le discours sur la plate-forme croisée concerne davantage la possibilité de coder vers .NET et XAML pour déclarer l'interface utilisateur - puis de faire fonctionner cette application sur Android, iOS, macOS, Linux ?! - sans avoir à changer le code derrière ou abandonner le XAML.

Maintenant, s'il y avait des rendus XAML pour ces autres plates-formes - la façon dont ils interprètent le XAML pourrait être comme Xamarin Forms, qui passe aux plates-formes d'interface utilisateur natives - ou simplement dessiner essentiellement vers le tampon de la carte graphique et dessiner les pixels à l'écran - en conservant la plupart des mêmes styles de contrôles.

WinUI 3.0 devrait rester un projet axé sur Windows pour unifier les différentes API et ABI avec une plate-forme d'interface utilisateur moderne basée sur XAML. Mais cela ne signifie pas que Xamarin ou les individus ne peuvent pas prendre le code de rendu et créer des versions pour d'autres plates-formes.

Tout ce qui serait vraiment nécessaire (à un niveau de réflexion élevé) serait de s'assurer que le code qui rend XAML à l'écran dans Windows est contenu, afin que d'autres moteurs de rendu puissent intervenir pour les scénarios multiplateformes.

WinRT/UWP/XAML aura besoin d'une refactorisation pour les extraire du système d'exploitation Windows 10 - il faut donc garder à l'esprit la manière dont cette refactorisation est effectuée, pour permettre une expansion future. Que la plateforme multiplateforme devienne une réalité ou non.

@MarkIngramUK Je suis d'accord avec @mdtauk

Il ne devrait y avoir aucune raison pour laquelle nous ne pouvons pas utiliser xaml pour décrire les composants d'interface utilisateur dans d'autres bibliothèques, y compris React. Si vous regardez un projet comme http://www.cshtml5.com , ils utilisent xaml qui est converti en html.
Je ne pense pas non plus que quiconque fasse allusion au fait que l'objectif final est que l'interface utilisateur ait la même apparence sur d'autres plates-formes, mais ce que je veux personnellement, c'est quelque chose du côté de l'interface utilisateur que je peux utiliser pour tirer parti de mon investissement existant dans, par exemple, UWP

Le point est simplement ceci. Si je fais une proposition à une entreprise cliente et présente une application UWP géniale qui est fantastique à tous égards. Si ce client d'entreprise a 1 utilisateur qui utilise par exemple un MacBook Pro, alors j'ai immédiatement un problème car le client d'entreprise préférera quelque chose qui fonctionne partout (plus petit dénominateur => site Web) que mon "application native" même s'ils fonctionnent sur Windows 10.

L' accessibilité est donc la clé. Le fait que MS s'attend toujours à ce que nous investissions dans des "applications natives" en 2019 sans aucune feuille de route pour une capacité multiplateforme est fou.

Tout nouveau projet du point de vue de l'entreprise est susceptible de suivre la logique ci-dessus pour l'accessibilité et, par conséquent, tous les nouveaux projets seront biaisés vers le Web et tout cela parce qu'il n'y a pas de feuille de route qui inclut une capacité multiplateforme sur XAML/UWP

Alors, nous avançons rapidement dans 2-3 ans, aucun nouvel investissement des entreprises dans UWP/win32 et vous êtes assis avec un autre "Silverlight" dont personne ne se soucie.

MS peut même me dire que XAML est déprécié demain et que la "nouvelle" bibliothèque d'interface utilisateur est par exemple React. Tant que c# peut être collé à cette nouvelle bibliothèque, je réduirai mes pertes, viderai XAML et adopterai cette nouvelle bibliothèque d'interface utilisateur multiplateforme. Au moins mon investissement a une durabilité et est accessible à long terme.

En ne fournissant pas de clarté sur ce problème spécifique concernant la capacité d'interface utilisateur multiplateforme, MS crée une incertitude autour de sa "pile native" et, par conséquent, la plupart des entreprises préféreront traverser un incendie avec une jambe de bois plutôt que d'embrasser l'inconnu.

Et en ce qui concerne PWA, ceux-ci ne représentent pas la pleine utilisation du système d'interface utilisateur Windows

Assez juste, et je suis d'accord. Mon point principal avec PWA était de démontrer que sa part de marché éclipse n'importe quel marché particulier, car elle est composée de l'ensemble de tous les marchés.

Cela dit, je suppose qu'une partie de la confusion ici de ma part est l'espacement des noms pour refléter Microsoft.* , alors qu'en réalité il semble que cela devrait toujours être Windows.* (ou même Microsoft.Windows.* ) .

Il existe déjà des solutions pour PWA et multiplateforme - nous n'en avons pas besoin d'une autre.

Malheureusement, ce n'est pas le cas pour le développement .NET, qui fait partie de la confusion et de l'angoisse multiplateforme autour de cette annonce et de la discussion qui a suivi.

maximisant ainsi la portée du marché et les revenus potentiels pour les développeurs d'applications tout en réduisant les coûts nécessaires de création d'applications pour le faire.

Parfois, les performances et les détails UX peuvent faire une grande différence. Skype a maximisé la portée du marché en utilisant le cadre Electron au prix de sacrifier les performances et le résultat est un désastre commercial.

Concernant les solutions multiplateformes (xplat).
Les solutions Xplat sont une abstraction sur plusieurs systèmes sous-jacents natifs. Ma compréhension de WinUI est que ce sera le système natif pour Windows.

Si WinUI devait également être xplat, comment intégrerait-il des éléments uniques à Windows ? Cela ne l'empêcherait-il pas de faire des choses nouvelles et innovantes ? Ou cela signifie-t-il que c'est à Microsoft de porter quelque chose de nouveau ou de différenciant de Windows vers d'autres plates-formes également ? Qu'en est-il des éléments qui n'ont pas pu être portés parce que l'autre système d'exploitation sous-jacent ne pouvait pas les prendre en charge - ne devraient-ils pas être ajoutés à Windows ?

Si vous construisez quelque chose avec des technologies Windows natives, il est raisonnable de supposer que Microsoft prendra cela en charge pendant un certain temps et fournira une voie à suivre vers de nouveaux systèmes Windows à l'avenir. (Reconnaissant SilverLight comme une exception.) Je ne pense pas qu'il soit raisonnable de supposer que si vous créez quelque chose avec les technologies Windows natives et que vous souhaitez ensuite l'exécuter sur un système d'exploitation concurrent, il appartient à Microsoft/Windows de rendre cela facile. Si vous avez créé une application pour l'iPad avec Swift et que vous vouliez également l'apporter sur le bureau Windows, vous attendriez-vous à ce qu'Apple modifie le développement iOS pour rendre cela plus facile ?

Si vous aimez ou préférez utiliser les technologies Windows natives, c'est parfait. Ce que vous ne pouvez pas faire, c'est reporter la décision d'affaires que vous prenez en choisissant ces technologies à quelqu'un d'autre. Tous les choix technologiques ont des conséquences et personne ne sait ce qui pourrait être nécessaire dans quelques années ou ce que vos clients pourraient demander. Demander qu'un logiciel développé spécifiquement pour Windows puisse également fonctionner ailleurs peut donner l'impression que l'objectif est d'éviter de prendre une décision technologique qui pourrait avoir des conséquences négatives à tout moment dans le futur. Compte tenu de la nature de la technologie et de la vitesse du changement, je ne pense pas que ce soit réaliste.

Cela dit, si vous voulez créer une solution xplat (et il y a beaucoup de gens qui le font et des raisons pour cela) parce que vous voulez cibler plusieurs systèmes d'exploitation maintenant, ou peut-être le souhaitez à l'avenir, alors c'est une solution raisonnable et compréhensible scénario.
Pour cela, Microsoft a Xamarin. Ou, si vous préférez quelque chose avec XAML plus comme UWP, il y a Uno. (Il y a beaucoup d'autres options aussi.)
Si, comme moi, vous voulez voir Xamarin avoir une meilleure prise en charge native pour la création d'applications Windows, je ne pense pas que WinUI essaie de faire plusieurs choses soit la réponse.

WinUI ne se limite pas au XAML et à des contrôles spécifiques. Il comprend des détails sur la façon dont ces contrôles et les applications qui les accompagnent s'intègrent au système d'exploitation sous-jacent.
Si la planification de WinUI vise à rendre le développement Windows sur Windows le meilleur possible, alors c'est un bon argument pour avoir de l'innovation et un bon support futur. Cela est également susceptible d'augmenter les chances que les gens veuillent continuer à utiliser Windows et il devient donc important qu'il bénéficie d'une prise en charge solide de plusieurs solutions xplat.

Concernant les solutions multiplateformes (xplat).
Les solutions Xplat sont une abstraction sur plusieurs systèmes sous-jacents natifs. Ma compréhension de WinUI est que ce sera le système natif pour Windows.

Désolé mais je ne me sens pas comme ça...

Regardez Flutter... Il a un moteur de base qui peut rendre n'importe quoi sur n'importe quelle plate-forme qu'il prend en charge.

En plus de cela, il contient des composants entièrement implémentés sur Dart à l'aide de la couche gérée par le moteur et qui représentent (dessin/rendu) en fidélité aux pixels la plate-forme et le langage de conception que vous souhaitez utiliser, par exemple, Material.io et Cupertino d'Apple.

Donc, à mon humble avis, ce serait la meilleure approche pour créer quelque chose sur plusieurs plates-formes et cela représente en même temps les capacités sous-jacentes de la plate-forme.

Je ne pense pas qu'il soit raisonnable de supposer que si vous créez quelque chose avec les technologies Windows natives et que vous souhaitez ensuite l'exécuter sur un système d'exploitation concurrent, il appartient à Microsoft/Windows de rendre cela facile

D'accord... Je pense que ce que d'autres font remarquer ici, c'est que cela semble un peu en arrière / sourd ces jours-ci, en particulier dans le contexte du démarrage d'une nouvelle application. Pourquoi quelqu'un créerait-il une application Windows native alors qu'elle n'atteint qu'un petit % du marché ? Ce n'est pas une bonne utilisation du capital.

S'il s'agit de maintenir des applications Windows héritées ou de créer spécifiquement une application Windows, alors oui, je suis d'accord avec tout cela et cela a du sens. Cependant, comme il semble y avoir des changements de rupture et des investissements supplémentaires, la proposition de valeur de faire cela par rapport à l'utilisation de Flutter n'a pas encore été expliquée.

C'est exactement ce que je dis...

Par exemple, les intégrateurs flutter pour Desktop sur Win10 (WPF et UWP) ainsi que sur OSX arrivent.

Ils sont gérés à 100% par flutter runtime, mais ils n'utilisent (par exemple) WPF/UWP que pour obtenir la gestion du fenêtrage et le pointeur Graphics . Tout le reste est géré par le moteur...

Nous avons porté nous-mêmes le moteur de flutter sur un périphérique ARM intégré et je dois dire que ce fut une expérience formidable. Pourquoi? Parce qu'il est né pour être portable et pour fonctionner n'importe où en laissant "l'embedder" gérer les détails d'implémentation spécifiques à la plate-forme sur des primitives comme le GPU, le rendu logiciel, la gestion des entrées, etc...

C'est pourquoi je dis que WinUI au moyen de UWP: The empire strikes back ne fonctionnera pas à long terme.

MSFT doit être livré avec quelque chose de multiplateforme, ouvert et portable. Tout comme ils l'ont fait avec .Net Core, avec Blazor, etc... Réinventer UWP/XAML n'ira nulle part.

Je pense que XAML a un bon potentiel s'il est utilisé correctement dans un sens où il est utilisé pour « décrire » (ou déclarer comme certains le disent) l'interface utilisateur. Le "moteur" construit l'arbre de rendu à partir de celui-ci, puis envoie les commandes de rendu à la plate-forme sous-jacente.

Comme MSFT l'a récemment fait avec Chromium comme noyau pour Edge, je pense que WinUI (ou quel que soit son nom) pourrait tirer parti de Skia car il a des backends pour GL, DX, Vulkan, Software Rendering, FB, etc... Juste en commençant par que vous avez un ÉNORME potentiel d'ajouter d'autres plateformes plus tard...

@galvesribeiro ,

Regardez Flutter... Il a un moteur de base qui peut rendre n'importe quoi sur n'importe quelle plate-forme qu'il prend en charge.

En plus de cela, il contient des composants entièrement implémentés sur Dart à l'aide de la couche gérée par le moteur et qui représentent (dessin/rendu) en fidélité aux pixels la plate-forme et le langage de conception que vous souhaitez utiliser, par exemple, Material.io et Cupertino d'Apple.

Génial, donc dès qu'Apple publie une mise à jour de macOS et que les mises à jour de l'interface utilisateur (peut-être des changements de rayon de coin de bouton, ou des dégradés d'arrière-plan, etc.), votre application Flutter ne se met pas à jour et continue de ressembler au système d'exploitation précédent - contrairement à un natif contrôle qui obtiendrait les avantages gratuitement.

@MarkIngramUK c'est le travail de l'équipe pour prendre en charge les mises à jour.

Tout comme l'équipe Xamarin fournit des mises à jour à partir du jour 0+1, cette équipe pourrait faire de même. L'équipe Google le fait aussi...

En utilisant le contrôle "natif", vous êtes de retour sur le monde Xamarin où vous ne faites que des wrappers (aka Renders)...

Nous ne parlons pas des liaisons C# aux contrôles natifs (comme le fait Xamarin)... Nous parlons d'un framework d'interface utilisateur complet comme vous le faites avec Flutter...

Pour mémoire, personne n'utilise le thème "par défaut" pour aucune plate-forme. Ils créent tous leur UX unique en plus des langages de conception de chaque plate-forme.

Si vous êtes si soucieux d'avoir toujours l'apparence du composant natif, votre application n'aura probablement jamais une bonne audience comme elle le ferait... Meh...

Je crois que nous parlons ici de deux projets différents. WinUI doit être le remplaçant de Win32. Les gens demandent une solution multiplateforme, ce qui est raisonnable, mais je ne pense pas que ce devrait être ce projet.

De plus, Flutter vous permet d'utiliser le "thème" sur toutes les plateformes. Vous pouvez donc exécuter Cupertino sur votre PC Win10. Un GRAND exemple est la conception matérielle. C'est un langage de conception, pas un ensemble de contrôles. Il peut être utilisé n'importe où... Il se trouve que certaines plates-formes (comme Android) ont leurs contrôles natifs pour l'implémenter...

@MarkIngramUK

Je précise simplement pourquoi WinUI ne devrait pas être un simple remplacement de Win32, c'est tout.

Si tel est le cas, alors je suis presque sûr qu'il tombera dans un avenir prévisible, tout comme UWP...

Je suis d'accord @MarkIngramUK WinUI lui-même devrait se concentrer sur la fourniture d'une interface utilisateur unifiée pour Windows, que vous utilisiez C#, les API WinRT, les ABI Win32, C++, F#, VB, .NET Core.

WinUI 3.0 implique de supprimer tout ce code et le rendu de XAML hors du système d'exploitation Windows, et d'en faire un framework, indépendant du cycle de mise à jour du système d'exploitation, et de le rendre open source.

La façon dont il est soulevé et reconditionné est encore en suspens. Seuls ceux internes à Microsoft savent comment ils vont le faire. Afin de prendre en charge la future prise en charge multiplateforme de XAML, j'espère seulement que l'on réfléchit à la manière dont cela pourrait être réalisé à l'avenir, car ils l'extraient de Windows.

.NET Core est déjà disponible sur d'autres plateformes. Voilà donc le code C# derrière déjà transférable. Il ne s'agit désormais que de XAML et de l'interface utilisateur et des contrôles, qui nécessitent un chemin vers iOS/macOS/Android/Linux (et tout ce qui peut arriver à l'avenir)

En dehors du cadre de WinUI 3.0 peut-être, mais très certainement lié à ce projet et à cet effort.

@jesbis @terrajobst @jevansaks

Quels sont les plans de Microsoft pour intégrer un framework d'interface utilisateur dans .NET Core qui s'affiche sur le bureau, le mobile (Droid, iOS) et le Web ?
L'incertitude à ce sujet dure depuis très longtemps.

@weitzhandler , ils ont déjà une feuille de route , avec le paragraphe suivant :

Une cible Windows native pour les frameworks web et multiplateformes
WinUI 3 est mieux optimisé pour les bibliothèques et les frameworks sur lesquels
Par exemple, nous prévoyons de baser la nouvelle implémentation C++ React Native Windows hautes performances sur WinUI 3.

Notez la partie soulignée, « sur laquelle bâtir ». Comme je l'ai dit ci-dessus, il n'y a aucune raison pour que cela ne puisse pas être Windows en premier, avec d'autres bibliothèques construites dessus.

Alors ok...

/me keep working on FluSharp

ce qui est raisonnable, mais je ne pense pas que ce devrait être ce projet.

Il fait soif là-bas @MarkIngramUK , pardonnez nos projections. ??

avec le paragraphe suivant

Ne dit pas grand chose. Cela ne révèle pas l'intention claire de MS de créer un xplat de développement C# et .NET. Cela dit peut-être que HTML JS et CSS shi{ sont un meilleur équipement pour vous que C# si vous voulez être portable.

À l'heure actuelle, Xamarin et Xamarin Forms sont l'histoire de Microsoft pour le développement C# et .NET Core en dehors de Windows.

React Native pour Windows arrive pour le code Javascript et l'interface utilisateur native (qui utilisera WinUI 3.0 XAML)

Pour le moment, Microsoft n'a pas prévu d'apporter le XAML de WinUI 3.0 sur d'autres plates-formes.

WinUI, le projet tente d'unifier les frameworks de développement Win32, WPF, MFC, UWP, .NET Core, sous un seul framework de présentation XAML moderne.

Je pense qu'après cela, le travail devrait consister à trouver des moyens de rendre XAML écrit pour WinUI 3.0 - sur des plates-formes comme macOS, iOS, Android, etc. - mais ce n'est pas à l'ordre du jour jusqu'à présent.

Une fois que le travail de WinUI 3.0 commencera ici, il sera open source, ce qui rendra possible un futur travail multiplateforme pour l'avenir, s'il y a suffisamment de besoin. Et ce n'est peut-être pas Microsoft qui mettra finalement à disposition ces chemins multiplateformes, ce pourrait être la communauté open source.

Avez-vous l'intention de faire de F#, le beau-fils roux de .NET, un citoyen de première classe ? Et puis les gens se demandent pourquoi la grande majorité des développeurs .NET ne toucheront pas F# avec un poteau de dix pieds.

À l'heure actuelle, Xamarin et Xamarin Forms sont l'histoire de Microsoft pour le développement C# et .NET Core en dehors de Windows.

Oui, Xamarin.Forms est porté sur macOS, GTK, UWP et WPF, en plus d'avoir une conception matérielle partout dans les travaux, ce qui en fait de facto .NET UI Framework, mais il est si lent et bogué que je me demande ce que pense Microsoft sur ses développeurs. Il suffit de regarder la liste des problèmes ! Une fois le développement sérieux commencé, les bugs sont touchés à gauche et à droite. J'espère qu'avec WinUI, nous pourrons enfin avoir une meilleure expérience de développement.

Re : Fa#

Si vous pensez que d'autres nouvelles fonctionnalités telles qu'une meilleure prise en charge de F# ou de nouvelles capacités de balisage sont importantes, veuillez ouvrir une nouvelle demande de fonctionnalité afin que nous puissions les suivre séparément !

Oui, c'est toujours F# qui est à nouveau suivi séparément et ignoré. Il suffit de regarder UWP et .NET Native - les deux n'avaient pas F# en tête et la communauté dans son ensemble devait tout comprendre. 🙄 Après 4 ans, F# n'est toujours pas pris en charge sur .NET Native.

Pour les suggestions/questions F#, j'ai créé un problème dédié :
https://github.com/microsoft/microsoft-ui-xaml/issues/740

N'hésitez pas à y diriger les discussions F#.

Nous n'ignorons certainement pas les commentaires à ce sujet - avoir un problème dédié nous aide simplement à l'organiser et à le suivre.
L'équipe discute de la manière dont il pourrait s'intégrer dans la feuille de route pour la version 3.0 et au-delà et mettra à jour le nouveau numéro avec tout développement.

RE : interface utilisateur multiplateforme :

Merci à tous pour les points soulevés jusqu'à présent et pour la passion pour .NET et Xaml.
Je veux juste répéter que nous écoutons attentivement tous les commentaires et que nous partagerons nos réflexions et nos mises à jour au fur et à mesure de notre progression.

Juste pour réaffirmer la feuille de route actuelle et certains points qui ont été soulevés :

WinUI est la plate-forme d'interface utilisateur native pour Windows (y compris les applications natives, pas seulement .NET). cycle. Nous voulons nous assurer que la portée est suffisamment réalisable pour que nous puissions en avoir un aperçu cette année.

L'un de nos autres objectifs actuels à court terme est de permettre à WinUI de servir de cible native pour d'autres plates-formes à utiliser sur Windows : par exemple, nous travaillons également à garantir react-native-windows - une implémentation C++ React Native haute performance pour Windows - utilise WinUI et que les contrôles WinUI peuvent être utilisés pour créer des vues d'interface utilisateur natives dans les applications React Native.

Je serai parfaitement honnête. J'ai une application de bureau Windows native que j'ai écrite en 2006 sur WinForms et que je vends toujours en ligne aujourd'hui.

Je n'ai pas l'intention de migrer cette application vers WPF, UWP ou d'utiliser une technologie d'interface utilisateur Windows exclusive. Peu m'importe à quel point les démos Windows sont convaincantes. Si jamais je décide de travailler à nouveau sur cette application, la prochaine version majeure sera une sorte d'implémentation multiplateforme pouvant fonctionner sur MacOS, Linux et Windows.

Actuellement, cela ressemblerait probablement à Blazor + .NET Core + Electron.

Je pense que @Mike-EEE fait d'excellents points. L'UX/la plate-forme qui me permet de tirer parti de mes compétences en C# pour toucher le plus grand nombre d'audience est la technologie la plus probable que je choisirai.

Microsoft devrait se concentrer sur l'autonomisation des développeurs pour tirer parti de leurs compétences existantes pour atteindre un plus grand public avec leurs applications. Je pense que c'est une stratégie gagnante et qu'elle gardera Microsoft dans le coup.

L'écriture sur le mur est que le logiciel du système d'exploitation devient de plus en plus une marchandise. Cela étant, les utilisateurs peuvent choisir n'importe quel système d'exploitation et obtenir les applications qu'ils souhaitent utiliser. Je pense que cela deviendra de plus en plus évident à mesure que le temps avancera alors que les éditeurs de logiciels du monde continueront de se concentrer sur le multiplateforme.

En économie, une marchandise est un bien ou un service économique qui a une fongibilité complète ou substantielle : c'est-à-dire que le marché traite les instances du bien comme équivalentes ou presque sans se soucier de qui les a produites. https://en.wikipedia.org/wiki/Commodity

Microsoft doit décider, veut-il faire partie de l'histoire des outils de développement ? Ou Microsoft investit-il des millions de dollars dans une nouvelle pile UX uniquement Windows qui finira par rejoindre le cimetière des piles UX que de moins en moins de personnes utilisent ?

Ce projet appartient à une équipe qui possède une vaste connaissance du fonctionnement des composants internes de Windows.

C'est une position difficile à occuper, c'est sûr. Mais les temps ont changé. Le monde d'aujourd'hui est très différent de celui d'en 1995. De la façon dont je le vois, il y a plusieurs options :

Vous pourriez embaucher plus de personnes pour étendre ces connaissances au-delà de Windows.

Ou utilisez les connaissances de cette équipe pour créer une plomberie UX dans Windows qui améliore la compatibilité des frameworks d'applications d'interface utilisateur multiplateformes afin de mieux fonctionner sous Windows.

Tout comme WSL l'a fait pour exécuter Linux sur Windows.

• Utilisez les connaissances de l'équipe pour faire tourner GTK 200 fois plus vite.
• Utilisez les connaissances de l'équipe pour que les applications QT s'exécutent 200 fois plus rapidement.
• Utilisez les connaissances de l'équipe pour rendre les applications Electron plus rapides que tout autre système d'exploitation.

Il y a beaucoup de travail qui peut être fait pour améliorer l'histoire de la compatibilité UX multiplateforme de Windows. Mais investir dans une toute nouvelle pile UX et espérer que nous changions tous (sans histoire multiplateforme) est un assez gros pari. Vous allez devoir rompre cette habitude en créant de nouveaux frameworks UX uniquement pour Windows.

Juste mes deux cents. :Sac d'argent:

:horse_racing: :cowboy_hat_face: Lil Nas X - Old Town Road (Film officiel) ft. Billy Ray Cyrus

@bchavez

Vous allez devoir rompre cette habitude en créant de nouveaux frameworks UX uniquement pour Windows.

-- Non seulement que. Même l'habitude de casser la portabilité XAML interne de Windows. WPF, Siliverlight, UWP tous sur leur propre fork... Ce genre de chose éloigne de plus en plus de gens des outils de développement Windows en général que j'aimerais personnellement continuer à utiliser à l'avenir. Plus les outils de développement Windows sont repoussés, moins C# est pertinent et pour moi, c'est ce qui m'importe quand je m'y mets.

RE : interface utilisateur multiplateforme :

... WinUI est la plate-forme d'interface utilisateur native pour Windows (_ y compris les applications natives _, pas seulement .NET) et pour la version 3.0 initiale, nous nous concentrons principalement sur la rendre indépendante du système d'exploitation et à travailler à sa préparation pour l'open source développement sur un cycle de publication plus rapide. Nous voulons nous assurer que la portée est suffisamment réalisable pour que nous puissions en avoir un aperçu cette année.

Ajoutez un +1 pour l'idée de mettre à jour l'apparence visuelle des contrôles WinForms, MFC, WPF exécutés avec WinUI 3.0 afin de mieux correspondre aux styles de contrôle Fluent/FabricWeb.

Bien sûr, différentes tailles de contrôle (tout ce qui n'est pas WinRT XAML devrait probablement correspondre à leurs métriques avec la version Compact des contrôles UWP) mais un aspect poli cohérent et cohérent.

Ajoutez une dépendance WinUI 3.0 dans WinForms et les contrôles changent.

Les applications WinUI 3.0 WPF détectent et utilisent les thèmes de contrôle Fluent.Light.xaml ou Fluent.Dark.xaml.

@weitzhandler Je comprends votre sentiment. J'espère ne jamais avoir à toucher à javaScript et autres pour faire cette interface graphique multiplateforme. Je n'aime même pas penser à démarrer un projet en utilisant des électrons, angulaires, dard, flutter.
J'espère que nous pourrons bientôt avoir une solution avec .NET 5, qui apportera le rêve Universal XAML. Microsoft XAML peut GAGNER, Web, Mobile, Desktop et IoT.
Silverlight l'a presque fait, pour de nombreux cas d'utilisation .

Vous allez devoir rompre cette habitude en créant de nouveaux frameworks UX uniquement pour Windows.

WinUI 3.0 ne sera jamais publié si nous devons attendre (ce qui est inévitablement compromis sur toutes les plateformes) un support multiplateforme. WinUI doit être le framework d'interface utilisateur de niveau le plus bas sur Windows, et si vous voulez une capacité multiplateforme, construisez dessus (ou utilisez React Native, Xamarin, etc.).

Vous allez devoir rompre cette habitude en créant de nouveaux frameworks UX uniquement pour Windows.

Je voudrais juste préciser que nous n'essayons pas de créer un nouveau framework d'interface utilisateur avec WinUI 3.0.

Notre objectif initial est de :

• supprimer les obstacles à l'utilisation des technologies natives modernes existantes (interface utilisateur Windows 10 Xaml et compositeur) en les dissociant du système d'exploitation et en leur permettant de fonctionner sur des modèles d'applications existants (win32 et UWP), des langues, d'autres frameworks (via des îles) et des versions de Windows

• mettre à jour notre processus d'ingénierie pour qu'il soit open source

WinUI 3.0 ne sera jamais publié si nous devons attendre (ce qui est inévitablement compromis sur toutes les plateformes) un support multiplateforme.

Mec... Si vous y croyez vraiment, vous voulez dire que des frameworks performants comme Flutter ne fonctionnent pas...

Je n'aime pas Dart non plus, mais ils ont sorti un joli produit de descente qui évolue et obtient une traction VRAIMENT rapide.

Je suis frustré que WinUI ne devienne qu'une chose Windows...

.Net a besoin d'un cadre d'interface utilisateur qui correspond à l'incroyable capacité des plates-formes multiplateformes .Net Core, tout comme nous venons de l'avoir pour le Web avec Blazor (côté client et côté serveur).

Je pense que pour l'instant, nous devons encore compter sur les efforts communautaires.

Je comprends ce que votre équipe essaie de faire @jesbis... C'est juste que beaucoup d'entre nous sont fatigués de voir l'interface utilisateur sur .Net/C++/UWP/MFC/Windows une chose _silo_' qui ne fonctionne que sur Windows alors que tout le monde (ofc sauf Apple et OSX) vont dans le sens inverse en offrant aux développeurs de meilleures solutions multiplateformes. Comme vous avez mentionné le React et le Rect-Native (pour info, je n'aime pas non plus, juste en mentionnant qu'ils évoluent).

Donc, ce que nous avons maintenant, ce ne sont que des initiatives communautaires comme Avalonia ou même Uno et d'autres frameworks (comme FluSharp sur lequel je travaille comme mentionné) qui évoluent TRÈS LENTEMENT pour des raisons évidentes...

Ma suggestion est que plutôt que de simplement retirer le XAML et le compositeur de la base de code Windows et en faire un Windows uniquement, pour l'obtenir et faire des abstractions appropriées afin qu'il puisse fonctionner sur plusieurs plates-formes. Tout comme nous l'avons fait avec .Net Core, qui était initialement réservé à Windows, mais les efforts de la communauté l'ont fait fonctionner assez rapidement sur Linux, OSX et même sur les appareils ARM...

(un inévitablement compromis sur toutes les plateformes) support multiplateforme

Je ne pense vraiment pas que ce sera un problème, étant donné que la conception multiplateforme est, et a toujours été, un aspect clé de l'interface utilisateur XAML d'UWP et de Fluent Design. Il existe certainement des contrôles où la conception visuelle est différente entre les versions de Windows - cela est géré de manière transparente, vous obtenez une interface utilisateur native qui correspond au système d'exploitation de l'appareil.

Par exemple, Acrylic et Reveal intégrés aux contrôles, accentuent les couleurs sur les pivots et les vues de navigation - ces éléments n'apparaissent pas dans la mise à jour du créateur, mais sur FCU et les versions ultérieures. Aucun changement requis.

De toute évidence, il y a beaucoup plus de complexité dans les coulisses pour rendre l'interface utilisateur sur un système d'exploitation entièrement différent, mais en termes de conception de l'interface utilisateur, je ne pense pas qu'il y ait de nouvelles considérations à prendre en compte, qu'il n'y en a jamais eu avec UWP et WinUI.

Je pense que la grande préoccupation est de savoir quels sont vraiment les plans à long terme. D'après les réponses de @jesbis, il semble qu'ils se concentrent uniquement sur le court terme pour le moment, et les plans à long terme sont toujours ouverts à la discussion.

C'est compréhensible, la portée d'un tel projet est énorme. Je pouvais tout à fait comprendre si ce n'était pas le plan à court terme, mais plutôt le plan de fin de partie. La transparence est importante ici, il est clair que personne ne veut soutenir une plateforme sans avenir clair.

Il est clair que MS dans son ensemble se concentre sur le multiplateforme - nous le voyons avec Fluent Design (qui a maintenant des exemples pour iOS, Android et Web), un grand nombre d'applications MS sur d'autres plateformes - donc l'interface utilisateur partagée est vraiment juste un gros chaînon manquant. Et c'est pourquoi il serait si décevant de ne pas voir cela se produire - je pense que beaucoup de gens aiment l'idée d'une plate-forme d'application universelle conçue par MS, mais cela n'a pas de sens de prendre en charge, si nous n'avons pas de solution complète pour cela.

Le point est... Comme avec material.io et Cupertino, nous pourrions (et je ne suis pas surpris si Google ne le fait pas déjà !) avoir le "thème" sur flutter pour un langage de conception fluide...

Et c'est ce que je voulais dire lorsque j'ai dit qu'un cadre d'interface utilisateur vraiment multiplateforme ne se soucierait pas de cela et fonctionnerait, comme le fait Flutter... Je ne vois pas où nous avons des compromis à ce sujet...

@weitzhandler Je n'aime pas non plus le HTML pour les applications natives. Sinon, j'utiliserais Electron avec React

Je ne suis tout simplement pas passionné ici, mais plutôt rationnel.

J'attends vraiment avec impatience le WinUI 3.0 et je l'utiliserais immédiatement pour un nouveau projet de bureau Windows C++/WinRT. Et j'espère que la prochaine version majeure après 3.0 introduira un runtime portable pour héberger les applications WinUI (comme le runtime Flutter). Pour un nombre important d'applications métier et d'applications de type Photoshop, l'interface graphique peut être la même sur chaque plate-forme, mais la clé réside dans les performances et la réutilisation du code source. Et je pense aussi que le projet xlang est une excellente idée et promet de bonnes nouvelles dans le futur.

Je suggère aux utilisateurs ici de prendre le temps d'écouter Scott Hunter après BUILD 2019 sur la façon dont Win UI, Xamarin Form, UNO, Web Assembly pourraient se réunir.

.NET Core 3 et au-delà avec Scott Hunter @.NET Rock

Les formulaires Xamarin (XAML) et UNO (XAML) ont tous deux été créés avec la vision d'une plateforme multiplateforme. Dans le cas de UNO (en plus d'iOS, Android, XAML pour le Web via Web Assembly).

UWP a été créé sans vision au-delà de l'écosystème Microsoft, par exemple Web, Android, iOS. Tous les efforts de conception impressionnants de Fluent ont peu de succès en raison de l'adoption lente de l'UWP

Comme @Mike-EE l'a souligné, droid et iOS ont 2~ et 1,5~ milliards tandis que Win10 en a 0,9 milliard. La plupart d'entre eux hésitent encore à passer de WinForm et WPF à UWP.

POURQUOI? Les contrôles UWP, de commercial et de Microsoft, sont INCOMPLETS !!!!! par rapport à ceux de WinForm et WPF. Il n'y a aucun effort de la part de Microsoft pour aider cette transition. XAML île ne traitera pas cet AS LONG AS MICROSOFT a ANGLES MORTS comme ce manquent que les développeurs a besoin de transition vers UWP de WinForm et WPF.

Avec ces contrôles UWP manquants, des efforts importants sont maintenant déployés pour amener Win UI à React Native for Web. ?????? Nous avons besoin de ces contrôles Win UI manquants pour UWP afin que nous puissions faire pression pour la transition de WinForm et WPF vers UWP .

Un de ces contrôles est Diagram Control . Toutes les applications commerciales gourmandes en données ont besoin d'un contrôle de diagramme pour UWP.

==> Je comprends la nécessité de découpler l'interface utilisateur UWP. Cela n'a de sens que pour diffuser la marque Fluent Design sur d'autres plates-formes, par exemple iOS, Android, Web.
==> Veuillez vous concentrer sur un meilleur contrôle du modèle 3D et des contrôles de diagramme (à la fois 2D/3D)

Cela n'a de sens que de rester et d'attendre NET5 lorsque TOUTES les BCL de (mono est fusionné avec le natif de Windows, pour l'assemblage Web, etc.), car JE VOIS L'AVENIR DE L'interface utilisateur 3D créative de HOLOLENS.

Pour cela, nous avons besoin d' un contrôle de diagramme 2D/3D pour UWP et d' un contrôle de modèle 3D qui ne devrait pas simplement afficher le modèle, mais permettre au développeur d'accéder à l'animation squelettique/sommet.

@jesbis, je vous exhorte à mettre plus de personnes dans ces USP (arguments de vente uniques) de Win UI pour UWP.

@weitzhandler

Ce numéro a été créé pour discuter de la feuille de route WinUI 3.0 .

@jesbis a fait une déclaration de clarification :

WinUI est la plate-forme d'interface utilisateur native pour Windows (y compris les applications natives, pas seulement .NET). cycle. Nous voulons nous assurer que la portée est suffisamment réalisable pour que nous puissions en avoir un aperçu cette année.

Vos deux premiers commentaires étaient sur le sujet.

Les six suivants étaient une combinaison d'improductifs et de péjoratifs, et vous êtes sur le point d'enfreindre le code de conduite Microsoft Open Source .

Cela devrait rester une conversation productive et professionnelle avec Microsoft.

// Je ne suis pas cette conversation pour écouter un mec toute la journée.

Je pense qu'il y a d'excellents commentaires ici, même s'il semble qu'il pourrait y avoir deux discussions distinctes. Je vais être bref car la plupart des choses ont déjà été dites.

Multiplateforme & Web

.NET Core est génial. Nous pouvons enfin cibler chaque plate-forme et chaque point de contact avec d'excellents outils et un langage génial.
La seule chose qui manque est une pile d'interface utilisateur, à l'exception de Blazor (HTML / CSS craint cependant). Pour une comparabilité maximale, ce serait formidable d'avoir un cadre qui permet aux développeurs de bureau de migrer vers le Web et au-delà avec les mêmes compétences, outils et langage (Xaml et C#). Tbh, Silverlight a fait une bonne chose là-bas - cela a juste fonctionné). Je ne sais pas si WinUI doit être ce framework, mais veuillez soulever le problème en interne. Fondamentalement, Flutter pour les développeurs .NET, et le ciblage du Web serait le plus grand avantage.

Je ne sais pas si Xamarin pourrait être cette plate-forme, mais si c'est le cas, assurez-vous que le Xaml est aligné autant que possible sur WinUI et Xamarin.

WinUI

Cela doit arriver. Il devrait y avoir une pile Xaml commune pour créer les meilleures expériences possibles sur la plate-forme Windows. Idéalement, les lacunes manquantes de WPF en termes de contrôles et de fonctionnalités devraient être comblées.

HoloLens et au-delà

Avec l'arrivée de Lite et de nouveaux facteurs de forme super excitants tels que HoloLens, on pourrait affirmer que UWP n'est pas prêt pour cela en termes d'interface utilisateur. Oui, nous pouvons les exécuter sur un HoloLens, ce qui est bien, mais j'aimerais voir un moyen d'optimiser vraiment les applications pour la 3D sans utiliser Unity complet.

WinUI est bien en avance sur Xamarin. Mais l'équipe Microsoft vient de sortir Xamarin 4.0...
Personnellement, je suis plus comme Xamarin car c'est la dénomination la plus basse pour Cross Platform, le nombre d'applications natives pour SaaS augmentera à l'avenir.

À part Xamarin, il existe une alternative.
1) Pourquoi ne pas adopter la plate-forme UNO et faire le rendu Web en utilisant SkiaSharp ?
2) @zezba9000 Vous avez besoin d'un backend de rendu agnostique comme les moteurs de jeu l'utilisent pour commencer. En fait, je le reconnais un peu...

Peut-être que Microsoft pousse plus WinUI, car il y a une trace de code non open source à l'intérieur contrairement à d'autres solutions multiplateformes: Xamarin, UNO, peuvent avoir des bibliothèques UNIX...

Quoi qu'il en soit, que la force soit avec vous.
PS: les sponsors Github proviennent de Microsoft, alors veuillez sponsoriser un développeur Mac/Linux notable pour le fork Cross Platform de WPF/Winforms.

@jkoritzinsky , Une chose à laquelle l'équipe WinUI doit faire attention avec le renommage de WinUI 3.0 : si vous renommez l'un des types projetés dans .NET, les projections ne fonctionneront pas (et nous ne prévoyons pas d'en ajouter d'autres car ce n'est pas un système extensible maintenable). Voici une liste des types que nous projetons : https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Toute modification apportée à des types différents de ces types obligera les utilisateurs à envelopper leurs objets dans de nouveaux objets qui implémentent les nouvelles interfaces ou à copier leurs données dans les nouveaux types. En particulier, les types INotifyPropertyChanged et INotifyCollectionChanged sont intéressants en ce qui concerne les îles XAML et fournissent un support en aval.

Je suis d'accord et je suis heureux que vous ayez soulevé cette question, même si j'aimerais ajouter que je pense que ces projections sont un peu un mal malheureux. Nous ne projetons pas toutes les API qui devraient probablement l'être (en pensant aux API System.IO), nous devrions donc soit y remédier, soit penser différemment. Une chose qui vient à l'esprit est de ne pas ajouter de types similaires, mais différents, aux types .NET dans un espace de noms différent. Au lieu de cela, nous devrions permettre à nos développeurs C++ d'utiliser également System.ComponentModel.INotifyDataErrorInfo. C'est en quelque sorte ce que nous avons fait avec C++/CLI, mais cela ne nécessiterait pas de charger le CLR pour une application C++ pure. Je ne sais pas si cela serait plus déroutant, mais il semble que nous divulguions les différences fondamentales et sous-jacentes des technologies .NET et WinRT au niveau de la couche API, ce qui rend les choses incohérentes.

@meir-pletinsky. NET n'est qu'un framework que vous pouvez utiliser pour créer des applications avec UWP XAML. Ils veulent que la validation des champs de texte soit disponible pour les développeurs, quel que soit le framework qu'ils utilisent

C'est juste pour l'argent, nous avons des développeurs C++ qui nous tiennent à cœur. Bien que, comme je l'ai mentionné ci-dessus, j'aimerais que nous ne causions pas de confusion dans la communauté .NET juste pour que cela se produise.

@mdtauk , non, WinUI Desktop (anciennement Xaml Desktop) vous permet d'utiliser directement Xaml avec Win32, sans utiliser l'îlot.

Je pense que @meir-pletinsky faisait référence à .NET/C++, à moins que quelque chose me manque ?

@MarkIngramUK Je pense que nous parlons ici de deux projets différents. WinUI doit être le remplaçant de Win32. Les gens demandent une solution multiplateforme, ce qui est raisonnable, mais je ne pense pas que ce devrait être _ce_ projet.

Oui, je suis tout à fait d'accord ! Pour moi, WinUI consiste à définir l'interface utilisateur la plus moderne, la plus performante et la meilleure pour Windows. Xamarin devrait être l'histoire multiplateforme de Microsoft et devrait évoluer pour être au-dessus de WinUI.

@mdtauk

Ajoutez un +1 pour l'idée de mettre à jour l'apparence visuelle des contrôles WinForms, MFC, WPF exécutés avec WinUI 3.0 afin de mieux correspondre aux styles de contrôle Fluent/FabricWeb.

Bien sûr, différentes tailles de contrôle (tout ce qui n'est pas WinRT XAML devrait probablement correspondre à leurs métriques avec la version Compact des contrôles UWP) mais un aspect poli cohérent et cohérent.

Ajoutez une dépendance WinUI 3.0 dans WinForms et les contrôles changent.

Les applications WinUI 3.0 WPF détectent et utilisent les thèmes de contrôle Fluent.Light.xaml ou Fluent.Dark.xaml.

Je ne veux pas vraiment voir MS investir du temps et des ressources dans ces frameworks pour les faire ressembler à des applications Windows 10 natives. C'est pourquoi il y aura WinUI 3.0. Vous voulez l'apparence de Windows 10 dans les applications WPF/WinForms ? Utilisez WinUI 3.0.
MS devrait de loin investir ses ressources dans la fermeture des écarts existants (et bloquants) entre UWP/WinUI et leurs homologues Win32, plutôt que de revoir leurs anciens frameworks. D'autant plus que WinUI est destiné à devenir _le_ framework de présentation pour Windows...

J'aimerais demander des éclaircissements sur les intentions de WinUI et de Microsoft sur l'UI/UX :

1. WinUI remplace-t-il TOUS les éléments suivants (hypothétiquement ?) : Win32, ATL, MFC, WinForms, Silverlight (je sais), WPF, UWP et/ou XAML Islands ? Je reconnais que ces technologies continueront d'exister et continueront d'être supportées pendant une durée indéterminée ; Je veux juste comprendre clairement que c'est ce que Microsoft dit être "la voie à suivre", et que (par exemple), nous devrions considérer WinForms et WPF de la même manière que nous considérons Win32 ou MFC.

2. WinUI dérive-t-il de UWP ? (Ou, à quel point les deux sont-ils similaires ?) À quel point WinUI est-il similaire (ou différent) par rapport à UWP, XAML Islands ou WPF ?

En tant que développeur professionnel C# et C++, j'ai commencé à travailler avec WinForms, puis je suis passé à WPF, puis je suis revenu à WinForms simplement parce que je pouvais concevoir une interface utilisateur/UX à des fins professionnelles dans WinForms environ deux fois plus vite que je le pouvais dans WPF. WPF offrait beaucoup plus de flexibilité, de performances et avait une bien meilleure apparence, mais la modification XAML qui se produisait dès que quelqu'un touchait l'interface via le concepteur au lieu de modifier manuellement le XAML était horrible. Dans certains cas, je pense que WinForms (à l'aide du concepteur) était des ordres de grandeur plus rapide que la construction manuelle d'un formulaire ou d'un contrôle XAML similaire.

Personnellement, j'aimerais une interface utilisateur disponible et identique pour tous les produits Microsoft. Un framework qui peut être exploité par Win32 ou .NET d'une manière similaire signifierait des applications cohérentes et modernes pour TOUS les développeurs Microsoft, et signifierait également que les questions et problèmes courants peuvent être résolus dans des sessions qui ciblent une seule technologie, par exemple, en posant une question sur un contrôle, la réponse serait identique (sinon presque identique) pour un développeur Win32 OU un développeur .NET. Cela rendrait l'apprentissage de "WinUI" utile pour l'une ou l'autre pile pour tout développeur donné, et rendrait également l'accès aux informations en ligne (StackOverflow, etc.) beaucoup plus précieux, quel que soit l'endroit où vous développez. Bien que je n'utilise pas Xamarin, si Xamarin pouvait suivre ces traces (en tant qu'extension de WinUI ?), alors la déclaration ci-dessus pourrait être appliquée non seulement aux développeurs Windows, mais également à ceux ciblant Android, iOS, etc.

Pour quel type d'applications serais-je ravi d'utiliser WinUI ?

Si ma compréhension de WinUI est correcte et que c'est "la voie à suivre", remplaçant Win32, MFC, Forms, WPF, etc., et que le même framework est disponible pour le développement natif ou .NET, alors je remplacerai avec impatience la composition dans _ TOUTES _ des applications que je supporte. Des interfaces utilisateur modernes et cohérentes, qui fonctionnent (et se comportent) de la même manière quelle que soit la plate-forme ou la pile ? N'est-ce pas ce que nous voulons tous ? Je ne pense pas que quiconque veuille se rappeler comment à la fois CreateWindowEx() et exécuter une boucle de message pour distribuer des événements dans Win32 tout en gérant les événements de manière complètement séparée dans WinForms ou WPF. Il est temps pour quelque chose de "moderne". J'espère vraiment que c'est ce qu'est WinUI (3.0).

Compatibilité du système d'exploitation et prise en charge de bas niveau

Je pense que c'est bien que WinUI se concentre sur le découplage de la composition du système d'exploitation, mais il y a un grand nombre de clients qui ne sont même pas encore sur Windows 10. Je sais que c'est un point douloureux, et nous souhaitons tous que nos publics cibles soient les plus récents, mais c'est un réel problème auquel nous sommes tous confrontés quotidiennement. Quelle discussion est en cours sur la mise à disposition de WinUI sur les anciennes plates-formes au-delà de 1703, qui, je crois, est la plate-forme la plus ancienne actuellement ciblée ?

Est-ce que faire de WinUI peut être lié de manière statique ou intégrable (comme .NET Core/5) est une option ? Nous allons devoir cibler Windows 8.1, Windows 8, Windows 7, voire Windows PE. Comment pouvons-nous utiliser WinUI avec ces exigences ?

@shidell :

WinUI dérive-t-il de UWP ? (Ou, à quel point les deux sont-ils similaires ?) À quel point WinUI est-il similaire (ou différent) par rapport à UWP, XAML Islands ou WPF ?

WinUI 3.0 sera en quelque sorte la prochaine version des composants de la plate-forme d'interface utilisateur de Windows 10/UWP, y compris la plate-forme Xaml, la composition et la saisie. Cela vient de cette base de code.

Il devrait être très similaire aux API de la plate-forme Windows 10/UWP Xaml à l'exception de ce qui est mentionné dans la feuille de route : à savoir un espace de noms racine différent, une meilleure prise en charge du mélange et de la correspondance avec d'autres technologies (par exemple, en utilisant un modèle d'application win32 au lieu d'UWP), et quelques nouvelles fonctionnalités additives.

WinUI remplace-t-il TOUS les éléments suivants (hypothétiquement ?) : Win32, ATL, MFC, WinForms, Silverlight (je sais), WPF, UWP et/ou XAML Islands ? Je reconnais que ces technologies continueront d'exister et continueront d'être prises en charge pendant une durée indéterminée ; Je veux juste comprendre clairement que c'est ce que Microsoft dit être "la voie à suivre", et que (par exemple), nous devrions considérer WinForms et WPF de la même manière que nous considérons Win32 ou MFC.

WinUI est l'endroit où notre principal développement actif et nos progrès concernent l'interface utilisateur d'application native sur Windows. C'est également ce que Windows lui-même et les applications et appareils Microsoft natifs utilisent.

Les îles Xaml feront partie de WinUI et vous permettront d'utiliser WinUI pour créer de nouvelles vues dans des applications existantes (par exemple WPF, WinForms).

Quelle discussion est en cours sur la mise à disposition de WinUI sur les anciennes plates-formes au-delà de 1703, qui, je crois, est la plate-forme la plus ancienne actuellement ciblée ?
Est-ce que faire de WinUI peut être lié de manière statique ou intégrable (comme .NET Core/5) est une option ? Nous allons devoir cibler Windows 8.1, Windows 8, Windows 7, voire Windows PE. Comment pouvons-nous utiliser WinUI avec ces exigences ?

Merci d'avoir partagé les commentaires à ce sujet. Pour 3.0, nous nous concentrons sur les plates-formes de la feuille de route (1703+, avec un peu de support sur 8.1). Nous comprenons certainement que les développeurs ont également des clients sur d'autres versions, et c'est quelque chose que nous prévoyons d'évaluer à l'avenir.

Génial - il semble que WinUI soit "la voie à suivre", et étant donné cette compréhension, dire que je suis excité serait un euphémisme.

En particulier, je pense qu'il est fantastique que les îles XAML permettent aux développeurs d'étendre WinUI à des technologies plus anciennes, telles que WPF et WinForms. C'est un grand pont "en avant" tout en travaillant sur / étendant d'anciens (plus) projets.

Génial - il semble que WinUI soit "la voie à suivre", et étant donné cette compréhension, dire que je suis excité serait un euphémisme.

En particulier, je pense qu'il est fantastique que les îles XAML permettent aux développeurs d'étendre WinUI à des technologies plus anciennes, telles que WPF et WinForms. C'est un grand pont "en avant" tout en travaillant sur / étendant d'anciens (plus) projets.

J'aimerais penser que si un projet WinForms, MFC ou WPF était créé avec WinUI 3.0 inclus, ils pourraient simplement afficher des pages/contenus/fenêtres XAML sans avoir à utiliser un îlot XAML dans une fenêtre Form/WPF/HWND.

La possibilité d'utiliser simplement du XAML pur ou d'utiliser une île pour placer XAML dans les surfaces fournies par le framework - ferait vraiment de WinUI 3.0 "L'interface utilisateur unique pour les gouverner tous"

ferait vraiment de WinUI 3.0 "L'interface utilisateur unique pour les gouverner tous"

... sous Windows. ??

WinUI 3.0 sera en quelque sorte la prochaine version des composants de la plate-forme d'interface utilisateur de Windows 10/UWP, y compris la plate-forme Xaml, la composition et la saisie. Cela vient de cette base de code.

Sur cette note, @jesbis , je me demande si vous pouvez parler de la façon dont l'intégration se déroulera entre WPF et UWP. En particulier, avec des concepts tels que les extensions de balisage que nous demandons depuis des années dans UWP, avec très peu de succès.

Une tentative a été faite , bien sûr, mais n'a pas réussi à mettre en œuvre WPF malgré le fait qu'il ait fallu plus de deux années complètes de développement.

De plus, de nombreux services qui étaient disponibles dans le balisage WPF restent disponibles et implémentés dans UWP. L'effort est-il ici pour garantir que le nouveau balisage WinUI 3.0 basé sur UWP sera entièrement fidèle à WPF ? Je m'excuse si cela est expliqué quelque part, mais je n'ai pas encore analysé le message pour le voir (et j'accueille toutes les ressources pour corriger/compléter ma compréhension).

ferait vraiment de WinUI 3.0 "L'interface utilisateur unique pour les gouverner tous"

... sous Windows. ??

Au moins pour la fenêtre de publication de WinUI 3.0. J'espère que cela pourrait être le début d'un processus pour amener le rendu XAML sur d'autres plates-formes...

Je me demande si vous pouvez parler de la façon dont l'intégration se déroulera entre WPF et UWP. En particulier, avec des concepts tels que les extensions de balisage que nous demandons depuis des années dans UWP, avec très peu de succès. [...] L'effort est-il ici pour garantir que le nouveau balisage WinUI 3.0 basé sur UWP sera entièrement fidèle à WPF ?

@Mike-EEE la fidélité totale avec WPF n'est pas un objectif pour 3.0. Cependant, nous suivons un certain nombre d'éléments de travail pour combler les lacunes au fil du temps (par exemple, améliorations de l'extension de balisage #741 - veuillez jeter un œil et laisser un commentaire pour savoir si cela répondrait à vos besoins !) et continuer à étendre WinUI au-delà de WPF (par exemple # 686 prise en charge du modèle 3D).

S'il y a d'autres fonctionnalités spécifiques dans WPF que vous voudriez/devriez utiliser dans WinUI, n'hésitez pas à ouvrir de nouveaux problèmes de proposition de fonctionnalités pour eux, ou commentez dans le récent numéro 719 " Fonctionnalités WPF qui devraient être dans WinRT XAML ". Nous n'avons pas des ressources infinies, mais nous essayons certainement de tenir compte de la contribution de la communauté dans notre planification. Une fois que tout sera open source, tout le monde aura également la possibilité d'aider potentiellement à contribuer à des fonctionnalités.

C'est encourageant, @jesbis merci de partager ça. J'ai mis à jour les votes pertinents sur UserVoice pour indiquer aux abonnés ce problème.

Je suppose que ma principale préoccupation est que si la fidélité totale de WPF n'est pas un objectif, alors que WinUI est utilisé dans WPF _est_ un objectif, alors vous allez rencontrer des frictions avec l'adoption de WPF, car il a le modèle Xaml supérieur (et original).

C'est-à-dire qu'il ne semble pas y avoir de proposition de valeur évidente pour l'incorporation de WinUI3.0 dans WPF, de la même manière que les îles Xaml n'ont pas de proposition de valeur évidente. En fin de compte, il semblerait que vous essayez d'introduire un modèle Xaml régressé/inférieur/sous-développé dans le modèle Xaml établi et supérieur, ce qui n'a tout simplement aucun sens.

Pour les cas d'utilisation dans WinForms, MFC, etc., oui, cette approche est logique pour WinUI3.0. Cependant, avec WPF, il dispose d'un modèle de présentation supérieur et d'un paradigme développeur/concepteur qui n'a tout simplement été égalé par aucune autre initiative de MSFT ou de fournisseurs externes.

@Mike-EEE basé sur le discours de Scott Hunter , il me semble, ce qui pourrait être faux, que l'objectif de "UNE BCL pour les gouverner tous" a une priorité plus élevée que "Une interface utilisateur pour les gouverner tous".

En remplaçant MONO sous-jacent Xamarin Forms XAML et UNO XAML dans l'assemblage Web via Web par un BCL commun qui a AoC, les applications basées sur Xamarin Forms XAML, Uno XAML sur le Web BÉNÉFICIERONT TOUTES des performances de vitesse.

Cette performance de vitesse EST CRITIQUE pour tous ceux qui se soucient de l'avenir de leur carrière en investissant dans C# pour les plates-formes multiplateformes face à la concurrence intense provenant d'autres technologies, par exemple flutter, réagir, etc.

Espérons que dans ce voyage vers .NET5 = une BCL commune pour les gouverner tous , la normalisation XAML est prise en charge, partiellement ou complètement, tout au long du processus, MAIS pas l'objectif principal de .NET5.

Une autre priorité en plus du besoin de normalisation XAML est la diffusion de la marque Microsoft grâce à une conception fluide sur toutes les plateformes (mobile, bureau et Web). [En termes techniques, le découplage via WinUI 3.0, auquel on nous demande maintes et maintes fois de se concentrer sur l'objectif de la feuille de route WinUI 3.0]

À LA FIN, combien UWP, dont Win UI est à l'origine, joue réellement un rôle dans cette BCL UNIQUE POUR LES RÉGLER TOUS d'ici NOV2020 lorsque .NET5 est publié, N'EST PAS AUSSI un objectif hautement prioritaire à mon avis.

Du point de vue du marketing, malheureusement pas traduit en technologie qui nous tient à cœur, c'est que l'image de marque Microsoft grâce à un design fluide est omniprésente et l'application faisant la promotion de ce design est RAPIDE PARTOUT.

C'est ainsi que je vois la stratégie à long terme de Microsoft pour "rattraper la part de marché" en raison du manque de présence mobile.

C'est évident, sauf que JE VOIS QU'UN POTENTIEL BEAUCOUP PLUS GRAND réside dans Hololens 2 et au-delà. Pour cela, NOUS DEVONS ASSURER QUE LES APPLICATIONS UWP avec WinUI 3.0 sont livrées avec des commandes de diagramme 3D et une visionneuse de modèle 3D avancée.

Désolé les gars, je continue d'insister car je veux utiliser le temps limité dont je dispose sur la MEILLEURE TECHNOLOGIE. :-)

Concernant la période de transition WinUI 3.0

Je suggérerais que Microsoft travaille directement avec les mainteneurs de Windows Community Toolkit (dont certains fonctionnent pour MS) afin de :

1. Testez pour voir s'il y a des barrages routiers imprévus lors du reciblage de la boîte à outils vers WinUI 3.0 (y compris l'exemple d'application).
2. Testez le renommage automatique des espaces de noms via Visual Studio ou "un autre outil" pour voir à quel point cela se passe bien.
3. Faites un rapport public sur le déroulement du processus (article de blog/problème GitHub/ce que vous voulez).
4. Fournissez un morceau de texte copier + coller sur WinUI 3.0 et la transition que les responsables du projet peuvent ajouter à leur GitHub/Nuget/autres Lisezmoi, ou au moins une URL avec des informations concises à ce sujet. Cela aidera rapidement tous les utilisateurs de ces projets à se familiariser avec WinUI 3.0 et expliquera ce qu'ils devront faire pour terminer la transition.
5. Décrivez un processus de transition suggéré et un calendrier que les responsables de projet/bibliothèque peuvent choisir d'adopter.

En ce qui concerne le dernier élément, cela devrait couvrir des suggestions telles que :

• Créez un nouveau numéro de version majeure indiquant qu'il doit être utilisé avec les applications WinUI 3.0 (telles que WCT v6.0).
• Facultativement (?) Créez une branche pour contenir le code hérité qui prendra en charge les projets qui n'ont pas encore été mis à jour vers WinUI 3.0.
• Prévoyez une période (par exemple 3/6/12 mois) pendant laquelle le support pour les projets hérités sera fourni (c'est-à-dire la fusion des corrections de bogues et autres de la branche principale). Cela pourrait potentiellement avoir des dates spécifiques pour « synchroniser » la période de soutien entre les projets/bibliothèques communautaires.

Enfin, je pense qu'il sera important d'identifier ce qui peut être fait si vous devez prendre en charge Windows 10 version 1507 et 1607 LTSB. Ce sont les 2 seules versions prises en charge de W10 qui seront à l'état sauvage et avec lesquelles WinUI 3.0 ne sera pas compatible au moment de la sortie.

À l'origine, j'allais suggérer de tester le processus avec la calculatrice Windows 10, car il s'agit d'une application open source de qualité de production. Cependant, j'ai alors réalisé que cette application devait fonctionner sur 1507 et 1607 LTSB pendant encore 6 à 7 ans. Il y aura évidemment des conflits autour de la prise en charge de ces types d'applications, en particulier lorsqu'il s'agit de projets communautaires plus petits. S'ils ont vraiment besoin de ce soutien, une stratégie claire à long terme sur la façon de le faire devrait être fournie.

Concernant WinUI 4.0/3.x/vNext

Comme l'indiquent les commentaires ici, la communauté a une liste de souhaits assez longue pour les futures versions de WinUI. Nous devrions vraiment capitaliser sur l'élan et l'enthousiasme qui se développent ici en documentant publiquement certains des plans à plus long terme.

Étant donné que la plupart de ces éléments sont hors de portée de la v3.0, je pense qu'un nouveau problème devrait être créé le plus tôt possible pour commencer à recueillir les commentaires de la communauté sur WinUI 4.0/3.x/vNext. Le cas échéant, cela aidera à identifier à la fois les types de travail envisagés par l'équipe WinUI et ce qui est hors de portée de WinUI et/ou de la responsabilité des autres équipes MS.

Un exemple du dernier point - j'aimerais vraiment voir ces choses:

• Prise en charge de .NET Core 3.0 pour les projets UWP (responsabilité de l'équipe .NET, si je comprends bien)
• Prise en charge complète des applications Windows (UWP et Win32) à partir de Visual Studio App Center (évidemment pas quelque chose dont l'équipe WinUI est responsable)
• Directives de conception fluide plus concrètes, similaires à celles que vous pouvez trouver dans les documents de conception matérielle (là encore, responsabilité distincte de l'équipe)
• Utilisation de WinUI 3.0 et de la conception Fluent dans les applications W10 intégrées (des équipes distinctes et certaines de ces applications doivent prendre en charge les versions LTSB)

En identifiant ces éléments hors de portée, nous pouvons rediriger la communauté vers les points de rétroaction appropriés et/ou expliquer autrement ce qui se passe dans ces domaines.

En dehors de ces éléments, la liste de souhaits dans le champ d'application peut commencer à se rassembler et la communauté peut commencer à montrer son soutien à ce qu'elle souhaite le plus de WinUI à l'avenir.

Ce serait formidable si F# avait une prise en charge équivalente à C#, par exemple en ayant les mêmes modèles de projet que C#.

J'aimerais que WinUI (UWP vNext) ait un objet Window approprié comme WPF, avec les méthodes Top, Left, Width, Height, StartupPosition, IsTopMost, AllowTransparency et Show() / ShowDialog().

(_Je ne suis pas sûr de la façon dont cette fenêtre fonctionnerait (ou serait autorisée) sur les appareils à petit écran, comme les téléphones mobiles et l'IoT_)

@TonyHenrique, il existe une nouvelle API de fenêtrage pour UWP en 1903, mais elle est loin d'être terminée.

Se penche à nouveau sur le rendu de XAML dans le cadre de WinUI 3.0.

Les choses que je pense être un pas en arrière par rapport au rendu de WPF sont :

• Texte n'utilisant pas ClearType, privilégiant plutôt l'anticrénelage en niveaux de gris ;
• Manque de précision des pixels pour des choses comme les traits de bordure ;

Je peux comprendre quand Windows Phone 7 et Windows Phone 8 ont dû partager un système de rendu - le type de technologie d'écran et la vitesse de rendu poussaient à être plus performants. Mais avec WinUI qui pivote d'abord vers le bureau et des écrans plus grands, il est peut-être temps de restaurer ces qualités dans le moteur de rendu XAML.

Et si des choses comme Hololens et Xbox nécessitent une attention particulière, pourquoi ne pas proposer un mode de performance qui peut être activé au niveau de la plate-forme sur les appareils qui ont besoin du rendu tel qu'il est actuellement ?

Qu'en est-il du modèle f# ?

À moins que cela ne fonctionne immédiatement dans les modèles de projet Windows Forms et WPF standard ciblant .NET Framework 4.5 ou une version plus récente, nous ne pouvons pas adopter la bibliothèque WinUI.

Exiger uniquement la dernière version de Windows 10 et/ou l'application UWP est un obstacle pour l'adoption de la conception Fluent.

Je suggérerais que Microsoft travaille directement avec les mainteneurs de Windows Community Toolkit (dont certains fonctionnent pour MS)

@kmgallahan
Super proposition ! C'est certainement dans le plan. Notre équipe travaille souvent en étroite collaboration avec les mainteneurs de Windows Community Toolkit et c'est l'une des choses que nous aimerions utiliser comme projet de test.

Se penche à nouveau sur le rendu de XAML dans le cadre de WinUI 3.0.

@mdtauk
Tout changement de rendu est probablement hors de portée pour la 3.0, mais veuillez ouvrir un problème pour cela afin que nous puissions potentiellement revoir l'idée pour les versions ultérieures. Les performances universelles ont certainement été au centre de l'attention, ce qui, comme vous le constatez, a entraîné des changements de rendu dans Windows 8+. Le commutateur de mode de performance est une idée intéressante.

Qu'en est-il du modèle f# ?

@edgarsanchez , @khoshroomahdi
Il semble que nous nous intéressons beaucoup à F# ! Nous aimerions en savoir plus sur les raisons pour lesquelles vous voulez F# : n'hésitez pas à commenter dans le numéro F# ​​pourquoi vous le voulez et à quoi vous l'utiliseriez : #740

À moins que cela ne fonctionne immédiatement dans les modèles de projet Windows Forms et WPF standard ciblant .NET Framework 4.5 ou une version plus récente, nous ne pouvons pas adopter la bibliothèque WinUI.

@jozefizso
Avez-vous regardé dans les îles Xaml? Cette fonctionnalité vous permet d'utiliser WinRT Xaml dans les applications WPF et Windows Forms afin de pouvoir commencer à les améliorer avec des vues/pages Xaml modernes :
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

Nous prévoyons que WinUI 3.0 inclue des îles et soit rétrocompatible avec Creators Update et les versions plus récentes, qui correspondent au moins aux 5 dernières versions de Windows.

Xaml Islands travaillant sur Creators Update et plus récent avec WinUI 3.0 pourrait-il répondre à vos besoins ?

Tout changement de rendu est probablement hors de portée pour la 3.0, mais veuillez ouvrir un problème pour cela afin que nous puissions potentiellement revoir l'idée pour les versions ultérieures. Les performances universelles ont certainement été au centre de l'attention, ce qui, comme vous le constatez, a entraîné des changements de rendu dans Windows 8+. Le commutateur de mode de performance est une idée intéressante.

Terminé #768

Les îles XAML nécessitent Windows 10, version 1903 et la bibliothèque Windows Community Toolkit requiert que le projet soit UWP. C'est un non.

Les îles XAML nécessitent Windows 10, version 1903 et la bibliothèque Windows Community Toolkit requiert que le projet soit UWP. C'est un non.

WinUI 3.0 ne passera pas sous Windows 7/8/8.1 - mais ces systèmes d'exploitation arriveront très bientôt en fin de vie. Et vous pouvez toujours utiliser WPF et WinForms pour le moment. C'est pour quand vos utilisateurs sont passés à Windows 10

Dans ce cas, le projet sera UWP pour Windows 10, il ne sert donc à rien de prendre en charge WPF/WinForms. Cela ne fait que tourner en rond et fragmenter les outils de développement.

@jozefizso Plus précis pour dire que UWP change pour lui permettre de ressembler davantage à WPF et WinForms, et l'interface utilisateur XAML se rapproche des plates-formes WPF et WinForms.

Des applications UWP avec une interface utilisateur XAML moderne sortant du sandbox restrictif et capables de se connecter aux plates-formes WPF et WinForms.

C'est ainsi que je le comprends.

Les îles XAML nécessitent Windows 10, version 1903

Auquel cas le projet sera UWP pour Windows 10

Avec WinUI 3.0, nous prévoyons de rendre les îles disponibles sur 1703 et plus (donc beaucoup plus loin).

Nous travaillons également à ce que WinUI soit utilisable avec un modèle d'application Win32 au lieu d'UWP (appelé officieusement "Bureau WinUI"), il ne devra donc pas nécessairement s'agir d'une application UWP.

Nous travaillons également à ce que WinUI soit utilisable avec un modèle d'application Win32 au lieu d'UWP (appelé officieusement "Bureau WinUI"), il ne devra donc pas nécessairement s'agir d'une application UWP.

C'est la chose qui me passionne le plus. Une application native avec l'API complète de Windows disponible, que ce soit Win32 ou Windows Runtime, capable d'avoir une interface utilisateur performante via Xaml.

Nous travaillons également à ce que WinUI soit utilisable avec un modèle d'application Win32 au lieu d'UWP (appelé officieusement "Bureau WinUI"), il ne devra donc pas nécessairement s'agir d'une application UWP.

C'est la chose qui me passionne le plus. Une application native avec l'API complète de Windows disponible, que ce soit Win32 ou Windows Runtime, capable d'avoir une interface utilisateur performante via Xaml.

Prenez une application WinForms, gardez le code derrière, mais remplacez le formulaire par une fenêtre XAML et accédez à tous les pinceaux et contrôles XAML.

WPF serait légèrement plus compliqué d'utiliser simplement le XAML WinUI en place - mais au moins les contrôles WPF pourraient être stylisés pour correspondre à ceux de WinUI

1. L'espace de noms doit être renommé. "Xaml" n'est pas approprié car Xaml fait référence à un langage de balisage, qui est utilisé à tort comme langage marketing (qui change souvent) pour les composants UWP natifs. "Xaml" doit être remplacé par "WinUI". Vous pouvez voir combien de confusion est causée même dans ce fil, où il est très souvent difficile de savoir si "Xaml" fait référence au langage .xaml ou aux composants de l'interface utilisateur.
2. Dans la mesure où cela rapproche WPF et UWP, c'est bien. Ils ont chacun des fonctionnalités non présentes dans l'autre, et il est logique d'avoir "Windows UI" qui combine les deux. Il peut y avoir des doublons de fonctionnalités mais cela peut aussi être un chemin de transition WPF -> UWP.
3. Le découplage des versions Windows est logique, mais il est également possible de supposer un Win10 relativement mis à jour, étant donné que Win7 aura dépassé la fin de vie une fois ce travail terminé.

Xaml est le nom du framework d'interface utilisateur. D'où Windows.UI.Xaml...

Xaml est le nom du framework d'interface utilisateur

Xaml était une technologie de WPF qui permettait aux développeurs de décrire et de construire de manière puissante non seulement des scènes de présentation dans leurs applications, mais aussi les applications elles-mêmes. C'est-à-dire que vous pouvez décrire des éléments d'interface utilisateur _ainsi que des POCO_. S'il s'agissait de .NET, il pourrait être richement décrit avec Xaml et chargé dans un contexte d'application.

N'oublions pas (et il semble que nous l'avons fait) que Xaml signifie eXtended Application Markup Language, ce qui signifie qu'il s'agit d'un langage de balisage qui vous permet de décrire avec élégance et efficacité les composants .NET _application_. Bien qu'il ait été principalement utilisé pour décrire les éléments de l'interface utilisateur, il n'était en pratique ni relégué ni contraint en tant que tel.

Personnellement, j'ai fini par utiliser Xaml pour décrire l'ensemble de ma configuration d'application, en supprimant et en remplaçant App.config - et oui, même Web.config - la complexité, sauf dans les cas des API externes qui l'exigeaient absolument.

Xaml n'est _pas_ l'interface utilisateur. Ce sont deux concepts totalement différents mais qui sont malheureusement amalgamés depuis des années sous UWP. Pour ma part, j'aimerais voir le terme "Xaml" démêlé de ces efforts, mais je ne suis pas très confiant que de telles mesures seraient envisagées, et encore moins entreprises.

@charlesroddie Je suis plutôt d'accord pour dire que le nom est vraiment arbitraire. Juste une tangente, si jamais vous inspectez les traces de pile d'éléments provenant de l'espace de noms WUXaml, c'est en fait en interne dans un espace de noms DirectUI. J'aimerais connaître l'histoire de Win8 si quelqu'un ici était présent à cette époque, car j'imagine qu'il y avait une histoire différente. DirectComp pour la composition de calques, DirectManipulation pour un défilement fluide et des bandes élastiques, puis Direct2D/DirectWrite comme moteur graphique vectoriel avec DirectUI sur le dessus pour tout rassembler. Ensuite, pour une raison quelconque, une partie a été rétroportée sur Win7, seuls les bits Xaml ont été exposés via le système WinRT, tandis que toutes les autres API ont été laissées en tant qu'interfaces de communication cryptiques avec des usines et des modèles étranges dont vous aviez besoin pour voir des exemples expliquer comment invoquer.

En fait, maintenant que j'y pense, ce serait vraiment bien si, tout comme WUComposition exposait DirectComp et DirectManipulation via WinRT (ou est-ce une réécriture), Direct2D/DirectWrite avait également une maison formelle ici. Ils fonctionnent tous ensemble pour permettre différents niveaux de trappes d'évacuation et de points de contact de fidélité si vous le recherchez. Win2D est vraiment à moitié cuit et n'est pas non plus une bonne API.

Je crois que Windows.UI.Composition est une réécriture de DirectComposition. Les API sont similaires mais pas identiques.

Arrêtez de supposer que tous les moniteurs sont plus sRGB.
Traitez les couleurs de toutes les applications héritées comme sRGB et effectuez la conversion pour chaque moniteur lors de la composition.

Cela peut être un peu hors sujet, mais supposons que vous ayez déjà une grande application Win32 écrite en C++, vous souhaitez moderniser le système d'interface utilisateur, vous pouvez donc utiliser WinUI ou Comp avec une dépendance minimale, comme utiliser Comp uniquement sans in- box control set, ou même sans XAML .

C'est déjà possible maintenant, nous n'avons pas besoin d'attendre WinUI 3.0 pour cela.

Merci à tous pour vos retours sur le nom. Comme indiqué, nous avons aujourd'hui une distinction entre la "plate-forme Xaml" et le "langage Xaml" (avec ses propres spécifications/dialectes différents), ce qui peut prêter à confusion. Je ne pense pas qu'un changement de marque majeur soit dans les cartes, mais nous discutons définitivement du nommage et des espaces de noms.

Utilisez Windows.UI.Composition dans une application C++ Win32 sans XAML pour moderniser les applications existantes (comme Photoshop). Ils ont déjà une architecture d'interface utilisateur.

Cela peut être un peu hors sujet, mais supposons que vous ayez déjà une grande application Win32 écrite en C++, vous souhaitez moderniser le système d'interface utilisateur, vous pouvez donc utiliser WinUI ou Comp avec une dépendance minimale, comme utiliser Comp uniquement sans in- box control set, ou même sans XAML.

Merci pour vos commentaires à ce sujet - je pense que cela devrait être possible à la fin avec WinUI 3, similaire à une application "sans cadre" utilisant Windows.UI.Composition que vous pouvez déjà faire aujourd'hui. Nous garderons cela à l'esprit lorsque nous déterminerons comment structurer le ou les packages et les dépendances WinUI NuGet.

Arrêtez de supposer que tous les moniteurs sont plus sRGB.
Traitez les couleurs de toutes les applications héritées comme sRGB et effectuez la conversion pour chaque moniteur lors de la composition.

@reli-msft pourriez-vous ouvrir un numéro séparé pour suivre cela ?

@jesbis 👉 #67

Apple a annoncé aujourd'hui SwiftUI...

Que diriez-vous si Xaml Direct devait recevoir des modèles Visual Studio pour permettre aux développeurs de choisir de créer des applications en utilisant du code au lieu de XAML et du code derrière.

Je ne pense pas qu'un changement de marque majeur soit dans les cartes, mais nous discutons définitivement du nommage et des espaces de noms.

Merci @jesbis, j'apprécie que vous soyez si engagé dans ce fil. Habituellement, il semble que quelqu'un fera un message/une annonce comme celui-ci et le laissera ensuite pour mort (ou pour que d'autres le gèrent avec parcimonie), il est donc encourageant de voir que vous, en tant qu'auteur du fil, êtes non seulement engagé, mais aussi attentif à Qu'est-ce que disent les autres. Surtout quand ces autres sont _me_. ??

Et vous avez raison : il y a 1) la plate-forme d'interface utilisateur et 2) le mécanisme langage/balisage/description. Dans mes remarques critiques, je dirai que je n'accorde jamais assez de crédit à la (première) plate-forme d'interface utilisateur, car je sais qu'il y a eu beaucoup de travail formidable de la part de l'équipe Windows autour de cela. Cela n'a jamais été un sujet de préoccupation pour moi, personnellement. C'est le 2ème domaine qui attire ma colère et ma consternation (et celles des autres), et nous le voyons dans les problèmes UserVoice qui ont surgi au fil des ans.

Cela dit, je demanderais au moins (par exemple, même 😅) d'envisager davantage les efforts de branding pour mieux catégoriser ces deux sphères. Je pense que « Xaml Direct » est le summum de la confusion ici, comme son nom l'indique « langage de balisage » – c'est juste dans le nom ! -- mais il n'y a rien de la sorte dans son utilisation réelle. Terriblement déroutant et trompeur, et abus de marque limite, je dirais.

Et en parlant de Xaml Direct, @mdtauk :

Que diriez-vous si Xaml Direct devait recevoir des modèles Visual Studio pour permettre aux développeurs de choisir de créer des applications en utilisant du code au lieu de XAML et du code derrière.

Comme dans quelque chose comme CSharpForMarkup ?

Un nom bien meilleur et approprié que Xaml Direct, je suggérerais. Bien sûr, _any_ name serait. ??

Et en parlant de Xaml Direct, @mdtauk :

Que diriez-vous si Xaml Direct devait recevoir des modèles Visual Studio pour permettre aux développeurs de choisir de créer des applications en utilisant du code au lieu de XAML et du code derrière.

Comme dans quelque chose comme CSharpForMarkup ?

Un nom bien meilleur et approprié que Xaml Direct, je suggérerais. Bien sûr, _any_ name serait. ??

@Mike-EEE https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

Il est conçu pour que les middleware écrivent l'interface utilisateur XAML à partir du code, mais que se passe-t-il s'il existe des modèles pour l'utiliser à la place des fichiers XAML ? Juste une idée à émettre là-bas...

@mdtauk OUI ! SwiftUI ressemble en quelque sorte à Xaml mais fait dans le code. J'aime vraiment l'idée de tout dans le code de la façon dont React le fait. C'est un peu la vieille école de diviser vos fichiers de conception et de les lier ensuite à une sorte de code-behind, et je trouve que cela rend la maintenance difficile.

Un ami venait de mentionner qu'il avait besoin du moteur de mise en page SwiftUI pour fonctionner avec l'écran 120 Hz de l'iPad Pro. C'est donc là-dessus qu'ils se sont concentrés. Assez fascinant vraiment.

J'ai fait un nouveau numéro #804 où la discussion sur les changements inspirés de SwiftUI pourrait aller @ eklipse2k8

N'OUBLIEZ PAS d'ajouter des modèles pour Visual Basic.😀

Laissez WPF construire les couches inférieures de _sur_ WinUI 3 !

@reli-msft quels avantages voudriez-vous tirer de la mise à jour de WPF ?

S'il existe des fonctionnalités WPF spécifiques sur lesquelles vous comptez et que vous aimeriez voir dans WinUI, nous aimerions en savoir plus dans le fil de discussion "Fonctionnalités WPF qui devraient être dans WinRT [WinUI]": https://github.com/microsoft /microsoft-ui-xaml/issues/719

Clôture en faveur du nouveau numéro épinglé #888

J'attends vraiment ça avec impatience. Résoudra de nombreux problèmes spécialement liés à la version.

@weitzhandler [le 16 mai 2019

Pour moi, tous les détails techniques sont moins importants.
UWP, WPF ou tout autre framework Windows, aussi génial soit-il, ne suffira pas tant qu'il ne fonctionnera pas sur toutes les plates-formes (au moins Windows, Droid, iOS et Web) et est convivial avec n'importe quelle taille d'écran.

En ce qui concerne WinUI et XAML en général, j'aimerais voir des améliorations dans les aspects suivants, dont certains que je trouve ennuyeux et ralentissent mon travail.

• BEAUCOUP plus de convertisseurs intégrés Il devrait y avoir une tonne de convertisseurs, dont certains devraient même être utilisés comme extension de balisage pour réduire la verbosité. Cela devrait également inclure la négation d'une action arithmétique simple, d'un convertisseur d'objet en booléen (faux par valeur sémantique, c'est-à-dire chaîne vide, collection vide, visibilité cachée, etc. par contexte).
• Idem que ci-dessus mais avec des comportements. Il devrait y avoir un port facile entre la liaison et les événements/actions. Ce serait beaucoup plus facile si cela avait été intégré et que le développeur ne doute pas du NuGet non testé à utiliser.
• Tous les éléments manquants de WPF, tels que certains types de liaison, extensions de balisage, vues génériques et autres.

Merci!

BEAUCOUP plus de convertisseurs intégrés

Depuis le moteur analytique de Babbage et la théorie du calcul universel de Turing, un seul ordinateur peut exécuter n'importe quel programme que n'importe quel ordinateur peut exécuter. Vous voulez revenir à une époque où nous devions créer un nouvel ordinateur pour chaque calcul que vous souhaitez effectuer.

Toute l'activité des convertisseurs devrait être abandonnée sans ménagement.

convertisseur objet en booléen

les booléens sont des booléens. Les autres objets ne sont pas des booléens. Et il n'y a pas de conversion naturelle des objets en booléens. Les types sont importants dans .Net et les autres systèmes non typés ne doivent pas être exposés aux utilisateurs.

Oui et les systèmes non typés existants comme les liaisons doivent également être vidés.

Toute l'activité des convertisseurs devrait être abandonnée sans ménagement.

Je veux dire quelles sont vos alternatives?
Mon problème avec les convertisseurs est seulement que vous devez les réécrire vous-même / choisir parmi NuGet, et qu'ils sont si détaillés. Qu'en plus d'être non flexibles, ne permettant aucune expression telle que l'arithmétique ou la négation, etc.

les booléens sont des booléens. Les autres objets ne sont pas des booléens.

Vous avez raison, mais en ce qui concerne l'interface utilisateur, cela n'a pas vraiment d'importance.
Vous voulez afficher/masquer des éléments basés sur l'état conventionnel de l'objet. Tout ne devrait pas avoir une propriété de visibilité dédiée.

les systèmes non typés existants comme les liaisons doivent également être vidés.

Hein? Je pense en fait qu'il a un avantage. Un couplage lâche entre V et VM peut être bon.

les systèmes non typés existants comme les liaisons doivent également être vidés.

Un couplage lâche entre V et VM peut être bon.

Pour les petits projets peut-être, mais il existe de meilleures abstractions pour le couplage lâche que de désactiver littéralement l'assistance du compilateur. Si vous avez déjà dû gérer une grande application avec des dizaines à des centaines de vues et que vous souhaitez refactoriser quelque chose qui peut être utilisé sur plusieurs sites, ne pas demander au compilateur de vérifier l'exactitude des chemins de liaison est une dégradation majeure de l'expérience du développeur. Il y a une raison pour laquelle nous avons des systèmes de types dans nos langages, les grands projets sont littéralement impossibles à maintenir sans outils pour aider le programmeur, actuellement les langages d'interface utilisateur sont à la traîne.

Les liaisons compilées aident beaucoup pour cela.

@weitzhandler Je veux dire quelles sont vos alternatives ?
... Tout ne devrait pas avoir une propriété de visibilité dédiée.
Hein? Je pense en fait que [les fixations] ont un avantage. Un couplage lâche entre V et VM peut être bon.

Dans un bon cadre réactif, vous pouvez définir des variables observables (dans le code) comme name:Mutable<string> , puis les mapper sur let visibility = name.map(fun s -> s <> "") , puis les lier pour afficher les propriétés avec visibility.bind someView.set_IsVisible ou name.bind(fun s -> someView.IsVisible <- s <> "") .

J'utilise https://github.com/ReedCopsey/Gjallarhorn mais il existe divers frameworks réactifs.

Notez que : 1. tout est tapé, contrairement aux liaisons. 2. Les choses (fonctions, propriétés, vues) sont appelées objets, pas en passant des noms de chaîne, 3. les fonctions ne sont que des fonctions, beaucoup moins maladroites que les convertisseurs, 4. passe-partout de liaison, où des propriétés d'objet simples doivent être données en plus « propriétés pouvant être liées », etc., peuvent être supprimées.

Les vues peuvent toujours être écrites en Xaml, surtout s'il s'agit de mises en page simples pour la plupart statiques, avec l'inconvénient des chaînes magiques partout, mais l'avantage d'avoir un concepteur pour donner une vue en direct. Mieux serait d'avoir un code qui donne une vue en direct. Très possible avec un interprète.

En parlant de frameworks réactifs, veuillez consulter Chain Reactive et dire si je dois l'ouvrir en source.

Salut, ms team peut-il résoudre tous les bugs/fonctionnalités sur uservoice ?
Si c'était le cas, ce serait un grand pas, plus que WinUI 3.0.

@ hupo376787 Je pense que vous avez obtenu des

Mais c'est un problème qu'il n'y ait pas de place pour une discussion ouverte sur les plates-formes de développement Windows auxquelles Microsoft et les développeurs peuvent participer, et c'est un problème que le groupe Microsoft concerné ne maintienne aucun mécanisme de retour d'information, n'ayant pas mis à jour ou répondu à cela uservoice depuis plusieurs années.

@charlesroddie Oui, il semble que la voix des utilisateurs soit abandonnée. J'enverrai ma voix à Feedback Hub. Peut-être que Mme les ignorera, mais je ferai mon travail.

UserVoice est entièrement retiré ce mois-ci.

Pour des produits spécifiques, les dépôts GitHub (comme celui-ci) sont le meilleur endroit pour les commentaires puisque les équipes d'ingénierie concernées les utilisent activement.

Pour les commentaires qui ne sont pas liés au produit d'un dépôt spécifique, veuillez utiliser Feedback Hub. Il existe une catégorie « Plateforme de développeur » avec diverses sous-catégories spécifiquement pour les commentaires sur les API et les outils de développement.

Je sais qu'il y a actuellement beaucoup d'historique et de commentaires sur UserVoice (dont nous garderons toujours une trace), mais GitHub et Feedback Hub fournissent un chemin plus direct vers nos équipes d'ingénierie et le suivi des éléments de travail que UserVoice ne le pourrait jamais, alors j'espère que cela devrait être un changement positif. Nous sommes en train de mettre à jour divers liens d'assistance et de commentaires.

Nous voyons tout ce qui vient de l'un ou l'autre canal et apprécions vraiment les commentaires et les rapports de bogues !

@jesbis OK, j'ai compris.

Pour WinForms, lors de l'utilisation du nouveau modèle de projet WinUI, la fenêtre Propriétés fonctionnera-t-elle toujours et pourra-t-elle définir les propriétés des contrôles WinUI ? Je peux coder du HTML toute la journée sans problème (Asp.net MVC généralement), mais quand il y a autant de paramètres disponibles pour les contrôles, j'ai apprécié l'utilisation de la fenêtre des propriétés au cours des 20 dernières années.

@Dean-NC Je suppose que vous posez des questions sur le concepteur XAML, pas de WinFoms/Windows Forms, n'est-ce pas ? Si c'est le cas, oui, le panneau Propriétés fonctionnera toujours pour les contrôles WinUI lorsque vous sélectionnez un élément sur le concepteur XAML.

@ marb2000 Je suppose que je pensais naïvement que WinUI 3 apporterait les nouveaux contrôles à WinForms dans le sens où ce serait principalement transparent, et que je pourrais avoir un formulaire avec à la fois des contrôles hérités et WinUI, et que la fenêtre Propriétés fonctionnerait pour les contrôles hérités et WinUI.

J'ai lu l'intégralité du message ci-dessus et j'ai suivi cela avec beaucoup d'enthousiasme (en tant que développeur WinForms), mais je suppose que j'ai mal compris le flux de travail de haut niveau sur la façon dont cela fonctionnera (encore une fois, du point de vue de WinForms ).

J'ai dit depuis longtemps que WinForms pourrait encore être une bonne chose pour les années à venir, mais sa plus grande faiblesse est que ses contrôles de base semblent datés (la zone de texte n'autorise pas le remplissage, il a donc l'air maigre, de petits boutons radio et case à cocher , etc.). Les bases mêmes des contrôles Win 10 (zone de texte, radio, case à cocher) contribueraient grandement à donner une nouvelle vie à WinForms.
Y a-t-il un article, ou cela vous dérange-t-il de donner une brève description de la façon dont le flux de travail serait pour un nouveau projet WinForms qui souhaite utiliser à la fois les contrôles hérités et les nouveaux ?
Merci.

@ marb2000 Je suppose que je pensais naïvement que WinUI 3 apporterait les nouveaux contrôles à WinForms dans le sens où ce serait principalement transparent, et que je pourrais avoir un formulaire avec à la fois des contrôles hérités et WinUI, et que la fenêtre Propriétés fonctionnerait pour les contrôles hérités et WinUI.

J'ai lu l'intégralité du message ci-dessus et j'ai suivi cela avec beaucoup d'enthousiasme (en tant que développeur WinForms), mais je suppose que j'ai mal compris le flux de travail de haut niveau sur la façon dont cela fonctionnera (encore une fois, du point de vue de WinForms ).

J'ai dit depuis longtemps que WinForms pourrait encore être une bonne chose pour les années à venir, mais sa plus grande faiblesse est que ses contrôles de base semblent datés (la zone de texte n'autorise pas le remplissage, il a donc l'air maigre, de petits boutons radio et case à cocher , etc.). Les bases mêmes des contrôles Win 10 (zone de texte, radio, case à cocher) contribueraient grandement à donner une nouvelle vie à WinForms.
Y a-t-il un article, ou cela vous dérange-t-il de donner une brève description de la façon dont le flux de travail serait pour un nouveau projet WinForms qui souhaite utiliser à la fois les contrôles hérités et les nouveaux ?
Merci.

Il est plus probable que vous puissiez prendre votre projet d'application, ajouter des fenêtres et des pages WinUI et utiliser l'interface utilisateur XAML moderne pour remplacer votre interface utilisateur soit totalement, soit petit à petit.

Et il existe des îles XAML pour insérer du XAML dans les interfaces utilisateur Winforms et WPF existantes

Votre équipe Blazor devrait travailler avec Uno pour que certains de ses modèles d'hébergement soient inclus dans Uno (en particulier côté serveur), et/ou pour obtenir la couche de rendu/visuel Uno UI (et donc WinUI 3) utilisable par Blazor.... et/ou peut-être Xaml Islands pour Blazor ?

Je me sens un peu à l'écart ici parce que la plupart des commentaires proviennent de développeurs qui travaillent principalement dans l'espace xaml. Ils semblent généralement chercher une meilleure version de ce qu'ils ont déjà. Cela pourrait être bon pour les utilisateurs existants, mais je ne sais pas si cela attirera de nombreux développeurs qui ont évité UWP à ce jour.

Mon équipe n'a développé qu'une seule application UWP. Nous ne développerons plus.

L'obstacle insurmontable est l'absence d'un rédacteur de rapport tabulé intégré. Nous avons essayé tous les rédacteurs de rapports tiers sur le marché qui déclarent prendre en charge UWP. Malheureusement, aucun d'entre eux ne fonctionne bien avec UWP. Leur offre UWP est généralement un hack rapide de leur variante WPF/WinForms et ne fonctionnera pas correctement.

Nous utilisons Stimulsoft Reports dans notre produit UWP. C'est très bogué et ils nous ont dit qu'ils ne corrigeraient pas les bogues car leur utilisation de l'UWP est si faible.

Je vois que vous avez la visualisation de données sur la liste. Mais la raison pour laquelle il existe encore des millions d'applications grises pour cuirassés est que de nombreuses entreprises ne se soucient pas beaucoup des visuels des applications internes. Ils veulent des colonnes de nombres avec des sous-totaux.

Donc, si WinUI est destiné à attirer enfin les formulaires sur les développeurs de données, nous avons besoin d'un rédacteur de rapport tabulé intégré.

J'espère que cela n'offense pas les visuels :-)

Je suis entièrement d'accord. Comment pouvons-nous développer des applications d'entreprise modernes sans un système de reporting qui peut être facilement intégré à l'application ? c'est un canyon massif qui empêchera les développeurs de se déplacer.

Les utilisateurs professionnels doivent pouvoir interagir avec les données tabulées, puis les imprimer ou les exporter dans d'autres formats. Ils doivent également être en mesure de créer des factures, des devis, des relevés et d'autres documents instrumentaux.

D'après ce que je comprends, l'entreprise/entreprise est toujours le plus gros consommateur de Windows. Pourquoi quelque chose d'aussi fondamental pour l'écosystème Windows n'est-il pas développé pour UWP ?

Merci pour les retours @VagueGit et @Elmarcotoro ! Les contrôles d'entreprise sont une lacune pour nous en ce moment. Mais votre timing est bon, nous recueillons des retours pour la conception d'un contrôle DataGrid. Veuillez lire et donner votre avis ici : #1500 .

De même, à côté du contrôle des données tabulaires carrées, nous avons besoin d'un contrôle graphique UWP open source pour partager de manière créative et démocratique des relations complexes via le contrôle de diagramme.

Pour un système de reporting, je pense que Telerik UI est le meilleur choix actuellement. Un proverbe chinois disant "Certaines personnes se spécialisent dans certaines professions tandis que d'autres dans d'autres professions.". Telerik, ou DevExpress ou quelqu'un d'autre, sont bons pour les rapports.

Pour l'absence de divers contrôles, il ne faut pas blâmer cette équipe, mais toute la stratégie MS. Depuis le début de Satya abandonne le mobile, ils préfèrent mieux iOS et Android, car un patron comme eux. L'ensemble de l'écosystème UWP devient de plus en plus faible.

Pour l'instant, il y a un argument nommé "UWP is dead" sur twitter, je pense que MS devrait clarifier cela et déclarer leur route uwp.

Pour l'instant, il y a un argument nommé "UWP is dead" sur twitter, je pense que MS devrait clarifier cela et déclarer leur route uwp.

Vous venez de poster ça sur le fil de la feuille de route...

@jevansaks Merci pour l'info sur le contrôle Datagrid. Cela ne traite pas les problèmes d'impression de rapports et de pagination, d'exportation et autres. Ce sont des scénarios commerciaux réels qui doivent être traités, pas si un bouton s'anime (aussi agréable et cool que cela puisse être).

@hupo376787
"Pour un système de reporting, je pense que Telerik UI est le meilleur choix actuellement."

D'après ce que je peux voir, Dev Express est le seul à fournir actuellement une pile complète pour créer et afficher des rapports pour UWP, et leur prix semble être du côté premium. Tous les autres, y compris Telerik, ont des lacunes dans leurs outils, ce qui signifie que les rapports pour UWP ne peuvent pas être créés. Je suis prêt (en espérant) qu'on me corrige à ce sujet.

Pour un système de reporting, je pense que Telerik UI est le meilleur choix actuellement. Un proverbe chinois disant "Certaines personnes se spécialisent dans certaines professions tandis que d'autres dans d'autres professions.". Telerik, ou DevExpress ou quelqu'un d'autre, sont bons pour les rapports.

@ hupo376787, veuillez faire très attention à vérifier vos faits avant de Telerik Reporting a un concepteur de rapports pour WPF et WinForms mais pas UWP.

DevExpress dispose également d'un concepteur de rapports pour WinForms et WPF, mais pas pour UWP

Veuillez donc vérifier vos faits avant de vous engager dans une erreur qui sera préservée à perpétuité et largement diffusée. Hé ça sonne comme si ça pourrait être un vieux proverbe un jour

@ hupo376787, veuillez faire très attention à vérifier vos faits avant de Telerik Reporting a un concepteur de rapports pour WPF et WinForms mais pas UWP.

DevExpress dispose également d'un concepteur de rapports pour WinForms et WPF, mais pas pour UWP

Veuillez donc vérifier vos faits avant de vous engager dans une erreur qui sera préservée à perpétuité et largement diffusée. Hé ça sonne comme si ça pourrait être un vieux proverbe un jour

OK, je pense que nous avons une compréhension différente du Reporting. Je veux dire https://www.telerik.com/universal-windows-platform-ui et https://www.devexpress.com/products/net/controls/win10apps/.

J'avais tort, Dev Express ne fournit pas de rapports pour UWP. Il semble qu'aucun développeur d'outils tiers ne le fasse ! J'ai contacté Dev express via leur chat, pour savoir s'ils avaient une feuille de route pour fournir des rapports pour UWP.
Ils ont dit,
"La suite XtraReports utilise les fonctionnalités fournies par l'assemblage System.Drawing et ce qui nous empêche d'implémenter le même ensemble d'outils pour les applications de fenêtre universelle, c'est que cet assemblage n'y est pas disponible (https://stackoverflow.com/questions /31545389/windows-universal-app-with-system-drawing-and-possible-alternative). Donc, nous n'avons pas encore établi nos plans futurs dans ce domaine."

@jevansaks , il semble qu'il y ait un manque de communication entre l'équipe Microsoft UI et ces fournisseurs d'outils tiers. Nous serions heureux d'utiliser des outils tiers, mais il semble que la plate-forme UWP rende difficile pour ces entreprises d'intégrer les outils dont elles disposent pour d'autres plates-formes dans UWP.

Ils m'ont demandé de contacter leur [email protected] avec nos exigences en matière de rapports, il peut être utile pour l'équipe Win UI 3.0 d'entrer en contact avec eux et de voir s'il s'agit d'un moyen de les aider dans la mise en œuvre. Je ne vois pas comment vous obtiendrez des développeurs commerciaux sur la plate-forme universelle sans outils de reporting appropriés.

https://www.devexpress.com/subscriptions/reporting/

Rapports : juste du point de vue de WinForms, j'ai utilisé à la fois Telerik et DevExpress (même leurs dernières versions), et même si Telerik était bon, je pense que DevExpress a non seulement un meilleur concepteur et une meilleure expérience, mais a des fonctionnalités beaucoup plus subtiles qui m'a permis de faire des mises en page plus complexes que Telerik. Je pense que la technologie de rendu DevExpress est plus avancée.

il peut être utile pour l'équipe Win UI 3.0 d'entrer en contact avec eux et de voir s'il s'agit d'un moyen de les aider dans la mise en œuvre.

Merci pour l'appel. Nous les contacterons également.

Merci pour l'appel. Nous les contacterons également.

Cela vaut peut-être la peine de parler avec chacun d'eux et de voir quels sont les blocages ? Telerik, Grapecity, DevExpress etc.

Merci pour l'appel. Nous les contacterons également.

Cela vaut peut-être la peine de parler avec chacun d'eux et de voir quels sont les blocages ? Telerik, Grapecity, DevExpress etc.

Bien sûr, c'est notre plan.

Nous sommes un peu différents de la plupart des développeurs qui créent pour Windows. Nous développons principalement des applications kiosque (applications destinées à être exécutées par des utilisateurs autres que le propriétaire de l'ordinateur, et généralement en plein écran sans aucun accès au système plus large). Les applications sont généralement conçues selon les exigences spécifiques du client, sans intention de les distribuer via le magasin ou l'équivalent.

Étant donné que les applications s'exécutent en plein écran, la valeur des commandes intégrées qui préserve l'apparence des autres applications Windows est très limitée ; au lieu de cela, ils ont tendance à être fortement marqués pour chaque client. Nous avons encore besoin de beaucoup de _comportements_ et de contrôles communs à partir d'applications Windows standard, mais nous personnalisons généralement beaucoup les modèles de contrôle de chacun ou au moins substituons leurs styles de base. Pendant très longtemps, nous avons construit de nombreuses applications en tant que backends WinForms avec des frontaux Flash intégrés pour l'interface utilisateur.

D'une manière générale, presque toutes les applications que nous écrivons intègrent une sorte de backend Web avec un certain matériel (par exemple, une imprimante, un scanner de codes-barres, un lecteur de bande magnétique, un scanner RFID, un appareil photo, du matériel de paiement par carte, un paiement en espèces de type distributeur automatique composants, etc.), et la grande majorité de ces composants sont historiquement fournis avec des SDK Win32 et non UWP.

Pour ces deux raisons, la plupart de nos applications historiques sont des applications WinForms et la plupart de nos applications modernes sont des applications WPF. Nous avons construit quelques applications UWP (en grande partie pour bénéficier des très belles capacités du mode Accès assigné/Kiosque de Windows), mais elles sont généralement difficiles à travailler par rapport à WPF, et nous ne pouvons généralement pas obtenir de SDK matériels compatibles de toute façon .

Nous sommes cependant très intrigués par les îles XAML, pour nous permettre d'écrire des applications compatibles Win32 avec une interface utilisateur moderne (bien que l'avantage d'UWP par rapport à WPF ne soit pas toujours clair, surtout si nous n'utilisons pas de contrôles standard ou spécifiques à Microsoft effets comme Fluent, etc.).

Pour répondre à vos questions spécifiques :

Quels modèles vous intéresseraient le plus ?

C# avec .NET Core, Win32 avec WinUI 3.0 superposé serait bien.

Connaissez-vous les îles Xaml pour la modernisation des applications de bureau ?

Oui, et j'étais relativement satisfait d'eux quand j'ai joué avec eux, bien que nous n'utilisions probablement pas un seul contrôle, autant que de prendre une décision pour l'ensemble de l'interface utilisateur personnalisée.

La principale raison pour laquelle j'étais au courant était que nous obtiendrions le support de Lottie pour les applications Win32.

Cette compatibilité ascendante étendue sur Windows 10 rend-elle les îles Xaml plus utiles pour vous ?

Pas vraiment; nous contrôlons presque toujours les PC cibles et pouvons nous assurer que nous obtenons toujours la dernière version compatible.

Cela aiderait-il si Visual Studio ou un autre outil mettait automatiquement à jour les espaces de noms pour vous ?

Oui.

Quelle importance accordez-vous à la compatibilité totale entre les composants UWP Xaml existants et les applications WinUI 3.0 ?

Très minime. Le principal casse-tête de compatibilité que nous aurions serait la modification des clés StaticResource pour le style des éléments de base.

Créez-vous ou utilisez-vous des bibliothèques de contrôle UWP Xaml ou des composants WinRT que vous ne pouvez pas facilement recompiler et mettre à jour avec le code de l'application ?

Oui, nous avons utilisé la bibliothèque de contrôle Syncfusion UWP dans le passé.

Quelle serait votre solution préférée pour utiliser les composants UWP Xaml avec WinUI 3 ?

La solution préférée serait d'avoir plus de contrôles standard disponibles dans WinUI lui-même plutôt que de s'appuyer sur des sources externes (par exemple, des visionneuses de documents), mais je m'attends à ce que ces bibliothèques de composants externes soient généralement plus progressives dans la mise à jour de leurs bibliothèques que nous ne le serions en passant à WinUI 3 de toute façon pour la plupart.

Que pensez-vous du plan global 3.0 décrit ci-dessus et dans la feuille de route ? Cela vous permettrait-il d'utiliser WinUI pour vos applications Windows nouvelles et existantes ?

Je suis ravi de voir les contrôles UWP être plus clairement découplés de l'application UWP et du modèle de sécurité qui nous a historiquement bloqués pour des raisons de compatibilité matérielle, d'autant plus que WinUI est conçu et développé à l'air libre.

Avec des conseils aussi clairs sur la façon dont Microsoft nous recommande de créer des interfaces utilisateur d'application, je m'attendrais à ce que toutes nos applications se retrouvent avec des frontaux WinUI, quel que soit le backend que nous pouvons prendre en charge.

Pour quel type d'applications seriez-vous le plus enthousiaste à l'idée d'utiliser WinUI 3.0 ? Créer une nouvelle application Win32 et l'emballer avec MSIX ? Ajouter de nouvelles vues à une application WPF ? Moderniser une application C++ MFC avec Fluent UI ?

Principalement pour accéder à des bibliothèques de contrôles plus activement maintenues dans mes anciennes applications, avec une documentation plus agréable et plus évidente (ou même un accès au code sous-jacent pour le contrôle standard) il est beaucoup plus facile de savoir quand je peux adapter un contrôle standard et quand j'ai besoin de lancer mon propre contrôle utilisateur. Par exemple, dans une application récente intégrée à WPF, j'avais quelques sélecteurs de date ; faire en sorte que ce contrôle fonctionne bien pour le toucher et personnaliser la taille, la police, l'icône contextuelle, etc. était extrêmement ennuyeux. Je serais enclin à utiliser WinUI pour ce type d'application par _default_ à l'avenir compte tenu de la feuille de route ci-dessus, car :

1. Je peux être raisonnablement assuré qu'il existe un contrôle natif du sélecteur de date qui est au moins modérément tactile
2. Je peux examiner facilement les modèles natifs/prêts à l'emploi de ce contrôle, etc., pour voir facilement ce que je dois remplacer pour qu'il corresponde aux preuves de conception pour l'apparence et la convivialité du client (comme exemple à peu près représentatif, je pourrais vouloir pour trouver le moyen le plus propre de styliser le type (taille de police, poids, famille) de l'en-tête d'un contrôle TextBox indépendamment de son texte d'entrée ; le HeaderTemplate standard utilise-t-il des ressources statiques magiques que je peux redéfinir ou dois-je remplacer le modèle lui-même ? Si je remplace le modèle, à quoi ressemble le balisage du modèle par défaut ; fait-il/prend-il en charge tout ce que je n'avais pas envisagé ?).

Je vois que cela a été fermé, mais il y a quelques problèmes qui sont soulevés par nos utilisateurs et qui, selon moi, vaudraient la peine d'être soulevés. Ce sont des améliorations de productivité pour les utilisateurs qui travaillent avec de grandes quantités de données.

Zone de texte:
Si un utilisateur doit modifier une zone de texte, il doit d'abord cliquer dans la zone de texte pour afficher le bouton Effacer, puis cliquer sur le bouton Effacer pour effacer la zone de texte. Ceci est très inefficace lorsque vous travaillez avec de grandes quantités de données. Ce serait bien si lorsque les utilisateurs cliquent ou onglets dans la zone de texte, le texte peut être mis en surbrillance prêt à être écrit.

Gridview/ListView :
Le Gridview et ListView ne semblent pas permettre à l'utilisateur de tabuler efficacement dans la collection.
Le ListView permet à Tab de se déplacer vers les contrôles de la même ligne, mais il ne permet pas de passer à la ligne de contrôles suivante. Au lieu de cela, ListView perd le focus et Tab passe au contrôle suivant dans l'arborescence visuelle.

Ce sont deux problèmes soulevés par nos utilisateurs comme très ennuyeux.

@Elmarcotoro

Je vous recommande de créer un nouveau problème pour chacune des améliorations que vous avez mentionnées. L'équipe WinUI effectuera ensuite un triage pour déterminer si elle nécessitera ou non la publication de WinUI 3 avant la mise en œuvre.

Ce problème existait principalement pour recueillir des commentaires concernant les 2 "Questions générales" en haut du message.

Prend en charge le modèle d'hébergement Blazor natif dans WinUI. Cela permettrait à un contrôle Blazor d'être utilisé directement dans le Web Client/Serveur, ou directement dans WinUI. La feuille de route Blazor a ce futur concept sans utiliser de contrôle WebView. De cette façon, l'interface utilisateur du contrôle s'exécute en natif avec la partie .Net Standard du code également en natif.

Prise en charge du modèle d'hébergement Blazor natif dans WinUI

Discuté du côté de Blazor, FWIW :
https://github.com/dotnet/aspnetcore/issues/11082

Bien sûr, c'est notre plan.

@jevansaks Ce serait bien d'entrer aussi dans la boucle.

J'aimerais une meilleure cohérence des menus de plateau / menus d'icônes avec WinUI 3.0. Chaque application a un espacement différent et les applications Win32 ne suivent pas le rendu / l'espacement / les thèmes des polices de manière cohérente. Veuillez déjà corriger cela !

WinUi dans le bureau complètement inutile pour moi en raison de l'absence de toute possibilité de gestion des fenêtres : afficher/masquer les fenêtres, position des fenêtres, taille des fenêtres, dock/undock...

@alexandrevk c'est encore un aperçu. Avez-vous vu la conception de l'API de fenêtrage ? https://github.com/microsoft/ProjectReunion/issues/157

Merci @dotMorten pour le lien vers le message d'annonce du fenêtrage !

@alexandrevk - nous mettons en place des API pour la Réunion qui vous permettront d'effectuer ce type d'opérations de fenêtrage à partir de Win32 et UWP avec du contenu WinUI ainsi que lors de l'utilisation d'autres frameworks/contenus de swapchain dans votre fenêtre. Certaines de ces fonctionnalités de fenêtrage peuvent ensuite être abstraites dans la classe de fenêtre WinUI pour un accès plus facile également, mais c'est plus loin sur la route. Les spécifications des fonctionnalités pour la zone de fenêtrage sont dans le tuyau, restez à l'écoute.

Parlant strictement en tant qu'utilisateur individuel (c'est-à-dire: non-entreprise/entreprise) et c++ uniquement, même si je ne suis qu'une voix solitaire criant dans le vide, je ressens le besoin de dire que tant que l'un de ces nouveaux systèmes d'interface utilisateur est lié à UWP et à cet horrible système d'emballage dans lequel ils sont intégrés, alors je crains que ce ne soit toujours dans le noir, quoi que vous fassiez. (Parlant de l'expérience WinRT, je n'ai pas encore essayé WinUI mais cela me semble à peu près la même chose).
Il faut sûrement savoir que peu ou personne n'utilise réellement les applications UWP ? (en fait détesté par la plupart des gens) donc si cela s'appelle "natif", alors pourquoi n'est-il pas vraiment "natif", c'est-à-dire: quelques #includes, liez un .lib ou deux et construisez votre application en STANDARD c++.
Devoir recourir à des choses comme Qt lorsque le cross-plat n'est pas un problème, juste pour éviter d'envelopper win32 pour la 1000e fois devient un peu vieux pour être juste.
Quoi qu'il en soit, juste mes 2 cents, de quelqu'un qui utilise la langue tous les jours, mais n'a probablement pas sa place pour commenter ici.

@nl-n, vous devriez être heureux de savoir que l'un des gros problèmes avec WinUI est qu'il ne nécessite pas de fonctionner en tant qu'application UWP. En fait, cela est possible depuis l'aperçu 2.
_Actuellement_ cela nécessite un emballage en tant que msix, mais msix est en fait un moyen assez décent de distribuer (et de mettre à jour) vos applications.

@dotMorten C'est l'un des gros problèmes: nécessiter un chargement/installation latérale via le magasin. Je ne connais pas une seule personne qui ne désactive/supprime pas le magasin avant (ou juste après) l'installation de Windows, alors comment sommes-nous censés les distribuer ?.
Je sais que c'est un peu rhétorique, mais cela sert le point. Je devrais juste pouvoir compresser le répertoire de construction et le distribuer (ou un installateur si nécessaire).
Ensuite, il y a le problème de compatibilité, beaucoup de gens refusent encore d'installer W10, donc il y a ça aussi...
Il est cependant bon d'entendre que c'est la direction que prend la 3.0, même si je déteste xaml, ce serait un ajout bienvenu.
Peut-être pourrions-nous l'obtenir sans avoir besoin d'installer toute la charge de travail UWP de 50 Go dans VS également ? (j'exagère je sais, mais quand même)

Pour citer @MarkIngramUK vers le début de ce fil :

Nous sommes en 2019, je veux une interface utilisateur native rapide et je ne veux pas avoir à envisager sérieusement de créer une interface utilisateur avec CreateWindowExW , GDI, etc.

ce que (assez curieusement) je dois littéralement faire en ce moment, et oui c'est aussi douloureux que ça en a l'air :)

@nl-n qui a parlé du magasin ? MSIX n'est pas vraiment différent de l'installation à partir de MSI. C'est juste un installateur d'application. Double-cliquez dessus pour l'installer. Aucun magasin nécessaire. Garantit également une désinstallation 100% propre (contrairement à MSI qui fait un gâchis géant)

je ne connais pas une seule personne qui ne désactive/supprime pas le magasin

Ce n'est pourtant pas courant.

comment est-on censé les distribuer

Tout d'abord, vous devez informer les utilisateurs de ne pas désactiver le magasin)

Je devrais juste pouvoir compresser le répertoire de construction et le distribuer

MSIX peut être installé sans magasin. Avec les dernières versions de Windows, l'utilisateur n'a pas besoin d'activer quoi que ce soit pour cela. Bien sûr, si le package a été signé auparavant avec un certificat de confiance. Mais oui, si l'utilisateur supprime le magasin du PC, il peut également en supprimer MSIX/APPX AppInstaller. Dans ce cas, ils ne veulent probablement pas de toute la variabilité des applications.

un grand nombre de personnes refusent encore d'installer W10,

C'est leur choix. dit Nuff.

toute la charge de travail UWP de 50 Go dans VS également

Un seul SDK fait environ 3 Go. Il n'est pas nécessaire de télécharger tout le monde à partir de 10240 un.

@nl-n qui a parlé du magasin ? MSIX n'est pas vraiment différent de l'installation à partir de MSI. C'est juste un installateur d'application. Double-cliquez dessus pour l'installer. Aucun magasin nécessaire. Garantit également une désinstallation 100% propre (contrairement à MSI qui fait un gâchis géant)

C'était à partir de la description que visual studio vous donne, "pour le chargement/l'installation via le magasin microsoft", la seule autre information que j'ai trouvée sur msix provient du msdn, qui dit essentiellement: les packages msix sont des applications "appx" en sandbox / virtualisées , ce qui est à peu près un tueur pour tout ce qui fonctionne directement avec le winapi. Et ils nécessitent une signature pour être même installables ?...

Cela pourrait aussi être simplement des fils croisés, je suppose, une terminologie trop différente, et je ne connais pas grand-chose à UWP.

Ce n'est pourtant pas courant.

Plus courant que vous ne le pensez, et avec raison 😄

Quoi qu'il en soit, ce n'était pas mon intention de faire dérailler, alors je vais recommencer à écrire mes trucs CreateWindowExW pour le moment 🤣