@jassmith ,

Esta es una muy buena idea desde el punto de vista de la estandarización de XAML y proporcionará una funcionalidad poderosa. Sin embargo, tendría cuidado al seguir este camino. Definitivamente contribuirá al objetivo general de mover Xamarin.Forms hacia el estándar XAML (https://github.com/Microsoft/xaml-standard). Pero, junto con VisualStates, hay grandes interrogantes sobre qué tan útil será esto en la realidad.

Se debe tener en cuenta la aceleración gráfica en este tipo de áreas. La falta de aceleración de gráficos ya es un problema en algunas partes del sistema, como las animaciones. Supongo que si Xamarin.Forms asume la responsabilidad de representar imágenes vectoriales, se eliminará posteriormente de la plataforma subyacente y se moverá del procesamiento de GPU al procesamiento de CPU. Este será un gran éxito de rendimiento en algunos casos. No es que no se deba hacer, pero se debe pensar si el procesamiento se puede dejar o no en el nivel de GPU en lugar de moverlo a la CPU. Los consumidores de la biblioteca XF deben saber qué se ejecutará en la plataforma nativa y qué renderizará la biblioteca XF.

También está la cuestión del equilibrio entre el dibujo nativo y las diferencias de dibujo multiplataforma. El texto es un punto importante. ¿Debe el texto mostrarse igual en todas las plataformas? Es decir, ¿debería transferirse la representación de fuentes a XF para crear uniformidad en todas las plataformas? Quizás. Pero no siento que ese deba ser el proyecto general para XF. Las personas detectan subconscientemente pequeños detalles visuales. Los detalles pueden estar en una animación o algo así. Incluso una pequeña desviación de la norma en una plataforma determinada puede hacer que el usuario se sienta incómodo. Por lo tanto, no es necesariamente una buena idea que todos los dibujos sean uniformes. Sin duda, Avalonia va por ese camino, pero ese es un caso totalmente diferente, y ese es un punto de diferencia entre Avalonia y Xamarin Forms.

Además, un comentario más es que se debe tener cuidado para asegurarse de que los tipos primitivos tengan el mismo nombre y estén lo más alineados posible con otras plataformas como UWP y WPF para estar en línea con el estándar XAML.

@davidortinau , ¿tienes alguna idea sobre esto?

Una de las grandes características en el diseño de materiales es Ripple. ¿Esperas apoyar esto?
En general, creo que esto es fantástico!

Me gusta mucho esta dirección. Para iOS, estaba usando celdas de vista nativas usando los elementos nativos (i, > opciones), pero cuanto más aplico temas personalizados, me encuentro imitando un poco las celdas nativas y busco más un tema atractivo/funcional que sea fluido y consistente para la aplicación pero no per se nativo aparte de los detalles. Creo que si se usa la biblioteca de renderizado subyacente adecuada, la GPU no será un problema, lea Skia. Lo mismo que alimenta a Flutter.

Tal vez sea un problema aparte, pero sería bueno hacer de SVG un ciudadano de primera clase de Formularios al mismo tiempo. Habilitación de efectos nítidos, como tintes animados para un botón de imagen al presionarlo, por ejemplo.

Mi opinión es que, al final, desea controles potentes, ricos y de aspecto nativo (¡no nativos per se!) Que sean fáciles de programar con un comportamiento coherente entre plataformas, con la extraña excepción de acomodar una peculiaridad nativa de una plataforma. Por ejemplo, un efecto dominó para Android.

@ChaseFlorell , de hecho, lo hago. La idea es que puede x: nombrar cosas en la plantilla y luego desenterrarlas usando FindByName. Una vez que tenga el elemento nativo, puede aplicarle animaciones como cualquier otra cosa, sin embargo, es probable que haya una forma especial de obtener una devolución de llamada de animación. Todavía estoy trabajando en esos detalles exactos. Con Skia dibujando, esto puede llegar fácilmente a 60FPS en Android e incluso sin Skia puedes alcanzar 60FPS en las otras plataformas.

@rogihee SVG realmente no es un formato de envío, lo siento :/ No quiero ser responsable de tratar de renderizar SVG consistentemente entre plataformas. De todos modos, ¿cuándo van a agregar sugerencias a los SVG?

@jassmith , ¿será esto nosotros aceleración de gráficos de hardware?

Viniendo de QML de Qt, me encantaría ver esto. Combinado con algunos controles integrados obvios, puede cubrir mucho terreno.

Tal vez un poco prematuro o valga la pena otro problema, pero ¿cuál es el plan de historia de accesibilidad/probabilidad para los controles construidos con esto?

@RichiCoder1 a11y es ciertamente algo que deberá resolverse adecuadamente. Idealmente, un elemento de texto establecería automáticamente la mayoría de las propiedades requeridas para controles simples.

¿Es esta la función para xf 4.0?

serie 3.0

@jassmith no hay nada sobre dibujar y shell en la hoja de ruta

AFAIK, la hoja de ruta pública no incluye nada que no se haya programado completamente

¿Todos estos avances en 2018? @jassmith

@juepiezhongren no nos hemos comprometido a hacer estas propuestas. Se presentan aquí para una discusión abierta sobre sus méritos, deficiencias, etc.

Deduzco de su interés que estas especificaciones son interesantes para usted. ¿Compartiría algunos ejemplos específicos de dónde los ve ayudándolo al crear aplicaciones con Xamarin.Forms? ¿Qué problemas ves que esto resuelve? ¿Qué oportunidades ves que se abren para ti?

Cualquier ejemplo e historia del mundo real que pueda compartir sería tremendamente útil para ayudarnos a validar que esto podría proporcionar un valor real.

Como siempre, cualquiera puede enviarme un correo electrónico si lo prefiere. David. [email protected]

El mayor problema para mí es la respuesta "no podemos hacer eso con el marco de Forms" que tengo que dar a los clientes potenciales y UX/UI. Desacredita el marco y solo tengo tantas oportunidades con un cliente.

Las formas carecen de un paradigma compositivo donde pr. El proyecto puede construir la interfaz de usuario utilizando primitivas de interfaz de usuario. Esto se aplica a la navegación, las animaciones (incluidas cosas como animaciones de héroes), los elementos de la interfaz de usuario y los gestos.

¿Esta sugerencia nos dará tales primitivas de interfaz de usuario compositivas independientes de la plataforma?

@timahrentlov Necesitamos ver discutir y ver exactamente cuáles son esas limitaciones y el motivo de esas limitaciones. Pero, sinceramente, ni siquiera me atrevo a pensar o mirar tan lejos. El problema que veo con Xamarin Forms es desde una perspectiva mucho más simple: sigue siendo un proyecto con recursos de desarrollo muy limitados. Es poco realista o inútil discutir lo que se podría hacer, cuando en realidad no hay suficiente energía y combustible. No veo el punto. ¿Quizás Xamarin sigue esperando en secreto que algunas personas de la comunidad OSS comiencen a trabajar y a arreglar las cosas? No me malinterpreten, respeto el tiempo y el esfuerzo que Xamarin ha puesto en Xamarin Forms.

@davidortinau
La plataforma cruzada es difícil de distinguir el diseño visual característico, la apariencia única del botón, el efecto de desaparición del marcador de posición único, etc. Realmente evita que nuestras aplicaciones sean idénticas. Por ejemplo, el desvanecimiento del aviso de mac, con una ligera explosión, es realmente fácil de impresionar a sus clientes. Por qué nos encanta wpf ese día, una de las razones que mencionaré es la plantilla de control, donde disfrutamos tanto de las rutas por nuestra singularidad, como un botón hexagonal acorralado. Queremos que xf los lleve a los desarrolladores de clientes multiplataforma.

@juepiezhongren si está buscando ese tipo de personalización de la interfaz de usuario, no creo que haya ningún marco multiplataforma que pueda hacer eso. Y sobre WPF: es una mala idea mezclar WPF con dispositivos móviles.

mi equipo también usa react native, donde tantos jsers contribuyen mucho, donde después de 3 meses llegamos a la conclusión de que no es productivo en absoluto. Para xf, tiene inconvenientes, errores, pero básicamente es una solución sólida, eps x.native hace que todas las api nativas sean válidas. Lo que falta es sólo la apariencia de ubi, considerando la reciente estupidez de flutter. Además, con shell, flutter será inútil, sin algo como flutter.ios, flutter será como rn con api nativo sufrimiento ilimitado.

@opcodewriter
usamos skiasharp con bastante frecuencia, haciendo un control especial, su rendimiento es satisfactorio

@jassmith , ¿has considerado portar materialShell a wasm usando webgl, para skia, tal vez sea demasiado grande para descargarlo?

correcto, no queremos tomar una decisión dura sobre las bibliotecas de terceros para la API de dibujo predeterminada. \podría hacer eso

con xamarin.mono y shell en wasm, cualquier producto alfa provocará un renacimiento de dotnet en china, donde prevalece demasiado el odio contra dotnet

@jassmith ¿ alguna buena noticia sobre este tema?

que noticia buscas @juepiezhongren? En este punto, es una especificación publicada para invocar la discusión.

queremos ver cuándo se incluirán draw y shell en la hoja de ruta@ChaseFlorell
la representación universal ya es válida para avalonia y flutter

La línea de tiempo en esto va a depender de mi velocidad de desarrollo personal. El objetivo aquí no es distraer a todo el equipo en estos esfuerzos y solo ahorrarme a mí. Puede rastrear la rama de la concha si quiere ver cómo se une. Después de Shell vendrá el dibujo.

Como nota, tengo la intención de levantar un corte vertical de dibujo muy rápidamente y luego pedir ayuda a la comunidad si quieren hacerlo más rápido.

Todo esto está muy bien, pero ¿utilizará la aceleración de gráficos?

@jassmith en ios, se utilizará system.draw; en android, se usará skiasharp || ¿skiasharp para cada cosa?

@juepiezhongren admitirá múltiples backends, por lo que si desea que use Skia, usará Skia, si desea que use la API de dibujo nativa, la usará en su lugar. De forma predeterminada, utilizará el backend nativo y Skia se habilitará para que no se le imponga la dependencia.

@jassmith , realmente está conectado que system.draw está disponible para iOS pero no para Android

@juepiezhongren agregar soporte para System.Drawing no es algo que esté dentro de mi ámbito aquí. Sin embargo, nada usará System.Drawing con esta especificación.

básicamente, dibujar causará muchos menos renderizados

No realmente, los dibujos tendrán que estar respaldados por algo que los represente. A menos que se refiera a una menor necesidad de renderizadores personalizados, en cuyo caso sí, estoy de acuerdo.

Estoy en el campo "hazlo lo más cerca posible de wpf/uwp", que sé que no siempre es la posición más popular por aquí.

PERO, esto parece un gran compromiso entre totalmente sin apariencia con el marco haciendo TODO el renderizado y el paradigma XF actual.

Supongo que los primitivos tendrán contrapartes en cada plataforma y, por lo tanto, la aceleración de hardware no sería un problema. Windows/iOS/Android/etc todavía representan rectángulos, círculos, degradados y similares, y utilizarán la aceleración de hardware en la misma medida en que ya lo hacen. Esto simplemente nos daría a los diseñadores de controles la capacidad de diseñar nuestros controles usando primitivas en lugar de quedarnos atrapados con la idea de un botón de Apple frente a la de Microsoft.

¿Lo resumo correctamente?

@pmoorelegistek esa es básicamente la idea, sí. Y estamos abordando Material primero principalmente porque no tiene Blur detrás como un elemento de diseño importante. Esto significa que podemos hacer que funcione en todas partes (mirando tu Android).

cuando termine Shell v1, me pasaré inmediatamente a este

@jassmith Esto es dorado. Use controles nativos donde se ajusten al diseño de UX y agregue fácilmente controles dibujados tipo skia solo para los (preferiblemente pocos) elementos de diseño que lo necesiten.

No más charlas de "no puedo hacer eso en Xamarin Forms" con diseñadores y clientes. Esto elimina las limitaciones de diseño y conserva la verdadera sensación nativa (a diferencia del aleteo).

Me encantaría ver esto antes de material shell. Esto resuelve una limitación real de XF.
Shell es la enésima característica para comenzar fácil y rápido. Comenzar_ ha sido el enfoque durante demasiado tiempo, pero características como esta para avanzar más _mantendrán_ a los desarrolladores de XF a bordo.

Esto tiene que suceder antes de Material Shell porque Material Shell depende de esto. Creo que quisiste decir que preferirías ver esto antes que Shell.

Shell no se enfoca en comenzar más rápido o más fácil. Está destinado a modernizar las páginas de una manera que no podemos hacer con ellas siendo sus propios controles. Básicamente, tiene la intención de reemplazarlos por completo y animaremos a las personas a considerar la portabilidad. Shell se enfoca en proporcionar una experiencia mucho más fluida y rica a los usuarios finales, su animación se puede personalizar, puede retrasar/cargar perezosamente las cosas antes/después de las animaciones para que no tengan contratiempos. Proporciona un área de contenido de sobregiro de 0 GPU en Android, compare esto con las páginas actuales donde el sobregiro está solo en la parte "roja vete a la mierda" del gráfico en todas partes.

Shell no se trata de hacer que las personas comiencen más rápido, se trata de hacer que su aplicación sea más rápida. Con Shell puede, por ejemplo, marcar páginas/pestañas/grupos como "frecuentes" y el sistema los retendrá bajo el supuesto de que el usuario los visita constantemente. Esto significa que no se recargarán cuando navegue y regrese. Podemos hacerlo porque Shell posee toda la jerarquía de páginas.

También tenemos algunas ideas sobre cómo optimizar el rendimiento del dibujo con Shell que, si bien nunca limitaremos el dibujo a Shell, potencialmente haría que el dibujo fuera mucho más eficiente con Shell, ya que podemos hacer todos los dibujos en el mismo paso. Se requiere un grano de sal aquí ya que este pico aún no se ha hecho, pero se ve decente en el papel.

@weitzhandler Espero pasar a esto en las próximas 4 a 6 semanas. Esto será mucho más rápido para empezar a trabajar ese caparazón. Ninguno de esos tiempos está escrito en piedra.

+1

@jassmith https://github.com/nventive/Uno
eso es genial
Uni-rendering es genial

Forms va a ser un explorador radical, mientras que uno va a ser conservador.
amamos a los dos

+1 Gran característica que resolverá muchos problemas de interfaz de usuario personalizados que queremos ver lo antes posible

@jassmith parece que el sorteo se hará para 3.3.0？

¿Algún avance en esto?

Para nosotros, esta es la característica más convincente que esperamos que implemente Xamarin.

Desarrollamos principalmente aplicaciones LoB, y una de nuestras principales prioridades es la velocidad de desarrollo.
Nos importa menos la apariencia nativa, siempre que haya una interfaz de usuario convincente que haga un trabajo decente, se muestre bien y requiera menos tiempo de desarrollo.

Tener que probar y adaptar cada formulario y página por separado en cada plataforma, es un asesino en tiempo real, que requiere que cualquier cambio menor en la interfaz de usuario se verifique tres veces en todas las plataformas de un lado a otro.

Shell & Material Shell es una bendición y una gran noticia, ¡siga adelante! Esto es lo único que mantendrá a sus usuarios yendo a otro lado (Uno, Flutter y otros).

triste noticia que no saldria draw para la 3.3

+1 por esto, viniendo de un fondo uwp, realmente quiero usar XF pero tiene sus inconvenientes, actualmente estoy probando flutter pero seguramente vendré a XF si esto se implementa lo antes posible.

Estoy de acuerdo en que esta es una gran característica y debe implementarse. También incluiré estilo para líneas, por ejemplo, línea sólida, línea punteada, etc.

¿Hay noticias? ¿Planes? ¿Mapa vial?

Curiosamente, anoche me encontré experimentando con renderizadores personalizados y casi llegué a la conclusión de que todo esto se puede hacer simplemente definiendo nuestras propias primitivas como vistas personalizadas y construyendo a partir de ellas. No necesita mucho más que un borde, una elipse y una línea.
Estoy ansioso por ver que esto se admita oficialmente, pero no estoy esperando. :)

@jassmith
Entonces Line y Rectangle , por ejemplo, ¿serán vistas reales? (porque en el ejemplo veo que hay Grid con Ellipse como vista secundaria). Voluntad
¿Podré adjuntar un TapGestureRecognizer a un Rectangle para manejar el evento de toque?
Dado que estas son vistas reales, ¿tener vistas reales para dibujar primitivos no va a ser perjudicial para la velocidad de renderizado?

@andreinitescu , creo que la intención es que sean vistas reales en el lado de Xamarin Forms, pero que nunca se realicen como vistas de forma nativa:

_una primitiva de dibujo es simplemente una vista que no tiene renderizador_

Entonces, un renderizador más arriba en la cadena ( Drawing ? DrawingTemplate ?) es responsable de iterar a través de los descendientes dibujables y dibujarlos.

Supongo que esto significa que se aplicarían el mismo tipo de restricciones que se aplican a los diseños con CompressedLayout.IsHeadless establecidos (sin reconocedores de gestos, sin efectos, sin transformaciones, etc.)

@GalaxiaGuy Estoy pensando de la misma manera, pero lo encuentro un poco confuso debido a la mezcla con vistas reales como Grid. ¿Es realmente necesario? En lugar de derivar de View, ¿por qué no tenerlos como elementos de dibujo abstractos (tal vez tener una clase abstracta base llamada DrawingElement con propiedades comunes?)

Buen trabajo solo muestra correcta

<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>

Tal vez será en 4.0?

Drawing es bueno porque implementa controles utilizando primitivas de gráficos independientes de la plataforma de destino. Solía ​​haber NControl, pero tenía problemas (desde los días anteriores a netstandard2.0, anteriores a SkiaSharp) y no está actualizado.

La especificación 1. duplica la funcionalidad ya implementada en una forma mucho más completa en SkiaSharp, 2. agrega capas innecesarias de complejidad a través de XAML/Binding que va dentro del repositorio Xamarin.Forms que ya no se puede mantener.

Un mejor enfoque es crear una pequeña biblioteca de control basada en SkiaSharp. NControl++

@jassmith @rogihee SVG realmente no es un formato de envío, lo siento :/ No quiero ser responsable de intentar renderizar SVG consistentemente entre plataformas.

SkiaSharp tiene soporte SVG.

¿Alguna noticia sobre esto?

¿Alguna noticia sobre esto?

También me pregunto si esto todavía es probable que suceda. Estoy muy interesado en querer un marco de interfaz de usuario multiplataforma sin apariencia y esta parece ser la mejor manera de lograrlo.

@legistek Puede usar SkiaSharp para dibujar sin apariencia en varias plataformas. ¿Cuáles son las ventajas de uno específico de Xamarin.Forms en su mente?

Hay un poco más en un marco de interfaz de usuario que dibujar.

Pero este hilo está discutiendo un marco de dibujo, no un marco de interfaz de usuario ...

Pensé que estaba discutiendo un marco de dibujo _para Xamarin Forms_.

SkiaSharp es un marco de dibujo para Xamarin Forms. El hecho de que también funcione en otras plataformas .Net UI es sin duda una ventaja, no una desventaja.

Y como se dijo en el OP, SkiaSharp bien podría ser el motor de dibujo subyacente en las plataformas individuales, pero la idea de esta propuesta es agregar una capa de abstracción y admitir el dibujo a través de XAML con todos sus beneficios, el más notable es el enlace de datos. Lo que tú llamas complejidad innecesaria, yo lo llamo elegante.

¿Sigue vivo y / o se incluirá en MAUI?

@legistek https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap enumera formas, rutas y pinceles como en la hoja de ruta para Xamarin.Forms 4.7.0.

¡Noticias maravillosas! ¡Gracias!