O Expander é muito útil e tenho usado a versão do Windows Community Toolkit desde que foi adicionada. Eu não reinventaria muito a roda, no entanto, apenas portar o código do kit de ferramentas seria perfeito para a versão 1.0 na minha opinião.

Outro exemplo: o ColorPicker com seu 'MoreButton' poderia usar isso.

Muito obrigado por enviar esta proposta! Vou fazer algumas edições, incluindo a diferenciação entre o que eu acho que são cenários verdadeiros do Expander e o que é mais parecido com o uso de Flyout / MenuFlyout.

Atualizei esta proposta para incluir mais detalhes sobre o escopo, uma API proposta e a seguinte questão em aberto.

• Precisamos oferecer suporte a ExpandDirection em um Expander v1? Existem cenários comuns de aplicativos em que o Expander precisaria se expandir em outras direções que não para baixo?

Adoraria receber feedback sobre como eles se encaixam ou não em seus casos de uso do Expander!

Atualizei esta proposta para incluir mais detalhes sobre o escopo, uma API proposta e a seguinte questão em aberto.

• Precisamos oferecer suporte a ExpandDirection em um Expander v1? Existem cenários comuns de aplicativos em que o Expander precisaria se expandir em outras direções que não para baixo?

Adoraria receber feedback sobre como eles se encaixam ou não em seus casos de uso do Expander!

Parece uma função básica do controle

Parece uma função básica do controle

@mdtauk , você

Sim, precisamos expandir a direção. Há muitos casos para usá-lo e seria uma alteração desnecessária no modelo de controle após uma versão v1 adicioná-lo. A API Expander não mudou muito desde o WPF e a proposta aqui já possui todas as propriedades / eventos / métodos necessários. Eu apenas implementaria tudo de uma vez e podemos terminar com esse controle. Em termos de design, o UWP Community Toolkit fez as alterações necessárias para trabalhar melhor com o toque. Acho que temos todas as peças e não há necessidade de reinventar nada.

Editar: O kit de ferramentas da comunidade também possui uma propriedade ContentOverlay . Isso pode ser algo para pular em um V1.

Sim, precisamos expandir a direção. Há muitos casos para usá-lo e seria uma alteração desnecessária no modelo de controle após uma versão v1 adicioná-lo.

@robloo Você poderia explicar como isso seria uma mudança significativa? Meu entendimento é que poderíamos evitar que ele fosse interrompido com V1 tendo expansão para baixo, e V2 poderia adicionar ExpandDirection e padrão para baixo.

Parece uma função básica do controle

@mdtauk , você

Aplicativos de bate-papo que carregam o novo conteúdo da lista de baixo para cima, sendo um deles talvez.

Além do essencial básico:

• IsCollapsed
• IsExpanding
• IsExpanded
• IsCollapsing

Bem como IsEnabled

O próximo ponto principal é para onde expandir.

• ExpandUp
• ExpandDown
• ExpandLeft
• ExpandRight

Aplicativos de bate-papo que carregam o novo conteúdo da lista de baixo para cima, sendo um deles talvez.

@mdtauk Não entendo totalmente o que você quer dizer com este exemplo de aplicativos de bate-papo - poderia explicar?
Quanto às propriedades - a API proposta é baseada no WPF Expander, então acho que IsExpanded e ExpandDirection as abrangem. Para que IsEnabled seria usado - há um cenário de aplicativo em que você deseja desabilitar um Expander?

Outro exemplo que usei no passado são as propriedades editáveis ​​secundárias que normalmente deveriam ser ocultadas. Eles são mostrados na parte inferior de um editor apenas ao clicar em um botão de 'opções' e o expansor abre para cima. Depende do design que você deseja. Existem muitos casos úteis para expandir direções diferentes e parece desnecessário restringir isso artificialmente, especialmente quando a convenção anterior é tão forte. Não acho que nada disso seria muito difícil em um V1 do controle, especialmente porque todos os problemas já foram resolvidos no kit de ferramentas da comunidade e no WPF.

@robloo Você poderia explicar como isso seria uma mudança significativa? Meu entendimento é que poderíamos evitar que ele fosse interrompido com V1 tendo expansão para baixo, e V2 poderia adicionar ExpandDirection e padrão para baixo.

https://github.com/windows-toolkit/WindowsCommunityToolkit/blob/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander/Expander.xaml

Suponho que se você for muito cuidadoso ao projetar o modelo e os estados visuais, será possível torná-lo ininterrupto. No entanto, para fazer isso, você realmente precisa projetar a funcionalidade de qualquer maneira, portanto, também pode implementá-la. Isso tudo é bastante básico e não há razão para um plano V2 desde o início deste controle.

Eu sei que é tentador reinventar a roda. Mas, por favor, mantenha-o para que as pessoas que portam aplicativos do WPF para o WinUI possam fazer isso sem nada além de mudanças de código absolutamente necessárias. O WinUI precisa começar a corrigir alguns dos erros com o UWP.

Para que IsEnabled seria usado - há um cenário de aplicativo em que você deseja desabilitar um Expander?

@mdtauk está correto, também precisa ser compatível com IsEnabled. Desativar controles é uma convenção bastante forte sempre que houver a possibilidade de alteração de entrada ou estado. Por favor, não nos faça defender isso.

Nas imagens acima, o Windows Security tem um expansor para a seção de antivírus, bem como o menu de navegação esquerdo. Isso mostra um uso muito realista do expansor em mais de uma direção que muitos aplicativos precisariam oferecer suporte. Meu voto é para apoiar várias direções em V1.

@robloo

Outro exemplo que usei no passado são as propriedades editáveis ​​secundárias que normalmente deveriam ser ocultadas. Eles são mostrados na parte inferior de um editor apenas ao clicar em um botão de 'opções' e o expansor abre para cima.

Você poderia explicar com uma captura de tela ou um aplicativo específico onde isso acontece para que eu possa entender melhor o cenário? Posso pensar em editores em que um botão de opções abre um pop-up com mais botões, mas naqueles que estou familiarizado com o outro conteúdo não é empurrado para cima - um comportamento de pop-up / flyout em vez de uma expansão.

Suponho que se você for muito cuidadoso ao projetar o modelo e os estados visuais, será possível torná-lo ininterrupto. No entanto, para fazer isso, você realmente precisa projetar a funcionalidade de qualquer maneira, portanto, também pode implementá-la. Isso tudo é bastante básico e não há razão para um plano V2 desde o início deste controle.
Eu sei que é tentador reinventar a roda. Mas, por favor, mantenha-o para que as pessoas que portam aplicativos do WPF para o WinUI possam fazer isso sem nada além de mudanças de código absolutamente necessárias.

Eu concordo com você que a portabilidade de aplicativos do WPF para o WinUI deve ser o mais suave possível! Em discussão com a equipe WinUI, foi sugerido que um V1 com escopo para expandir para baixo encurtaria o tempo de desenvolvimento e tornaria o Expander disponível para desenvolvedores mais cedo (já que os cenários do Expander até agora foram todos para baixo), e um V2 planejado poderia adicionar ExpandDirection logo depois. (Vou editar a questão aberta para ter esse contexto adicional) É por isso que espero entender se há casos de uso específicos que os desenvolvedores têm para o Expander não descendente! 😄

Desativar controles é uma convenção bastante forte sempre que houver a possibilidade de alteração de entrada ou estado. Por favor, não nos faça defender isso.

Obrigado por explicar isso, faz totalmente sentido que desabilitar a mudança de estado seja um recurso desejado para este tipo de controle!

Nas imagens acima, o Windows Security tem um expansor para a seção de antivírus, bem como o menu de navegação esquerdo. Isso mostra um uso muito realista do expansor em mais de uma direção que muitos aplicativos precisariam oferecer suporte. Meu voto é para apoiar várias direções em V1.

@JustABearOz Acho que o menu de navegação esquerdo é um NavigationView , na verdade. 😃 Concordo que a seção de antivírus é um cenário Expander, neste caso expandindo para baixo. Adoraria saber quaisquer casos de uso específicos que você tem para o Expander não descendente!

@ kat-y Ok, isso elimina a necessidade de esquerda / direita, mas 2 exemplos em janelas que parecem se expandir e que podem ser facilmente aplicáveis ​​a aplicativos:
1: A imagem acima com o menu de ações rápidas. Tenho certeza de que isso se expande.
2: No Windows, o calendário popup da bandeja do sistema tem uma seção que se expande para mostrar a agenda / compromissos.

É possível suportar Up / Down para V1 em vez de apenas Down?

1: A imagem acima com o menu de ações rápidas. Tenho certeza de que isso se expande.

@JustABearOz muito obrigado por trazer esses exemplos! Para 1: Eu acho que este é um caso interessante - a expansão é 'para baixo' a partir do 'cabeçalho' (o botão de expansão), mas o próprio controle está posicionado na parte inferior da superfície, então o cabeçalho (e o conteúdo expandido) tem que 'deslocar' para cima (caso contrário, sairia da tela!). Parece uma boa maneira de lidar com um item de expansão na 'parte inferior' de um aplicativo, você concorda?

2: No Windows, o calendário popup da bandeja do sistema tem uma seção que se expande para mostrar a agenda / compromissos.
É possível suportar Up / Down para V1 em vez de apenas Down?

Concordo com você, esse é um cenário em que o cabeçalho fica na parte inferior da área e se expande para cima! Nesse caso, o expansor do calendário (e o pop-up como um todo) está vinculado à barra de tarefas - você encontrou cenários em aplicativos em que os expansores têm um posicionamento vinculado semelhante que necessita de expansão para cima?

@ kat-y Não quero ofender, mas sinto que estamos tendo que reexplicar coisas que eram conhecidas há 15 anos. Não entendo por que você está nos pedindo para dar exemplos de direção de expansão no uso no mundo real. Espero que internamente você tenha que levar isso para revisão de especificações e defendê-lo para a gerência. Mas a explicação pode ser simplesmente (1) você precisa capacitar os usuários para atingir seus objetivos de design, não cabe à Microsoft dizer o que é / não é possível fazer com os controles, cabe aos desenvolvedores / designers de aplicativos descobrir o que é melhor para seu caso de uso (um conceito crítico para controles sem aparência) (2) Mais importante, esta não é uma ideia nova. Você está copiando sobre uma API existente nesta área e precisa manter a compatibilidade do aplicativo. Novamente, se essa fosse uma ideia nova, eu entenderia mais por que temos que defendê-la - é bom ter certeza de que os recursos são úteis antes de investir tempo neles.

Além do cabeçalho, existem literalmente duas propriedades neste controle e se fosse C # eu poderia escrevê-lo em algumas horas usando a base do WCT. Vamos gastar mais horas de trabalho apenas falando sobre isso do que implementando-o como existe hoje no WPF / WCT.

Obrigado @robloo pela contribuição, estou entrando em contato com a equipe WinUI para discutir como podemos tornar essas propostas mais robustas inicialmente quando elas existem em outras bibliotecas de terceiros, como o Toolkit. Definitivamente, acho que deveria fazer parte do modelo de problema chamar os exemplos existentes.

Para sua informação, @ryandemopoulos @stmoy

@robloo Obrigado por ser honesto comigo! Eu entendo que os desenvolvedores de aplicativos devem ser capazes de determinar o que se encaixa melhor em seus casos de uso, e que a compatibilidade de aplicativos é importante. Espero que a discussão com @michael-hawker e a equipe WinUI nos ajude a avançar de forma produtiva na definição do escopo do Expander!

Anteriormente, eu não tinha nenhum exemplo concreto de expansores sendo usados ​​na direção não descendente. Trarei qualquer exemplo da comunidade WinUI (incluindo o flyout do calendário que @justABearOz apontou) e qualquer um que eu aprender com Michael para discussões com a equipe WinUI como evidência para manter ExpandDirection na v1 do Expander.

Eu atualizei a proposta com uma lista de controles do Expander que conheço - deixe-me saber se eu esqueci algo.

• WPF
• Kit de ferramentas da comunidade do Windows
• Telerik UI
• Xamarin.Forms
• Syncfusion.XForms.Expander

Dei uma olhada no código-fonte do WPF e no código-fonte do WCT. Tenho certeza de que isso pode ser implementado no WinUI em algumas horas também. O controle deve seguir a implementação do WCT pelo que vi, embora a propriedade ContentOverlay provavelmente deva ser renomeada ou deixada de fora da V1.

WPF:
https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/Themes/XAML/Expander.xaml
https://github.com/dotnet/wpf/blob/master/src/Microsoft.DotNet.Wpf/src/PresentationFramework/System/Windows/Controls/Expander.cs

WCT:
https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander

Como essas duas fontes são da Microsoft e licenciadas pelo MIT, elas devem ser a base, não comece do zero. O Xamarin Forms não se alinha com os conceitos de WPF-> WinUI, portanto, provavelmente deve ser desconsiderado (também não há funcionalidade adicional). As soluções de terceiros também não têm nenhuma ideia nova e inovadora pelo que tenho visto. Esse controle resistiu amplamente ao teste do tempo.

@robloo Obrigado por ser honesto comigo! Eu entendo que os desenvolvedores de aplicativos devem ser capazes de determinar o que se encaixa melhor em seus casos de uso, e que a compatibilidade de aplicativos é importante. Espero que a discussão com @michael-hawker e a equipe WinUI nos ajude a avançar de forma produtiva na definição do escopo do Expander!

Anteriormente, eu não tinha nenhum exemplo concreto de expansores sendo usados ​​na direção não descendente. Trarei qualquer exemplo da comunidade WinUI (incluindo o flyout do calendário que @JustABearOz apontou) e qualquer um que eu aprender com Michael para discussões com a equipe WinUI como evidência para manter ExpandDirection na v1 do Expander.

Bem, meu ponto é que realmente não deveria haver muitas discussões sobre isso. Estou escolhendo expressar minhas frustrações aqui, pois este controle é um exemplo perfeito. Os novos controles de pager ou migalhas de pão precisam de mais supervisão e é importante seguir o processo. No entanto, a sobrecarga de um grande processo está aparecendo aqui e novamente, você gastará muito mais horas-homem cuidando de papéis e discussões que não agregam valor, do que apenas implementando o controle do WCT. Eu também ainda não vi a equipe WinUI usar outro trabalho anterior, o que é um tanto preocupante. Não há necessidade de reprojetar o modelo de controle XAML.

Bem-vindo ao projeto WinUI @ kat-y - Xaml tem uma longa história, mas pode ser um pouco peculiar para aqueles que são novos nele. Embora o WinUI seja uma oportunidade de repensar como as coisas funcionam, neste caso, o expansor é um controle relativamente simples e, portanto, uma simples mudança do WPF para o WinUI deve ser suficiente.

@robloo Não concordo com sua afirmação de que não há necessidade de reprojetar o modelo de controle XAML. O WPF AFAIR tem vários elementos semelhantes a cromo que estariam deslocados no WinUI / Fluent.

Lidar com os tamanhos Chevron e alvos de toque, bem como usar os tamanhos de escala da fonte. O Chevron deve ser fácil de remover ou adicionar.

Este exemplo tem uma divisa alinhada com o texto.

Este exemplo não tem chevron

Este exemplo tem um lado anterior voltado para a divisa

Quanto à implementação, deve haver uma transição animada ao abrir e fechar, a menos que o usuário tenha desativado as animações, então ele apenas muda de estado.

Quanto à implementação, deve haver uma transição animada ao abrir e fechar, a menos que o usuário tenha desativado as animações, então ele apenas muda de estado.

Eu estava prestes a perguntar sobre animações. Deve haver uma maneira de desativá-los para o controle, por exemplo, em cenários onde a animação de layouts seria muito cara? Nem todos os usuários / desenvolvedores desejam animações para coisas que podem parecer um pouco sem resposta ou simplesmente indesejadas (por exemplo, TreeView). Ter que não refazer o modelo do controle para personalizar esse ponto pode ser melhor. Outra coisa que pode ser personalizável é a duração da animação, em alguns casos animações curtas são melhores do que as mais longas.

Obrigado por todas as ótimas discussões. alguns pensamentos

• Precisaremos atualizar o modelo conforme @mdtauk menciona para dar conta do novo design, bem como oportunidades para reduzir os elementos / melhorar o desempenho, se possível.
• IsEnabled é herdado de Control, então espero que funcione.

Quanto à implementação, deve haver uma transição animada ao abrir e fechar, a menos que o usuário tenha desativado as animações, então ele apenas muda de estado.

Eu estava prestes a perguntar sobre animações. Deve haver uma maneira de desativá-los para o controle, por exemplo, em cenários onde a animação de layouts seria muito cara? Nem todos os usuários / desenvolvedores desejam animações para coisas que podem parecer um pouco sem resposta ou simplesmente indesejadas (por exemplo, TreeView). Ter que não refazer o modelo do controle para personalizar esse ponto pode ser melhor. Outra coisa que pode ser personalizável é a duração da animação, em alguns casos animações curtas são melhores do que as mais longas.

Acredito que alguns controles têm uma propriedade Transition que pode ser atribuída. Portanto, se um storyboard não animado fosse incluído como um recurso, ele poderia ser aplicado e trataria disso sem qualquer retemplamento.

Você teria que substituir a transição quando a configuração do sistema desativa as animações.

UIElement.Transitions?
https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.uielement.transitions?view=winrt-19041

Além disso, com a propriedade IsEnabled, deve haver um estado Disabled. Deve haver um Desativado Expandido e Desativado recolhido ou Desativado sempre recolhido?

Ponto interessante sobre animações. Desativamos todas as animações com a configuração do sistema, mas não acho que exponhamos os botões para desligar as animações, a não ser através da reformulação atual.

Ponto interessante sobre animações. Desativamos todas as animações com a configuração do sistema, mas não acho que exponhamos os botões para desligar as animações, a não ser através da reformulação atual.

Acredito que você possa adicionar um estilo que substitui a coleção Transition por null no caso de você querer desativar as animações, supondo que haja uma coleção Transition para substituir.

Incluindo um ExpandTransition e CollapseTransition , que podem usar a direção definida pela propriedade do controle - o que pode permitir que o dev defina a transição para cada um.

Gosto da ideia, mas não acho que haja uma maneira hoje de criar transições de tema personalizadas que limitariam a capacidade de personalização. Isso permitiria desabilitá-lo facilmente removendo-o.

Além disso, com a propriedade IsEnabled, deve haver um estado Disabled. Deve haver um Desativado Expandido e Desativado recolhido ou Desativado sempre recolhido?

Por que não espelhar o controle TreeView onde você pode usar as propriedades IsExpanded e IsEnabled para criar qualquer combinação necessária dos dois? Se desativado, expandido funciona melhor em alguns casos, isso pode ser feito. Se você precisa desabilitado recolhido, isso também é possível desta forma.

@robloo Não concordo com sua afirmação de que não há necessidade de reprojetar o modelo de controle XAML. O WPF AFAIR tem vários elementos semelhantes a cromo que estariam deslocados no WinUI / Fluent.

@mdtauk Bem, minha recomendação foi que "devemos seguir a implementação do WCT" aqui: https://docs.microsoft.com/en-us/windows/communitytoolkit/controls/expander. O design muda para se adaptar ao toque e uma interface mais moderna já foi feita. É claro que ninguém pode fazer designs tão bons quanto você, então tenho certeza de que há espaço para melhorias. Mesmo assim, mudar o 'design' não exigiria a reengenharia do modelo para suportar todas as direções de expansão. O WCT deve ser a base e, se tivermos um novo estilo para aplicar, muito bem, pode ser feito rapidamente, mas não do zero.

@robloo Não concordo com sua afirmação de que não há necessidade de reprojetar o modelo de controle XAML. O WPF AFAIR tem vários elementos semelhantes a cromo que estariam deslocados no WinUI / Fluent.

@mdtauk Bem, minha recomendação foi "devemos seguir a implementação do WCT" aqui ...
Presumi que você quisesse dizer nenhuma alteração do XAML da versão WPF

Mas ainda acho que a equipe de design do WinUI precisará aprová-lo e às suas variantes - nem que seja apenas para confirmar a especificação a ser incluída nos kits de ferramentas do figma

@kat-y Se você é novo no projeto, peço desculpas se pareci rude. Eu mantenho meus pontos acima sobre como a velocidade do projeto pode ser melhorada em algumas áreas, o que certamente é necessário. Além disso, como devemos usar o que já foi feito no passado e fortemente testado em batalhas nos últimos 15 anos. Claro, nada disso é dirigido pessoalmente a você ou a ninguém. É um problema geral de 'inchaço' que vejo na Microsoft há anos, em que as equipes precisam ser mais simplificadas e reequilibradas em favor de mais codificação / menos gerenciamento de projetos. Tão bons quanto os planos, nada supera a tentativa e erro, então a velocidade da iteração vence no final.

@ranjeshj @ michael-hawker Por que não usar o que já foi feito no kit de ferramentas da comunidade? Esta não é a primeira vez que a equipe WinUI parece estar adotando uma abordagem nova. Isso duplica desnecessariamente o trabalho e causa fragmentação no pior dos casos. A versão do WCT já era baseada nas idéias do WPF e fez as mudanças 'modernas' necessárias.

@ranjeshj @ michael-hawker Por que não usar o que já foi feito no kit de ferramentas da comunidade? Esta não é a primeira vez que a equipe WinUI parece estar adotando uma abordagem nova. Isso duplica desnecessariamente o trabalho e causa fragmentação no pior dos casos. A versão do WCT já era baseada nas idéias do WPF e fez as mudanças 'modernas' necessárias.

O Community Toolkit está em C #, eu acredito, e WinUI requer código C / C ++.

Além disso, a equipe de design do WinUI não teve nenhuma palavra a dizer AFAIK com a versão do Toolkit e, portanto, as necessidades das equipes de design do Windows e do aplicativo podem ter necessidades específicas se quiserem adotar o controle sobre suas soluções personalizadas.

O Community Toolkit está em C #, eu acredito, e WinUI requer código C / C ++.

Traduzir código de / para C # e C ++ / WinRT é relativamente trivial. Especialmente para o Expander onde já olhei o código https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander. A grande maioria da complexidade está no XAML, que é 1: 1 utilizável no WinUI, desde que nenhuma extensão WCT tenha sido usada. Eu poderia portar esse código para C ++ sozinho, se necessário.

Além disso, a equipe de design do WinUI não teve nenhuma palavra a dizer AFAIK com a versão do Toolkit e, portanto, as necessidades das equipes de design do Windows e do aplicativo podem ter necessidades específicas se quiserem adotar o controle sobre suas soluções personalizadas.

Para pontos específicos, sim. No entanto, para a funcionalidade de controle geral, devo discordar. O WCT nos deixaria 95% completos e 100% completos em termos de funcionalidade. Quaisquer alterações de design aplicadas na parte superior seriam triviais.

@robloo Você poderia explicar quais partes da funcionalidade são diferentes? A API proposta acima é muito próxima do WPF / WCT enquanto tenta manter a consistência com os padrões existentes no WinUI.

@ranjeshj Podemos não estar na mesma página. Eu não estava sugerindo que a API proposta fosse significativamente diferente do WCT ou do WPF.

Foi mencionado que ExpandDirection pode não ser suportado na primeira versão deste controle. Isso parece um problema para um Expander que tem uma longa história com essa funcionalidade. Então parecia que temos que justificar por que esse recurso é necessário.

Eu sugeri usar o WCT como base para implementar isso rapidamente com uma direção de expansão. Não há necessidade de reinventar a roda, pois apenas uma porta de C # -> C ++ é necessária (e o code-behind é muito pequeno para isso) ao copiar e colar o modelo XAML. Isso implementaria todas as funcionalidades de que precisaríamos e evitaria preocupações de que não há tempo suficiente para adicionar ExpandDirection. Essa abordagem nos daria um controle totalmente funcional. Então, qualquer mudança de design / estilo pode ser feita no topo com base em @mdtauk ou na sugestão de qualquer outra pessoa. Eu não entendo (1) Por que ExpandDirection é potencialmente um obstáculo para V1 (2) Por que se o tempo é uma limitação, não usamos o código existente.

Sim, minhas frustrações com o desenvolvimento do WinUI 3 em geral estão se espalhando por alguns lugares e eu peço desculpas por isso.

@robloo Não se trata de algo estar em

Ao priorizar quais recursos são essenciais para serem incluídos em uma V1 e, em seguida, em uma V2, apenas as propriedades e comportamentos básicos e essenciais estarão lá, e não coisas legadas que não são comumente usadas.

A Microsoft parece determinar quais recursos adicionar com base nas necessidades e desejos do cliente - não apenas alcançando a paridade com estruturas mais antigas.

Portanto, não é _justificando_, mas apenas tentando entender o que os desenvolvedores realmente fazem com esses padrões de controle em sua IU.
O fato de o Windows Shell sozinho ter várias versões de um padrão de controle do expansor seria um motivo claro para incluí-lo. E o fato de cada implementação parecer diferente, se não se comportar de forma diferente - é motivo suficiente para a equipe de design consolidar o design de controle para atender às necessidades das equipes internas.

@mdtauk Como sempre, você faz bons pontos. No entanto, devo discordar dessa filosofia de uma maneira importante, se for realmente a abordagem que a Microsoft está adotando. Para que o WinUI seja bem-sucedido, ele deve fazer sentido para os desenvolvedores de aplicativos existentes. Estou tentando evitar outro cenário UWP, pois todos sabemos que o UWP nunca decolou. Os desenvolvedores que a Microsoft precisa convencer a vir para o WinUI, assim como o UWP antes, são desenvolvedores do WPF. Um dos motivos pelos quais os aplicativos WPF nunca deram o salto para o UWP é que o UWP, especialmente quando foi lançado pela primeira vez, era um equivalente muito pobre em várias áreas principais de funcionalidade. É por isso que, quando vi cantos arredondados faltando no roteiro, comecei a me lembrar do pesadelo da UWP (os cantos arredondados fundamentais para o WPF foram deixados de fora da UWP por muito tempo). A prioridade número 1 deve ser para uma experiência de portabilidade suave vinda de AMBOS WPF e UWP e honestamente WPF deve ser uma prioridade mais alta, pois há muito mais aplicativos lá e a Microsoft está claramente se concentrando em gabinetes de desktop com WinUI primeiro. Portanto, novamente, temos que ser muito cuidadosos e evitar ativamente reinventar a roda.

E o fato de cada implementação parecer diferente, se não se comportar de forma diferente - é motivo suficiente para a equipe de design consolidar o design de controle para atender às necessidades das equipes internas.

Sempre entendi que o design pode precisar ser modificado. No entanto, usando conceitos de controle sem aparência, este é um problema separado do ExpandDirection. Se precisarmos modernizar mais o design ou torná-lo mais útil em alguns casos, ótimo - deve ser relativamente trivial. No final do dia, também pode ser totalmente refeito para aqueles que precisam de um controle preciso.

Ponto interessante sobre animações. Desativamos todas as animações com a configuração do sistema, mas não acho que exponhamos os botões para desligar as animações, a não ser através da reformulação atual.

Para ser justo, quase nenhum controle usa animações. TreeView e NavigationView usam essencialmente um Expander, mas ambos não usam animações para expandir / recolher. A maioria dos controles que usam animações geralmente dependem deles, por exemplo, ProgressBar ou ProgressRing. O Expander, entretanto, não depende dele, seria mais um "bom ter". Outro caso em questão é que algumas pessoas não usaram o controle WCT Expander porque não gostaram da animação. Se quisermos incluir o máximo de pessoas possível, ter uma maneira fácil de desabilitar animações indesejadas tornaria isso mais fácil.

Acredito que você possa adicionar um estilo que substitui a coleção Transition por null no caso de você querer desativar as animações, supondo que haja uma coleção Transition para substituir.

Mas essa seria uma maneira comum de desabilitar / habilitar isso? Na maioria das vezes, quando fornecemos vários estilos, eles diferem mais drasticamente do que apenas uma animação, por exemplo, AccentColorButtonStyle ou RevealButtonStyle.

Incluindo um ExpandTransition e CollapseTransition, que podem usar a direção definida pela propriedade do controle - o que pode permitir que o dev defina a transição para cada um.

Eu realmente gosto dessa ideia!

Gosto da ideia, mas não acho que haja uma maneira hoje de criar transições de tema personalizadas que limitariam a capacidade de personalização. Isso permitiria desabilitá-lo facilmente removendo-o.

Eu também estou preocupado com isso. com a API ExpandTransition e CollapseTransition sem quaisquer transições de tema personalizado, isso está perto de ter apenas um "ExpendTransitionEnabled" e "CollapseTransitionEnabled".

@robloo Se você gostaria de conversar sobre as frustrações relacionadas ao desenvolvimento do WinUI 3, gostaria de me escrever (meu Twitter e e-mail de trabalho estão no meu perfil do GitHub). Não estou totalmente ciente de suas frustrações atuais, mas geralmente sou uma boa pessoa para começar em tópicos relacionados ao envolvimento / desenvolvimento do cliente ou da comunidade, bem como dirigi um número significativo de nossos grupos de foco no ano passado que cobriu as considerações que você listou sobre ferramentas, paridade de recursos, etc.

Notarei que nosso roteiro é extremamente apertado, então não posso prometer que terei a capacidade de fazer as alterações que você deseja ver, mas é sempre útil saber o que poderia ser feito para melhor apoiá-lo cliente e / ou contribuidor da WinUI, então o pior caso é que pelo menos suas necessidades sejam bem consideradas por nossa equipe no futuro. No melhor dos casos, suponho que isso dependerá do que você está procurando. Vamos conversar? 😄

@mdtauk Obrigado pelo seu apoio no esclarecimento - você está sempre bem sintonizado! Direi que claramente há MUITO em nosso prato e as equipes estão comprometidas em ser o mais enxutas e eficazes possível na tentativa de entregar o progresso mais significativo e impactante em todas as áreas. Para continuar investindo em novos controles / recursos entre todas as outras áreas de progresso contínuo, é necessário que os membros da nossa equipe, como @kat-y desenvolvam especificações de requisitos _muito_ precisas, já que a pior coisa para nós seria jogar uma parte de nossos recursos limitados em um botão ou API que na verdade não tem amplo uso, já que não há apenas o custo de desenvolvimento inicial, mas também o custo de manutenção continuado depois. Eu apenas analisei este tópico levemente, mas é correto para @ kat-y, especialmente como um novo membro da equipe, querer ser perfeitamente claro ao garantir que há um cenário real em um aplicativo real que precisa da funcionalidade solicitada ( tanto pelo motivo declarado e também para garantir que temos parceiros de validação de visualização que são capazes de ajudar a garantir que todos os recursos desenvolvidos funcionem conforme necessário em ambientes de produção que fornecem cobertura de casos extremos). A conformidade com essa aspiração nem sempre pode ser divulgada publicamente, como nos casos em que os parceiros de validação são privados (e você pode entrar em contato com @ kat-y diretamente se suas necessidades não forem adequadas para serem postadas publicamente aqui no momento), mas isso tem sido um precedente em todos os nossos lançamentos de controle WinUI 2+.

Espero que tenha ajudado? Meu objetivo é retornar este tópico para @ kat-y e os tópicos do Expander em questão, mas entre em contato diretamente se houver mais informações que eu possa responder ou se houver comentários que você gostaria de ver considerados. Obrigado a vocês dois por todo o trabalho, paixão e energia que colocaram neste tópico e no WinUI! 😄

@mdtauk Como sempre, você faz bons pontos. No entanto, devo discordar dessa filosofia de uma maneira importante, se for realmente a abordagem que a Microsoft está adotando.

Não estava comentando se concordo ou não com a abordagem, só que a partir da minha passagem por aqui e vendo como os repos são avaliados, é como acredito que a equipe está trabalhando nisso.

(pelo motivo declarado e também para garantir que temos parceiros de validação de visualização que são capazes de ajudar a garantir que todos os recursos desenvolvidos funcionem conforme necessário em ambientes de produção que fornecem cobertura de casos extremos). A conformidade com essa aspiração nem sempre pode ser divulgada publicamente, como nos casos em que os parceiros de validação são privados (e você pode entrar em contato com @ kat-y diretamente se suas necessidades não forem adequadas para serem postadas publicamente aqui no momento), mas isso tem sido um precedente em todos os nossos lançamentos de controle WinUI 2+.

Acredito que usar os próprios aplicativos da Microsoft e o Shell como exemplos são mais propensos a obter reconhecimento, pois mostra onde havia uma necessidade interna de algo, que não existia, ou não era adequado para o propósito, a tal ponto que deveria " rolar seus próprios "- mas é claro que grandes bestas como Netflix, Facebook, etc, que criam aplicativos para Windows - também vão pedir controles e outros bits.

WinUI não se trata apenas de alcançar a paridade com WPF, MFC, CommonControls, WinForms etc - (mas o mais comumente usado desses controles legados sem um equivalente moderno, deve ser analisado seriamente)

O fato de Barras de migalhas de pão e expansores estarem sendo propostos é um sinal de que isso está começando a acontecer IMO. E cada adição de controle ou API deve ser avaliada e "justificada" em um ambiente ideal, assim como os designers de aplicativos devem sempre reavaliar suas UIs e UX para garantir que sejam adequados para o propósito. - Nesse caso, pode parecer óbvio, mas ainda devemos apresentar exemplos onde esse padrão e essas APIs são usados ​​- para fortalecer o caso de inclusão.

Sobre as animações: Que tal usar uma abordagem ElementAnimator como a ItemsRepeater oferece? A API ElementAnimator com seus StartShowAnimation() e StartHideAnimation() parece promissora ("mostrar" para ser usado para expansão, "ocultar" usado para recolher). Uma propriedade ElementAnimator pode ser oferecida no controle com uma implementação de animação padrão. Se nenhuma animação for desejada, a propriedade pode ser definida como nula ou se um controle mais refinado for necessário, apenas uma animação Mostrar ou Ocultar pode ser fornecida ao ElementAnimator.

Não estou muito familiarizado com a API ElementAnimator e parece que ainda não pode ser usada em todos os cenários, pois existe o problema https://github.com/microsoft/microsoft-ui-xaml/issues/166 . No entanto, se ainda houver uma lacuna de funcionalidade, talvez esses itens de trabalho (controle do Expander e ElementAnimator trabalhem para torná-lo utilizável pelo controle do Expander) possam ser sincronizados e projetados juntos.

Hmm, a ideia do ElementAnimator é realmente interessante. Minha preocupação aqui é que isso pode ser muito complicado ou sobredimensionado. Afinal, para o ExpanderControl, precisaríamos fornecer um ElementAnimator personalizado enquanto, de outra forma, poderíamos reutilizar as animações de tema existentes. Além disso, ElementAnimator fornece mais métodos do que o controle expansor realmente precisa, então parece um ajuste um pouco estranho.

Estou certo em pensar que o ElementAnimator é para lidar com deslocamentos para elementos filhos ou contidos que aparecem na tela?

Pode ser um exagero, dependendo do que está dentro do painel que é mostrado como o expansor se expande. Mas se houvesse uma maneira de conectá-lo de alguma forma, se o painel de expansão contendo elementos - pudesse gerar animações filho se o dev adicionar algo ao elemento.

Portanto, o Expander não controla diretamente as transições do elemento filho, mas pode habilitá-las se o desenvolvedor quiser

Sim, se pudéssemos criar animações reutilizáveis ​​aqui, ao mesmo tempo que fornecíamos aos clientes algum nível satisfatório de opções de personalização, valeria a pena explorar. Por exemplo, já vimos pedidos para adicionar animações ao controle TreeView quando um item se expande / recolhe (https://github.com/microsoft/microsoft-ui-xaml/issues/208). Eu imagino que um caso pode ser feito aqui em que um conjunto de animações pode ser construído para ter uma ótima aparência para os controles Expander e TreeView. Que virá automaticamente com um nível de consistência entre os diferentes controles. criando familiaridade visual para o usuário, que também é um argumento convincente.

Eu acho que idealmente, TreeView e NavigationView hierárquico deveriam apenas mudar para o controle Expander quando o controle estiver pronto. Afinal, atualmente ambos os controles precisam lidar exatamente com o mesmo problema que seria resolvido pelo ExpanderControl. Portanto, uma animação compartilhada não faria uma grande diferença para TreeView.

A coisa com ElementAnimator (como eu entendi) é que teríamos que escrever uma nova animação. No entanto, já existem animações integradas que podemos aproveitar para o Expander.

Pode ser um exagero, dependendo do que está dentro do painel que é mostrado como o expansor se expande. Mas se houvesse uma maneira de conectá-lo de alguma forma, se o painel de expansão contendo elementos - pudesse gerar animações filho se o dev adicionar algo ao elemento.

Acho que um dos pontos principais do ElementAnimator era permitir adicionar animações a painéis e coleções, por exemplo, ItemsRepeater. No caso do Expander, este não é realmente o caso, porém, o expander não é um painel que renderiza uma coleção de itens.

No topo da minha cabeça, um redimensionamento para o painel principal com atenuação. Então, um slide e um fade para o (s) objeto (s) que o contém pareceriam corretos.

Se se tornasse uma ampla transição do sistema operacional generalizado com o easing adequado determinado pela equipe de movimento do Fluent Design - isso seria bom.

Marcando @stmoy já que estamos falando de animações.

Obrigado @SavoySchuler por se juntar e fornecer mais contexto sobre os compromissos de nossa equipe - espero que isso ajude a explicar por que estou procurando especificamente exemplos de aplicativos onde a funcionalidade de ExpandDirection é necessária! Para repetir o que Savoy disse, entre em contato comigo diretamente (DMs do Twitter se você precisar de privacidade) se suas necessidades de Expander forem aquelas que não podem ser compartilhadas aqui.

@robloo Obrigado por suas desculpas, eu entendo completamente suas intenções e definitivamente quero que os controles WinUI tenham o escopo definido e sejam desenvolvidos de uma maneira significativa e eficiente. Eu sou novo na equipe e realmente aprecio que a comunidade WinUI seja tão amigável e entusiasmada em discutir o escopo e a implementação do Expander!

Por falar nisso, estou animado para ler esses comentários mais recentes sobre animações!

Depois de ler os comentários relacionados às animações, parece que há três rotas possíveis, em ordem crescente de trabalho:

Sem incluir uma animação de cenário - isso tem o benefício, pois @chingucoding apontou para não desencorajar os desenvolvedores quando seu cenário não funciona ou parece bom com a animação de cenário. O risco aqui é uma possível inconsistência, embora realmente não pareça haver muito "espaço" para inconsistência nesta rota.

@mdtauk propôs uma ExpandTransition e CollapseTransition,

que pode usar a direção definida pela propriedade do controle - o que pode permitir que o dev defina a transição para cada um.

Parece um escopo menor do que usar o ElementAnimator. Isso daria aos desenvolvedores total flexibilidade na configuração das transições?

No topo da minha cabeça, um redimensionamento para o painel principal com atenuação. Então, um slide e um fade para o (s) objeto (s) que o contém pareceriam corretos.

Eu entendo partes disso, mas é difícil para mim visualizar sem, bem, um visual 😄. "Redimensionar para o painel principal" significa que o tamanho do cabeçalho mudaria? Você poderia explicar melhor o que entende por "um slide e esmaecimento para o (s) objeto (s) que o contém"?

@Felix-Dev proposto usando ElementAnimator

A API ElementAnimator com seu StartShowAnimation () e StartHideAnimation () parece promissora ("mostrar" para ser usado para expansão, "ocultar" usado para recolher). Uma propriedade ElementAnimator pode ser oferecida no controle com uma implementação de animação padrão. Se nenhuma animação for desejada, a propriedade pode ser definida como nula ou se um controle mais refinado for necessário, apenas uma animação Mostrar ou Ocultar pode ser fornecida ao ElementAnimator.

@chingucoding observou que

precisaríamos então fornecer um ElementAnimator customizado enquanto, de outra forma, poderíamos reutilizar as animações de tema existentes. Além disso, ElementAnimator fornece mais métodos do que o controle expansor realmente precisa, então parece um ajuste um pouco estranho.

um dos pontos principais do ElementAnimator era permitir adicionar animações a painéis e coleções, por exemplo, ItemsRepeater. No caso do Expander, este não é realmente o caso, porém, o expander não é um painel que renderiza uma coleção de itens.

TreeView e NavigationView hierárquico devem apenas mudar para o controle Expander quando o controle estiver pronto. Afinal, atualmente ambos os controles precisam lidar exatamente com o mesmo problema que seria resolvido pelo ExpanderControl. Portanto, uma animação compartilhada não faria uma grande diferença para TreeView.

Não tenho certeza se TreeView e NavigationView hierárquico têm exatamente o mesmo cenário de animação que Expander, e quando o Expander enviará qualquer conteúdo (não necessariamente texto / botões) nas proximidades e os cenários em que os expansores forem "ajustados" entre si e potencialmente tem lógica para fechar / abrir dependendo da expansão de cada um.

O ElementAnimator é um exagero para animações do Expander, visto que ele se destina a animações de painel / coleção?

@mdtauk propôs uma ExpandTransition e CollapseTransition,

que pode usar a direção definida pela propriedade do controle - o que pode permitir que o dev defina a transição para cada um.

Parece um escopo menor do que usar o ElementAnimator. Isso daria aos desenvolvedores total flexibilidade na configuração das transições?

No topo da minha cabeça, um redimensionamento para o painel principal com atenuação. Então, um slide e um fade para o (s) objeto (s) que o contém pareceriam corretos.

Eu entendo partes disso, mas é difícil para mim visualizar sem, bem, um visual 😄. "Redimensionar para o painel principal" significa que o tamanho do cabeçalho mudaria? Você poderia explicar melhor o que entende por "um slide e esmaecimento para o (s) objeto (s) que o contém"?

Desculpem a demora, tive que fazer essa pequena animação de mock-up.
Ignore os tempos reais da animação, eles são apenas para ilustração. O contorno rosa é o Cabeçalho Expansor - e a Borda Verde é para o Painel Expansor / Conteúdo, etc.

Não tenho certeza se TreeView e NavigationView hierárquico têm exatamente o mesmo cenário de animação que Expander, e quando o Expander enviará qualquer conteúdo (não necessariamente texto / botões) nas proximidades e os cenários em que os expansores forem "ajustados" entre si e potencialmente tem lógica para fechar / abrir dependendo da expansão de cada um.

A questão é: será que o Expander deve aplicar animações? TreeView e Hierarchical NavigationView definitivamente se beneficiariam de ter um controle expansor embutido que cuida da expansão / recolhimento e nos permitiria ter uma experiência mais unificada nessa área. Por exemplo, TreeView não anima nada, enquanto NavigationView hierárquico anima a rotação da divisa.

O ElementAnimator é um exagero para animações do Expander, visto que ele se destina a animações de painel / coleção?

Pode ser que um dos controles que suportam ativamente o ElementAnimator (pelo menos na visualização) é o ItemsRepeater, que lida com grandes painéis que renderizam dezenas de itens. O Expander, por outro lado, não tem um cenário tão complexo, mas sim um único item para mostrar / ocultar.

Uma coisa diferente que notei é que não haveria uma maneira de personalizar onde a divisa seria colocada (esquerda / direita ou superior / inferior). Talvez isso seja útil ter como ponto de personalização? NavigationView coloca a divisa à direita enquanto TreeView a coloca à esquerda. O mesmo vale para expansores existentes no sistema, algumas áreas do aplicativo de configurações o colocam à esquerda enquanto as Notificações, por exemplo, os colocam à direita.

Uma coisa diferente que notei é que não haveria uma maneira de personalizar onde a divisa seria colocada (esquerda / direita ou superior / inferior). Talvez isso seja útil ter como ponto de personalização? NavigationView coloca a divisa à direita enquanto TreeView a coloca à esquerda. O mesmo vale para expansores existentes no sistema, algumas áreas do aplicativo de configurações o colocam à esquerda enquanto as Notificações, por exemplo, os colocam à direita.

Poderíamos introduzir algo como ExpandGlyphPlacementMode com valores como TopLeft, TopRight, BottomCentered (e possivelmente mais (Left, Right, ...)) e uma propriedade adicional de ExpandGlyphPlacementOffset os desenvolvedores poderiam usar para modificar o posição base (definida pelo modo de posicionamento), se necessário.

Além disso, como @mdtauk já notou, APIs para personalizar os glifos de expansão / recolhimento (alguns controles usam > , outros usam v para expandir o glifo) e para controlar a visibilidade do glifo.

Poderíamos introduzir algo como um ExpandGlyphPlacementMode com valores como TopLeft, TopRight, BottomCentered (e possivelmente mais (Left, Right, ...)) e uma propriedade ExpandGlyphPlacementOffset adicional que os desenvolvedores podem usar para modificar a posição base (definida pelo modo de posicionamento), se necessário .

Não tenho certeza se TopLeft, TopRight ... é a escolha certa aqui. Talvez algo como "Início" e "Fim" seja mais adequado aqui?
Em layouts horizontais, Iniciar estaria à esquerda (direita em idiomas RTL), no modo de abertura vertical, seria o topo. "Fim" poderia ser definido em conformidade então. O problema que vejo com TopLeft ... é que ele apresenta muita complexidade (consulte TeachingTip) para poucos benefícios. TopLeft e TopRight seriam iguais se o ExpanderControl fosse aberto à direita. Acho que ter algo como centrado na parte inferior vai parecer um pouco estranho em muitos espaços e ocupar muito espaço.

Além disso, como @ mdtauk (separando a menção para não enviar spam para sua caixa de entrada) já notou, APIs para personalizar os glifos de expansão / recolhimento (alguns controles usam>, outros usam v para expandir o glifo) e para controlar a visibilidade do glifo.

A questão é como conseguir isso. Se quisermos animar o ícone de maneira semelhante ao que o NavigationView hierárquico faz, não seremos capazes de permitir uma API para trocar o glifo expandido e recolhido que poderia ser usado para alternar para v ou> para recolhido. Talvez pudéssemos ter uma API indicando a direção do glifo recolhido?

As ideias para animações parecem muito boas. Deve ser possível ligá-los / desligá-los como a Visualização de lista, et al. O cabeçalho e o glifo também precisam mudar de lado para idiomas RTL automaticamente. No entanto, toda a personalização de glifos parece estar exagerando na engenharia do problema. É impossível criar um estilo que funcione para todos os casos identificados que possuem implementações personalizadas. Em vez disso, assim como o CheckBox e outros controles, o design padrão deve ser o melhor que podemos fazer, mas o estilo padrão deve ser simples o suficiente para reformular. Eu não sei por que todo mundo é tão adverso a reformular os controles, é a solução e é realmente uma grande força de olhar menos controles. Adicionar mais propriedades também está aumentando a carga de manutenção de que tanto ouço falar.

Editar: definir recursos para algumas coisas para melhorar o estilo leve também pode ser uma opção razoável.

Não tenho certeza se TopLeft, TopRight ... é a escolha certa aqui. Talvez algo como "Início" e "Fim" seja mais adequado aqui?
Em layouts horizontais, Iniciar estaria à esquerda (direita em idiomas RTL), no modo de abertura vertical, seria o topo. "Fim" poderia ser definido em conformidade então. O problema que vejo com TopLeft ... é que ele apresenta muita complexidade (consulte TeachingTip) para poucos benefícios.

@chingucoding O NavigationView usa um modo de abertura vertical (já que um NavigationViewItem se expande verticalmente), certo? Como eu poderia definir o glifo à esquerda ou à direita do cabeçalho? Estou lendo seu comentário porque "início" seria no topo, "fim" provavelmente na parte inferior do cabeçalho. Mas não estou vendo uma maneira de especificar se o glifo pode ser colocado no canto superior esquerdo ou no canto superior direito. Eu não deveria ter que usar uma API como ExpandGlyphPlacementOffset para algo que estamos vendo tão comumente.

Acho que ter algo como centrado na parte inferior vai parecer um pouco estranho em muitos espaços e ocupar muito espaço.

Tenho certeza de que já vi exemplos disso na web, em aplicativos, etc ... e é por isso que tive essa ideia. No entanto, seria melhor se os exemplos pudessem ser postados aqui para ver se vale a pena apoiar diretamente ou se deixaríamos isso para reformulação do modelo.

No entanto, toda a personalização de glifos parece estar exagerando na engenharia do problema. É impossível criar um estilo que funcione para todos os casos identificados que possuem implementações personalizadas. Em vez disso, assim como o CheckBox e outros controles, o design padrão deve ser o melhor que podemos fazer, mas o estilo padrão deve ser simples o suficiente para reformular. Eu não sei por que todo mundo é tão adverso a reformular os controles, é a solução e é realmente uma grande força de olhar menos controles.

@robloo Não sou contra a reformulação do modelo, mas olhando os exemplos postados até agora, alguns desenvolvedores usam ">" para o glifo de expansão e outros usam "v" para o glifo de expansão ao expandir verticalmente. O mesmo que para a posição do glifo. O controle Expander deve tornar muito fácil para os desenvolvedores definirem o glifo de acordo com seus desejos. A reformulação do modelo sempre vem com vantagens e desvantagens, principalmente porque você não se beneficiará automaticamente de futuras alterações feitas no modelo de controle no WinUI. Em vez disso, a responsabilidade agora recairá sobre os desenvolvedores para manter seu modelo personalizado.

Devemos identificar cenários de customização comuns e nos esforçar para torná-los o mais acessíveis possível pelo controle Expander.

Veja, por exemplo, este caso de glifos personalizados (encontrados no site da

A personalização do símbolo de glifo significa necessariamente que qualquer animação de glifo embutida deve ser considerada com cuidado. Também é interessante saber: O que seria mais desejado pelos clientes - a capacidade de personalizar facilmente os glifos de acordo com sua preferência ou ter uma animação embutida para o glifo (como visto no NavigationView). Pessoalmente, acho que o primeiro seria mais importante, mas não tenho dados concretos para fazer o backup.

Outro controle Expander é o controle Telerik Expander, que expõe algumas das APIs de personalização que discutimos aqui (como a capacidade de alterar a posição do glifo ou do símbolo de glifo) que também podemos usar como inspiração.

ExpandedGlyph
CollapsedGlyph
Que o desenvolvedor pode substituir conforme achar necessário

GlyphPlacement.Start .End .Above .Below
Pode ser?

Talvez também use o alinhamento de conteúdo para lidar com o cabeçalho preenchendo a largura ou tenha o glifo e o texto agrupados

Para a Central de Notificações, há uma limpeza de todos na mesma linha do expansor, então, como isso seria tratado? Algum tipo de maneira de separar o painel de expansão do cabeçalho de expansão?

@chingucoding O NavigationView usa um modo de abertura vertical (já que um NavigationViewItem se expande verticalmente), certo? Como eu poderia definir o glifo à esquerda ou à direita do cabeçalho? Estou lendo seu comentário porque "início" seria no topo, "fim" provavelmente na parte inferior do cabeçalho. Mas não estou vendo uma maneira de especificar se o glifo pode ser colocado no canto superior esquerdo ou no canto superior direito. Eu não deveria ter que usar uma API como ExpandGlyphPlacementOffset para algo que vemos com frequência.

Isso foi mal formulado no meu final. Com "modo de abertura horizontal", eu quis dizer que a dimensão horizontal é fixa, então o conteúdo é apresentado de forma horizontal. O mesmo para o modo vertical. Além disso, qual é o canto superior esquerdo e o canto inferior esquerdo? Eu diria que o ícone está centralizado, na maioria das vezes o cabeçalho não deve / nem ocupa muito espaço na região em expansão e o canto superior esquerdo e o canto inferior esquerdo acabam sendo quase iguais.

Portanto, para esclarecer, se o expansor se expande na direção vertical, start é para a esquerda (direita em RTL) e end é para direita (esquerda em RTL); na expansão horizontal, start é o topo e end é o fundo. Semelhante ao flex-start e flex-end do CSS.

O Visual Studio usa um ícone centralizado, no entanto, a região do botão de expansão estende todo o controle:

Fechadas:

Expandido:

GlyphPlacement.Start .End .Above .Below
Pode ser?

Parece uma ideia muito legal! Qual seria a aparência de cima e de baixo? Semelhante ao que o Visual Studio faz?

ExpandedGlyph
CollapsedGlyph
Que o desenvolvedor pode substituir conforme achar necessário

Esta seria uma forma de fazer isso, mas não nos permitiria animar o ícone (por exemplo, girando). No entanto, acho que faz mais sentido priorizar a possibilidade de trocar totalmente o ícone do que ter uma animação aqui.

Talvez também use o alinhamento de conteúdo para lidar com o cabeçalho preenchendo a largura ou tenha o glifo e o texto agrupados

100%

Para a Central de Notificações, há uma limpeza de todos na mesma linha do expansor, então, como isso seria tratado? Algum tipo de maneira de separar o painel de expansão do cabeçalho de expansão?

Estou preocupado que este cenário específico possa ser muito complexo para ser alcançado simplesmente com o controle do expansor. O posicionamento dos botões é bastante único, mas mais importante, o cabeçalho e o ícone de expansão não estão na mesma linha, o que seria muito difícil de fazer com um controle de expansão padrão que coloca o cabeçalho e o ícone um ao lado do outro. Aqui está um exemplo para referência:

Não sou contra a reformulação do modelo, mas olhando para os exemplos postados até agora, alguns desenvolvedores usam ">" para o glifo de expansão e outros usam "v" para o glifo de expansão ao expandir verticalmente. O mesmo que para a posição do glifo. O controle Expander deve tornar muito fácil para os desenvolvedores definirem o glifo de acordo com seus desejos.

@Felix-Dev Esta é uma daquelas coisas que deve ser padronizada no sistema de design fluente. É importante que os usuários tenham uma aparência consistente. A única vez que isso deve mudar é se um aplicativo deve fazer isso para atender à sua própria linguagem de design ou se houver um novo caso de uso no qual não pensamos. Nesse caso - re-template.

Edit: Eu perdi seu exemplo Telerik na primeira leitura. Ainda acho que estamos aumentando demais a complexidade e permitindo muitas opções de design que: (1) não serão tão facilmente reconhecidas pelos usuários (2) irão expor muita complexidade que não era historicamente necessária. Claro que há uma linha tênue aqui. Queremos expor funcionalidades suficientes para que os usuários não precisem reformular, mas também não queremos expor tantas funcionalidades que a linguagem de design se torne confusa.

O WPF, ou qualquer outro controle expansor que eu possa imaginar, nunca expôs uma propriedade para controlar isso. Ele realmente faz parte do modo de exibição e deve persistir apenas em XAML. O modelo de visualização (ou seja, DPs do controle, neste caso) não deve saber nada sobre essa escolha de estilo em um controle limpo e sem aparência.

O WPF, ou qualquer outro controle expansor que eu possa imaginar, nunca expôs uma propriedade para controlar isso. Ele realmente faz parte do modo de exibição e deve persistir apenas em XAML. O modelo de visualização (ou seja, DPs do controle, neste caso) não deve saber nada sobre essa escolha de estilo em um controle limpo e sem aparência.

@robloo Uma possibilidade de expor a personalização de glifos seria por meio de um estilo leve. Esses recursos, assim como os DPs, devem ser considerados parte da superfície de API pública de um controle, mas estão muito mais próximos do modelo de controle (a aparência do controle). Portanto, poderíamos expor recursos como ExpanderExpandGlyph e ExpanderCollapseGlyph (o NavigationView, por exemplo, tem um recurso NavigationViewItemExpandedGlyph ).

Expor a personalização do símbolo de glifo dessa forma também pode ser lido como uma recomendação para fornecer elementos de fonte presentes na fonte MDL2, usando, portanto, ícones aprovados pelo Fluent Design. Olhando para a fonte MDL2, ela parece apresentar todos os ícones de glifo de expansão / recolhimento comumente usados ​​que vi em exemplos na web (as divisas diferentes, +/-, +/- em círculos, ...). Embora os desenvolvedores provavelmente ainda possam substituir o FontFamily (fornecido pelo recurso SymbolThemeFontFamily ), nós apenas exporíamos diretamente os ExpanderExpandGlyph , ... recursos como recursos públicos para o controle, portanto, os desenvolvedores irão potencialmente primeiro observe a família de fontes MDL2 se quiser personalizar os ícones (já que essa seria a família de fontes padrão usada pelo Expander para os glifos).

Para os interessados, há também pelo menos uma outra questão ainda não resolvida sobre o quão longe nós, como WinUI, queremos ir para fornecer opções de glifo de personalização fácil quando apenas um conjunto fixo de ícones fará sentido no contexto dado (botões giratórios NumberBox personalização de glifo) : https://github.com/microsoft/microsoft-ui-xaml/issues/2789 Eu sei que pelo menos alguns de vocês já estão cientes desse problema, mas como estou vendo alguns paralelos na discussão aqui e aqui sobre como expor a opção de personalização (glifo), achei que valeria a pena consultar aqui. Talvez a solução encontrada aqui também possa ser aplicada no caso NumberBox para consistência no WinUI.

@Felix-Dev Sua recomendação para um estilo leve faz mais sentido para mim. É o que eu quis dizer com "Editar: definir recursos para algumas coisas para melhorar o estilo leve também pode ser uma opção razoável." alguns comentários acima.

A questão é qual a probabilidade de os desenvolvedores não fornecerem um glifo, mas sim alguma forma de outro ícone, por exemplo, um BitmapIcon ou alguma forma de FontIcon personalizado. Se ícones não glifos não são realmente um ponto de personalização que muitos desenvolvedores usariam, acho que um recurso de estilo leve para o glifo (e talvez um para a fonte do símbolo) usar é a melhor coisa aqui, conforme proposto por @robloo e @ Felix- Dev.

A reformulação do modelo é sempre uma opção, se um glifo ou fonte personalizada não for suficiente.

• Glifos de fonte com Segoe MDL2 ou FluentIcons são os mais prováveis ​​e devem ser o padrão;

• Nenhum glifo também é comum;

• Depois, há caminhos, SVGs que são menos prováveis, mas muito possíveis;

• E então PNGs ou bitmaps completos não são uma opção provável, mas possível para os desenvolvedores.

Qualquer que seja a abordagem usada, provavelmente deve se concentrar nos dois primeiros cenários, mas sempre permitir a reformulação do modelo para o terceiro.

Então, há a possibilidade de ter um ContentPresenter para o glifo e permitir que qualquer coisa seja colocado nele. Mas não tenho certeza de como isso funciona com o VisualStates para mover de recolhido para expandido.

Quanto à animação do ícone - talvez o controle Lottie pudesse ser usado aqui?

Outro pensamento, assim como você tem RadioButton e RadioButtons como um grupo deles ...

Um grupo de expansores deve fazer um controle de acordeão? O que permitiria um comportamento em que apenas um único expansor pode ser expandido por vez?

https://explore.fast.design/components/fast-accordion

A reformulação do modelo é sempre uma opção, se um glifo ou fonte personalizada não for suficiente.

Glifos de fonte com Segoe MDL2 ou FluentIcons são os mais prováveis ​​e devem ser o padrão;

Nenhum glifo também é comum;

Depois, há caminhos, SVGs que são menos prováveis, mas muito possíveis;

E então PNGs ou bitmaps completos não são uma opção provável, mas possível para os desenvolvedores.

Qualquer que seja a abordagem usada, provavelmente deve se concentrar nos dois primeiros cenários, mas sempre permitir a reformulação do modelo para o terceiro.

Retemplar sempre será uma opção, no entanto, é claro que é algo que pode falhar com o tempo se houver (grandes) alterações no controle. Portanto, ter um recurso leve é ​​provavelmente o melhor aqui, já que trocar os glifos (e a fonte do ícone) são os cenários mais comuns.

Então, há a possibilidade de ter um ContentPresenter para o glifo e permitir que qualquer coisa seja colocado nele. Mas não tenho certeza de como isso funciona com o VisualStates para mover de recolhido para expandido.

Usar um ContentPresenter não faz diferença em relação ao recolhimento / expansão, seria apenas um elemento como os outros.

Quanto à animação do ícone - talvez o controle Lottie pudesse ser usado aqui?

A questão é que tipo de animação você deseja ter. A rotação simples pode (e é) já feita sem lottie.

Outro pensamento, assim como você tem RadioButton e RadioButtons como um grupo deles ...

Um grupo de expansores deve fazer um controle de acordeão? O que permitiria um comportamento em que apenas um único expansor pode ser expandido por vez?

Talvez isso pudesse ser um controle separado? Embora existam cenários em que eles podem ser exclusivos um do outro, acho que em muitos casos, realmente não importa se vários estão abertos.

Então, há a possibilidade de ter um ContentPresenter para o glifo e permitir que qualquer coisa seja colocado nele. Mas não tenho certeza de como isso funciona com o VisualStates para mover de recolhido para expandido.

Usar um ContentPresenter não faz diferença em relação ao recolhimento / expansão, seria apenas um elemento como os outros.

Mas seria um ContentPresenter usado por ambos os estados ou um por estado que é trocado / alternado?

Quanto à animação do ícone - talvez o controle Lottie pudesse ser usado aqui?

A questão é que tipo de animação você deseja ter. A rotação simples pode (e é) já feita sem lottie.

As rotações fazem sentido quando o glifo é uma seta / divisa direcional - mas e se for uma lâmpada acendendo e apagando para algum tipo de dica ou cenário de dica? Há uma proposta para um controle de ícone animado generalizado usando Lottie # 2802 - essa situação exigiria isso, mesmo se seu uso padrão / mais comum fosse uma simples rotação de ícone?

Outro pensamento, assim como você tem RadioButton e RadioButtons como um grupo deles ...
Um grupo de expansores deve fazer um controle de acordeão? O que permitiria um comportamento em que apenas um único expansor pode ser expandido por vez?

Talvez isso pudesse ser um controle separado? Embora existam cenários em que eles podem ser exclusivos um do outro, acho que em muitos casos, realmente não importa se vários estão abertos.

Menciono isso apenas porque o Fast Design inclui um controle de acordeão, e é essencialmente o mesmo que um monte de expansores - só que há uma API de comportamento Multi e Único que muda a forma como eles funcionam juntos. Com um controle Expander feito, um Acordeão seria uma próxima etapa lógica e deve ser relativamente fácil de obter com uma propriedade de orientação para substituir as direções individuais.

Então, há a possibilidade de ter um ContentPresenter para o glifo e permitir que qualquer coisa seja colocado nele. Mas não tenho certeza de como isso funciona com o VisualStates para mover de recolhido para expandido.

Usar um ContentPresenter não faz diferença em relação ao recolhimento / expansão, seria apenas um elemento como os outros.

Mas seria um ContentPresenter usado por ambos os estados ou um por estado que é trocado / alternado?

Ambas as opções fazem sentido. Acho que trocar o conteúdo do ContentPresenter é melhor do que trocar o ContentPresenter ou ter dois e ocultar / mostrar um.

Quanto à animação do ícone - talvez o controle Lottie pudesse ser usado aqui?

A questão é que tipo de animação você deseja ter. A rotação simples pode (e é) já feita sem lottie.

As rotações fazem sentido quando o glifo é uma seta / divisa direcional - mas e se for uma lâmpada acendendo e apagando para algum tipo de dica ou cenário de dica? Há uma proposta para um controle de ícone animado generalizado usando Lottie # 2802 - essa situação exigiria isso, mesmo se seu uso padrão / mais comum fosse uma simples rotação de ícone?

Uma animação de rotação seria uma forma de animar e seria fácil de conseguir. Ter um ícone animado em um diferente seria bem diferente. Isso provavelmente também tornaria a API mais complicada (como você suporta esse comportamento? 2 animações e 2 ícones? Ou uma animação que você interrompe?)

Outro pensamento, assim como você tem RadioButton e RadioButtons como um grupo deles ...
Um grupo de expansores deve fazer um controle de acordeão? O que permitiria um comportamento em que apenas um único expansor pode ser expandido por vez?

Talvez isso pudesse ser um controle separado? Embora existam cenários em que eles podem ser exclusivos um do outro, acho que em muitos casos, realmente não importa se vários estão abertos.

Menciono isso apenas porque o Fast Design inclui um controle de acordeão, e é essencialmente o mesmo que um monte de expansores - só que há uma API de comportamento Multi e Único que muda a forma como eles funcionam juntos. Com um controle Expander feito, um Acordeão seria uma próxima etapa lógica e deve ser relativamente fácil de obter com uma propriedade de orientação para substituir as direções individuais.

Certo, entendo. Sim, um controle de acordeão é definitivamente uma boa ideia após o controle do expansor e provavelmente seria muito fácil de implementar!

As rotações fazem sentido quando o glifo é uma seta / divisa direcional - mas e se for uma lâmpada acendendo e apagando para algum tipo de dica ou cenário de dica? Há uma proposta para um controle de ícone animado generalizado usando Lottie # 2802 - essa situação exigiria isso, mesmo se seu uso padrão / mais comum fosse uma simples rotação de ícone?

Uma animação de rotação seria uma forma de animar e seria fácil de conseguir. Ter um ícone animado em um diferente seria bem diferente. Isso provavelmente também tornaria a API mais complicada (como você suporta esse comportamento? 2 animações e 2 ícones? Ou uma animação que você interrompe?)

Esta é uma grande questão e, para ser honesto, é algo para a proposta do Ícone Animado.

Animar o glifo / ícone está bem se for sempre uma seta. Mas meio que bloqueia isso, a menos que você tenha uma maneira fácil de remover ou alterar a própria animação.

Fazer uma animação Lottie giratória mantém a animação padrão, significa um pouco mais de trabalho para implementar, mas é mais flexível ao permitir a alteração do ícone e das animações, se necessário.

A opção mais fácil é simplesmente não ter animação para o glifo. Porém, quanto mais você adiciona, torna-se mais importante substituir ou alterar facilmente.

Olhando pela web, vejo muitos ícones estáticos usados ​​para expandir / recolher glifos em exemplos típicos de IU do Expander. No entanto, no Windows, também temos clientes em potencial desse controle que parecem preferir animações (consulte, por exemplo, NavigationView e notificações do sistema no shell). O movimento é um dos pilares do Fluent Design, então provavelmente faz sentido aqui manter as opções abertas para os clientes que desejam um glifo animado sem a necessidade de refazer o modelo do controle.

Idealmente, se diferentes equipes na MS gostariam de usar um Expander com um glifo animado (ou seja, um glifo de seta animado), o controle forneceria uma opção embutida, portanto, acabamos tendo uma experiência consistente por padrão. Se cada equipe fosse responsável por si mesma pela animação, poderíamos acabar vendo durações de animação diferentes, direções de animação diferentes (ou seja, no sentido horário ou anti-horário), ... Se bem me lembro, a animação do glifo para notificações no O centro de ação é diferente da animação do glifo no NavigationView. Isso deve ser evitado, se possível.

As animações são mais divertidas e ajudam a tornar a interface do usuário mais suave. A codificação permanente em um Storyboard de rotação é a maneira simples de adicionar uma animação, mas se essa animação for difícil de remover ou alterar - talvez usar o controle AnimatedIcon seja uma boa maneira de fazer uma maneira flexível de permitir a personalização.

Não estou dizendo que uma maneira é melhor do que a outra - apenas chamando a atenção aqui, pois está animando um ícone, e esse é o Raison Detra para o novo controle.

E se for reconhecido que os glifos devem ser personalizáveis ​​- a animação de rotação pode nem sempre ser apropriada.

O que animar e o que não animar é uma questão muito difícil. Como Martin já mencionou, uma animação de rotação nem sempre faz sentido. E os ícones animados ainda têm muitas questões em aberto.

Eu acho que seria melhor raspar as animações de glifo / ícone para v1 então, especialmente porque não é muito comum. Uma coisa a reconsiderar é se removermos a animação existente no NavigationView hierárquico para ter uma experiência uniforme. Atualmente, já existe uma inconsistência entre TreeView e h-NavigationView para animar / não animar a alternância do ícone.

Exatamente. Eu não pretendia desencorajar qualquer exploração aqui com meu último parágrafo, mas apenas escrevendo mais uma vez que um dos desafios que enfrentamos aqui é fornecer opções de personalização suficientes fora do "último" - reformulação de modelos - para satisfazer o cliente comum deseja, mas ainda certificando-se de que o controle ajudará a trazer mais consistência ao Windows, em vez de potencialmente menos.

Como já vimos, pode não haver uma solução perfeita aqui, pois o desejo de fornecer personalizações de ícone e suporte de animação (talvez além de animações integradas para consistência) pode facilmente colidir um com o outro.

Pode ser útil atrair clientes em potencial, como o Windows Shell, para ver como eles veem as animações. O 10X supostamente colocará algum foco em animações, e o Shell do Windows e os aplicativos internos do Windows podem ser "clientes" aqui. Se um glifo animado for considerado uma peça importante na experiência geral do usuário que a equipe do Windows está se esforçando para obter 10X, isso pode exigir não "punting" neste desafio por enquanto, mas, em vez disso, oferece suporte para animação na V1.

Eu gostaria de ver uma abordagem consistente para animar ícones, que agora parece ser a proposta do Ícone Animado.

Eu não removeria nenhuma animação de NavigationView, pois é um novo paradigma totalmente independente para WinUI - e parece que a intenção é adicionar animações a todos esses controles semelhantes - então, talvez, quando estiver pronto, o controle pode ser adicionado ao NavigationView

Parece que ElementAnimator é demais para animar o Expander e que ExpandTransition e CollapseTransition seriam suficientes.

@mdtauk obrigado por fazer a animação do mock-up! Eu entendo o que você quis dizer com as animações em expansão e recolhimento.

Acredito que o comportamento do acordeão será alcançado por meio da lógica de nível de lista (em vez de um novo controle Acordeão) com IsExpanded para que os desenvolvedores personalizem isso para diferentes cenários (Ex: onde alguns expansores se fecham e outros podem ser expandidos simultaneamente).

@ Felix-Dev - Eu adicionei o Telerik Expander à proposta, obrigado por compartilhá-lo!

Parece que há um desejo de personalização nas seguintes direções:

Aparência de glifo : o estilo leve parece ser a rota preferida para trocar os glifos e a fonte do ícone, tendo ExpanderExpandGlyph e ExpanderCollapseGlyph . Este nível de personalização é necessário no v1 Expander?

@ Felix-Dev Embora os desenvolvedores provavelmente ainda possam substituir o FontFamily (fornecido pelo recurso SymbolThemeFontFamily), nós apenas exporíamos diretamente o ExpanderExpandGlyph ... assim, os desenvolvedores irão potencialmente primeiro olhar para a família de fontes MDL2 se quiserem personalize os ícones (já que essa seria a família de fontes padrão usada pelo Expander para os glifos).

Animação de glifo : incluindo mudança para um glifo diferente na expansão - o que é parcialmente resolvido com o AnimatedIcon # 2802. Parece que esse nível de personalização não é necessário para o v1 Expander.
@chingucoding declarou e eu tendo a concordar:

Eu acho que seria melhor raspar as animações de glifo / ícone para v1 então, especialmente porque não é muito comum.

Posição do glifo : este nível de personalização é necessário no v1 Expander? Isso é ainda mais complicado se v1 incluir ExpandDirection e a opção de alterar a posição do glifo. @ Felix-Dev descrito

Algo como um ExpandGlyphPlacementMode com valores como TopLeft, TopRight, BottomCentered (e possivelmente mais (Left, Right, ...)) e uma propriedade ExpandGlyphPlacementOffset adicional que os desenvolvedores podem usar para modificar a posição base (definida pelo modo de posicionamento), se necessário.

Espero ter entendido corretamente a grande discussão deste fim de semana - me avise se eu estiver errado em algum lugar! Muito obrigado a todos por seus pensamentos perspicazes sobre isso. 😄

Aparência de glifo
Posição do Glifo

Acho que essas são as personalizações mais fáceis e mais importantes de incluir na V1.

Eu também adicionaria uma maneira de esconder o glifo

Glyph Animation
Transições de estado

Eles podem receber uma prioridade mais baixa se a priorização for necessária e o comportamento e a funcionalidade principais estiverem demorando muito.

Obrigado pela ordem de prioridade @mdtauk!

Eu adicionei uma nova pergunta aberta:

• Como o Expander deve funcionar com o InfoBar? Adicionando funcionalidade de expansão ao InfoBar? Colocando InfoBar como conteúdo de um Expander? O reverso?

Eu imagino que substituiria o conteúdo, mas acho que aqueles que projetam a barra de informações devem fornecer uma especificação de design para uma barra dobrável, que os designers do expansor podem ver.

É uma conversa para se ter

Há um _banco_ de ótimas conversas aqui! Sobre o tema das animações ...

Parece que ElementAnimator é demais para animar Expander, e que ExpandTransition e CollapseTransition seriam suficientes.

Concorde que ElementAnimator é demais para animar o Expander. Pode funcionar se tudo estiver em um ItemsRepeater, mas o ElementAnimator ainda não funciona fora do ItemsRepeater, então precisamos descobrir isso.

Gosto da ideia de ter uma ExpandTransition e CollapseTransition em teoria, mas recebemos muitos comentários de que as APIs de transição são boas na teoria, mas menos boas na prática porque não são personalizáveis, geralmente estão fortemente acopladas aos controles em quais são usados ​​e não acho que possam ser construídos na série WinUI 2.x, pois dependem de ganchos de sistema operacional. Como essas transições específicas não existem, prefiro explorar outras opções do que adicionar à nossa coleção de APIs ThemeTransition.

Além de tudo isso, a área geral de "animações de layout" onde o conteúdo se move como resultado de novos elementos da IU que entram / aumentam / diminuem / saem da página não são bem suportados no Xaml como uma plataforma hoje. Corrigir isso também exigirá o WinUI 3, mas não está no roteiro imediato.

Para o Expander em particular, acho que o curso de ação adequado provavelmente acabará sendo:
1) Codifique a animação de aumentar / diminuir no código do Expander (e considere incluir uma API para desligá-la - embora eu pessoalmente não ache que uma seja necessária)
2) Fornecer orientação aos desenvolvedores de aplicativos sobre como animar o conteúdo em torno do Expander para que o conteúdo abaixo do Expander deslize para baixo em vez de "pular"

Eu não acho que (2) pode ser resolvido geralmente sem "animações de layout", mas provavelmente pode ser contornado usando RepositionThemeAnimation no conteúdo abaixo do Expander.

@stmoy Poderíamos usar PopInThemeAnimation para (1) se quiséssemos ir com os existentes.

Esta proposta foi aprovada para redação de especificações .

Como parte da discussão com a equipe WinUI, determinamos que o Expander poderia ter o escopo definido para oferecer suporte a ExpandDirection para expansão para cima / para baixo na V1. Isso cobre os cenários que vimos para o Expander e estabelece as bases para potencialmente adicionar expansão esquerda / direita no futuro.

Sinta-se encorajado a continuar a discussão aqui, e uma discussão mais detalhada ocorrerá nas especificações e no PR associado assim que estiverem disponíveis. Gostaríamos especialmente de ouvir sua opinião sobre esta questão em aberto:

• Como o Expander deve funcionar com o InfoBar? Adicionando funcionalidade de expansão ao InfoBar? Colocando InfoBar como conteúdo de um Expander? O reverso?

Para o InfoBar, acho que preciso abrir uma proposta separada para mergulhar no que ele precisa especificamente e como ele pode tirar proveito desse controle Expander. Aqui estão algumas das minhas primeiras idéias:

• Um InfoBar precisa personalizar o cabeçalho e o conteúdo / painel do controle Expander. A InfoBar deve mostrar uma mensagem "cortada" no cabeçalho quando recolhida e uma mensagem completa no conteúdo / painel expandido quando aberto.
• Uma InfoBar não _tem_ para permitir o truncamento e a opção deve estar lá para o desenvolvedor escolher o comportamento de empacotamento atual, se necessário, por meio de uma propriedade "shouldTruncate".
• Uma InfoBar pode / deve "tornar-se" um Expander se o conteúdo não couber mais em uma única linha e shouldTruncate estiver definido como true. Implementar isso e entender quando exatamente adicionar o comportamento de expansão é onde fica complicado 😊 MessageBar atenua isso por meio de sua propriedade isMultiline, mas é necessário pensar mais profundamente nesta área.

Acho que também podemos olhar para outros controles no WinUI atualmente que podem se beneficiar desse comportamento do Expander.

Algumas composições iniciais para truncar o InfoBar:

Para implementação, meu pensamento inicial é que um InfoBar deve derivar de um Expander e não ser aninhado dentro do conteúdo do Expander. Pensamentos?

Acho que também podemos olhar para outros controles no WinUI atualmente que podem se beneficiar desse comportamento do Expander.

Algumas composições iniciais para truncar o InfoBar:

Acho que o Expander pode precisar separar o Botão Chevron do Conteúdo que está sendo expandido.

Notificações fazem isso

Também permitiria que o controle InformationBar integrasse seu Expander.

Se você separar isso, isso se torna um comportamento / propriedade? Portanto, se você especificar um elemento de interface do usuário ou botão para essa propriedade, o cabeçalho do expansor não exibirá seu botão?

Para implementação, meu pensamento inicial é que um InfoBar deve derivar de um Expander e não ser aninhado dentro do conteúdo do Expander. Pensamentos?

Se o Expander não puder separar o Conteúdo e o Cabeçalho do Botão Alternar / Divulgar - isso exigiria mais trabalho para a implementação da Barra de Informações.

O controle Expander deve ser o mais flexível possível, especificamente para integração em vários outros controles no futuro, bem como para uso no Shell do Windows

Eu adicionei informações iniciais à especificação do Expander e abri um PR - sinta-se à vontade para continuar a discussão das especificações lá! É PR 100 no repositório de especificações 😄