Expander es muy útil y he estado usando la versión de Windows Community Toolkit desde que se agregó. Sin embargo, no reinventaría demasiado la rueda, en mi opinión, solo transferir el código del kit de herramientas sería perfecto para la versión 1.0.

Otro ejemplo: el ColorPicker con su 'MoreButton' podría usar esto.

¡Muchas gracias por enviar esta propuesta! Voy a hacer algunas ediciones, incluida la diferenciación entre lo que creo que son verdaderos escenarios de Expander y lo que se parece más a los usos de Flyout / MenuFlyout.

Actualicé esta propuesta para incluir más detalles sobre el alcance, una API propuesta y la siguiente pregunta abierta.

• ¿Necesitamos admitir ExpandDirection en un expansor v1? ¿Existen escenarios comunes de aplicaciones en los que Expander debería expandirse en direcciones distintas a la descendente?

¡Me encantaría recibir comentarios sobre cómo encajan o no con sus casos de uso de Expander!

Actualicé esta propuesta para incluir más detalles sobre el alcance, una API propuesta y la siguiente pregunta abierta.

• ¿Necesitamos admitir ExpandDirection en un expansor v1? ¿Existen escenarios comunes de aplicaciones en los que Expander debería expandirse en direcciones distintas a la descendente?

¡Me encantaría recibir comentarios sobre cómo encajan o no con sus casos de uso de Expander!

Parece una función básica del control

Parece una función básica del control

@mdtauk, ¿

Sí, necesitamos expandir la dirección. Hay muchos casos para usarlo y agregarlo sería un cambio rotundo innecesario en la plantilla de control después de una versión v1. La API de expansión no ha cambiado mucho desde WPF y la propuesta aquí ya tiene todas las propiedades / eventos / métodos necesarios. Lo implementaría todo de una vez y podemos terminar con este control. En cuanto al diseño, el kit de herramientas de la comunidad de UWP realizó los cambios necesarios para trabajar mejor con el tacto. Creo que tenemos todas las piezas y no hay necesidad de reinventar nada.

Editar: El kit de herramientas de la comunidad también tiene una propiedad ContentOverlay . Eso podría ser algo para omitir en un V1.

Sí, necesitamos expandir la dirección. Hay muchos casos para usarlo y agregarlo sería un cambio rotundo innecesario en la plantilla de control después de una versión v1.

@robloo ¿Podrías explicar cómo esto sería un cambio radical? Tengo entendido que podríamos evitar que se rompa con V1 con expansión hacia abajo, y V2 podría agregar ExpandDirection y por defecto hacia abajo.

Parece una función básica del control

@mdtauk, ¿

Las aplicaciones de chat que cargan nuevas listas de contenido de abajo hacia arriba son quizás una de ellas.

Más allá de lo esencial muy básico:

• Está colapsado
• Se esta expandiendo
• Está expandido
• Está colapsando

Así como IsEnabled

El siguiente elemento central es dónde expandirse.

• ExpandUp
• Expandir hacia abajo
• Expandir a la izquierda
• Expandir a la derecha

Las aplicaciones de chat que cargan nuevas listas de contenido de abajo hacia arriba son quizás una de ellas.

@mdtauk No entiendo completamente lo que quieres decir con este ejemplo de aplicaciones de chat, ¿podrías explicarlo?
En cuanto a las propiedades, la API propuesta se basa en WPF Expander, por lo que creo que IsExpanded y ExpandDirection las cubrirían. ¿Para qué se usaría IsEnabled? ¿Existe un escenario de aplicación en el que desee deshabilitar un expansor?

Otro ejemplo que he usado en el pasado son las propiedades secundarias editables que normalmente deberían estar ocultas. Estos se muestran en la parte inferior de un editor solo cuando se hace clic en un botón de 'opciones' y el expansor se abre hacia arriba. Realmente depende del diseño que busques. Hay muchos casos útiles para expandir diferentes direcciones y parece innecesario restringir esto artificialmente, especialmente cuando la convención pasada es tan fuerte. No creo que nada de esto sea demasiado difícil en una V1 del control, especialmente porque todos los problemas ya se han resuelto en el kit de herramientas de la comunidad y WPF.

@robloo ¿Podrías explicar cómo esto sería un cambio radical? Tengo entendido que podríamos evitar que se rompa con V1 con expansión hacia abajo, y V2 podría agregar ExpandDirection y por defecto hacia abajo.

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

Supongo que si tiene mucho cuidado al diseñar la plantilla y los estados visuales, es posible que no se rompa. Sin embargo, para hacer eso, realmente necesita diseñar la funcionalidad de todos modos, por lo que también podría implementarla. Todo esto es bastante básico y no hay razón para un plan V2 desde el principio en este control.

Sé que es tentador reinventar la rueda. Pero manténgalo para que las personas que portan aplicaciones de WPF a WinUI puedan hacerlo sin nada más que cambios de código absolutamente necesarios. WinUI debe comenzar a corregir algunos de los errores con UWP.

¿Para qué se usaría IsEnabled? ¿Existe un escenario de aplicación en el que desee deshabilitar un expansor?

@mdtauk Es correcto, esto también debe ser compatible con IsEnabled. Deshabilitar los controles es una convención bastante fuerte cada vez que existe la posibilidad de un cambio de entrada o de estado. Por favor, no nos hagas defender eso.

En las capturas de pantalla anteriores, la seguridad de Windows tiene un expansor para la sección antivirus, así como el menú de navegación izquierdo. Esto muestra un uso muy realista del expansor en más de una dirección que muchas aplicaciones deberían admitir. Mi voto es para apoyar múltiples direcciones en V1.

@robloo

Otro ejemplo que he usado en el pasado son las propiedades secundarias editables que normalmente deberían estar ocultas. Estos se muestran en la parte inferior de un editor solo cuando se hace clic en un botón de 'opciones' y el expansor se abre hacia arriba.

¿Podrías explicar con una captura de pantalla o una aplicación específica dónde sucede esto para que pueda comprender mejor el escenario? Puedo pensar en editores donde un botón de opciones abre una ventana emergente con más botones, pero en los que estoy familiarizado, el otro contenido no se empuja hacia arriba: un comportamiento emergente / flotante en lugar de una expansión.

Supongo que si tiene mucho cuidado al diseñar la plantilla y los estados visuales, es posible que no se rompa. Sin embargo, para hacer eso, realmente necesita diseñar la funcionalidad de todos modos, por lo que también podría implementarla. Todo esto es bastante básico y no hay razón para un plan V2 desde el principio en este control.
Sé que es tentador reinventar la rueda. Pero manténgalo para que las personas que portan aplicaciones de WPF a WinUI puedan hacerlo sin nada más que cambios de código absolutamente necesarios.

Estoy de acuerdo con usted en que la migración de aplicaciones de WPF a WinUI debería ser lo más sencilla posible. En una discusión con el equipo de WinUI, se mencionó que una V1 con alcance para expandirse hacia abajo acortaría el tiempo de desarrollo y haría que Expander esté disponible para los desarrolladores antes (ya que los escenarios para Expander hasta ahora han sido todos hacia abajo), y una V2 planificada podría agregar ExpandDirection poco después. (Editaré la pregunta abierta para tener este contexto adicional) ¡Es por eso que espero entender si hay casos de uso específicos que los desarrolladores tienen para el expansor no descendente! 😄

Deshabilitar los controles es una convención bastante fuerte cada vez que existe la posibilidad de un cambio de entrada o de estado. Por favor, no nos hagas defender eso.

Gracias por explicar esto, ¡tiene mucho sentido que deshabilitar el cambio de estado sea una característica deseada para este tipo de control!

En las capturas de pantalla anteriores, la seguridad de Windows tiene un expansor para la sección antivirus, así como el menú de navegación izquierdo. Esto muestra un uso muy realista del expansor en más de una dirección que muchas aplicaciones deberían admitir. Mi voto es para apoyar múltiples direcciones en V1.

@JustABearOz Creo que el menú de navegación de la izquierda es NavigationView , en realidad. 😃 Estoy de acuerdo en que la sección antivirus es un escenario expansor, en este caso expandiéndose hacia abajo. ¡Me encantaría saber cualquier caso de uso específico que tenga para el expansor no descendente!

@ kat-y Ok, eso elimina la necesidad de izquierda / derecha, pero hay 2 ejemplos en ventanas que parecen expandirse y que podrían aplicarse fácilmente a las aplicaciones:
1: La captura de pantalla anterior con el menú de acciones rápidas. Estoy bastante seguro de que eso se expande.
2: En Windows, el calendario emergente de la bandeja del sistema tiene una sección que se expande para mostrar la agenda / citas.

¿Es posible admitir Up / Down para V1 en lugar de solo Down?

1: La captura de pantalla anterior con el menú de acciones rápidas. Estoy bastante seguro de que eso se expande.

@JustABearOz ¡Muchas gracias por traer estos ejemplos! Para 1: creo que este es un caso de borde interesante: la expansión es 'hacia abajo' desde el 'encabezado' (el botón de expansión), pero el control en sí está posicionado en la parte inferior de la superficie, por lo que el encabezado (y el contenido expandido) tiene que 'desplazarse' hacia arriba (¡de lo contrario se saldría de la pantalla!). Parece una buena manera de manejar tener un elemento en expansión en la 'parte inferior' de una aplicación, ¿está de acuerdo?

2: En Windows, el calendario emergente de la bandeja del sistema tiene una sección que se expande para mostrar la agenda / citas.
¿Es posible admitir Up / Down para V1 en lugar de solo Down?

Estoy de acuerdo con usted, este es un escenario en el que el encabezado está en la parte inferior del área y se expande hacia arriba. En este caso, el expansor del calendario (y la ventana emergente en su conjunto) está vinculado a la barra de tareas: ¿ha encontrado escenarios en aplicaciones donde los expansores tienen un posicionamiento vinculado similar que necesita una expansión ascendente?

@ kat-y No quiero ofender, pero siento que tenemos que volver a explicar cosas que se conocieron hace 15 años. No entiendo por qué nos pide que demos ejemplos de dirección de expansión en el uso en el mundo real. Espero que internamente tenga que llevar esto a revisión de especificaciones y defenderlo ante la gerencia. Pero la explicación puede ser simplemente (1) usted necesita capacitar a los usuarios para que logren sus objetivos de diseño, no le corresponde a Microsoft decir qué es / no es posible hacer con los controles, depende de los desarrolladores / diseñadores de aplicaciones descubrir qué es lo mejor para su caso de uso (un concepto crítico para controles sin apariencia) (2) Lo más importante es que esta no es una idea nueva en absoluto. Está copiando una API existente en esta área y necesita mantener la compatibilidad de la aplicación. Nuevamente, si se tratara de una idea nueva, entendería mejor por qué tenemos que defenderla: es bueno asegurarse de que las funciones sean útiles antes de invertir tiempo en ellas.

Aparte del encabezado, hay literalmente dos propiedades en este control y si fuera C # podría escribirlo en unas pocas horas usando la base WCT. Dedicaremos más horas hombre a hablar de ello que a implementarlo tal como existe hoy en WPF / WCT.

Gracias @robloo por el aporte, me comunico con el equipo de WinUI para discutir cómo podemos hacer que estas propuestas sean más sólidas inicialmente cuando existen en otras bibliotecas de terceros como Toolkit. Definitivamente creo que debería ser parte de la plantilla de problemas mencionar ejemplos existentes.

FYI @ranjeshj @ryandemopoulos @stmoy

@robloo ¡ Gracias por ser honesto conmigo! Entiendo que los desarrolladores de aplicaciones deberían poder determinar qué se adapta mejor a su caso de uso, y que la compatibilidad de las aplicaciones es importante. ¡Espero que la discusión con @ michael-hawker y el equipo de WinUI nos ayude a avanzar de manera productiva en el alcance de Expander!

Anteriormente, no tenía ningún ejemplo concreto de expansores que se usaran en dirección no descendente. Traeré cualquier ejemplo de la comunidad de WinUI (incluido el calendario flotante que señaló @justABearOz ) y todo lo que aprenda de Michael a las discusiones con el equipo de WinUI como evidencia para mantener ExpandDirection en v1 de Expander.

Actualicé la propuesta con una lista de controles de Expansor que conozco; avíseme si me he perdido algo.

• WPF
• Kit de herramientas de la comunidad de Windows
• Interfaz de usuario de Telerik
• Xamarin.Forms
• Syncfusion.XForms.Expander

He echado un vistazo tanto al código fuente de WPF como al código fuente de WCT. Estoy seguro de que esto también se puede implementar en WinUI en unas pocas horas. El control debe seguir la implementación de WCT de lo que he visto, aunque la propiedad ContentOverlay probablemente debería cambiarse de nombre o dejarse fuera de 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 ambas fuentes son de Microsoft y del MIT con licencia, deberían ser la base, no empiece desde cero. Xamarin Forms no se alinea con los conceptos de WPF-> WinUI, por lo que probablemente debería ignorarse (tampoco hay ninguna funcionalidad adicional). Las soluciones de terceros tampoco tienen ideas nuevas e innovadoras de lo que he visto. Este control ha resistido en gran medida la prueba del tiempo.

@robloo ¡ Gracias por ser honesto conmigo! Entiendo que los desarrolladores de aplicaciones deberían poder determinar qué se adapta mejor a su caso de uso, y que la compatibilidad de las aplicaciones es importante. ¡Espero que la discusión con @ michael-hawker y el equipo de WinUI nos ayude a avanzar de manera productiva en el alcance de Expander!

Anteriormente, no tenía ningún ejemplo concreto de expansores que se usaran en dirección no descendente. Traeré cualquier ejemplo de la comunidad de WinUI (incluido el calendario flotante que señaló @JustABearOz ) y cualquier

Bueno, mi punto es que realmente no debería haber demasiadas discusiones sobre esto. Elijo expresar mis frustraciones aquí, ya que este control es un ejemplo perfecto. El nuevo control de buscapersonas o los controles de pan rallado necesitan más supervisión y es importante seguir el proceso. Sin embargo, la sobrecarga de un gran proceso se muestra aquí y nuevamente, pasará muchas más horas de trabajo haciendo papeleo sin valor agregado y discusiones que simplemente implementando el control de WCT. También tengo que ver que el equipo de WinUI use otro trabajo previo, lo cual es algo preocupante. No es necesario rediseñar la plantilla de control XAML.

Bienvenido al proyecto WinUI @ kat-y: Xaml tiene una larga historia, pero puede ser un poco peculiar para los nuevos. Si bien WinUI es una oportunidad para repensar cómo funcionan las cosas, en este caso, el expansor es un control relativamente simple y, por lo tanto, un simple movimiento de WPF a WinUI debería ser suficiente.

@robloo No estoy de acuerdo con su afirmación de que no es necesario rediseñar la plantilla de control XAML. WPF AFAIR tiene una serie de elementos similares a los de cromo que estarían fuera de lugar en WinUI / Fluent.

Manejo de Chevron y tamaños de destino táctiles, así como el uso de tamaños de escala de fuente. El Chevron debería ser fácil de quitar o agregar.

Este ejemplo tiene un cheurón en línea con el texto.

Este ejemplo no tiene ningún galón

Este ejemplo tiene un chevron de cara anterior

En cuanto a la implementación, debe haber una transición animada al abrir y cerrar, a menos que el usuario haya desactivado las animaciones, entonces solo cambia de estado.

En cuanto a la implementación, debe haber una transición animada al abrir y cerrar, a menos que el usuario haya desactivado las animaciones, entonces solo cambia de estado.

Estaba a punto de preguntar sobre animaciones. ¿Debería haber una forma de deshabilitarlos para el control, por ejemplo, en escenarios donde animar diseños sería demasiado costoso? No todos los usuarios / desarrolladores quieren animaciones para cosas como las que pueden parecer un poco insensibles o simplemente no deseadas (por ejemplo, TreeView). No tener que volver a diseñar el control para personalizar ese punto podría ser mejor. Otra cosa que podría ser personalizable es la duración de la animación, en algunos casos las animaciones cortas son mejores que las más largas.

Gracias por todas las excelentes discusiones. Algunos pensamientos

• Tendremos que actualizar la plantilla como menciona @mdtauk para tener en cuenta el nuevo diseño, así como las oportunidades para reducir los elementos / mejorar el rendimiento si es posible.
• IsEnabled se hereda de Control, por lo que esperaría que funcione.

En cuanto a la implementación, debe haber una transición animada al abrir y cerrar, a menos que el usuario haya desactivado las animaciones, entonces solo cambia de estado.

Estaba a punto de preguntar sobre animaciones. ¿Debería haber una forma de deshabilitarlos para el control, por ejemplo, en escenarios donde animar diseños sería demasiado costoso? No todos los usuarios / desarrolladores quieren animaciones para cosas como las que pueden parecer un poco insensibles o simplemente no deseadas (por ejemplo, TreeView). No tener que volver a diseñar el control para personalizar ese punto podría ser mejor. Otra cosa que podría ser personalizable es la duración de la animación, en algunos casos las animaciones cortas son mejores que las más largas.

Creo que algunos controles tienen una propiedad de transición a la que se podría asignar. Entonces, si se incluyó un guión gráfico no animado como un recurso, se podría aplicar y eso lo maneja sin ningún tipo de reemplazo.

Tendría que anular la transición cuando la configuración del sistema apague las animaciones.

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

También con la propiedad IsEnabled, debe haber un estado Disabled. ¿Debería haber un Deshabilitado expandido y Deshabilitado contraído, o Deshabilitado siempre está contraído?

Punto interesante sobre animaciones. Apagamos todas las animaciones con la configuración del sistema, pero no creo que expongamos las perillas para apagar las animaciones más allá de la re-plantilla actual.

Punto interesante sobre animaciones. Apagamos todas las animaciones con la configuración del sistema, pero no creo que expongamos las perillas para apagar las animaciones más allá de la re-plantilla actual.

Creo que podría agregar un estilo que sobrescriba la colección Transition con un valor nulo en el caso de que desee desactivar las animaciones, asumiendo que hay una colección Transition para sobrescribir.

Incluyendo ExpandTransition y CollapseTransition , que pueden usar la dirección establecida por la propiedad del control, lo que podría permitir al desarrollador establecer la transición para cada uno.

Me gusta la idea, pero no creo que hoy exista una forma de crear transiciones de temas personalizados que limitarían la capacidad de personalización. Sin embargo, esto permitiría deshabilitarlo fácilmente eliminándolo.

También con la propiedad IsEnabled, debe haber un estado Disabled. ¿Debería haber un Deshabilitado expandido y Deshabilitado contraído, o Deshabilitado siempre está contraído?

¿Por qué no reflejar el control TreeView donde puede usar las propiedades IsExpanded y IsEnabled para crear cualquier combinación que necesite de las dos? Si deshabilitado expandido funciona mejor en algún caso, eso se puede hacer. Si necesita discapacitados colapsados, eso también es posible de esta manera.

@robloo No estoy de acuerdo con su afirmación de que no es necesario rediseñar la plantilla de control XAML. WPF AFAIR tiene una serie de elementos similares a los de cromo que estarían fuera de lugar en WinUI / Fluent.

@mdtauk Bueno, mi recomendación fue que "deberíamos seguir la implementación de WCT" aquí: https://docs.microsoft.com/en-us/windows/communitytoolkit/controls/expander. Ya se realizaron los cambios de diseño para adaptarse al tacto y una interfaz más moderna. Por supuesto, nadie puede hacer diseños tan buenos como tú, así que estoy seguro de que hay margen de mejora. Seguir cambiando el 'diseño' no requeriría rediseñar la plantilla para admitir todas las direcciones de expansión. WCT debería ser la base y luego si tenemos un nuevo estilo para aplicar, muy bien, se puede hacer rápidamente pero no desde cero.

@robloo No estoy de acuerdo con su afirmación de que no es necesario rediseñar la plantilla de control XAML. WPF AFAIR tiene una serie de elementos similares a los de cromo que estarían fuera de lugar en WinUI / Fluent.

@mdtauk Bueno, mi recomendación fue que "deberíamos seguir la implementación del WCT" aquí ...
Supuse que no querías hacer cambios con respecto al XAML de la versión de WPF

Pero sigo pensando que el equipo de diseño de WinUI deberá aprobarlo y sus variantes, aunque solo sea para confirmar la especificación que se incluirá en los kits de herramientas de figma.

@ kat-y Si eres nuevo en el proyecto, me disculpo si estaba sonando duro. Estoy de acuerdo con mis puntos anteriores sobre cómo se puede mejorar la velocidad del proyecto en algunas áreas, lo que seguramente es necesario. Además, cómo deberíamos usar lo que ya se ha hecho en el pasado y probado en batalla durante los últimos 15 años. Por supuesto, nada de esto está dirigido personalmente a usted ni a nadie. Es un problema general 'hinchado' que he visto con Microsoft durante años, donde los equipos necesitan ser más optimizados y reequilibrados a favor de más codificación / menos gestión de proyectos. Tan buenos como los planes son nada mejor que ensayo y error, por lo que la velocidad de iteración gana al final.

@ranjeshj @ michael-hawker ¿Por qué no utilizar lo que ya se ha hecho en la caja de herramientas de la comunidad? Esta no es la primera vez que el equipo de WinUI parece estar adoptando un enfoque nuevo. Eso duplica innecesariamente el trabajo y provoca fragmentación en el peor de los casos. La versión WCT ya se basaba en las ideas de WPF e hizo los cambios "modernos" necesarios.

@ranjeshj @ michael-hawker ¿Por qué no utilizar lo que ya se ha hecho en la caja de herramientas de la comunidad? Esta no es la primera vez que el equipo de WinUI parece estar adoptando un enfoque nuevo. Eso duplica innecesariamente el trabajo y provoca fragmentación en el peor de los casos. La versión WCT ya se basaba en las ideas de WPF e hizo los cambios "modernos" necesarios.

El kit de herramientas de la comunidad está en C #, creo, y WinUI requiere código C / C ++.

Además, el equipo de diseño de WinUI no tenía nada que decir con la versión de Toolkit, por lo que las necesidades de los equipos de diseño de Windows y App pueden tener necesidades específicas si van a adoptar el control sobre sus soluciones personalizadas.

El kit de herramientas de la comunidad está en C #, creo, y WinUI requiere código C / C ++.

Traducir código a / desde C # y C ++ / WinRT es relativamente trivial. Especialmente para el expansor donde ya miré el código https://github.com/windows-toolkit/WindowsCommunityToolkit/tree/master/Microsoft.Toolkit.Uwp.UI.Controls/Expander. La gran mayoría de la complejidad se encuentra en XAML, que se puede usar 1: 1 en WinUI siempre que no se usen extensiones WCT. Podría portar este código a C ++ yo mismo si fuera necesario.

Además, el equipo de diseño de WinUI no tenía nada que decir con la versión de Toolkit, por lo que las necesidades de los equipos de diseño de Windows y App pueden tener necesidades específicas si van a adoptar el control sobre sus soluciones personalizadas.

Para puntos específicos, sí. Sin embargo, para la funcionalidad de control general no estoy de acuerdo. El WCT ya nos haría un 95% completo y un 100% completo en funcionalidad. Cualquier cambio de diseño aplicado en la parte superior sería trivial.

@robloo ¿Podrías explicar qué piezas de funcionalidad son diferentes? La API propuesta anteriormente coincide muy de cerca con WPF / WCT mientras intenta mantener la coherencia con los patrones existentes en WinUI.

@ranjeshj Es posible que no

Se mencionó que ExpandDirection puede no ser compatible con la primera versión de este control. Eso parece un problema para un expansor que tiene un largo historial con esta funcionalidad. Entonces parecía que teníamos que justificar por qué esta función es necesaria.

Sugerí usar el WCT como base para implementar rápidamente esto con dirección de expansión. No es necesario reinventar la rueda, ya que solo se necesita un puerto de C # -> C ++ (y el código subyacente es muy pequeño para esto) mientras se copia y pega la plantilla XAML. Eso implementaría toda la funcionalidad que necesitaríamos y evitaría preocupaciones de que no hay tiempo suficiente para agregar ExpandDirection. Este enfoque nos daría un control completamente funcional. Luego, cualquier cambio de diseño / estilo se podría realizar en la parte superior según @mdtauk o la sugerencia de cualquier otra persona. No entiendo (1) Por qué ExpandDirection está potencialmente en la tabla de cortar para V1 (2) Por qué si el tiempo es una limitación, no usamos el código existente.

Sí, mis frustraciones por el desarrollo de WinUI 3 en general se están extendiendo a algunos lugares y me disculpo por eso.

@robloo No se trata de que algo esté en la

Al priorizar qué características son esenciales para ser incluidas en una V1, y luego en una V2, solo estarán allí las propiedades y comportamientos básicos y esenciales, y no las cosas heredadas que no se usan comúnmente.

Microsoft parece determinar qué características agregar en función de las necesidades y deseos del cliente, no solo alcanzar la paridad con los marcos más antiguos.

Así que no es _justificar_, sino simplemente tratar de entender qué hacen los desarrolladores con estos patrones de control en su interfaz de usuario.
El hecho de que Windows Shell por sí solo tenga varias versiones de un patrón de control de expansión, sería una razón suficientemente clara para incluirlo. Y el hecho de que cada implementación se vea diferente, si no se comporta de manera diferente, es razón suficiente para que el equipo de diseño consolide el diseño de control para satisfacer las necesidades de los equipos internos.

@mdtauk Como siempre, haces buenos puntos. Sin embargo, debo estar en desacuerdo con esta filosofía de una manera clave si es realmente el enfoque que está tomando Microsoft. Para que WinUI tenga éxito, debe tener sentido para los desarrolladores de aplicaciones existentes. Estoy tratando de evitar otro escenario de UWP, ya que todos sabemos que UWP nunca despegó. Los desarrolladores que Microsoft necesita convencer para que se acerquen a WinUI, al igual que antes UWP, son desarrolladores de WPF. Una de las razones por las que las aplicaciones de WPF nunca dieron el salto a UWP es porque UWP, especialmente cuando se lanzó por primera vez, era un equivalente muy pobre en varias áreas clave de funcionalidad. Es por eso que cuando vi que faltaban esquinas redondeadas en la hoja de ruta, comencé a recordar la pesadilla de UWP (las esquinas redondeadas fundamentales para WPF se dejaron fuera de UWP durante más tiempo). La prioridad número 1 debe ser para una experiencia de transferencia fluida proveniente de AMBOS WPF y UWP y, honestamente, WPF probablemente debería ser una prioridad más alta ya que hay muchas más aplicaciones allí y Microsoft se está enfocando claramente en casos de escritorio con WinUI primero. Así que, de nuevo, tenemos que tener mucho cuidado y evitar activamente reinventar la rueda.

Y el hecho de que cada implementación se vea diferente, si no se comporta de manera diferente, es razón suficiente para que el equipo de diseño consolide el diseño de control para satisfacer las necesidades de los equipos internos.

Siempre he entendido que es posible que sea necesario modificar el diseño. Sin embargo, el uso de conceptos de control sin apariencia es un problema diferente al de ExpandDirection. Si necesitamos modernizar más el diseño o hacerlo más útil en algunos casos, genial, debería ser relativamente trivial. Al final del día, también se puede cambiar la plantilla por completo para aquellos que necesitan un control preciso.

Punto interesante sobre animaciones. Apagamos todas las animaciones con la configuración del sistema, pero no creo que expongamos las perillas para apagar las animaciones más allá de la re-plantilla actual.

Sin embargo, para ser justos, casi ningún control usa animaciones. TreeView y NavigationView esencialmente usan un expansor, pero ambos no usan animaciones para expandir / contraer. La mayoría de los controles que utilizan animaciones suelen depender de ellos, por ejemplo, ProgressBar o ProgressRing. Sin embargo, Expander no depende de él, sería más "bueno tenerlo". Otro ejemplo es que algunas personas no usaron el control WCT Expander porque no les gustó la animación. Si queremos incluir a tantas personas como sea posible, tener una manera fácil de deshabilitar animaciones no deseadas lo haría más fácil.

Creo que podría agregar un estilo que sobrescriba la colección Transition con un valor nulo en el caso de que desee desactivar las animaciones, asumiendo que hay una colección Transition para sobrescribir.

Pero, ¿sería esta una forma común de deshabilitar / habilitar eso? La mayoría de las veces, cuando proporcionamos varios estilos, difieren más drásticamente que una sola animación, por ejemplo, AccentColorButtonStyle o RevealButtonStyle.

Incluyendo ExpandTransition y CollapseTransition, que pueden usar la dirección establecida por la propiedad del control, lo que podría permitir al desarrollador establecer la transición para cada uno.

¡Realmente me gusta esta idea!

Me gusta la idea, pero no creo que hoy exista una forma de crear transiciones de temas personalizados que limitarían la capacidad de personalización. Sin embargo, esto permitiría deshabilitarlo fácilmente eliminándolo.

Eso también me preocupa. con la API ExpandTransition y CollapseTransition sin ninguna transición de tema personalizada, esto está cerca de tener un "ExpendTransitionEnabled" y "CollapseTransitionEnabled".

@robloo Si desea conversar sobre las frustraciones relacionadas con el desarrollo de WinUI 3, le invito a que me escriba (mi Twitter y mi correo electrónico del trabajo están en mi perfil de GitHub). No soy del todo consciente de sus frustraciones actuales, pero en general soy una buena persona para comenzar con los temas relacionados con el desarrollo o la participación de los clientes o la comunidad, así como he dirigido un número significativo de nuestros grupos focales durante el último año. que cubrieron las consideraciones que ha enumerado sobre herramientas, paridad de funciones, etc.

Notaré que nuestra hoja de ruta es extremadamente ajustada, por lo que no puedo prometer que tendré la capacidad de realizar los cambios que desea ver, pero siempre es útil para mí saber qué se podría hacer para brindarle un mejor apoyo como cliente y / o colaborador de WinUI, por lo que el peor resultado de caso es que al menos sus necesidades estén bien consideradas por nuestro equipo en el futuro. En el mejor de los casos, supongo que dependerá de lo que estés buscando. ¿Charlemos? 😄

@mdtauk Gracias por tu apoyo para aclarar, ¡siempre estás bien sintonizado! Diré que claramente hay MUCHO en nuestro plato y que los equipos están comprometidos a ser lo más ágiles y efectivos posible para tratar de lograr el progreso más significativo e impactante en todas las áreas. Para continuar invirtiendo en nuevos controles / funciones entre todas las demás áreas de progreso continuo, es necesario que los miembros de nuestro equipo como @ kat-y desarrollen especificaciones de requisitos _muy_ precisas, ya que lo peor para nosotros sería arrojar una parte de nuestros recursos limitados a una perilla o API que en realidad no tiene un uso amplio, ya que no solo existe el costo de desarrollo por adelantado, sino también el costo de mantenimiento continuo después. Acabo de analizar este hilo a la ligera, pero es justo para @ kat-y, especialmente como nuevo miembro del equipo, querer ser perfectamente nítido para garantizar que haya un escenario real en una aplicación real que necesite la funcionalidad solicitada ( tanto por la razón indicada como también para asegurarnos de que tenemos socios de validación de vista previa que pueden ayudar a garantizar que todas las funciones desarrolladas funcionen según lo requerido en entornos de producción que brindan cobertura de casos extremos). Es posible que el cumplimiento de esta aspiración no siempre se transmita públicamente, como en los casos en que los socios de validación son privados (y puede comunicarse con @ kat-y directamente si sus necesidades no son aptas para publicarse aquí. en este momento), pero esto ha sido un precedente en todas nuestras versiones de control WinUI 2+.

Espero que esto haya ayudado Mi objetivo es devolver este hilo a @ kat-y y los temas de Expander en cuestión, pero comuníquese directamente si hay más que pueda responder o si hay comentarios que le gustaría que se consideraran. ¡Gracias a ambos por todo el trabajo, la pasión y la energía que han puesto en este hilo y en WinUI! 😄

@mdtauk Como siempre, haces buenos puntos. Sin embargo, debo estar en desacuerdo con esta filosofía de una manera clave si es realmente el enfoque que está tomando Microsoft.

No estaba comentando si estoy de acuerdo o no con el enfoque, solo que desde mi tiempo aquí y viendo cómo se evalúan los repositorios, así es como creo que el equipo está trabajando en esto.

(tanto por el motivo indicado como también para asegurarnos de que tenemos socios de validación de vista previa que pueden ayudar a garantizar que todas las funciones desarrolladas funcionen según lo requerido en entornos de producción que brindan cobertura de casos extremos). Es posible que el cumplimiento de esta aspiración no siempre se transmita públicamente, como en los casos en que los socios de validación son privados (y puede comunicarse con @ kat-y directamente si sus necesidades no son aptas para publicarse aquí. en este momento), pero esto ha sido un precedente en todas nuestras versiones de control WinUI 2+.

Creo que usar las propias aplicaciones de Microsoft y Shell como ejemplos es más probable que genere reconocimiento, ya que muestra dónde había una necesidad interna de algo, que no existía o no era adecuado para su propósito, hasta el punto en que tenían que hacerlo ". rodar los suyos ", pero, por supuesto, las grandes bestias como Netflix, Facebook, etc. que crean aplicaciones para Windows, también pedirán controles y otros bits.

WinUI no se trata solo de alcanzar la paridad con WPF, MFC, CommonControls, WinForms, etc. (pero el uso más común de estos controles heredados sin un equivalente moderno debe considerarse seriamente)

El hecho de que se propongan barras de migas de pan y expansores es una señal de que esto está comenzando a suceder, en mi opinión. Y cada control o adición de API debe evaluarse y "justificarse" en un entorno ideal, del mismo modo que los diseñadores de aplicaciones siempre deben reevaluar sus UI y UX para asegurarse de que sean adecuadas para su propósito. - En este caso, puede parecer obvio, pero aún deberíamos presentar ejemplos en los que se utilizan este patrón y estas API, para fortalecer el caso de inclusión.

Acerca de las animaciones: ¿Qué tal usar un enfoque de ElementAnimator como las ofertas de ItemsRepeater? La API de ElementAnimator con sus StartShowAnimation() y StartHideAnimation() parece prometedora ("mostrar" se usa para expansión, "ocultar" se usa para colapsar). Se podría ofrecer una propiedad ElementAnimator en el control con una implementación de animación predeterminada. Si no se desea ninguna animación, la propiedad se puede establecer en nula o si se necesita un control más detallado, solo se puede proporcionar una animación Mostrar u Ocultar al ElementAnimator.

No estoy muy familiarizado con la API de ElementAnimator y parece que aún no se puede utilizar en todos los escenarios, ya que existe el problema https://github.com/microsoft/microsoft-ui-xaml/issues/166 . Sin embargo, si todavía hay una brecha de funcionalidad, quizás estos elementos de trabajo (control de expansor y ElementAnimator funcionan para que sea utilizable por el control de expansor) podrían sincronizarse y diseñarse juntos.

Hmm, la idea de ElementAnimator es realmente interesante. Mi preocupación aquí es que esto podría ser demasiado complicado o diseñado en exceso. Después de todo, para ExpanderControl, necesitaríamos proporcionar un ElementAnimator personalizado mientras que, de lo contrario, podríamos reutilizar las animaciones de temas existentes. Además, ElementAnimator proporciona más métodos de los que el control del expansor realmente necesita, por lo que parece un ajuste un poco incómodo.

¿Estoy en lo cierto al pensar que ElementAnimator es para manejar compensaciones para elementos secundarios o contenidos que aparecen en la pantalla?

Puede ser excesivo dependiendo de lo que haya dentro del panel que se muestra como el expansor, se expande. Pero si hubiera una forma de conectarlo de alguna manera, si el panel en expansión que contiene elementos, podría generar animaciones secundarias si el desarrollador agrega algo al elemento.

Por lo tanto, el expansor no controla directamente las transiciones de los elementos secundarios, pero podría habilitarlas si el desarrollador quiere

Sí, si pudiéramos crear aniamciones reutilizables aquí, sin dejar de ofrecer a los clientes un nivel satisfactorio de opciones de personalización, valdría la pena explorar esto. Por ejemplo, ya hemos visto solicitudes para agregar animaciones al control TreeView cuando un elemento se expande / colapsa (https://github.com/microsoft/microsoft-ui-xaml/issues/208). Me imagino que aquí se puede argumentar que un conjunto de animaciones podría construirse para verse bien tanto para el control Expander como para el TreeView. Que vendrá automáticamente con un nivel de coherencia entre los diferentes controles. creando familiaridad visual para el usuario, que también es un argumento convincente.

Creo que idealmente, TreeView y NavigationView jerárquico deberían simplemente cambiar al control Expander cuando el control esté listo. Después de todo, actualmente ambos controles necesitan manejar exactamente el mismo problema que sería resuelto por ExpanderControl. Entonces, una animación compartida no haría una gran diferencia para TreeView.

Lo que pasa con ElementAnimator (como lo entendí) es que tendríamos que escribir una nueva animación. Sin embargo, ya hay animaciones integradas que podríamos aprovechar para Expander.

Puede ser excesivo dependiendo de lo que haya dentro del panel que se muestra como el expansor, se expande. Pero si hubiera una forma de conectarlo de alguna manera, si el panel en expansión que contiene elementos, podría generar animaciones secundarias si el desarrollador agrega algo al elemento.

Creo que uno de los puntos principales de ElementAnimator fue permitir agregar animaciones a paneles y colecciones, por ejemplo, ItemsRepeater. Sin embargo, en el caso de Expander, este no es realmente el caso, el expansor no es un panel que representa una colección de elementos.

En la parte superior de mi cabeza, un cambio de tamaño para el panel principal con suavizado. Luego, un deslizamiento y un desvanecimiento para el objeto o los objetos que lo contienen se sentirían bien.

Si se convirtiera en una transición generalizada de todo el sistema operativo con la relajación adecuada determinada por el equipo de movimiento de Fluent Design, eso sería bueno.

Etiquetando @stmoy ya que estamos hablando de animaciones.

Gracias @SavoySchuler por unirse y proporcionar más contexto sobre los compromisos de nuestro equipo. Espero que esto ayude a explicar por qué estoy buscando específicamente ejemplos de aplicaciones donde se necesita la funcionalidad de ExpandDirection. Para hacerme eco de lo que dijo Savoy, comuníquese conmigo directamente (DM de Twitter si necesita privacidad) si sus necesidades de Expansor son las que no se pueden compartir aquí.

@robloo Gracias por su disculpa. Entiendo completamente sus intenciones y definitivamente quiero que los controles de WinUI sean delimitados y desarrollados de una manera significativa y eficiente. Soy nuevo en el equipo y realmente aprecio que la comunidad de WinUI sea tan amigable y entusiasta al discutir el alcance y la implementación de Expander.

En ese sentido, ¡estoy emocionado de leer estos comentarios más recientes sobre animaciones!

Después de leer los comentarios relacionados con las animaciones, parece que hay 3 rutas posibles, en orden de aumento de la cantidad de trabajo:

Sin incluir una animación de conjunto : esto tiene la ventaja, como señaló @chingucoding , de no disuadir a los desarrolladores cuando su escenario no funciona o no se ve bien con la animación de conjunto. El riesgo aquí es una posible inconsistencia, aunque realmente no parece haber mucho "espacio" para la inconsistencia en esta ruta.

@mdtauk propuso incluir ExpandTransition y CollapseTransition,

que puede usar la dirección establecida por la propiedad del control, lo que podría permitir al desarrollador establecer la transición para cada uno.

Suena como un alcance más pequeño que usar ElementAnimator. ¿Daría esto a los desarrolladores una flexibilidad total para establecer las transiciones?

En la parte superior de mi cabeza, un cambio de tamaño para el panel principal con suavizado. Luego, un deslizamiento y un desvanecimiento para el objeto o los objetos que lo contienen se sentirían bien.

Entiendo partes de esto, pero es difícil para mí visualizar sin, bueno, un visual 😄. ¿"Cambiar el tamaño del panel principal" significa que el encabezado cambiaría de tamaño? ¿Podría explicar lo que quiere decir con "una diapositiva y un desvanecimiento para los objetos que los contienen"?

@ Felix-Dev propuso usar ElementAnimator

La API de ElementAnimator con su StartShowAnimation () y StartHideAnimation () parece prometedora ("mostrar" se utilizará para la expansión, "ocultar" se utiliza para contraer). Se podría ofrecer una propiedad ElementAnimator en el control con una implementación de animación predeterminada. Si no se desea ninguna animación, la propiedad se puede establecer en nula o si se necesita un control más detallado, solo se puede proporcionar una animación Mostrar u Ocultar al ElementAnimator.

@chingucoding señaló que

luego necesitaríamos proporcionar un ElementAnimator personalizado mientras que, de lo contrario, podríamos reutilizar las animaciones de temas existentes. Además, ElementAnimator proporciona más métodos de los que el control del expansor realmente necesita, por lo que parece un ajuste un poco incómodo.

Uno de los puntos principales de ElementAnimator fue permitir agregar animaciones a paneles y colecciones, por ejemplo, ItemsRepeater. Sin embargo, en el caso de Expander, este no es realmente el caso, el expansor no es un panel que representa una colección de elementos.

TreeView y NavigationView jerárquico deberían simplemente cambiar al control Expander cuando el control esté listo. Después de todo, actualmente ambos controles necesitan manejar exactamente el mismo problema que sería resuelto por ExpanderControl. Entonces, una animación compartida no haría una gran diferencia para TreeView.

No estoy seguro de que TreeView y NavigationView jerárquico tengan exactamente el mismo escenario de animación que Expander, ¿qué pasa cuando Expander empujará cualquier contenido (no necesariamente texto / botones) cerca y los escenarios en los que los expansores están en 'acordeón' entre sí y potencialmente tienen lógica para cerrar / abrir dependiendo de la expansión de cada uno.

¿ElementAnimator es excesivo para las animaciones de expansor dado que está destinado a animaciones de panel / colección?

@mdtauk propuso incluir ExpandTransition y CollapseTransition,

que puede usar la dirección establecida por la propiedad del control, lo que podría permitir al desarrollador establecer la transición para cada uno.

Suena como un alcance más pequeño que usar ElementAnimator. ¿Daría esto a los desarrolladores una flexibilidad total para establecer las transiciones?

En la parte superior de mi cabeza, un cambio de tamaño para el panel principal con suavizado. Luego, un deslizamiento y un desvanecimiento para el objeto o los objetos que lo contienen se sentirían bien.

Entiendo partes de esto, pero es difícil para mí visualizar sin, bueno, un visual 😄. ¿"Cambiar el tamaño del panel principal" significa que el encabezado cambiaría de tamaño? ¿Podría explicar lo que quiere decir con "una diapositiva y un desvanecimiento para los objetos que los contienen"?

Perdón por la demora, tuve que hacer esta pequeña animación de maqueta.
Ignore los tiempos de animación reales, son solo para ilustración. El contorno rosa es el encabezado expansor, y el borde verde es para el panel expansor / contenido, etc.

No estoy seguro de que TreeView y NavigationView jerárquico tengan exactamente el mismo escenario de animación que Expander, ¿qué pasa cuando Expander empujará cualquier contenido (no necesariamente texto / botones) cerca y los escenarios en los que los expansores están en 'acordeón' entre sí y potencialmente tienen lógica para cerrar / abrir dependiendo de la expansión de cada uno.

La pregunta es, ¿debería Expander hacer cumplir las animaciones? TreeView y Hierarchical NavigationView definitivamente se beneficiarían de tener un control de expansión incorporado que se encarga de la expansión / colapso y nos permitiría tener una experiencia más unificada en esa área. Por ejemplo, TreeView no anima nada mientras que NavigationView jerárquico anima la rotación del cheurón.

¿ElementAnimator es excesivo para las animaciones de expansor dado que está destinado a animaciones de panel / colección?

Podría ser, uno de los controles que apoyan activamente ElementAnimator (al menos en la vista previa) es ItemsRepeater, que se ocupa de paneles grandes que representan docenas de elementos. Expander, por otro lado, no tiene un escenario tan complejo, sino un solo elemento para mostrar / ocultar.

Una cosa diferente que noté es que no habría una forma de personalizar dónde se colocaría el cheurón (izquierda / derecha o arriba / abajo). ¿Quizás sería útil tener esto como punto de personalización? NavigationView coloca el cheurón a la derecha, mientras que TreeView lo coloca a la izquierda. Lo mismo ocurre con los expansores existentes en el sistema, algunas áreas de la aplicación de configuración lo colocan a la izquierda, mientras que las notificaciones, por ejemplo, las colocan a la derecha.

Una cosa diferente que noté es que no habría una forma de personalizar dónde se colocaría el cheurón (izquierda / derecha o arriba / abajo). ¿Quizás sería útil tener esto como punto de personalización? NavigationView coloca el cheurón a la derecha, mientras que TreeView lo coloca a la izquierda. Lo mismo ocurre con los expansores existentes en el sistema, algunas áreas de la aplicación de configuración lo colocan a la izquierda, mientras que las notificaciones, por ejemplo, las colocan a la derecha.

Podríamos introducir algo como ExpandGlyphPlacementMode con valores como TopLeft, TopRight, BottomCentered (y posiblemente más (Left, Right, ...)) y ExpandGlyphPlacementOffset adicionales que los desarrolladores de propiedades podrían usar para modificar el posición base (establecida por el modo de ubicación) si es necesario.

Además de eso, como @mdtauk ya notó, las API para personalizar los glifos expandir / contraer (algunos controles usan > , otros usan v para su glifo expandir) y para controlar la visibilidad del glifo.

Podríamos introducir algo como ExpandGlyphPlacementMode con valores como TopLeft, TopRight, BottomCentered (y posiblemente más (Left, Right, ...)) y una propiedad adicional ExpandGlyphPlacementOffset que los desarrolladores podrían usar para modificar la posición base (establecida por el modo de ubicación) si fuera necesario .

No estoy seguro de si TopLeft, TopRight ... es la opción correcta aquí. ¿Quizás algo como "Inicio" y "Fin" podría ser más adecuado aquí?
En diseños horizontales, Inicio estaría a la izquierda (derecha en idiomas RTL), en modo de apertura vertical, esto sería superior. Entonces, "Fin" podría definirse en consecuencia. El problema que veo con TopLeft ... es que introduce mucha complejidad (consulte TeachingTip) para obtener pocos beneficios. TopLeft y TopRight serían lo mismo si ExpanderControl se abre hacia la derecha. Creo que tener algo como centrado en la parte inferior se verá un poco incómodo en muchos espacios y ocupará mucho espacio.

Además de eso, como @ mdtauk (dividiendo la mención para no enviar spam a su bandeja de entrada) ya notó, las API para personalizar los glifos expandir / contraer (algunos controles usan>, otros usan v para su glifo expandir) y para controlar la visibilidad del glifo.

La pregunta es cómo lograrlo. Si queremos animar el icono de manera similar a lo que hace NavigationView jerárquico, no podremos permitir una API para intercambiar el glifo expandido y contraído que podría usarse para cambiar a vo> por contraído. ¿Quizás podríamos tener una API que indique la dirección del glifo contraído?

Las ideas para animaciones parecen bastante buenas. Debe ser posible activarlos / desactivarlos como en Vista de lista, et al. El encabezado y el glifo también deben cambiar de lado para los idiomas RTL automáticamente. Sin embargo, toda la personalización de glifos parece estar sobreingeniería del problema. Es imposible crear un estilo que funcione para todos los casos identificados que tienen implementaciones personalizadas. En cambio, al igual que CheckBox y otros controles, el diseño predeterminado debería ser lo mejor que podamos hacer, pero el estilo predeterminado debería ser lo suficientemente simple como para volver a crear una plantilla. No sé por qué todo el mundo es tan adverso a la reformulación de los controles; en gran medida, es la solución y, en realidad, es una gran ventaja de los controles sin apariencia. Agregar más propiedades también aumenta la carga de mantenimiento de la que tanto oigo hablar.

Editar: definir recursos para algunas cosas para mejorar el estilo ligero también podría ser una opción razonable.

No estoy seguro de si TopLeft, TopRight ... es la opción correcta aquí. ¿Quizás algo como "Inicio" y "Fin" podría ser más adecuado aquí?
En diseños horizontales, Inicio estaría a la izquierda (derecha en idiomas RTL), en modo de apertura vertical, esto sería superior. Entonces, "Fin" podría definirse en consecuencia. El problema que veo con TopLeft ... es que introduce mucha complejidad (consulte TeachingTip) para obtener pocos beneficios.

@chingucoding El NavigationView usa un modo de apertura vertical (ya que un NavigationViewItem se expande verticalmente), ¿verdad? ¿Cómo podría entonces establecer el glifo en el lado izquierdo o derecho del encabezado? Estoy leyendo su comentario como "inicio" sería superior, "final" probablemente al final del encabezado entonces. Pero no veo una forma de especificar si el glifo se puede colocar en la esquina superior izquierda o en la esquina superior derecha. No debería tener que usar una API como ExpandGlyphPlacementOffset para algo que vemos con tanta frecuencia.

Creo que tener algo como centrado en la parte inferior se verá un poco incómodo en muchos espacios y ocupará mucho espacio.

Estoy seguro de que he visto ejemplos de eso en la web, en aplicaciones, etc., por eso se me ocurrió esa idea. Aunque sería mejor si se pudieran publicar ejemplos aquí para ver si eso es algo que valga la pena apoyar directamente o si lo dejaríamos en manos de una nueva plantilla.

Sin embargo, toda la personalización de glifos parece estar sobreingeniería del problema. Es imposible crear un estilo que funcione para todos los casos identificados que tienen implementaciones personalizadas. En cambio, al igual que CheckBox y otros controles, el diseño predeterminado debería ser lo mejor que podamos hacer, pero el estilo predeterminado debería ser lo suficientemente simple como para volver a crear una plantilla. No sé por qué todo el mundo es tan adverso a la reformulación de los controles; en gran medida, es la solución y, en realidad, es una gran ventaja de los controles sin apariencia.

@robloo No soy adverso a la re-plantilla, pero mirando los ejemplos publicados hasta ahora, algunos desarrolladores usan ">" para el glifo de expansión y otros usan "v" para el glifo de expansión cuando se expanden verticalmente. Lo mismo que para la posición del glifo. El control Expander debería facilitar que los desarrolladores establezcan el glifo de acuerdo con sus deseos. La re-plantilla siempre viene con compensaciones, principalmente que no se beneficiará automáticamente de los cambios futuros que se realicen en la plantilla de control en WinUI. En cambio, esa carga recaerá ahora en los desarrolladores para mantener su plantilla personalizada.

Debemos identificar escenarios de personalización comunes y esforzarnos por hacerlos lo más accesibles posible mediante el control Expander.

Tomemos, por ejemplo, este caso de glifos personalizados (que se encuentran en el sitio web de Fluent UI ):

La personalización del símbolo de glifo necesariamente significará que cualquier animación de glifo incorporada debe considerarse cuidadosamente. También es interesante saber qué es lo que más desearían los clientes: la capacidad de personalizar fácilmente los glifos según su gusto o tener una animación incorporada para el glifo (como se ve en NavigationView). Personalmente, creo que sería más importante tener el primero, pero no tengo datos concretos para respaldarlo.

Otro control Expander es el control Telerik Expander que expone algunas de las API de personalización que hemos estado discutiendo aquí (como la capacidad de cambiar la posición del glifo o el símbolo del glifo) que también podríamos usar para inspirarnos.

Glifo expandido
Glifo Colapsado
Que el desarrollador podría anular como mejor le parezca

GlyphPlacement.Comience .Fin .Arriba .Abajo
¿Quizás?

Tal vez también use la alineación de contenido para manejar el encabezado que llena el ancho, o tener el glifo y el texto agrupados juntos

Para el Centro de notificaciones hay un claro todo en la misma línea que el expansor, entonces, ¿cómo se manejaría esto? ¿Alguna forma de separar el panel desplegable del encabezado desplegable?

@chingucoding El NavigationView usa un modo de apertura vertical (ya que un NavigationViewItem se expande verticalmente), ¿verdad? ¿Cómo podría entonces establecer el glifo en el lado izquierdo o derecho del encabezado? Estoy leyendo su comentario como "inicio" sería superior, "final" probablemente al final del encabezado entonces. Pero no veo una forma de especificar si el glifo se puede colocar en la esquina superior izquierda o en la esquina superior derecha. No debería tener que usar una API como ExpandGlyphPlacementOffset para algo que estamos viendo con tanta frecuencia.

Eso fue mal redactado por mi parte Con "modo de apertura horizontal", quise decir que la dimensión horizontal es fija, por lo que el contenido se presenta de manera horizontal. Lo mismo para el modo vertical. Además, ¿qué es la esquina superior izquierda y la esquina inferior izquierda? Asumiría que el ícono está centrado, la mayoría de las veces el encabezado no debería / ni siquiera ocupa mucho espacio en la región en expansión y la parte superior izquierda y la parte inferior izquierda terminarían siendo casi lo mismo.

Entonces, para aclarar, si el expansor se expande en dirección vertical, start está a la izquierda (derecha en RTL) y end está a la derecha (izquierda en RTL); en la expansión horizontal, start es superior y end es inferior. Similar a CSS flex-start y flex-end.

Visual Studio usa un icono centrado, sin embargo, la región del botón expandir extiende todo el control:

Cerrado:

Expandido:

GlyphPlacement.Comience .Fin .Arriba .Abajo
¿Quizás?

¡Suena como una idea genial! ¿Cómo se verían arriba y abajo? ¿Similar a lo que hace Visual Studio?

Glifo expandido
Glifo Colapsado
Que el desarrollador podría anular como mejor le parezca

Esta sería una forma de hacer esto, sin embargo, esto no nos permitiría animar el icono (por ejemplo, rotar). Sin embargo, creo que tiene más sentido priorizar la posibilidad de cambiar el ícono por completo que tener una animación aquí.

Tal vez también use la alineación de contenido para manejar el encabezado que llena el ancho, o tener el glifo y el texto agrupados juntos

100%

Para el Centro de notificaciones hay un claro todo en la misma línea que el expansor, entonces, ¿cómo se manejaría esto? ¿Alguna forma de separar el panel desplegable del encabezado desplegable?

Me preocupa que este escenario específico pueda ser demasiado complejo para lograrlo simplemente con el control del expansor. La ubicación de los botones es bastante única, pero lo que es más importante, el encabezado y el ícono de expansión no están en la misma línea, lo que sería bastante difícil de hacer con un control de expansión estándar que coloca el encabezado y el ícono uno al lado del otro. Aquí hay un ejemplo de referencia:

No soy adverso a la re-plantilla, pero mirando los ejemplos publicados hasta ahora, algunos desarrolladores usan ">" para el glifo de expansión y otros usan "v" para el glifo de expansión cuando se expanden verticalmente. Lo mismo que para la posición del glifo. El control Expander debería facilitar que los desarrolladores establezcan el glifo de acuerdo con sus deseos.

@ Felix-Dev Esta es una de esas cosas que deberían estandarizarse en el sistema de diseño fluido. Es importante que los usuarios tengan un aspecto y una sensación coherentes. La única vez que esto debería cambiar es si una aplicación debe hacerlo para cumplir con su propio lenguaje de diseño o si hay un nuevo caso de uso en el que no pensamos. En ese caso, vuelva a realizar la plantilla.

Editar: Extrañé tu ejemplo de Telerik en la primera lectura. Todavía creo que estamos aumentando la complejidad demasiado y permitiendo demasiadas opciones de diseño que: (1) no serán reconocidas tan fácilmente por los usuarios (2) expondrán mucha complejidad que históricamente no se había necesitado. Por supuesto que aquí hay una línea muy fina. Queremos exponer una funcionalidad suficiente para que los usuarios no necesiten volver a crear una plantilla, pero tampoco queremos exponer tanta funcionalidad que el lenguaje de diseño se vuelva confuso.

WPF, o cualquier otro control de expansión que se me ocurra, nunca expuso una propiedad para controlar esto. Realmente es una gran parte de la vista y debería persistir solo en XAML. El modelo de vista (es decir, los DP del control en este caso) no debería saber nada sobre dicha elección de estilo en un control sin apariencia limpia.

WPF, o cualquier otro control de expansión que se me ocurra, nunca expuso una propiedad para controlar esto. Realmente es una gran parte de la vista y debería persistir solo en XAML. El modelo de vista (es decir, los DP del control en este caso) no debería saber nada sobre dicha elección de estilo en un control sin apariencia limpia.

@robloo Una posibilidad de exponer la personalización de glifos sería mediante un estilo ligero. Estos recursos, al igual que los DP, deben considerarse parte de la superficie de API pública de un control, pero están mucho más cerca de la plantilla de control (el aspecto del control). Entonces podríamos exponer recursos como ExpanderExpandGlyph y ExpanderCollapseGlyph (NavigationView, por ejemplo, tiene un recurso NavigationViewItemExpandedGlyph ).

Exponer la personalización de símbolos de glifos de esa manera también podría leerse como una recomendación para proporcionar elementos de fuente presentes en la fuente MDL2, utilizando así íconos aprobados por Fluent Design. Al observar la fuente MDL2, parece que presenta todos los iconos de glifos de expansión / contracción de uso común que he visto en ejemplos en la web (los diferentes chevrones, +/-, +/- en círculos, ...). Si bien los desarrolladores probablemente aún podrían anular FontFamily (suministrado por el recurso SymbolThemeFontFamily ), solo expondríamos directamente los recursos ExpanderExpandGlyph , ... como recursos públicos para el control, por lo que los desarrolladores potencialmente serán los primeros mire la familia de fuentes MDL2 si quieren personalizar los íconos (ya que esa sería la familia de fuentes predeterminada utilizada por Expander para los glifos).

Para aquellos interesados, también hay al menos otro problema aún no resuelto sobre hasta dónde queremos llegar como WinUI para proporcionar opciones de glifos de personalización fáciles cuando solo un conjunto fijo de iconos tendrá sentido en el contexto dado (personalización de glifos de botones giratorios de NumberBox) : https://github.com/microsoft/microsoft-ui-xaml/issues/2789 Sé que al menos algunos de ustedes ya están al tanto de ese problema, pero estoy viendo algunos paralelismos en la discusión allí como aquí con respecto a cómo exponer la opción de personalización (glifo), sentí que valía la pena hacer referencia aquí. Quizás la solución que se encuentra aquí también se pueda aplicar en el caso de NumberBox para lograr coherencia en WinUI.

@ Felix-Dev Tu recomendación para un estilo ligero tiene más sentido para mí. Es lo que quise decir con "Editar: definir recursos para algunas cosas para mejorar el estilo ligero también podría ser una opción razonable". algunos comentarios arriba.

La pregunta es qué tan probable es que los desarrolladores no proporcionen un glifo, sino que tengan alguna forma de otro icono, por ejemplo, un BitmapIcon o alguna forma de FontIcon personalizado. Si los íconos que no son de glifo no son realmente un punto de personalización que muchos desarrolladores usarían, creo que lo mejor aquí es un recurso de estilo ligero para el glifo (y tal vez uno para la fuente del símbolo), como lo proponen @robloo y @ Felix- Dev.

La re-plantilla es siempre una opción, si un glifo o una fuente personalizada no es suficiente.

• Los glifos de fuente con Segoe MDL2 o FluentIcons son los más probables y probablemente deberían ser los predeterminados;

• Tampoco es común ningún glifo;

• Luego están las rutas, SVG que son menos probables pero muy posibles;

• Y luego PNG o mapas de bits completos como una opción poco probable pero posible para los desarrolladores.

Cualquiera que sea el enfoque que se utilice, probablemente debería centrarse en los dos primeros escenarios, pero siempre permitir la re-plantilla para el tercero.

Luego existe la posibilidad de tener un ContentPresenter para el glifo y permitir que se le coloque cualquier cosa. Pero no estoy seguro de cómo funciona eso con VisualStates para pasar de Colapsado a Expandido.

En cuanto a la animación del icono, ¿quizás el control Lottie podría usarse aquí?

Otro pensamiento, al igual que tiene RadioButton y RadioButtons como un grupo de ellos ...

¿Debería un grupo de expansores hacer un control de acordeón? ¿Qué permitiría un comportamiento en el que solo se pueda expandir un único expansor a la vez?

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

La re-plantilla es siempre una opción, si un glifo o una fuente personalizada no es suficiente.

Los glifos de fuente con Segoe MDL2 o FluentIcons son los más probables y probablemente deberían ser los predeterminados;

Tampoco es común ningún glifo;

Luego están las rutas, SVG que son menos probables pero muy posibles;

Y luego PNG o mapas de bits completos como una opción poco probable pero posible para los desarrolladores.

Cualquiera que sea el enfoque que se utilice, probablemente debería centrarse en los dos primeros escenarios, pero siempre permitir la re-plantilla para el tercero.

Reemplazar siempre será una opción, sin embargo, por supuesto, es algo que puede romperse con el tiempo si hay cambios (importantes) en el control. Por lo tanto, tener un recurso liviano es probablemente lo mejor aquí, ya que cambiar los glifos (y la fuente de los iconos) son los escenarios más comunes.

Luego existe la posibilidad de tener un ContentPresenter para el glifo y permitir que se le coloque cualquier cosa. Pero no estoy seguro de cómo funciona eso con VisualStates para pasar de Colapsado a Expandido.

El uso de ContentPresenter no hace una diferencia con respecto al colapso / expansión, sería solo un elemento como los demás.

En cuanto a la animación del icono, ¿quizás el control Lottie podría usarse aquí?

La pregunta es qué tipo de animaciones quieres tener. La rotación simple ya se puede (y se hace) sin lotería.

Otro pensamiento, al igual que tiene RadioButton y RadioButtons como un grupo de ellos ...

¿Debería un grupo de expansores hacer un control de acordeón? ¿Qué permitiría un comportamiento en el que solo se pueda expandir un único expansor a la vez?

¿Quizás eso podría ser un control separado? Si bien hay escenarios en los que podrían ser exclusivos entre sí, creo que en muchos casos, realmente no importa si hay varios abiertos.

Luego existe la posibilidad de tener un ContentPresenter para el glifo y permitir que se le coloque cualquier cosa. Pero no estoy seguro de cómo funciona eso con VisualStates para pasar de Colapsado a Expandido.

El uso de ContentPresenter no hace una diferencia con respecto al colapso / expansión, sería solo un elemento como los demás.

Pero, ¿sería un ContentPresenter que es utilizado por ambos estados, o uno por estado que se cambia / cambia?

En cuanto a la animación del icono, ¿quizás el control Lottie podría usarse aquí?

La pregunta es qué tipo de animaciones quieres tener. La rotación simple ya se puede (y se hace) sin lotería.

Las rotaciones tienen sentido cuando el glifo es una flecha direccional / cheurón, pero ¿qué pasa si es una bombilla de luz que se enciende y se apaga para algún tipo de escenario de sugerencia o sugerencia? Existe una propuesta para un control de íconos animados generalizados usando Lottie # 2802 - ¿Esta situación lo requeriría, incluso si su uso predeterminado / más común puede ser una simple rotación de íconos?

Otro pensamiento, al igual que tiene RadioButton y RadioButtons como un grupo de ellos ...
¿Debería un grupo de expansores hacer un control de acordeón? ¿Qué permitiría un comportamiento en el que solo se pueda expandir un único expansor a la vez?

¿Quizás eso podría ser un control separado? Si bien hay escenarios en los que podrían ser exclusivos entre sí, creo que en muchos casos, realmente no importa si hay varios abiertos.

Lo menciono solo porque Fast Design incluye un control de acordeón, y es esencialmente lo mismo que un grupo de expansores, solo que hay una API de comportamiento múltiple y único que cambia la forma en que funcionan juntos. Con un control de expansor hecho, un acordeón sería el siguiente paso lógico y debería ser relativamente fácil de lograr con una propiedad de orientación para anular las direcciones individuales.

Luego existe la posibilidad de tener un ContentPresenter para el glifo y permitir que se le coloque cualquier cosa. Pero no estoy seguro de cómo funciona eso con VisualStates para pasar de Colapsado a Expandido.

El uso de ContentPresenter no hace una diferencia con respecto al colapso / expansión, sería solo un elemento como los demás.

Pero, ¿sería un ContentPresenter que es utilizado por ambos estados, o uno por estado que se cambia / cambia?

Ambas opciones tienen sentido. Creo que cambiar el contenido del ContentPresenter es mejor que cambiar el ContentPresenter o tener dos y ocultar / mostrar uno.

En cuanto a la animación del icono, ¿quizás el control Lottie podría usarse aquí?

La pregunta es qué tipo de animaciones quieres tener. La rotación simple ya se puede (y se hace) sin lotería.

Las rotaciones tienen sentido cuando el glifo es una flecha direccional / cheurón, pero ¿qué pasa si es una bombilla de luz que se enciende y se apaga para algún tipo de escenario de sugerencia o sugerencia? Existe una propuesta para un control de íconos animados generalizados usando Lottie # 2802 - ¿Esta situación lo requeriría, incluso si su uso predeterminado / más común puede ser una simple rotación de íconos?

Una animación de rotación sería una forma de animar y sería fácil de lograr. Tener un ícono que se anime a otro diferente sería bastante diferente. Eso probablemente también haría que la API sea más complicada (¿cómo soporta tal comportamiento? ¿2 animaciones y 2 iconos? ¿O una animación que detiene?)

Otro pensamiento, al igual que tiene RadioButton y RadioButtons como un grupo de ellos ...
¿Debería un grupo de expansores hacer un control de acordeón? ¿Qué permitiría un comportamiento en el que solo se pueda expandir un único expansor a la vez?

¿Quizás eso podría ser un control separado? Si bien hay escenarios en los que podrían ser exclusivos entre sí, creo que en muchos casos, realmente no importa si hay varios abiertos.

Lo menciono solo porque Fast Design incluye un control de acordeón, y es esencialmente lo mismo que un grupo de expansores, solo que hay una API de comportamiento múltiple y único que cambia la forma en que funcionan juntos. Con un control de expansor hecho, un acordeón sería el siguiente paso lógico y debería ser relativamente fácil de lograr con una propiedad de orientación para anular las direcciones individuales.

Bien, ya veo. Sí, un control de acordeón es definitivamente una buena idea después del control del expansor y probablemente sería muy fácil de implementar.

Las rotaciones tienen sentido cuando el glifo es una flecha direccional / cheurón, pero ¿qué pasa si es una bombilla de luz que se enciende y se apaga para algún tipo de escenario de sugerencia o sugerencia? Existe una propuesta para un control de íconos animados generalizados usando Lottie # 2802 - ¿Esta situación lo requeriría, incluso si su uso predeterminado / más común puede ser una simple rotación de íconos?

Una animación de rotación sería una forma de animar y sería fácil de lograr. Tener un ícono que se anime a otro diferente sería bastante diferente. Eso probablemente también haría que la API sea más complicada (¿cómo soporta tal comportamiento? ¿2 animaciones y 2 iconos? ¿O una animación que detiene?)

Esta es una gran pregunta y, para ser honesto, es algo para la propuesta del Icono Animado.

Animar el glifo / icono está bien si siempre será una flecha. Pero de alguna manera lo bloquea, a menos que tenga una manera fácil de eliminar o cambiar la animación en sí.

Hacer una animación de Lottie giratoria mantiene la animación predeterminada, significa un poco más de trabajo para implementar, pero es más flexible al permitir cambiar el icono y las animaciones si es necesario.

La opción más sencilla es no tener animación para el glifo. Pero cuanto más añada, más importante será facilitar la anulación o el cambio.

Al mirar a través de la web, veo una gran cantidad de iconos estáticos utilizados para los glifos expandir / contraer en los ejemplos típicos de la interfaz de usuario de Expander. Sin embargo, en Windows, también tenemos clientes potenciales de este control que parecen preferir las animaciones (ver, por ejemplo, NavigationView y notificaciones de brindis en el shell). El movimiento es una de las piedras angulares de Fluent Design, por lo que probablemente tenga sentido mantener abiertas las opciones para aquellos clientes que quieran un glifo animado sin tener que volver a moldear el control.

Idealmente, si diferentes equipos en MS quisieran usar un expansor con un glifo animado (es decir, un glifo de flecha animado), el control proporcionaría una opción incorporada para que terminemos teniendo una experiencia consistente por defecto. Si cada equipo fuera responsable de la animación, podríamos terminar viendo una duración de animación diferente, diferentes direcciones de animación (es decir, en el sentido de las agujas del reloj o en el sentido contrario a las agujas del reloj), ... Si recuerdo correctamente, la animación del glifo para las notificaciones en el El centro de acción es diferente a la animación del glifo en NavigationView. Eso debería evitarse, si es posible.

Las animaciones son un placer y ayudan a que la interfaz de usuario se sienta fluida. La codificación rígida en un guión gráfico de rotación es la forma sencilla de agregar una animación, pero si esa animación es difícil de eliminar o cambiar, tal vez usar el control AnimatedIcon sería una buena manera de crear una forma flexible de habilitar la personalización.

No estoy diciendo que una forma sea mejor que la otra, solo llamo la atención aquí, ya que está animando un ícono, y esa es la Raison Detra para el nuevo control.

Y si se ha reconocido que los glifos deben ser personalizables, es posible que la animación de rotación no siempre sea adecuada.

Qué animar y qué no animar es una cuestión muy difícil. Como ya mencionó Martin, una animación de rotación no siempre tiene sentido. Y los íconos animados todavía tienen muchas preguntas abiertas.

Creo que sería mejor eliminar las animaciones de glifos / iconos para la versión 1, especialmente porque no es muy común. Una cosa a reconsiderar entonces es si eliminamos la animación existente en el NavigationView jerárquico para tener una experiencia uniforme. Actualmente ya existe una inconsistencia entre TreeView y h-NavigationView para animar / no animar el cambio del icono.

Exactamente. No tenía la intención de desalentar cualquier exploración aquí con mi último párrafo, pero simplemente escribo una vez más que uno de los desafíos que enfrentamos aquí es proporcionar suficientes opciones de personalización fuera de "la última", la reformulación de plantillas, para satisfacer al cliente común. quiere, pero aún asegurándose de que el control ayude a traer más consistencia a Windows, en lugar de potencialmente menos.

Como ya hemos visto, puede que no haya una solución perfecta aquí, ya que querer proporcionar personalizaciones de iconos y soporte de animación (quizás además de animaciones integradas para mayor coherencia) puede chocar fácilmente entre sí.

Podría ser útil que los clientes potenciales como Windows Shell se unan aquí para ver cómo ven las animaciones. 10X supuestamente se centrará en las animaciones y el Shell de Windows y las aplicaciones de Windows en la caja podrían ser "clientes" aquí. Si un glifo animado se considera una pieza importante en la experiencia de usuario general que el equipo de Windows se está esforzando por lograr con 10X, eso podría requerir no "patear" en este desafío por ahora, sino contar con soporte de animación en la V1.

Me gustaría ver un enfoque coherente para animar íconos, que en este momento parece ser la propuesta de íconos animados.

No eliminaría ninguna animación de NavigationView, ya que es un nuevo paradigma completamente autónomo para WinUI, y parece que la intención es agregar animaciones a todos estos controles similares, por lo que tal vez una vez que esté listo, el control podría ser agregado a NavigationView

Parece que ElementAnimator es demasiado para animar Expander, y que ExpandTransition y CollapseTransition serían suficientes.

@mdtauk ¡ gracias por hacer la animación de la maqueta! Entiendo lo que quisiste decir con las animaciones que se expanden y colapsan.

Creo que el comportamiento de acordeón se logrará a través de la lógica de nivel de lista (en lugar de un nuevo control de acordeón) con IsExpanded para que los desarrolladores lo personalicen en diferentes escenarios (por ejemplo, donde algunos expansores se cierran entre sí y otros pueden expandirse simultáneamente).

@ Felix-Dev: agregué el expansor Telerik a la propuesta, ¡gracias por compartirlo!

Parece que hay un deseo de personalización en las siguientes direcciones:

Apariencia de glifos : el estilo ligero parece ser la ruta preferida para cambiar los glifos y la fuente de los iconos, ya que tiene ExpanderExpandGlyph y ExpanderCollapseGlyph . ¿Es necesario este nivel de personalización en v1 Expander?

@ Felix-Dev Si bien los desarrolladores probablemente aún podrían anular el FontFamily (proporcionado por el recurso SymbolThemeFontFamily), solo expondríamos directamente el ExpanderExpandGlyph ... por lo que los desarrolladores potencialmente verán primero la familia de fuentes MDL2 si quieren personalizar los iconos (ya que esa sería la familia de fuentes predeterminada utilizada por el expansor para los glifos).

Animación de glifo : incluido el cambio a un glifo diferente al expandirse, que se resuelve parcialmente con AnimatedIcon # 2802. Parece que este nivel de personalización no es necesario para v1 Expander.
@chingucoding declaró y tiendo a estar de acuerdo:

Creo que sería mejor eliminar las animaciones de glifos / iconos para la versión 1, especialmente porque no es muy común.

Posición del glifo : ¿Se necesita este nivel de personalización en v1 Expander? Esto se complica aún más si v1 incluye ExpandDirection y la opción de cambiar la posición del glifo. @ Felix-Dev describió

Algo como un ExpandGlyphPlacementMode con valores como TopLeft, TopRight, BottomCentered (y posiblemente más (Left, Right, ...)) y una propiedad adicional ExpandGlyphPlacementOffset que los desarrolladores podrían usar para modificar la posición base (establecida por el modo de ubicación) si es necesario.

Espero haber entendido correctamente la gran discusión de este fin de semana. ¡Avísame si me equivoco en alguna parte! Muchas gracias a todos por sus profundos pensamientos sobre esto. 😄

Apariencia de glifo
Posición del glifo

Creo que estas son las personalizaciones más fáciles e importantes de incluir en V1.

También agregaría una forma de ocultar el glifo

Animación de glifos
Transiciones de estado

A estos se les podría dar una prioridad más baja si se necesita la priorización y el comportamiento y la funcionalidad principales están tardando demasiado.

¡Gracias por el orden de prioridad @mdtauk!

Agregué una nueva pregunta abierta:

• ¿Cómo debería funcionar Expander con InfoBar? ¿Agregar funcionalidad de expansión a la barra de información? ¿Poner InfoBar como contenido de un expansor? ¿El revés?

Me imagino que reemplazaría el contenido, pero creo que quienes diseñan la barra de información deberían proporcionar una especificación de diseño para una barra plegable, que los diseñadores de expansores pueden ver.

Es una conversación para tener

¡Hay un montón de gran conversación aquí! Sobre el tema de las animaciones ...

Parece que ElementAnimator es demasiado para animar Expander, y que ExpandTransition y CollapseTransition serían suficientes.

De acuerdo en que ElementAnimator es demasiado para animar Expander. Podría funcionar si todo estuviera en un ItemsRepeater, pero ElementAnimator aún no funciona fuera de ItemsRepeater, por lo que tendríamos que averiguarlo.

Me gusta la idea de tener ExpandTransition y CollapseTransition en teoría, pero hemos recibido un montón de comentarios de que las API de transición son buenas en teoría pero menos buenas en la práctica porque no son personalizables, generalmente están estrechamente acopladas a los controles en que se utilizan, y no creo que se puedan construir en la serie WinUI 2.x ya que dependen de los ganchos del sistema operativo. Dado que estas transiciones específicas no existen, preferiría explorar otras opciones que agregar a nuestra colección de API ThemeTransition.

Además de todo eso, el área general de "animaciones de diseño" donde el contenido se mueve como resultado de nuevos elementos de la interfaz de usuario que ingresan / crecen / encogen / salen de la página no son compatibles con Xaml como plataforma en la actualidad. Arreglar esto también requerirá WinUI 3, pero no está en la hoja de ruta inmediata.

Para Expander en particular, creo que el curso de acción adecuado probablemente terminará siendo:
1) Codifique la animación de crecimiento / reducción en el código del expansor (y considere incluir una API para desactivarla, aunque personalmente no creo que sea necesaria una)
2) Brindar orientación a los desarrolladores de aplicaciones sobre cómo animar el contenido alrededor del Expansor para que el contenido debajo del Expansor se deslice hacia abajo en lugar de "saltar" hacia abajo.

No creo que (2) se pueda resolver en general sin "animaciones de diseño", pero probablemente se pueda solucionar usando RepositionThemeAnimation en el contenido debajo del Expansor.

@stmoy Podríamos usar PopInThemeAnimation para (1) si quisiéramos ir con los existentes.

Esta propuesta ha sido aprobada para la redacción de especificaciones .

Como parte de la discusión con el equipo de WinUI, determinamos que el alcance de Expander podría ser compatible con ExpandDirection para la expansión hacia arriba / hacia abajo en V1. Esto cubre los escenarios que hemos visto para Expander y sienta las bases para agregar potencialmente la expansión izquierda / derecha en el futuro.

Siéntase animado a continuar la discusión aquí, y se producirá una discusión más detallada sobre las especificaciones y el RP asociado una vez que esté disponible. Especialmente me encantaría escuchar sus pensamientos sobre esta pregunta abierta:

• ¿Cómo debería funcionar Expander con InfoBar? ¿Agregar funcionalidad de expansión a la barra de información? ¿Poner InfoBar como contenido de un expansor? ¿El revés?

Para InfoBar, creo que necesito abrir una propuesta separada para profundizar en lo que necesita específicamente y cómo puede aprovechar este control de Expansor. Estos son algunos de mis primeros pensamientos:

• Una barra de información necesita personalizar el encabezado y el contenido / panel del control Expander. La barra de información debe mostrar un mensaje de "corte" en el encabezado cuando se contrae y un mensaje completo en el contenido / panel expandido cuando se abre.
• Una barra de información no _tiene_ que permitir el truncamiento y la opción debe estar ahí para que el desarrollador elija el comportamiento de ajuste actual si es necesario a través de una propiedad "shouldTruncate".
• Una barra de información podría / debería "convertirse" en un expansor si el contenido ya no cabe en una sola línea y shouldTruncate se establece en verdadero. Implementar esto y comprender cuándo exactamente agregar el comportamiento de expansión es donde se vuelve complicado 😊 MessageBar mitiga esto a través de su propiedad isMultiline, pero es necesario pensar más en esta área.

Creo que también podemos buscar otros controles en WinUI actualmente que pueden beneficiarse de este comportamiento de Expander.

Algunas composiciones iniciales para truncar la barra de información:

Para la implementación, mis pensamientos iniciales son que una barra de información debe derivar de un expansor y no estar anidada dentro del contenido del expansor. ¿Pensamientos?

Creo que también podemos buscar otros controles en WinUI actualmente que pueden beneficiarse de este comportamiento de Expander.

Algunas composiciones iniciales para truncar la barra de información:

Creo que el Expansor puede necesitar poder separar el Botón de Chevron del Contenido que se está expandiendo.

Las notificaciones hacen esto

También permitiría que el control de la barra de información integre su expansor.

Si lo separa, ¿eso se convierte en un comportamiento / propiedad? Entonces, si especifica un elemento o botón de la interfaz de usuario para esta propiedad, ¿el encabezado de expansión no muestra su botón?

Para la implementación, mis pensamientos iniciales son que una barra de información debe derivar de un expansor y no estar anidada dentro del contenido del expansor. ¿Pensamientos?

Si el expansor no puede separar el contenido y el encabezado del botón Alternar / Revelar, entonces eso requeriría más trabajo para que la barra de información lo implemente.

El control Expander debe ser lo más flexible posible específicamente para integrarse en varios otros controles en el futuro, así como para su uso en el Shell de Windows.

Agregué información inicial a la especificación de Expansor y abrí un PR . ¡No dude en continuar la discusión de especificaciones allí! Es PR 100 en el repositorio de especificaciones 😄