<p>Especificações de desenho do Xamarin.Forms</p>

Criado em 13 abr. 2018 · 69Comentários · Fonte: xamarin/Xamarin.Forms

Especificações de desenho do Xamarin.Forms

Tema

Para fazer o MaterialShell funcionar, ele não precisa apenas de um shell que pareça ser design de material, mas todo o seu conteúdo também deve ser design de material. Hoje isso significa renderizadores personalizados. Isso é pesado e indesejado do ponto de vista do trabalho do usuário. Em vez disso, é necessária uma abordagem melhor.

Exemplo de API de desenho simples

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

Os modelos de visualização, pelo menos por enquanto, devem ser DrawingTemplate . O primeiro filho de um DrawingTemplate é sempre um Drawing . Dentro de um Drawing você pode usar Layouts e primitivas de desenho.

As primitivas de desenho podem ser x:named e procuradas por nome e manipuladas no code behind como qualquer outro View . Na verdade, uma primitiva de desenho é simplesmente uma vista que não tem renderizador, mas deve estar dentro de um Drawing para funcionar. Drawing é limitado a crianças que ele pode suportar, pois todos são recolhidos em comandos de desenho simples.

Desenhar objetos primitivos pode usar um tipo Brush em vez de um tipo Color para fornecer cores/planos de fundo/etc.

Ao usar um MaterialShell, todos os controles relevantes receberão um Template padrão que os temas de acordo com as diretrizes de design do Material e unifica sua aparência em toda a plataforma. Este tema pode ser substituído em qualquer camada da hierarquia simplesmente bloqueando sua propagação em dicionários de recursos.

Uma vez realizado, um controle pode não ter seu modelo alterado, pois os controles DrawingTemplated podem, às vezes, exigir renderizadores diferentes.

Tipos

Modelo de desenho

Este é principalmente um tipo de marcador. No futuro, eliminaremos a exigência de que os Templates sejam DrawingTemplates.

public class DrawingTemplate : ControlTemplate {}

Desenho

Uma vista que não tem renderizador e, em vez disso, é consumida por sua vista pai como um desenho nativo. O desenho é um layout muito básico que pode ser medido, mas sempre dimensiona todos os seus filhos para o mesmo tamanho que ele mesmo quando disposto.

public class Drawing : Layout<View> {}

Nova API para desenhar à vista

public class View : VisualElement // new API only
{
  public ControlTemplate Template { get; set; }

  protected BindableObject GetTemplateChild(string childName);

  protected virtual void OnApplyTemplate ();
}

Escovar

public class Brush : BindableObject
{
  public static readonly BindableProperty OpacityProperty;
  public double Opacity { get; set; }
}

SolidColor Brush

public class SolidColorBrush : Brush
{
  public static readonly BindableProperty ColorProperty;
  public Color Color { get; set; }
}

GradientBrush

public class LinearGradientBrush : Brush
{
  public static readonly BindableProperty GradientStopsProperty;
  [Content]
  public GradientStopCollection GradientStops { get; set; }
}

GradientStopCollection

public sealed class GradientStopCollection : IEnumerable<GradientStop>, IList<GradientStop>

GradientStop

public sealed class GradientStop : BindableObject
{
  public static readonly BindableProperty ColorProperty;
  public Color Color { get; set; }

  public static readonly BindableProperty OffsetProperty;
  public double Offset { get; set; }

  public static readonly BindableProperty StartPointProperty;
  public Point StartPoint { get; set; }

  public static readonly BindableProperty EndPointProperty;
  public Point EndPoint { get; set; }
}

Desenhar Primitivos

Haverá a necessidade de um grande número de primitivas de desenho com propriedades associadas. Este documento não tenta definir todos eles, apenas observe alguns dos óbvios que precisarão existir. A API primitiva de desenho não se destina a substituir o SkiaSharp por atacado. No entanto, destina-se a ser agnóstico ao uso do Skia ou backends de desenho nativo para o paltform.

Um bom caminho para o Skia seria adicionar um elemento SkiaDrawing que instruiria o desenho a ser renderizado via Skia. O Skia pode então renderizar todas as primitivas de estoque, bem como fornecer um elemento de desenho Skia que permite o desenho codificado.

Forma

namespace Xamarin.Forms.Shapes 
{
  public class Shape : View
  {
    public static readonly BindableProperty FillProperty;
    public Brush Fill { get; set; }

    public static readonly BindableProperty StrokeProperty;
    public Brush Stroke { get; set; }

    public static readonly BindableProperty StrokeThicknessProperty;
    public double StrokeThickness { get; set; }
  }
}

Linha

namespace Xamarin.Forms.Shapes 
{
  public sealed class Line : Shape
  {
    public Point Start { get; set; }
    public Point End { get; set; }
  }
}

Elipse

namespace Xamarin.Forms.Shapes 
{
  public sealed class Ellipse : Shape
  {
  }
}

Texto

public sealed class Text : Shape 
{
  // All the same properties as Label more or less
}

Retângulo

namespace Xamarin.Forms.Shapes 
{
  public sealed class Rectangle : Shape
  {
    public CornerRadius CornerRadius { get; set; }
  }
}

Linha Bézier

Isso difere um pouco da UWP, no entanto, é capaz de desenhar um caminho/forma curva de Bezier, bem como polígonos e polilinhas regulares.

namespace Xamarin.Forms.Shapes 
{
  public sealed class BezierLine : Shape
  {
    public IList<BezierPoint> Points { get; }
    public bool ShouldClose { get; set; }
  }
}

BezierPoint

namespace Xamarin.Forms.Shapes 
{
  public sealed class BezierPoint : Point
  {
    public Size LeftControlOffset { get; set; }
    public Size RightControlOffset { get; set; }
  }
}

FAÇAM

[x] Adicionar API para desenho
[x] Preencha a API do pincel

Problemas

Formas

Não há correntes uma ótima maneira de desenhar apenas um arco. O mecanismo em UWP para fazer isso é um pouco... uhg, não é divertido.

Há também algo a ser dito pelo fato de que as Formas são atualmente Views. Isso é para garantir que eles possam ser consumidos por Layout's padrão, o que é bom porque o usuário não precisa aprender novos mecanismos de layout. A desvantagem é que as primitivas de desenho só funcionam no contexto de um desenho, mas o compilador não o impedirá de usá-las externamente a um. O contra caso é fazer layouts específicos de desenho que atualmente parecem ser o mal maior.

Idealmente, o Layout permitiria qualquer filho que implementasse alguma interface ILayoutable, da qual View and e Drawing Primitives implementariam. No entanto, isso seria uma mudança de ruptura, portanto, no momento, parece que a Visualização é a única opção viável.

Escovar

O ImageBrush provavelmente será necessário. A pesquisa precisa ser feita para garantir que todas as plataformas possam suportar o ImageBrush em todos os lugares em que os pincéis são usados.

Modelo de desenho

Atualmente, não existe nenhum mecanismo no núcleo para alternar o renderizador com base em uma propriedade, pois isso exigirá. Isso precisará ser adicionado. Idealmente, isso deve ser mais genérico do que um switch baseado no modelo.

brushes shapes in-progress high impact enhancement ➕

Fonte

jassmith

👍28 ❤18 🎉9 👎1

Comentários muito úteis

Isso tem que acontecer antes do Material Shell porque o Material Shell depende disso. Acho que você quis dizer que prefere ver isso antes da Shell?

A Shell não está focada em começar mais rápido/fácil. Seu objetivo é modernizar as Páginas de maneiras que não podemos fazer com elas sendo seus próprios controles. É basicamente destinado a substituí-los por completo e encorajaremos as pessoas a considerar a portabilidade. O Shell está focado em fornecer uma experiência muito mais suave e rica para os usuários finais, sua animação pode ser personalizada, pode atrasar/carregar coisas antes/depois das animações para que não causem soluços. Ele fornece uma área de conteúdo de overdraw de 0 GPU no Android, compare isso com as páginas atuais em que o overdraw está apenas na parte "vermelho, vá se foder" do gráfico em todos os lugares.

Shell não é sobre fazer as pessoas começarem mais rápido, é sobre tornar seu aplicativo mais rápido. Com o Shell você pode, por exemplo, marcar páginas/guias/grupos como "frequentes" e eles serão retidos pelo sistema sob a suposição de que o usuário os visite constantemente. Isso significa que eles não serão recarregados quando você sair e voltar. Podemos fazer isso porque a Shell possui toda a hierarquia de páginas.

Também temos alguns pensamentos sobre como otimizar o desempenho do desenho com o Shell que, embora certamente nunca limitaremos o desenho ao Shell, potencialmente tornaria o desenho muito mais eficiente com o shell, pois podemos fazer todos os desenhos na mesma passagem. Grão de sal necessário aqui, pois este pico ainda não foi feito, mas parece decente no papel.

jassmith em 18 mai. 2018

👍8 ❤1

Todos 69 comentários

@jassmith ,

Esta é uma idéia muito boa do ponto de vista da padronização XAML e fornecerá uma funcionalidade poderosa. No entanto, eu tomaria cuidado ao seguir esse caminho. Ele definitivamente contribuirá para o objetivo geral de mover o Xamarin.Forms para o XAML Standard (https://github.com/Microsoft/xaml-standard). Mas, junto com o VisualStates, há grandes pontos de interrogação sobre o quão útil isso será na realidade.

A aceleração gráfica nestes tipos de áreas deve ser levada em consideração. A falta de aceleração gráfica já é um problema em algumas partes do sistema como animações. Meu palpite é que, se o Xamarin.Forms assumir a responsabilidade de renderizar imagens vetoriais, ele será posteriormente removido da plataforma subjacente - e movido do processamento da GPU para o processamento da CPU. Este será um enorme sucesso de desempenho em alguns casos. Não é que isso não deva ser feito, mas deve-se pensar se o processamento pode ou não ser deixado no nível da GPU em vez de ser movido para a CPU. Os consumidores da biblioteca XF precisam estar cientes do que será executado na plataforma nativa e do que será renderizado pela biblioteca XF.

Há também a questão do equilíbrio entre o desenho nativo e as diferenças de desenho entre plataformas. O texto é um ponto importante. O texto deve ser renderizado da mesma forma em todas as plataformas? Ou seja, a renderização da fonte deve ser passada para o XF para criar uniformidade em todas as plataformas? Talvez. Mas, eu não sinto que isso deveria ser o projeto geral para o XF. As pessoas detectam subconscientemente pequenos detalhes visuais. Os detalhes podem estar em uma animação ou assim por diante. Mesmo um pequeno desvio da norma em uma determinada plataforma pode deixar o usuário desconfortável. Portanto, não é necessariamente uma boa ideia que todos os desenhos sejam uniformes. O Avalonia certamente está seguindo esse caminho, mas esse é um caso totalmente separado, e esse é um ponto de diferença entre o Avalonia e o Xamarin Forms.

Além disso, mais um comentário é que deve-se tomar cuidado para garantir que todos os tipos primitivos tenham o mesmo nome e estejam alinhados o mais próximo possível de outras plataformas, como UWP e WPF, para estarem alinhados com o XAML Standard.

@davidortinau , você tem pensamentos sobre isso?

MelbourneDeveloper em 13 abr. 2018

👍2

Uma das grandes características do design de materiais é o Ripple. Você espera apoiar isso?
No geral, acho isso fantástico!

ChaseFlorell em 13 abr. 2018

Eu gosto muito dessa direção. Para iOS, eu estava usando células de exibição nativas usando os elementos nativos (i, > opções), mas quanto mais eu aplico temas personalizados, me vejo apenas imitando um pouco as células nativas e indo mais para um tema bonito/funcional que é fluente e consistente para o aplicativo, mas não nativo per se, além dos detalhes. Eu acho que se a biblioteca de renderização subjacente apropriada for usada, a GPU não será um problema, leia Skia. A mesma coisa que alimenta o Flutter.

Talvez seja um problema separado, mas seria bom fazer do SVG um cidadão de primeira classe do Forms ao mesmo tempo. Ativando efeitos elegantes, como tingimento animado para um botão de imagem ao pressionar, por exemplo.

Minha opinião é que, no final, você quer controles poderosos, ricos e de aparência nativa (não nativos per se!) que sejam fáceis de programar com comportamento consistente em plataforma cruzada, com a estranha exceção de acomodar uma peculiaridade nativa de uma plataforma. Por exemplo, um efeito cascata para Android.

rogihee em 13 abr. 2018

@ChaseFlorell na verdade eu faço. A ideia é que você pode x:Name coisas no modelo e, em seguida, desenterrá-los usando FindByName. Depois de ter o elemento nativo, você pode aplicar animações a ele como qualquer outra coisa, no entanto, provavelmente haverá uma maneira especial de obter um retorno de chamada de animação. Ainda estou trabalhando nesses detalhes exatos. Com Skia fazendo para desenhar isso pode facilmente atingir 60FPS no Android e mesmo sem Skia você pode atingir 60FPS nas outras plataformas.

@rogihee SVG realmente não é um formato de envio desculpe :/ Eu não quero ser responsável por tentar renderizar SVG consistentemente entre plataformas. Quando eles vão adicionar dicas aos SVGs de qualquer maneira ...

jassmith em 14 abr. 2018

👍1

@jassmith , isso será aceleração gráfica de hardware?

MelbourneDeveloper em 16 abr. 2018

Vindo do QML do Qt, adoraria ver isso. Combinado com alguns controles embutidos óbvios, pode converter muito terreno.

Talvez um pouco prematuro ou valha a pena outro problema, mas qual é o plano de história de acessibilidade/testabilidade para controles construídos com isso?

RichiCoder1 em 16 abr. 2018

@RichiCoder1 a11y é certamente algo que precisará ser devidamente trabalhado. Idealmente, um elemento Text definiria automaticamente a maioria das propriedades necessárias para controles simples.

jassmith em 17 abr. 2018

este é o recurso para xf 4.0?

juepiezhongren em 18 abr. 2018

série 3.0

jassmith em 19 abr. 2018

🎉1

@jassmith não há nada sobre desenhar e shell no roteiro

juepiezhongren em 22 abr. 2018

AFAIK o roteiro público não inclui nada que não tenha sido totalmente agendado

jassmith em 22 abr. 2018

todos esses previews em 2018？@jassmith

juepiezhongren em 24 abr. 2018

@juepiezhongren não nos comprometemos a fazer essas propostas. Eles são apresentados aqui para discussão aberta sobre seus méritos, deficiências, etc.

Deduzo do seu interesse que essas especificações são interessantes para você. Você compartilharia alguns exemplos específicos de onde você os vê ajudando na criação de aplicativos com o Xamarin.Forms? Que problemas você vê isso resolvendo? Que oportunidades você vê se abrindo para você?

Quaisquer exemplos e histórias do mundo real que você possa compartilhar seriam extremamente úteis para nos ajudar a validar que isso pode fornecer valor real.

Como sempre, qualquer pessoa pode se sentir à vontade para me enviar um e-mail, se preferir. davi. [email protected]

davidortinau em 24 abr. 2018

O maior problema para mim é a resposta "não podemos fazer isso com a estrutura do Forms" que tenho que dar a clientes em potencial e UX/UI. Desacredita a estrutura e só tenho tantas chances com um cliente.

As formas carecem de um paradigma composicional onde nós pr. projeto pode construir a interface do usuário usando primitivas de interface do usuário. Isso se aplica à navegação, animações (incluindo coisas como animações de heróis), elementos de interface do usuário e gestos.

Essa sugestão nos fornecerá primitivas de interface do usuário de composição neutras em plataforma?

timahrentlov em 24 abr. 2018

🎉2 ❤1

@timahrentlov Precisamos ver discutir e ver exatamente quais são essas limitações e o motivo dessas limitações. Mas honestamente eu nem me atrevo a pensar ou olhar tão longe. O problema que vejo com o Xamarin Forms é de uma perspectiva muito mais simples: ainda continua sendo um projeto com recursos de desenvolvimento muito limitados. É irrealista ou inútil discutir o que poderia ser feito, quando na verdade não há energia e combustível suficientes. Eu não vejo o ponto. Talvez o Xamarin ainda esteja secretamente esperando que alguns indivíduos da comunidade OSS comecem a trabalhar e consertar as coisas? Não me entenda mal, eu respeito o tempo e o esforço que o Xamarin colocou no Xamarin Forms.

opcodewriter em 24 abr. 2018

@davidortinau
multiplataforma é difícil de distinguir design visual característico, aparência de botão exclusiva, efeito de desaparecimento de espaço reservado exclusivo etc. r realmente evita que nossos aplicativos sejam idênticos. Por exemplo, o desvanecimento do anúncio do mac, com uma leve explosão, é muito fácil de impressionar seus clientes. Por que amamos muito o wpf naquele dia, uma razão que devo mencionar, é o modelo de controle, onde gostamos tanto de caminhos por nossa singularidade, como botão hexagonal encurralado. Queremos que o xf leve isso para desenvolvedores de clientes de plataforma cruzada.

juepiezhongren em 24 abr. 2018

@juepiezhongren , se você estiver procurando por esse tipo de personalização da interface do usuário, não acho que exista uma estrutura multiplataforma que possa fazer isso. E sobre o WPF: é uma má ideia misturar WPF com mobile.

opcodewriter em 24 abr. 2018

minha equipe está usando react native também, onde tantos jsers contribuem muito, onde após 3 meses concluímos que não é nada produtivo. Para xf, é com desvantagens, com bugs, mas basicamente é uma solução sólida, eps x.native torna todas as api nativas válidas. O que falta é apenas a aparência ubi, considerando a mafness recente do flutter. Além disso, com o shell, o flutter será inútil, sem algo como flutter.ios, o flutter será como rn com o sofrimento ilimitado da API nativa.

juepiezhongren em 24 abr. 2018

@opcodewriter
usamos skiasharp com bastante frequência, fazendo controle especial, seu desempenho é satisfatório

juepiezhongren em 24 abr. 2018

@jassmith você considerou portar materialShell para wasm usando webgl, para skia, talvez seja muito grande para baixar

juepiezhongren em 25 abr. 2018

correto, não queremos fazer um hard dep em nenhuma biblioteca de terceiros para a API de desenho padrão. \poderia fazer isso

jassmith em 25 abr. 2018

👍2

com o xamarin.mono e o shell no wasm, qualquer produto alfa causará um renascimento do dotnet na China, onde o ódio contra o dotnet é muito predominante

juepiezhongren em 26 abr. 2018

👍2

@jassmith alguma boa notícia sobre esse problema?

juepiezhongren em 4 mai. 2018

que novidades você está procurando @juepiezhongren? Neste ponto, é uma especificação postada para invocar a discussão.

ChaseFlorell em 4 mai. 2018

queremos ver quando draw e shell serão incluídos no roadmap@ChaseFlorell
renderização universal já é válida para avalonia e flutter

juepiezhongren em 5 mai. 2018

A linha do tempo vai depender da minha velocidade de desenvolvimento pessoal. O objetivo aqui não é distrair toda a equipe nesses empreendimentos e apenas me poupar disso. Você pode rastrear a ramificação do shell se quiser vê-la se unir. Depois da Shell virá o desenho.

jassmith em 6 mai. 2018

🎉1

Como nota, pretendo levantar uma fatia vertical de desenho muito rapidamente e depois pedir a ajuda da comunidade se quiserem fazê-lo mais rápido.

jassmith em 6 mai. 2018

Isso tudo é muito bom, mas usará aceleração gráfica?

MelbourneDeveloper em 7 mai. 2018

@jassmith no ios, system.draw a ser usado; no android, skiasharp a ser usado || skiasharp para cada coisa?

juepiezhongren em 7 mai. 2018

@juepiezhongren ele suportará vários back-ends, portanto, se você quiser usar o Skia, ele usará o Skia, se você quiser usar a API de desenho nativa, ele usará isso. Por padrão, ele usará o backend nativo e o Skia será ativado para que a dependência não seja forçada a você.

jassmith em 7 mai. 2018

@jassmith é realmente com fio que system.draw está disponível para ios, mas não para android

juepiezhongren em 7 mai. 2018

@juepiezhongren adicionar suporte para System.Drawing não é algo que esteja dentro do meu alcance aqui. Nada usará System.Drawing no entanto com esta especificação.

jassmith em 7 mai. 2018

basicamente, desenhar causará muito menos renderizações

juepiezhongren em 8 mai. 2018

Na verdade, os Desenhos terão que ser apoiados por algo que os renderize. A menos que você queira dizer menos necessidade de renderizadores personalizados, nesse caso sim, eu concordo.

jassmith em 8 mai. 2018

Estou no campo "faça o mais próximo possível do wpf/uwp", que eu sei que nem sempre é a posição mais popular por aqui.

MAS, isso parece um grande compromisso entre totalmente sem aparência com o framework fazendo TODA a renderização e o atual paradigma XF.

Presumo que os primitivos terão contrapartes em cada plataforma e, portanto, a aceleração de hardware não seria um problema. Windows/iOS/Android/etc ainda estão renderizando retângulos, círculos, gradientes e similares e usarão a aceleração de hardware na mesma medida em que já fazem. Isso apenas nos daria aos designers de controle a capacidade de projetar nossos controles usando primitivos, em vez de ficar preso à ideia da Apple de um botão versus a da Microsoft.

Eu resumi isso corretamente?

legistek em 17 mai. 2018

🎉2 👍1

@pmoorelegistek essa é basicamente a ideia sim. E estamos abordando o Material primeiro principalmente porque ele não tem o Blur por trás como um elemento de design principal. Isso significa que podemos realmente fazê-lo funcionar em qualquer lugar (olhando para você Android).

jassmith em 17 mai. 2018

🎉2

quando termino o Shell v1, estou imediatamente passando para isso

jassmith em 17 mai. 2018

@jassmith Isso é de ouro. Use controles nativos onde eles se encaixam no design UX e adicione facilmente controles desenhados semelhantes a skia apenas para os (de preferência poucos) elementos de design que precisam disso.

Chega de conversas "não posso fazer isso no Xamarin Forms" com designers e clientes. Isso remove as limitações de design enquanto preserva a verdadeira sensação nativa (ao contrário da vibração).

Eu adoraria ver isso antes do material shell. Isso resolve uma limitação real do XF.
Shell é o enésimo recurso para começar fácil/mais rápido. Começar _começar_ tem sido o foco por muito tempo, mas recursos como este para obter _mais__ irão _manter_ os desenvolvedores XF a bordo.

VincentH-Net em 18 mai. 2018

Isso tem que acontecer antes do Material Shell porque o Material Shell depende disso. Acho que você quis dizer que prefere ver isso antes da Shell?

jassmith em 18 mai. 2018

👍8 ❤1

@weitzhandler Espero mudar para isso nas próximas 4-6 semanas. Isso será muito mais rápido para começar a trabalhar nesse shell. Nenhum desses tempos está gravado em pedra.

jassmith em 21 mai. 2018

timahrentlov em 23 mai. 2018

@jassmith https://github.com/nventive/Uno
isso é ótimo.
uni-rendering é ótimo

juepiezhongren em 26 mai. 2018

forms será um explorador radical, enquanto o uno será um conservador
nós amamos os dois

juepiezhongren em 26 mai. 2018

+1 Ótimo recurso, ele resolverá muitos problemas de interface do usuário personalizados, queremos vê-lo o mais rápido possível

RadwanIbrahim em 22 jun. 2018

👍2

@jassmith parece que o sorteio deve ser feito para 3.3.0？

juepiezhongren em 9 jul. 2018

❤1

alguma atualização disso?

Para nós, esse é o recurso mais atraente que esperamos que o Xamarin implemente.

Desenvolvemos principalmente aplicativos LoB e uma de nossas principais prioridades é a velocidade de desenvolvimento.
Nós nos importamos menos com a aparência nativa, desde que haja uma interface do usuário atraente que faça um trabalho decente, renderize bem e leve menos tempo de desenvolvimento.

Ter que testar e adaptar cada formulário e página separadamente em cada plataforma é um assassino em tempo real, exigindo que qualquer pequena alteração na interface do usuário seja verificada três vezes em todas as plataformas.

Shell & Material Shell é uma bênção e uma ótima notícia, por favor, avance! Esta é a única coisa que manterá seus usuários indo para outro lugar (Uno, Flutter e outros).

weitzhandler em 20 jul. 2018

👍1

triste notícia que empate não apareceria para 3.3

juepiezhongren em 24 jul. 2018

👍1

+1 para isso, vindo de um plano de fundo uwp, eu realmente quero usar o XF, mas tem desvantagens, atualmente estou tentando flutter, mas certamente chegarei ao XF se isso for implementado o mais rápido possível.

touseefbsb em 3 ago. 2018

👍1

Eu concordo que este é um ótimo recurso e deve ser implementado .. Também incluirei estilo para linhas, por exemplo, linha sólida, linha pontilhada, etc ...

jrahma em 7 ago. 2018

Qualquer notícia? Planos? Roteiro?

weitzhandler em 6 set. 2018

👍2

Engraçado, ontem à noite eu me encontrei experimentando renderizadores personalizados e quase concluí que tudo isso pode ser feito apenas definindo nossos próprios primitivos como visualizações personalizadas e construindo a partir deles. Você não precisa de muito mais do que uma Borda, Elipse e Linha.
Estou ansioso para ver isso oficialmente suportado, mas não estou esperando. :)

legistek em 6 set. 2018

👍1

@jassmith
Então Line e Rectangle por exemplo, serão visualizações reais? (porque no exemplo vejo que há um Grid com Ellipse como uma visão filha). Vontade
Poderei anexar um TapGestureRecognizer a um Rectangle para lidar com o evento de toque?
Como essas são visualizações reais, ter visualizações reais para desenhar primitivos não será prejudicial à velocidade de renderização?

andreinitescu em 15 out. 2018

@andreinitescu Acredito que a intenção é que eles sejam visualizações reais no lado do Xamarin Forms, mas nunca sejam percebidos como visualizações nativamente:

_uma primitiva de desenho é simplesmente uma visão que não tem renderizador_

Portanto, um renderizador mais acima na cadeia ( Drawing ? DrawingTemplate ?) é responsável por iterar pelos descendentes desenháveis e desenhá-los.

Eu acho que isso significa que o mesmo tipo de restrição que se aplica a Layouts com CompressedLayout.IsHeadless se aplicaria (sem reconhecedores de gestos, sem efeitos, sem transformações etc.)

GalaxiaGuy em 16 out. 2018

@GalaxiaGuy Estou pensando na mesma linha, mas acho um pouco confuso, por causa da mistura com visualizações reais como Grid. É realmente necessário? Em vez de derivar de View, por que não tê-los como elementos de desenho abstratos (talvez tenha uma classe abstrata básica chamada DrawingElement com propriedades comuns?)

andreinitescu em 16 out. 2018

Bom trabalho apenas amostra correta

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

minaairsupport em 11 fev. 2019

👍1

Talvez seja em 4.0?

KSemenenko em 5 mar. 2019

Drawing é bom porque implementa controles usando primitivos gráficos independentes da plataforma de destino. Costumava haver NControl, mas isso tinha problemas (de pré-netstandard2.0, dias pré-SkiaSharp), e não é atualizado.

A especificação 1. duplica a funcionalidade já implementada de uma forma muito mais completa no SkiaSharp, 2. adiciona camadas desnecessárias de complexidade via XAML/Binding que vai dentro do repositório Xamarin.Forms já insustentável.

Uma abordagem melhor é fazer uma pequena biblioteca de controle baseada em SkiaSharp. NControl++

@jassmith @rogihee SVG realmente não é um formato de envio desculpe :/ Eu não quero ser responsável por tentar renderizar SVG consistentemente entre plataformas.

SkiaSharp tem suporte SVG.

charlesroddie em 10 mai. 2019

👎2 👍1

Alguma notícia sobre isso?

timahrentlov em 12 ago. 2019

Alguma notícia sobre isso?

wuxueqicai em 18 set. 2019

Também querendo saber se isso ainda é provável de acontecer. Estou muito no campo de querer uma estrutura de interface do usuário multiplataforma sem aparência e essa parece ser a melhor maneira de conseguir isso.

legistek em 25 nov. 2019

@legistek Você pode usar o SkiaSharp para desenho multiplataforma sem aparência. Quais são as vantagens de um Xamarin.Forms específico em sua mente?

charlesroddie em 25 nov. 2019

Há um pouco mais em uma estrutura de interface do usuário do que desenhar.

legistek em 25 nov. 2019

Mas este tópico está discutindo uma estrutura de desenho, não uma estrutura de interface do usuário ...

charlesroddie em 25 nov. 2019

Eu pensei que estava discutindo uma estrutura de desenho _for Xamarin Forms_.

legistek em 25 nov. 2019

SkiaSharp é uma estrutura de desenho para Xamarin Forms. O fato de também funcionar em outras plataformas .Net UI é certamente uma vantagem, não uma desvantagem.

charlesroddie em 25 nov. 2019

E como foi dito no OP, o SkiaSharp poderia muito bem ser o mecanismo de desenho subjacente nas plataformas individuais, mas a ideia desta proposta é adicionar uma camada de abstração e dar suporte ao desenho por meio de XAML com todos os seus benefícios, sendo o mais notável a vinculação de dados. O que você chama de complexidade desnecessária eu chamo de elegante.

legistek em 25 nov. 2019

Isso ainda está vivo e/ou será lançado no MAUI?

legistek em 20 mai. 2020

👍1

@legistek https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap lista Formas, Caminhos e Pincéis como no roteiro para Xamarin.Forms 4.7.0.