Debería agregar un enlace a la muestra de Van Arsdel

Creo que los controles más genéricos del kit de herramientas siempre deberían adaptarse a C++ y estar disponibles en la biblioteca de interfaz de usuario de Windows. El control de las pestañas cuando es lo suficientemente maduro y estable también debería abrirse camino.

Ocurrió con el control del menú principal :)

Enlace a la muestra de Tab Tear-Off mencionada en la propuesta también.

Enlace a la muestra de Tab Tear-Off mencionada en la propuesta también.

¿El arrancar una pestaña genera una nueva AppWindow, una nueva CoreWindow y cómo maneja el respaldo cuando las API de la nueva ventana no están presentes?

@mdtauk, la muestra usa actualmente la API ApplicationView de múltiples ventanas anterior, la ventana se crea en una posición predeterminada en lugar de arrastrarla. He estado probando con AppWindow y espero actualizar la muestra para el nuevo SDK.

"Aunque estas soluciones han ayudado a cerrar la brecha de la plataforma con respecto a WPF, tienen una serie de limitaciones, que incluyen:"

Debe incluir el teclado aquí también. Esto no es solo tecla de tabulación o teclas de método abreviado. Las flechas eran algo con lo que luchamos cuando no teníamos control de pestañas y teníamos que hacer que todos fueran consistentes en la falta de él.

Comentarios sobre preguntas abiertas de lo que hemos escuchado en el kit de herramientas:

1. ¿Debe ser Tab Tearoff algo que maneje el control o que maneje la aplicación?

Creo que es importante que Tab Control maneje el arrastre y la recombinación entre TabViews (que alojan el mismo tipo de datos) y exponga un evento de arrastre, con la capacidad de inspeccionar/interceptar.

Pero no sé si es importante que TabView también administre directamente el ciclo de vida de la ventana, ya que eso se vuelve más complicado. Un desarrollador también puede querer personalizar lo que sucede cuando se arrastra una pestaña, ¿quizás simplemente la elimina o crea una ventana especial solo para ese contenido en lugar de una nueva ventana "principal" con pestañas? O es posible que no quieran manejar el tener que codificar para múltiples ventanas.

Puede ser más fácil exponer el evento y tener ayudantes (o aprovechar los existentes como los de Windows Template Studio) para ayudar en la creación/administración de Windows. La parte más complicada de este escenario es la "transferencia de datos" entre subprocesos, que al menos la nueva API de ventanas debería ayudar a aliviar.

1. ¿Debería haber un botón incorporado "Agregar nueva pestaña"? (Sospecho que probablemente no, porque el control no posee la colección de pestañas).

Creo que siempre que haya plantillas de encabezado y ejemplos adecuados, tener un implementador que agregue un botón 'agregar' es trivial, por lo que no creo que deba integrarse, ya que entonces el paradigma necesitaría otro evento. Esto es algo en lo que también habíamos pensado originalmente en el kit de herramientas. :)

1. ¿Debe TabItem.Icon ser IconElement o IconElementSource?

Usamos IconElement para imitar la propiedad de NavigationViewItem. Además, IconElementSource es un IconElement entonces, ¿no es mejor IconElement ya que es más amplio? Sin embargo, sería bueno si hubiera una subclase IconElement en WinUI que pudiera albergar un Image directo (similar a BitmapIcon pero sin el enmascaramiento forzado). De esa manera, la propiedad Icon podría albergar cualquier cosa, ya sea un buen símbolo vectorial/icono de fuente o un archivo ico/png (piense en el favicon de escenario de tipo navegador).

1. ¿Cómo puede una aplicación personalizar el aspecto de la pestaña Seleccionado (es decir, en Edge)?

¿Está hablando de propiedades de estilo expuestas que se pueden modificar o como una plantilla completamente diferente para el elemento seleccionado?

1. Actualmente, la API se inspira mucho en el kit de herramientas. ¿Hay alguna posibilidad de iterar/mejorar?

Uno de los comentarios que recibimos fue sobre la personalización del espacio al final de las pestañas. Por ejemplo, ¿debería ser solo un área de plantilla única que luego pueda usar la alineación horizontal izquierda/derecha para pegar cosas en los bordes en lugar de dos áreas separadas?

Otras preguntas:

• [ ] Es interesante con el arrastre sobre cómo manejar el arrastre al área de contenido en comparación con el encabezado, ¿son ambos objetivos? ¿Qué pasa si la aplicación quiere dejar caer algo más en el área de la pestaña (como un archivo del explorador)?
• [ ] ¿"La aplicación puede decidir cómo posicionar/dimensionar las pestañas" se refiere a la propiedad TabStripPlacement ?

También se olvidó de llamar al Requisito 9, originalmente tuvimos una discusión sobre si usar o no el modelo Edge (como se comporta actualmente el control del kit de herramientas) o el modelo NavigationView donde crea un cheurón desplegable. Pensamos que tal vez en el futuro apoyaríamos a ambos.

Terminamos eligiendo el modelo Edge porque era más simple de implementar, ya que no necesitábamos un objeto de tipo SplitObservableCollection . Comencé a trabajar en uno como prueba, pero me pregunto si sería una construcción útil para exponer.

@stmoy , ¿cerraste los problemas abiertos/los comentarios de arriba que teníamos de los diseños del kit de herramientas?

¿Cómo afecta la noticia de que Windows Sets abandona el modelo Edge Tab en cómo se puede desarrollar este control?

Con Edge y su interfaz de usuario bastante abandonada ahora a favor de ChromiumEdge (Edgium), ¿necesitamos/queremos repensar la apariencia o el comportamiento de este control para que sea más adecuado para los tipos de aplicaciones que pueden usarlo?

• diálogos de propiedades;
• MDI (interfaces de documentos múltiples), como Photoshop;
• Paletas de herramientas acopladas (Visual Studio/Blend/Adobe CC);

Sin mencionar controles similares como Pivot y UWP Ribbon en desarrollo. ¿Cuál se recomienda para qué caso de uso y por qué alguien elegiría uno sobre el otro? La orientación y los ejemplos deben ser claros para responder a estas preguntas a fin de evitar confusiones o el uso de un control más pesado en lugar de uno eficaz y más ligero.

Los controles de primera parte deben usar el control correcto para el propósito correcto, para tratar de liderar el camino en el uso consistente.

En #629 @mdtauk tenía una sugerencia de función:

Tal vez una idea para la lista de tareas pendientes. ¿Colocación de pestañas? Abajo, Izquierda, Derecha.

Sí, la ubicación de pestañas debería estar arriba en la lista de prioridades en algún momento para igualar la paridad de WPF para los escenarios de migración. Sin embargo, es algo que tampoco tuvimos tiempo de agregar en la versión inicial del Toolkit.

Cuando evaluamos esta característica, se convirtió en un objetivo no compatible con el escenario de "pestañas de la hoja de propiedades" y centrarse en el escenario de las pestañas del navegador. Vemos cierta superposición con las hojas de propiedades, pero la metáfora de la hoja de propiedades no es parte del diseño fluido, tenemos NavigationView (que tiene modos Izquierda/Superior) para ese escenario en este momento.

La vista de navegación es un control pesado y quiere ocupar toda la pantalla. También Sets ha desaparecido de la hoja de ruta, al igual que la versión XAML de Edge.

Por lo tanto, puede haber margen para repensar el TabView/Control para hacerlo más flexible y útil para el futuro.

Estos escenarios podrían ser posibles en aplicaciones UWP XAML, si el control TabView tuviera la capacidad de ocultar los botones Agregar y Cerrar.

Pero también hay controles de pivote, sin embargo, solo admite encabezados de pivote en la parte superior, y las pestañas pueden ir en la parte superior, inferior, izquierda o derecha...

En el kit de herramientas admitimos no tener el botón de cerrar, el botón Agregar también era algo que el implementador tenía que agregar. Es por eso que teníamos la propiedad TabWidthBehavior para ayudar a configurar estos diferentes modos entre documentos y pestañas clásicas. Una de las principales cosas que aún no admitíamos era el posicionamiento de las pestañas.

¡Gracias por toda la gran conversación! Dando vueltas alrededor...

Es interesante con el arrastre sobre cómo manejar el arrastre al área de contenido en comparación con el encabezado, ¿son ambos objetivos? ¿Qué pasa si la aplicación quiere dejar caer algo más en el área de la pestaña (como un archivo del explorador)?

Interesante pregunta. Ingenuamente, pensaría que ambos serían el mismo objetivo (grande) ya que TabControl aloja tanto el área de la tira de pestañas como el área de contenido. Sin embargo, este modelo se desmorona cuando se consideran aplicaciones como Edge (como ejemplo). Si se maximizó Edge y el usuario arrastra una pestaña fuera de la tira de pestañas pero aún sobre el contenido porque tiene el tamaño máximo, el usuario espera que la pestaña cree una nueva ventana.

Por lo tanto, creo que solo deberíamos tener el área de encabezado/tira de pestañas como el objetivo de arrastrar/soltar.

¿"La aplicación puede decidir cómo posicionar/dimensionar las pestañas" se refiere a la propiedad TabStripPlacement?

Esto estaba destinado a describir la propiedad y enumeración "TabWidthBehavior" y no TabStripPlacement. Actualicé el requisito y también agregué un requisito de ubicación de pestañas (discutido un poco más a continuación).

Sets ya no está en la hoja de ruta, al igual que la versión XAML de Edge.

El principal motivador de este trabajo en este momento es en realidad la nueva aplicación Windows Terminal . Continuaremos expandiendo/explorando otras aplicaciones para usar el control Tab, pero nuestro enfoque principal es habilitar sus escenarios por el momento.

La ubicación de pestañas debe estar arriba en la lista de prioridades en algún momento para que coincida con la paridad de WPF para los escenarios de migración. Sin embargo, es algo que tampoco tuvimos tiempo de agregar en la versión inicial del Toolkit.

Tab Placement es una idea increíble, particularmente en lo que se refiere a la paridad de WPF. Sin embargo, según lo anterior, dado que nuestro alcance se basa en gran medida en lo que necesita Terminal, esto termina siendo más un "podría" que una "necesidad". Dicho esto, lo agregué a la tabla de requisitos anterior.

Estos escenarios podrían ser posibles en aplicaciones UWP XAML, si el control TabView tuviera la capacidad de ocultar los botones Agregar y Cerrar.

El TabControl admite ocultar el botón de cierre en las pestañas mismas. Además, el botón "Agregar" lo proporcionará la propia aplicación (y no el control), por lo que esperamos poder crear escenarios de pestañas de estilo de propiedad usando el control como se especificó anteriormente.

Si el botón Agregar pestaña no forma parte del control, ¿puedo sugerir que se incluya un estilo de botón y un comando XAML con el control, para que sea más fácil para las personas implementar un botón de manera consistente dondequiera que se use el control?

@stmoy para el escenario de arrastre, creo que habrá casos en los que arrastrar hasta el encabezado y el área pueden ser diferentes o iguales. Sería bueno si una muestra pudiera mostrar el arrastre para el arranque, pero también, por ejemplo, soltar un archivo en el área de contenido principal y cómo atraparlo (eso puede estar fuera del alcance del control en sí, pero útil a su uso).

estilo de botón y comando XAML [para agregar una nueva pestaña]

@mdtauk - gran idea. Lo agregaré a la especificación.

Sería bueno si una muestra pudiera mostrar cómo se arrastra para arrancar, pero también, por ejemplo, cómo soltar un archivo en el área de contenido principal y cómo capturarlo.

@ michael-hawker: de acuerdo, valdría la pena una muestra. Sin embargo, no sé si debe ser específico de una pestaña, ya que el área de contenido se encargaría de arrastrar un archivo.

Hola a todos, solo quería informarles rápidamente que estoy iterando en la especificación de Tabs que actualmente está disponible para relaciones públicas . ¡Agregue comentarios al PR si tiene algún comentario!

Crucemos los dedos para que se parezcan más a las pestañas de Chrome que a las de Edge.

Crucemos los dedos para que se parezcan más a las pestañas de Chrome que a las de Edge.

Queremos que el diseño de interacción "se sienta bien", así que definitivamente presente los problemas con comentarios específicos sobre la versión preliminar para que podamos hacerlo bien antes de enviarlo.

No estoy seguro de si alguien como @chigy ya ha creado una composición de diseño para el control TabView, pero lo hice rápidamente y también demostré las opciones de ubicación lateral e inferior que podrían aparecer en el futuro.

No me gusta que los estados de pulsación/desplazamiento del botón de cierre cambien el fondo del botón y no su primer plano. Cambiar el fondo agrega demasiado énfasis al botón (y lo aleja del título de la pestaña) y este último también sería mucho más elegante.

Para ver ejemplos, vea el botón de cierre en Edge UWP (solo cambios en primer plano) o el botón de silencio de audio de pestaña en Edge (Chromium).

Consideré mantener el cambio de primer plano, pero sentí que el cambio de fondo estaría en línea con los otros controles y el comportamiento de la barra de título, pero por defecto podría ser solo el primer plano.

@mdtauk - eres genial. Gracias por crear estas composiciones de diseño. Aunque no vamos a hacer una colocación lateral para la primera caída del control, es genial ver cómo podría verse.

@chigy y yo estamos trabajando juntos para crear algunas composiciones de diseño que se alineen con los principios de Windows (incluidos elementos como esquinas redondeadas, sombra estándar, etc.), pero las composiciones de diseño que proporcionó nos ayudarán a inspirarnos.

No me gusta que los estados de pulsación/desplazamiento del botón de cierre cambien el fondo del botón y no su primer plano. Cambiar el fondo agrega demasiado énfasis al botón (y lo aleja del título de la pestaña) y este último también sería mucho más elegante.

Nuestro pensamiento actual es solo cambiar el color de primer plano y no el de fondo, como se sugiere aquí. Esto tiene el beneficio adicional de encajar un poco mejor con las esquinas redondeadas que estamos considerando.

Las pestañas de Edge usan un fondo detrás del glifo de cierre, pero es más pequeño que el que propuse, pero las pestañas de Edge aún no admiten ningún modo táctil.

Cuando pensábamos en las pestañas laterales para el diseño del kit de herramientas, nos debatimos entre hacerlo verticalmente con el texto girado como mostró @mdtauk o mantenerlas horizontales y ocupar un margen más grande hacia el lado izquierdo/derecho como solía hacerlo OneNote. antes de su último rediseño y similar a WPF (que pensamos que sería importante para la compatibilidad).

Por lo tanto, sugeriría mantenerlo como lo hizo WPF con el margen ancho y horizontal, pero también que sea súper simple admitir ambos como se muestra aquí , que es otra razón para admitir #546.

@michael-hawker Respaldo tener la lista vertical de pestañas a la derecha con el margen amplio y facilitar rotarlas como en Visual Studio.

Afectará los puntos de pestañas antes y después, pero buscaré hacer una maqueta de diseño cuando regrese a casa el lunes.

Afectará los puntos de pestañas antes y después, pero buscaré hacer una maqueta de diseño cuando regrese a casa el lunes.

Estoy en casa, y aquí está ese diseño:

He refinado una maqueta de diseño para el control.

_desbordamiento de pestañas agregado y tamaño de pestaña_

Así, su concepto de pestaña se parece mucho más a las pestañas de Edge UWP que a las pestañas de Edge Chromium. En mi opinión, el aspecto del control de pestañas debe ser lo más parecido posible al control de pestañas en Edge UWP. Acrílico como fondo de control de pestañas como en Edge UWP también sería bastante bueno.

Todavía espero que el botón de cierre de pestaña se pueda hacer como en Edge UWP, donde el botón solo se muestra para la pestaña seleccionada actualmente o al pasar el mouse sobre la pestaña.

Para el equipo de WinUI: @stmoy Aparentemente, el equipo de Windows Terminal no puede usar acrílico como fondo para el control de pestañas (consulte https://github.com/microsoft/terminal/issues/1375). El equipo de la terminal afirma que se debe a limitaciones arquitectónicas. ¿Es algo con lo que podría ayudar el equipo de WinUI? Parece que hay bastantes fanáticos del fondo acrílico para el control de pestañas como en Edge UWP.

@Felix-Dev Sé que Edgeium es el nuevo diseño al que avanzar, pero creo que el diseño de UWP Edge es un poco más agradable, así que quería intentar cerrar esa brecha

Todavía espero que el botón de cierre de pestaña se pueda hacer como en Edge UWP, donde el botón solo se muestra para la pestaña seleccionada actualmente o al pasar el mouse sobre la pestaña.

CloseButtonOverlay Es la propiedad que haría eso, creo

@mdtauk
Para aclarar, me gustaría ver que CloseButtonOverlay = OnHover se convierta en el valor predeterminado del control de pestañas, en lugar de que el botón de cierre se muestre constantemente en todas las pestañas (me quita espacio innecesariamente del título de la pestaña).

Siempre visible es lo mejor para los usuarios táctiles, por lo que creo que el valor predeterminado debería ser lo más inclusivo posible

¿Quizás el modo de superposición para el botón de cierre podría depender de las capacidades de la pantalla del usuario?

No estoy seguro de si eso podría ser un problema, ya que habría una ligera diferencia visual en el control de pestañas según el tipo de pantalla.

¿Quizás el modo de superposición para el botón de cierre podría depender de las capacidades de la pantalla del usuario?

No estoy seguro de si eso podría ser un problema de alguna manera, ya que habría una _ligera_ diferencia visual en el control de pestañas según el tipo de visualización.

Eso funciona para cosas como los controles flotantes porque puede detectar el tipo de entrada que lo activó, lo que proporciona objetivos táctiles más grandes si son convocados por una entrada táctil.

Esto no funciona para los controles siempre visibles, ya que algunos dispositivos táctiles también tendrán un mouse conectado.

Los desarrolladores podrán cambiar la opción predeterminada, por supuesto, y si una aplicación recibe muchos comentarios que solicitan que el botón de cerrar solo se muestre al pasar el mouse, entonces pueden optar por cambiarlo.

He agregado una idea para el desbordamiento de pestañas

Me encanta esto.

Sólo una pequeña cosa. Cuando hay sombras y esquinas redondeadas, es posible que queramos un pequeño espacio entre el elemento de la pestaña seleccionada y el borde del fondo.

Me encanta esto.

Sólo una pequeña cosa. Cuando hay sombras y esquinas redondeadas, es posible que queramos un pequeño espacio entre el elemento de la pestaña seleccionada y el borde del fondo.

Es curioso por qué sería necesario... ¿No se recorta la sombra con el marco de la ventana? ¿Es solo una elección estética para que la sombra sea visible arriba?

Tamaño de pestaña

@mdtauk : ¡Me encanta ver estos diseños! Tengo algunas preguntas de sondeo:

• ¿Es el morado el color de acento?
• ¿El propósito de la captura de pantalla de desbordamiento es mostrar los parachoques? Sólo quiero asegurarme de que estoy leyendo la imagen correctamente.
• ¿Cuál es el radio de la esquina de las pestañas?
• ¿Qué altura tienen las pestañas?
• ¿Qué tamaño de fuente se utilizó?

Usaré estos diseños para hablar con nuestros amigos en la Terminal y ver qué piensan. Estos diseños incluyen algunos deltas de nuestra dirección actual, pero los usaremos para ayudar a fomentar la conversación.

@Felix-Dev: Gracias por los comentarios; abordar algunos de sus puntos a continuación.

Así, su concepto de pestaña se parece mucho más a las pestañas de Edge UWP que a las pestañas de Edge Chromium. En mi opinión, el aspecto del control de pestañas debe ser lo más parecido posible al control de pestañas en Edge UWP. Acrílico como fondo de control de pestañas como en Edge UWP también sería bastante bueno.

Estamos iterando activamente con varios equipos (incluidos los equipos de Terminal y Edge) para tratar de alinear las pestañas en estas experiencias de aplicaciones. A medida que continuamos iterando (e implementando elementos como el #524), el diseño del control de pestañas se verá más consistente con los controles actualizados.

Todavía espero que el botón de cierre de pestaña se pueda hacer como en Edge UWP, donde el botón solo se muestra para la pestaña seleccionada actualmente o al pasar el mouse sobre la pestaña.

A corto plazo, nos estamos enfocando en implementar los escenarios que Terminal necesita y recortar la superficie de la API donde corresponda. Para v1, solo admitiremos Persistente. Dicho esto, originalmente también especifiqué el comportamiento de desplazamiento porque creo que es una gran idea. Hago un seguimiento de este tipo de solicitudes (como x-on-hover, ubicación de pestañas, etc.) para que podamos volver a evaluar en la siguiente versión del control.

Para el equipo de WinUI: @stmoy Aparentemente, el equipo de Windows Terminal no puede usar acrílico como fondo para el control de pestañas (ver microsoft/terminal#1375). El equipo de la terminal afirma que se debe a limitaciones arquitectónicas. ¿Es algo con lo que podría ayudar el equipo de WinUI? Parece que hay bastantes fanáticos del fondo acrílico para el control de pestañas como en Edge UWP.

Estamos trabajando activamente con el equipo de Terminal. Desafortunadamente, este escenario es el resultado de una limitación conocida con Xaml Islands y no con Tabs. Esperamos que las aplicaciones que no sean de Terminal puedan usar un fondo acrílico como una característica de "suscripción" si la aplicación establece TabControl.Background en un pincel acrílico.

¿Es el morado el color de acento?

Sí, no quería confundir mi diseño con una composición de diseño oficial.

¿El propósito de la captura de pantalla de desbordamiento es mostrar los parachoques? Sólo quiero asegurarme de que estoy leyendo la imagen correctamente.

Sí, muestra cómo se verían los botones izquierdo y derecho, y cómo se recortarían las pestañas.

¿Cuál es el radio de la esquina de las pestañas?

4 epx: sé que la guía es 2epx, pero la altura de 4epx del indicador seleccionado se veía mejor con 4

¿Qué altura tienen las pestañas?

40 píxeles

¿Qué tamaño de fuente se utilizó?

14 para el texto del título de la pestaña, 16 para los íconos MDL2

En Edge Canary hay una bandera llamada Nueva animación de carga de pestañas - edge://flags#new -tab-loading-animation

Parte de la especificación debe incluir un tema y/o animaciones implícitas como:

• TabAddAnimation
• PestañaEliminarAnimación
• PestañaSwitchToAnimation
• TabSwitchFromAnimation
• Pestaña seleccionadaCambiar a animación
• TabSelectedSwitchFromAnimation
• TabDragOutAnimation
• TabPlacedAnimation

@stmoy

Estamos trabajando activamente con el equipo de Terminal. Desafortunadamente, este escenario es el resultado de una limitación conocida con Xaml Islands y no con Tabs.

¿Es posible abordar esta limitación en futuras versiones de Xaml Island? Parece haber un fuerte deseo de acrílico de fondo en la aplicación Windows Terminal, por ejemplo. Consulte https://github.com/microsoft/terminal/issues/1375#issuecomment -504625390 y especialmente la última imagen de esa publicación (con acrílico de fondo en la barra de título). También tenga en cuenta los muchos votos positivos que recibió la publicación 😉. Otra publicación con muchos votos a favor aquí: https://github.com/microsoft/terminal/issues/1375#issuecomment -504644293

Hablando más ampliamente sobre el diseño de la interfaz de usuario de las pestañas, también tenga en cuenta las reacciones de apoyo a los comentarios de los usuarios que prefieren que las pestañas de Edge UWP busquen en Edge Chromium: https://github.com/microsoft/terminal/issues/1375#issuecomment -504622788 y el publicar directamente debajo de él.

Si las pestañas de Edge Chromium están destinadas a representar el aspecto futuro de las pestañas de Windows (modernas), esas abrumadoras reacciones de los usuarios podrían ser una razón para repensar el aspecto de las pestañas que se usan tanto en Edge Chromium como en WinUI. (También agrega @chigy aquí para que pueda notar las reacciones de la interfaz de usuario de la pestaña en el repositorio de Windows Terminal).

Editar: también llamar la atención de @ marb2000 sobre este tema, ya que el equipo de Windows Terminal acaba de reafirmar que "no podrán solucionar" este problema. ¿Cómo ve el equipo de WinUI las posibilidades de que la barra de título de acrílico (muy solicitada) suceda para la Terminal de Windows? @stmoy

@marb2000 @stmoy Comente la siguiente pregunta:

También llamo la atención de @marb2000 sobre este tema, ya que el equipo de Windows Terminal acaba de reafirmar que "no podrán solucionar" este problema [(barra de título acrílica en la terminal)]. ¿Cómo ve el equipo de WinUI las posibilidades de que la barra de título de acrílico (muy solicitada) suceda para la Terminal de Windows?

@marb2000 @SavoySchuler @jesbis @jevansaks

Hizo ping a todos, uno de ustedes, de la reciente llamada de la comunidad 😁
Sobre el soporte técnico de la barra de título de acrílico en Xaml Islands (Terminal de Windows), vea mis publicaciones anteriores y que @stmoy ya respondió en parte

Aquí hay tres de los puntos principales tomados de mis publicaciones y las respuestas anteriores:

Para el equipo de WinUI: Aparentemente, el equipo de Windows Terminal no puede usar acrílico como fondo para el control de pestañas (ver microsoft/terminal#1375). El equipo de la terminal afirma que se debe a limitaciones arquitectónicas. ¿Es algo con lo que podría ayudar el equipo de WinUI? Parece que hay bastantes fanáticos del fondo acrílico para el control de pestañas como en Edge UWP.

Respuesta de @stmoy :

Estamos trabajando activamente con el equipo de Terminal. Desafortunadamente, este escenario es el resultado de una limitación conocida con Xaml Islands y no con Tabs. Esperamos que las aplicaciones que no sean de Terminal puedan usar un fondo acrílico como una característica de "suscripción" si la aplicación establece TabControl.Background en un pincel acrílico.

Mi pregunta:

También llamo la atención de @marb2000 sobre este tema, ya que el equipo de Windows Terminal acaba de reafirmar que "no podrán solucionar" este problema [(barra de título acrílica en la terminal)]. ¿Cómo ve el equipo de WinUI las posibilidades de que la barra de título de acrílico (muy solicitada) suceda para la Terminal de Windows?

Gracias por responder 😁