@jassmith ,

C'est une très bonne idée du point de vue de la normalisation XAML et fournira des fonctionnalités puissantes. Cependant, je serais prudent dans cette voie. Cela contribuera certainement à l'objectif global de déplacer Xamarin.Forms vers XAML Standard (https://github.com/Microsoft/xaml-standard). Mais, avec VisualStates, il y a de gros points d'interrogation quant à son utilité dans la réalité.

L'accélération graphique dans ces types de domaines doit être prise en considération. Le manque d'accélération graphique est déjà un problème dans certaines parties du système comme les animations. Je suppose que si Xamarin.Forms assume la responsabilité du rendu de l'imagerie vectorielle, il sera ensuite supprimé de la plate-forme sous-jacente - et déplacé du traitement GPU au traitement CPU. Ce sera un énorme coup de performance dans certains cas. Ce n'est pas que cela ne devrait pas être fait, mais il faut réfléchir à la question de savoir si le traitement peut ou non être laissé au niveau du GPU au lieu d'être déplacé vers le CPU. Les utilisateurs de la bibliothèque XF doivent être informés de ce qui s'exécutera sur la plate-forme native et de ce qui sera rendu par la bibliothèque XF.

Il y a aussi la question de l'équilibre entre le dessin natif et les différences de dessin multiplateforme. Le texte est un point important. Le texte doit-il être rendu de la même manière sur toutes les plateformes ? C'est-à-dire que le rendu des polices doit être transmis à XF pour créer une uniformité sur toutes les plates-formes ? Peut-être. Mais, je ne pense pas que cela devrait être le projet global pour XF. Les gens détectent inconsciemment de petits détails visuels. Les détails pourraient être dans une animation ou ainsi de suite. Même un petit écart par rapport à la norme sur une plate-forme donnée peut mettre l'utilisateur mal à l'aise. Donc, ce n'est pas nécessairement une bonne idée que tous les dessins soient rendus uniformes. Avalonia s'engage certainement dans cette voie, mais c'est un cas totalement distinct, et c'est un point de différence entre Avalonia et Xamarin Forms.

En outre, un autre commentaire est qu'il convient de veiller à ce que tous les types primitifs portent le même nom et soient alignés aussi étroitement que possible sur d'autres plates-formes telles que UWP et WPF afin d'être en ligne avec XAML Standard.

@davidortinau , avez-vous des idées à ce sujet ?

L'une des grandes caractéristiques de la conception des matériaux est le Ripple. Comptez-vous soutenir cela ?
Dans l'ensemble, je pense que c'est fantastique!

J'aime beaucoup cette orientation. Pour iOS, j'utilisais des cellules de vue natives en utilisant les éléments natifs (i, > options), mais plus j'applique un thème personnalisé, je me retrouve à imiter un peu les cellules natives et à aller plus loin pour un joli thème de travail qui est fluide et cohérent pour l'application mais pas natif en soi à part les détails. Je pense que si la bibliothèque de rendu sous-jacente appropriée est utilisée, le GPU ne sera pas un problème, lisez Skia. La même chose qui alimente Flutter.

C'est peut-être un problème distinct, mais ce serait bien de faire de SVG un citoyen de première classe de Forms en même temps. Activer des effets soignés tels que la teinte animée pour un bouton d'image lors de la pression par exemple.

Mon opinion est qu'en fin de compte, vous voulez des contrôles puissants, riches et natifs (pas natifs en soi !) Faciles à programmer avec un comportement cohérent entre plates-formes, à l'exception étrange de s'adapter à une bizarrerie native d'une plate-forme. Par exemple, un effet d'entraînement pour Android.

@ChaseFlorell en fait je le fais. L'idée étant que vous pouvez x:Nommer des éléments dans le modèle, puis les extraire à l'aide de FindByName. Une fois que vous avez l'élément natif, vous pouvez lui appliquer des animations comme n'importe quoi d'autre, mais il y aura probablement un moyen spécial d'obtenir un rappel d'animation. Je travaille toujours sur ces détails exacts. Avec Skia faisant du dessin, cela peut facilement atteindre 60FPS sur Android et même sans Skia, vous pouvez atteindre 60FPS sur les autres plates-formes.

@rogihee SVG n'est vraiment pas un format d'expédition désolé :/ Je ne veux pas être responsable d'essayer de rendre SVG de manière cohérente sur plusieurs plates-formes. Quand vont-ils ajouter des allusions aux SVG de toute façon...

@jassmith , est-ce que cela nous permettra d'accélérer les graphismes matériels ?

Venant du QML de Qt, j'adorerais voir ça. Combiné avec quelques contrôles intégrés évidents, peut couvrir beaucoup de terrain.

Peut-être un peu prématuré ou mérite-t-il un autre problème, mais quel est le plan d'histoire d'accessibilité/testabilité pour les contrôles construits à partir de cela ?

@RichiCoder1 a11y est certainement quelque chose qui devra être correctement élaboré. Idéalement, un élément Texte définirait automatiquement la plupart des propriétés requises pour les contrôles simples.

est-ce la fonctionnalité pour xf 4.0 ?

Série 3.0

@jassmith il n'y a rien à propos de draw et shell dans la feuille de route

AFAIK la feuille de route publique n'inclut rien qui n'ait pas été entièrement programmé

tous ces aperçus en 2018？@jassmith

@juepiezhongren nous ne nous sommes pas engagés à faire ces propositions. Ils sont présentés ici pour une discussion ouverte sur leurs mérites, leurs lacunes, etc.

Je déduis de votre intérêt que ces spécifications vous intéressent. Pourriez-vous partager des exemples spécifiques où vous les voyez vous aider lors de la création d'applications avec Xamarin.Forms ? Quels problèmes pensez-vous que cela résout ? Quelles opportunités les voyez-vous s'ouvrir pour vous ?

Tous les exemples et histoires du monde réel que vous pouvez partager seraient extrêmement utiles pour nous aider à valider que cela pourrait apporter une réelle valeur.

Comme toujours, n'importe qui peut se sentir libre de m'envoyer un e-mail s'il le souhaite. David. [email protected]

Le plus gros problème pour moi est la réponse "nous ne pouvons pas faire cela avec le framework Forms" que je dois donner aux clients potentiels et à l'UX/UI. Cela discrédite le cadre et je n'ai que peu d'occasions avec un client.

Les formes manquent d'un paradigme de composition où nous pr. project peut créer l'interface utilisateur à l'aide de primitives d'interface utilisateur. Cela s'applique à la navigation, aux animations (y compris des éléments tels que les animations de héros), aux éléments d'interface utilisateur et aux gestes.

Cette suggestion nous donnera-t-elle de telles primitives d'interface utilisateur de composition indépendantes de la plate-forme ?

@timahrentlov Nous devons discuter et voir exactement quelles sont ces limitations et la raison de ces limitations. Mais honnêtement, je n'ose même pas penser ou regarder aussi loin. Le problème que je vois avec Xamarin Forms est d'un point de vue beaucoup plus simple : il reste toujours un projet avec des ressources de développement très limitées. Il est irréaliste ou inutile de discuter de ce que cela pourrait être fait, alors qu'en fait il n'y a pas assez de puissance et de carburant. Je ne vois pas l'intérêt. Est-ce que Xamarin espère toujours secrètement que certaines personnes de la communauté OSS commenceront à travailler et à réparer les choses ? Ne vous méprenez pas, je respecte le temps et les efforts que Xamarin a consacrés à Xamarin Forms.

@davidortinau
Il est difficile de distinguer la plate-forme croisée de la conception visuelle caractéristique, de l'apparence unique des boutons, de l'effet de disparition unique de l'espace réservé, etc. pour éviter vraiment que nos applications soient identiques. Par exemple, la décoloration de l'avis de mac, avec une légère explosion, est très facile à impressionner ses clients. Pourquoi nous aimons beaucoup wpf ce jour-là, une des raisons que je mentionnerai, est le modèle de contrôle, où nous apprécions tellement les chemins pour notre unicité, comme le bouton hexagonal en coin. Nous voulons que xf les apporte aux développeurs de clients multiplateformes.

@juepiezhongren si vous recherchez ce type de personnalisation de l'interface utilisateur, je ne pense pas qu'il existe un framework multiplateforme capable de le faire. Et à propos de WPF : c'est une mauvaise idée de mélanger WPF avec mobile.

mon équipe utilise également React Native, où tant de jsers contribuent beaucoup, où après 3 mois, nous avons conclu que ce n'était pas productif du tout. Pour xf, c'est avec des inconvénients, avec des bugs, mais fondamentalement c'est une solution solide, eps x.native rend toutes les API natives valides. Ce qui manque, c'est seulement l'apparence d'ubi, pensant à la folie récente du flutter. De plus, avec shell, le flutter sera inutile, sans quelque chose comme flutter.ios, le flutter sera comme rn avec une souffrance illimitée api native.

@opcodewriter
nous utilisons skiasharp assez fréquemment, en faisant un contrôle spécial, ses performances sont satisfaisantes

@jassmith avez-vous envisagé de porter materialShell sur wasm en utilisant webgl, pour skia, c'est peut-être trop gros pour être téléchargé

correct, nous ne voulons pas prendre de décision sur les bibliothèques tierces pour l'API de dessin par défaut. \pourrait faire ça

avec xamarin.mono et shell dans wasm, tout produit alpha provoquera une renaissance de dotnet en chine, où la haine contre dotnet prévaut trop

@jassmith une bonne nouvelle à propos de ce problème ?

quelles nouvelles cherchez-vous @juepiezhongren? À ce stade, il s'agit d'une spécification publiée pour invoquer la discussion.

nous voulons voir quand draw et shell seront inclus dans la feuille de route@ChaseFlorell
le rendu universel est déjà valable pour l'avalonia et le flutter

Le calendrier à ce sujet dépendra de ma vitesse de développement personnel. Le but ici n'est pas de distraire toute l'équipe dans ces efforts et de ne m'épargner que cela. Vous pouvez suivre la branche shell si vous voulez la regarder se rassembler. Après Shell viendra le dessin.

En guise de remarque, j'ai l'intention de créer très rapidement une tranche verticale de dessin, puis de demander à la communauté de l'aider si elle souhaite le faire plus rapidement.

Tout cela est très joli, mais utilisera-t-il l'accélération graphique ?

@jassmith sur ios, system.draw à utiliser ; sur android, skiasharp à utiliser || skiasharp pour chaque chose?

@juepiezhongren il prendra en charge plusieurs backends, donc si vous voulez qu'il utilise Skia, il utilisera Skia, si vous voulez qu'il utilise l'API de dessin native, il l'utilisera à la place. Par défaut, il utilisera le backend natif et Skia sera opt-in afin que la dépendance ne vous soit pas imposée.

@jassmith c'est vraiment câblé que system.draw est disponible pour ios mais pas pour android

@juepiezhongren ajouter la prise en charge de System.Drawing n'est pas quelque chose qui relève de ma compétence ici. Cependant, rien n'utilisera System.Drawing avec cette spécification.

fondamentalement, le dessin entraînera beaucoup moins de rendus

Pas vraiment, les dessins devront être soutenus par quelque chose qui les rend. Sauf si vous voulez dire moins besoin de moteurs de rendu personnalisés, auquel cas oui, je suis d'accord.

Je suis dans le camp "faites-le aussi près que possible de wpf/uwp", ce qui, je le sais, n'est pas toujours la position la plus populaire ici.

MAIS, cela semble être un excellent compromis entre totalement sans apparence avec le framework faisant TOUT le rendu, et le paradigme XF actuel.

Je suppose que les primitives auront des homologues sur chaque plate-forme et que l'accélération matérielle ne sera donc pas un problème. Windows/iOS/Android/etc restituent toujours des rectangles, des cercles, des dégradés, etc., et utiliseront l'accélération matérielle dans la même mesure qu'ils le font déjà. Cela nous donnerait simplement aux concepteurs de contrôles la possibilité de concevoir nos contrôles à l'aide de primitives plutôt que d'être coincés avec l'idée d'Apple d'un bouton par rapport à celle de Microsoft.

Est-ce que je résume bien ?

@pmoorelegistek c'est fondamentalement l'idée oui. Et nous nous attaquons d'abord au matériau principalement parce qu'il n'a pas de flou comme élément de conception majeur. Cela signifie que nous pouvons réellement le faire fonctionner partout (en vous regardant Android).

quand j'ai fini Shell v1, je passe immédiatement à ceci

@jassmith C'est doré. Utilisez des contrôles natifs là où ils correspondent à la conception UX et ajoutez facilement des contrôles dessinés de type ski uniquement pour les éléments de conception (de préférence quelques-uns) qui en ont besoin.

Fini les discussions "impossible de faire ça dans Xamarin Forms" avec les concepteurs et les clients. Cela supprime les limitations de conception tout en préservant la véritable sensation native (contrairement au flottement).

J'aimerais voir cela avant la coque matérielle. Cela résout une réelle limitation de XF.
Shell est la nième fonctionnalité pour démarrer facilement/plus rapidement. Le _démarrage_ a été l'objectif pendant bien trop longtemps, mais des fonctionnalités comme celle-ci pour aller _plus loin_ _tiendront_ les développeurs XF à bord.

Cela doit se produire avant Material Shell car Material Shell en dépend. Je pense que vous vouliez dire que vous préféreriez voir ça avant Shell ?

Shell ne vise pas à démarrer plus rapidement/plus facilement. Son but est de moderniser les pages d'une manière que nous ne pouvons pas faire avec elles étant leurs propres contrôles. Il est essentiellement destiné à les remplacer complètement et nous encouragerons les gens à envisager le portage. Shell se concentre sur la fourniture d'une expérience beaucoup plus fluide et plus riche aux utilisateurs finaux, son animation peut être personnalisée, elle peut retarder/lazy charger les choses avant/après les animations afin qu'elles ne provoquent pas de hoquets. Il fournit une zone de contenu à 0 overdraw GPU dans Android, comparez cela aux pages actuelles où l'overdraw est juste dans la partie "rouge allez vous faire foutre" du graphique partout.

Shell ne vise pas à accélérer le démarrage des utilisateurs, mais à rendre votre application plus rapide. Avec Shell, vous pouvez, par exemple, marquer des pages/onglets/groupes comme "fréquents" et ils seront conservés par le système en supposant que l'utilisateur les visite constamment. Cela signifie qu'ils ne se rechargeront pas lorsque vous naviguez et revenez. Nous pouvons le faire car Shell possède toute la hiérarchie des pages.

Nous avons également quelques réflexions sur la façon d'optimiser les performances de dessin avec Shell qui, même si nous ne limiterons certainement jamais le dessin à Shell, rendraient potentiellement le dessin beaucoup plus efficace avec Shell car nous pourrons peut-être faire tout le dessin dans le même passage. Grain de sel requis ici car ce pic n'a pas encore été fait, mais il semble décent sur le papier.

@weitzhandler J'espère passer à cela dans les 4 à 6 prochaines semaines. Ce sera beaucoup plus rapide pour faire fonctionner ce shell. Aucune de ces époques n'est gravée dans le marbre.

+1

@jassmith https://github.com/nventive/Uno
c'est super.
le rendu uni est super

forms va être un explorateur radical, tandis qu'uno sera un conservateur
nous aimons les deux

+1 Grande fonctionnalité qui résoudra de nombreux problèmes d'interface utilisateur personnalisés que nous voulons voir dès que possible

@jassmith semble que le tirage doit être fait pour 3.3.0 ?

Une mise à jour pour ceci?

Pour nous, c'est la fonctionnalité la plus convaincante que nous espérons que Xamarin implémentera.

Nous développons principalement des applications LoB, et l'une de nos principales priorités est la vitesse de développement.
Nous nous soucions moins de l'apparence native tant qu'il existe une interface utilisateur convaincante qui fait un travail décent, s'affiche bien et prend moins de temps de développement.

Devoir tester et adapter chaque formulaire et chaque page séparément sur chaque plate-forme est un tueur en temps réel, nécessitant que toute modification mineure de l'interface utilisateur soit vérifiée trois fois sur toutes les plates-formes.

Shell & Material Shell est une bénédiction et une excellente nouvelle, veuillez faire avancer les choses ! C'est la seule chose qui incitera vos utilisateurs à aller ailleurs (Uno, Flutter et autres).

triste nouvelle que le dessin n'apparaîtrait pas pour 3.3

+1 pour cela, venant d'un arrière-plan uwp, je veux vraiment utiliser XF mais il a des inconvénients, actuellement j'essaie de flotter mais je viendrai sûrement à XF si cela est implémenté dès que possible.

Je conviens qu'il s'agit d'une fonctionnalité intéressante et qu'elle doit être implémentée. J'inclurai également un style pour les lignes, par exemple, une ligne continue, une ligne pointillée, etc.

Des nouvelles? Des plans? Feuille de route ?

Assez drôle, pas plus tard qu'hier soir, je me suis retrouvé à expérimenter des moteurs de rendu personnalisés et j'ai presque conclu que tout cela peut être fait en définissant simplement nos propres primitives comme des vues personnalisées et en les construisant. Vous n'avez pas besoin de beaucoup plus qu'une bordure, une ellipse et une ligne.
Je suis impatient de voir cela officiellement pris en charge, mais je n'attends pas. :)

@jassmith
Ainsi, Line et Rectangle par exemple, vont-ils être de vraies vues ? (parce que dans l'exemple, je vois qu'il y a un Grid avec Ellipse comme vue enfant). Volonté
Pourrai-je ajouter un TapGestureRecognizer à un Rectangle pour gérer l'événement tap ?
Puisqu'il s'agit de vues réelles, le fait d'avoir des vues réelles pour le dessin primitif ne va-t-il pas nuire à la vitesse de rendu ?

@andreinitescu Je crois que l'intention est qu'elles soient de vraies vues du côté Xamarin Forms, mais qu'elles ne soient jamais réalisées en tant que vues nativement:

_une primitive de dessin est simplement une vue qui n'a pas de moteur de rendu_

Ainsi, un moteur de rendu plus haut dans la chaîne ( Drawing ? DrawingTemplate ?) est chargé d'itérer à travers les descendants dessinables et de les dessiner.

Je suppose que cela signifie que le même type de restrictions qui s'appliquent aux mises en page avec CompressedLayout.IsHeadless défini s'appliquerait (pas de reconnaissance de gestes, pas d'effets, pas de transformations, etc.)

@GalaxiaGuy Je pense dans le même sens mais je trouve cela un peu déroutant, à cause du mélange avec de vraies vues comme Grid. Est-ce vraiment nécessaire ? Au lieu de dériver de View, pourquoi ne pas les avoir comme éléments de dessin abstraits (peut-être avoir une classe abstraite de base appelée DrawingElement avec des propriétés communes ?)

Bon travail juste échantillon correct

<Button x:Class="Local.MyButton">
  <Button.Template>
    <DrawingTemplate>
      <Drawing>
        <Grid>
          <RoundedRectangle Background="{x:Bind BackgroundColor}" />
          <Ellipse x:Name="TouchFeedback" Opacity="0" />
          <Text Content="{x:Bind Text}" />
        </Grid>
      </Drawing>
    </DrawingTemplate>
  </Button.Template> --> correct this line
</Button>

Ce sera peut-être en 4.0 ?

Drawing est bon car il implémente des contrôles à l'aide de primitives graphiques indépendantes de la plate-forme cible. Il y avait NControl, mais cela avait des problèmes (depuis les jours pré-netstandard2.0, pré-SkiaSharp), et n'est pas mis à jour.

La spécification 1. duplique la fonctionnalité déjà implémentée sous une forme beaucoup plus complète dans SkiaSharp, 2. ajoute des couches de complexité inutiles via XAML/Binding qui va à l'intérieur du référentiel Xamarin.Forms déjà non maintenable.

Une meilleure approche consiste à créer une petite bibliothèque de contrôles basée sur SkiaSharp. NControl++

@jassmith @rogihee SVG n'est vraiment pas un format d'expédition désolé :/ Je ne veux pas être responsable d'essayer de rendre SVG de manière cohérente sur plusieurs plates-formes.

SkiaSharp prend en charge SVG.

Des nouvelles à ce propos?

Des nouvelles à ce propos?

Je me demande également si cela est encore susceptible de se produire. Je suis vraiment dans le camp de vouloir un cadre d'interface utilisateur multiplateforme sans apparence et cela semble être le meilleur moyen d'y parvenir.

@legistek Vous pouvez utiliser SkiaSharp pour un dessin multiplateforme impeccable. Quels sont les avantages d'un Xamarin.Forms spécifique dans votre esprit ?

Il y a un peu plus dans un cadre d'interface utilisateur que le dessin.

Mais ce fil discute d'un cadre de dessin et non d'un cadre d'interface utilisateur ...

Je pensais qu'il s'agissait d'un framework de dessin _pour Xamarin Forms_.

SkiaSharp est un framework de dessin pour Xamarin Forms. Le fait qu'il fonctionne également sur d'autres plates-formes d'interface utilisateur .Net est certainement un avantage et non un inconvénient.

Et comme cela a été dit dans l'OP, SkiaSharp pourrait bien être le moteur de dessin sous-jacent sur les plates-formes individuelles, mais l'idée de cette proposition est d'ajouter une couche d'abstraction et de prendre en charge le dessin via XAML avec tous ses avantages, le plus notable étant la liaison de données. Ce que vous appelez une complexité inutile, je l'appelle élégant.

Est-ce toujours vivant et/ou sera-t-il intégré à MAUI ?

@legistek https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap répertorie les formes, les chemins et les pinceaux comme sur la feuille de route pour Xamarin.Forms 4.7.0.

Merveilleuse nouvelle ! Merci!