¿Qué tal simplemente .ui?

¿Podría esta distinción ser útil también para los casos no insulares, o sería más confuso?

O si esto es principalmente para ayudar a distinguir entre, por ejemplo, WPF y WinUI Xaml en la misma solución, ¿qué pasa con una convención como .winui.xaml o .island.xaml ? Eso probablemente facilitaría el uso de las herramientas existentes.

¿Sería esto para escenarios de islas XAML o en todas partes? Para todos los demás escenarios, no veo cuál sería el valor de esto, más allá de crear confusión y obligar a las personas a migrar (y probablemente rompa la compatibilidad con versiones anteriores para muchas herramientas como versiones anteriores de VS). Una convención como "lo que sea.winui.xaml" probablemente sería menos destructiva, pero aún así solo veo que es útil en el ámbito de una isla, no en cualquier otro lugar.

Cambiando el título dado, no quiero reducir el alcance de la discusión solo a las islas XAML.

Yo digo seguir usando .xaml. El alcance (y el nombre) de WinUi podría cambiar para incluir otras plataformas además de Windows (¿Quizás a través de UnoPlatform?). ¿Qué pasa si cambia el nombre del proyecto?

Me inclino más por el NO. Microsoft ha estado haciendo demasiados cambios de nombre para productos y servicios, a veces en detrimento del producto/servicio o de sus usuarios (opinión). Este es otro cambio de nombre.

¿Sería esto para escenarios de islas XAML o en todas partes? Para todos los demás escenarios, no veo cuál sería el valor de esto, más allá de crear confusión y obligar a las personas a migrar (y probablemente rompa la compatibilidad con versiones anteriores para muchas herramientas como versiones anteriores de VS). Una convención como "lo que sea.winui.xaml" probablemente sería menos destructiva, pero aún así solo veo que es útil en el ámbito de una isla, no en cualquier otro lugar.

En todos lados

Creo que XAML debería seguir siendo .xaml, pero si apareciera algo nuevo para reemplazar o ser útil junto con el XAML tradicional, entonces una extensión .winui podría ser útil para eso. #804 :)

Esta solicitud me confunde totalmente... Tuve que leer este número dos veces para comprender lo que estaba pasando... Esto REALMENTE fragmentará el ecosistema xaml más de lo que lo hicieron los diferentes dialectos...

Sin palabras en este momento...

@liquidboy bueno, ese es al menos un comentario claro a favor de no hacer este cambio :) Gracias por prestar su voz.

Me gusta la idea de @jesbis , tal vez podríamos agregar un *.islands.xaml que ayude a distinguir más fácilmente la diferencia entre los archivos XAML que se ejecutan en un contexto de Islas y los que no.

Curioso: ¿sería mejor tener .islands.xaml que solo se aplica a los archivos XAML en una isla, o simplemente usar .winui.xaml como una extensión general en todas partes? No estoy seguro de cuál me gusta más de esas dos ideas.

Mi voto es para que ".islands.xaml" o similar sea el patrón recomendado (pero no estrictamente aplicado) en las islas, y en cualquier otro lugar, los archivos .xaml siguen siendo archivos .xaml. Así evitamos impactar innecesariamente a personas que no utilizan islas.

Mi mayor preocupación proviene de todas las herramientas. No tengo ningún problema con la extensión diferente, pero esto significa que cada herramienta que se basa en la extensión de archivo .xaml deberá actualizarse (estoy pensando en cosas como R#, XamlStyler , etc.). El soporte de herramientas en torno a xaml ya se siente como si estuviera luchando, y parece que esto probablemente empeorará las cosas.

Mis $0.02

Tal vez el título del problema debería cambiarse a algo como:
¿Deberían los archivos XAML incluidos para Xaml Islands tener una extensión de archivo diferente con los proyectos de WinUI 3?

Estoy totalmente a favor de mantener .xaml allí. Tal vez opte por .ui.xaml o .xaml.ui, pero la tecnología es sólida y mantiene la ayuda disponible. Por otro lado, desafortunadamente, xaml tiene cierto estigma a su alrededor después de las trampas de rendimiento de wpf, silverlight y windows phone, por lo que un nombre de archivo más limpio podría ayudar a dar la vuelta a la esquina. Todavía me encanta xaml, pero no necesitamos más confusión sobre los nombres de la tecnología a menos que esté claramente pensado.

Creo que es una buena idea tenerlo simplemente como .ui, ya que si winui alguna vez se vuelve multiplataforma (como lo han hecho muchas cosas de Windows), será más adecuado.

Esto significa que será una prueba de futuro.

Los archivos de código tendrán una extensión .ui.cs que se explica por sí misma y es fácil de leer.

.winui.xaml

¿Eso significa que tendremos archivos .winui.xaml.cs? ay..

Utilice el formato json. es 2020

JSON es duro y no muy amigable para trabajar.

Utilice el formato json. es 2020

El formato JSON es para que lo lean las computadoras, no para los humanos. Es difícil de leer y no se ve bien.

Creo que el .winui hará que el principiante se dé por vencido. Porque pensaremos que debemos aprender un nuevo idioma. Y ahora tenemos WinForms y WPF y UWP y SL y ASP y ASP.NET Core. Deberíamos dedicar cada vez más tiempo a aprenderlo pero no a heredarlo. No creo que siempre debamos hacer la nueva tecnología.

Lo siento, a mí y a muchos de mis amigos no nos gusta aprender cosas nuevas. Si no esperamos ser minoría, que debemos hacer que la tecnología se pueda heredar y se pueda reutilizar y sea compatible.

En mi opinión, una solución más elegante para "cuál XAML es cuál" sería depender del espacio de nombres xmlns predeterminado, como sugiere @grokys en este comentario: https://github.com/AvaloniaUI/AvaloniaVS/issues/95# problemacomentario -541078633

No hicimos esto con UWP, pero tal vez podamos cambiarlo por WinUI.

En mi opinión, una solución más elegante para "cuál XAML es cuál" sería depender del espacio de nombres xmlns predeterminado, como sugiere @grokys en este comentario: AvaloniaUI/AvaloniaVS#95 (comentario)

No hicimos esto con UWP, pero tal vez podamos cambiarlo por WinUI.

¿Podría introducir el equivalente de un Doctype, como con HTML?

¿Podría introducir el equivalente de un Doctype, como con HTML?

Tal vez, pero no deberíamos tener que hacerlo. El espacio de nombres predeterminado debe ser lo que distingue a cada plataforma diferente (después de todo, lo hacen en el código subyacente)

El soporte de herramientas en torno a xaml ya se siente como si estuviera luchando, y parece que esto probablemente empeorará las cosas.

@keboo , esto me afecta mucho, y es algo que estoy presionando para que lo arreglemos y lo hagamos bien.
El hecho de que estemos en un mundo donde no podemos distinguirlos (para el escenario de las islas) es producto de cómo ha evolucionado la herramienta a lo largo de los años. Todo está completamente separado y es casi imposible racionalizar las diferencias entre los diferentes dialectos. Quiero cambiar esto y comenzar a hacer que el análisis y la compilación de XAML se puedan compartir fácilmente entre todos los dialectos de XAML, donde en este ejemplo, WinUI y WPF usan el mismo motor fundamental. Las herramientas deben ser compatibles con complementos según lo declarado por el espacio de nombres predeterminado y se pueden personalizar cuando sea necesario. En mi opinión, no deberíamos necesitar nada más que eso para que este escenario funcione correctamente. Aunque es un gran esfuerzo, para mí es lo correcto que todos debemos hacer.

@stevenbrix La plataforma comprendería actualmente cuándo se usa XAML en una situación de isla, pero lo que leí en la pregunta de este problema es una forma para que el desarrollador diga y comprenda cómo se consumirá el archivo .xaml dentro de WinUI 3.0 proyecto.

En cuanto a las herramientas XAML en general, necesita una renovación total de la experiencia de tiempo de diseño de la OMI. Expression Blend fue la última vez que el diseño y el desarrollo de XAML se sintieron de primer nivel.

Debido a la naturaleza de XAML, es tanto una forma escrita como una forma visual. El diseño visual XAML ha pasado a un segundo plano para llevar Intellisense a una buena calidad. Si pudiera haber una experiencia de diseño XAML robusta, eficaz y fácil de crear prototipos y pulir, eso podría revitalizar a la comunidad.

Un enfoque de complemento, que no requiere mucho trabajo para que lo hagan los proveedores de control o kit de herramientas, al tiempo que brinda un buen tiempo de diseño, paleta de herramientas, experiencia en propiedades de elementos, podría ser muy útil. A medida que XAML pasa a otros factores de forma no tradicionales, se debe tener en cuenta el flujo de trabajo de diseño. Vistas de dos paneles (Neo y Duo), superficies XAML no alojadas en ventanas, integraciones de Shell, proyectos de marcos mixtos (xaml island, GDI y combinaciones de WinUI), Hololens Spatial 3D, Rotating Surface Hubs, etc.

Pero tal vez el marcado declarativo ya no sea la forma ideal de manejarlo. ¿O tal vez debería haber más separación entre el contenido XAML y el estilo XAML? ¿Como con HTML y CSS?

WinUI se siente como una buena oportunidad no solo para continuar con las cosas tal como están, sino también para planificar las próximas décadas.

No. No veo el punto. No resuelve nada.
En todo caso, crea problemas con los editores que ya conocen la extensión xaml.
Trabajo con wpf, uwp y formularios xaml todos los días y nunca me he confundido debido a la extensión.

¿No es el punto central de Xaml que es más fácil para las herramientas? ¿Las herramientas no pueden resolver esto sin confiar en la antigua idea de las extensiones de archivo?

Quiero decir, en general, si nada cambia en el marco de la interfaz de usuario, es decir, todavía es XAML, no lo haga.

Si fuera un marco de interfaz de usuario completamente nuevo, entonces no vería ningún problema.

Tampoco sé por qué querrías diferenciar los componentes XAML para las islas con el islands.xaml propuesto. ¿Haría algo diferente en las herramientas o es solo por la legibilidad en una solución?

Mi primer pensamiento es que absolutamente no me gusta esta idea. Pero tal vez no veo los problemas reales que puede resolver, y tal vez no entiendo el punto.

Si hay un archivo con xaml, quiero que sea un archivo .xaml. En el pasado, nunca se me ocurrió que quería que un archivo .xaml de UWP tuviera un nombre diferente al de un archivo .xaml de WPF.

Lo siguiente es que un nombre de marco en una extensión de archivo no parece ser una buena idea, ya que los nombres de los marcos pueden cambiar y XAML es 4ever XAML.

Entonces, mi opinión es: definitivamente quédate con .xaml.

Pero, ¿cuáles son las opciones con una extensión de archivo .xaml?
¿Otra extensión de archivo .islands.xaml? Eso significaría que la extensión de archivo se usa no solo para describir el formato, sino también el contenido de un archivo. Mhm... Pero la ventaja de este es que puedes hacerlo opcional para un desarrollador. Si quieren usarlo, pueden llamar a sus archivos .islands.xaml y las herramientas lo recogerán con diferentes íconos, etc.

Otro espacio de nombres predeterminado también es una opción válida. Pero eso significaría para las herramientas que tiene que buscar en cada archivo .xaml para averiguar qué tipo de archivo es. Y también significaría que los dialectos XAML vuelven a divergir un poco debido a otro espacio de nombres raíz.

Pero ahora un pensamiento completamente diferente:

Si lo hice bien, todos estos cambios solo son realmente útiles para el caso de la isla XAML en el que se combinan plataformas en la misma solución, ¿verdad? Porque si solo usa WinUI, sabe que todos los archivos XAML usan WinUI. No estoy seguro de si las islas XAML serán un escenario principal para WinUI o no. En el pasado, cuando se introdujo WPF, también teníamos la interoperabilidad de WPF y WinForms y, para ser honesto, rara vez he visto a los desarrolladores usar controles WPF en sus aplicaciones WinForms. En cambio, continuaron usando WinForms en WInForms y comenzaron nuevos proyectos con WPF en lugar de WinForms. Y tal vez lo mismo podría ser cierto para WinUI 3, y creo que será el caso. XAML Islands es una excelente manera de modernizarse, pero según mi experiencia, los desarrolladores solo lo harán si definitivamente necesitan un control de WinUI en su aplicación WPF/WinForms. Si no, continúan en la pila anterior y comienzan aplicaciones nuevas en la pila nueva. Tenga en cuenta que esto no tiene que ser la verdad, es solo mi experiencia. :-)

Eso significa que estamos hablando de cambiar el nombre de un archivo para un escenario que podría no ser el escenario principal de la plataforma. Y supongo que por eso creo que no vale la pena. ¿Qué sucede si un desarrollador de WPF/UWP/Silverlight/Windows Phone crea un nuevo proyecto de WinUI 3? Ellos pensarán

¿Por qué diablos cambiaron la extensión del archivo .xaml a...?

No elimine la extensión de archivo .xaml.

¡Por favor, no vayas cambiando extensiones!

Hace muchos años empezamos a usar la extensión .paml en Avalonia pero al final volvimos a .xaml debido a los problemas que causaba: ya hay herramientas en los IDE para manejar XAML (no importa cuán , al menos es algo!).

Si vamos a esperar que cada dialecto XAML tenga su propia extensión de archivo, entonces cada proyecto que quiera usar XAML tendrá que escribir el 100% de las herramientas desde cero, incluso cosas como las herramientas para cambiar el nombre de los archivos van a necesitar para ser reescrito cada vez para también cambiar el nombre de las clases de código subyacente, etc.

Como @stevenbrix mencionó anteriormente, hay una manera perfectamente buena de saber qué dialecto de XAML está usando un archivo, cuál es el espacio de nombres predeterminado en la parte superior del archivo. Como primer paso, haga que las herramientas respeten esto.

Luego abra el servicio de lenguaje XAML, proporcione una API para interactuar con un diseñador y todos pueden beneficiarse;)

Bastante por favor ;)

Una razón más para no hacerlo: UWP ya tiene problemas con los problemas de adopción. Cambiarle el nombre lo vende como otra tecnología más, en lugar de "es más o menos lo mismo que wpf".
Ya hay problemas más grandes con los cambios importantes de WinUI 3.0 que dañarán significativamente el ecosistema uwp existente. No agregues otra cosa que sea diferente.
Todavía es xaml, solo toca diferentes conjuntos de API, al igual que c # sigue siendo c #, incluso lo uso para un marco de interfaz de usuario diferente. El código y las API que puedo usar cambian, pero sigue siendo el mismo idioma.

Voto no, no veo beneficios, solo añado confusión.

Una razón más para no hacerlo: UWP ya tiene problemas con los problemas de adopción. Cambiarle el nombre lo vende como otra tecnología más, en lugar de "es más o menos lo mismo que wpf".
Ya hay problemas más grandes con los cambios importantes de WinUI 3.0 que dañarán significativamente el ecosistema uwp existente. No agregues otra cosa que sea diferente.
Todavía es xaml, solo toca diferentes conjuntos de API, al igual que c # sigue siendo c #, incluso lo uso para un marco de interfaz de usuario diferente. El código y las API que puedo usar cambian, pero sigue siendo el mismo idioma.

@dotMorten Ja, pensé lo mismo con C#. Si llamamos a los archivos $ .xaml .winui , deberíamos llamar a los archivos $ .cs .wincode para que sea consistente. :-)

Tal vez todavía me falta algo, pero a mí me causa más confusión y no veo los beneficios reales de ello.

Mis 2 centavos, quédate con _.xaml_, por favor.
Por favor, una las cosas en lugar de divergirlas.

¿Qué sucede si desea compartir pequeños fragmentos de código XAML entre WPF y WinUI? Supongo que debe haber ALGUNA superposición, ¿no? Haría que los proyectos compartidos fueran menos útiles... ¿o realmente hay una gran diferencia? Si se trata principalmente del mismo XAML similar, mantenga la misma extensión. Si el formato es MAYORMENTE diferente al XAML de transición, entonces podría ser algo más aceptable cambiar la extensión. La verdadera pregunta es, entonces, ¿qué tan cerca está el formato del original?

XAML también se usa en Xamarin, que se dirige no solo a Windows, sino también a iOS, Android, macOS...

Reemplazar .xaml por .winui creará una situación en la que Xamarin mantendrá .xaml para archivos XAML (¿por qué se usaría .winui para iOS o Android?) y los objetivos de Windows como UWP/WPF... se moverán a .winui para archivos XAML .

TL;DR un formato de archivo/convención dos nombres (.winui para Windows, .xaml para Xamarin), para mí es confuso.

La extensión debe ser .xaml como sintaxis del contenido es xaml, otra extensión solo crearía confusión.
Voto por algo como .winui.xaml

quédate con ".xaml", es poderoso

Debo decir que Microsoft tiene un problema de denominación patológica.

Y este realmente los supera a todos.

No

Si necesita tener UWP XAML y WPF XAML dentro del mismo archivo de proyecto, use un nuevo Custom Tool en su lugar.

De esta forma, la herramienta detectará si el archivo XAML usa UWP XAML o WPF XAML y los envía al compilador correcto a través de objetivos de msbuild.

Una forma aún mejor es estandarizar el lenguaje XAML, de modo que podamos desarrollar un compilador común, un formato binario y una librería de framework.

¡Así lo haría yo!

Ya que lo preguntas, no, no lo hagas.

Si las herramientas no pueden leer el archivo para ver la diferencia, entonces PEOR CASO debería ser una convención no requerida de ".winui.xaml" o similar. De nuevo, la clave NO ES REQUERIDA. Solo los archivos de extensión xaml deberían funcionar bien, pero tal vez falten algunas herramientas mejoradas.

Si bien entiendo la idea detrás de esto, creo que es una mala solución.
Primero, WinUI es el nombre comercial del marco, no el formato de archivo. ¿Qué pasa si alguien decide que la versión 4 necesita cambiar el nombre a UniversalUI o algo más? Terminaría con un nombre de marco diferente de la extensión del archivo, diferente del formato del archivo. Podría ser una pesadilla.

En segundo lugar, podría romper la compatibilidad con las herramientas y la documentación existentes. Los futuros desarrolladores no podrían tener claro que los archivos WinUI son internamente xaml, por lo que no encontrarían documentos xaml como relevantes.

En tercer lugar, fragmentaría más los idiomas de la interfaz de usuario utilizados en los productos de Microsoft. Realmente creo que debemos ir más a un estándar en Xaml, por lo que el producto no es tan importante. C# es el mismo para Xamarin, Net Core, Windows 10 o WPF, ¿por qué XAML debe ser diferente?

Deje que las personas organicen sus proyectos y organicen el código para que no les resulte confuso.

Utilice el formato json. es 2020

@rickydatta Incluso en 2020, la web usa HTML en lugar de JSON para definir las interfaces de usuario. Hay muchas razones por las que los lenguajes de marcado como HTML y XAML son excelentes para definir IU. JSON es excelente para varias cosas, pero no para definir interfaces de usuario. Cuando usa JSON para una interfaz de usuario e intenta crear funciones como enlace de datos, referencias de recursos estáticos, etc., verá que se vuelve bastante ilegible. Pero está fuera de tema aquí, así que dejémoslo. Si desea JSON, cree un nuevo problema y veamos cómo reacciona la comunidad. :-)

Realmente traté de evitar comentar aquí ya que la mayor parte de esto ya se ha dicho, pero cedí. Lo siento. Estoy débil.

No hagas esto.

Si desea realizar un cambio, debe haber un conjunto claro de beneficios que superen los aspectos negativos.

¿Cuáles son los beneficios potenciales?

• Evitaría posibles confusiones para las personas que tienen algunos archivos .xaml que contienen controles WinUI en su totalidad y algunos archivos .xaml que no los contienen.
• Ayude a habilitar las herramientas para determinar cómo trabajar con el contenido potencialmente diferente de los archivos .xaml.

Eso es.
He vuelto a leer este hilo completo tres veces y no puedo ver ningún otro beneficio potencial enumerado aquí.

¿Cuáles son las posibles desventajas?

• Introduciría confusión.
  -- "¿Qué es esta nueva extensión?" "¿Qué necesito para abrirlo?" "¿En qué se diferencia de...?" "¿Porque lo han cambiado?"
  -- ¿Qué extensión usa para un archivo que solo contiene algunos controles de WinUI, cuando combina elementos UWP XAML y WinUI3 existentes? ¿O esta misma sugerencia implica que esta capacidad desaparecerá? (Vea, simplemente al hacer la sugerencia de cambiar una extensión de archivo, ya está introduciendo más confusión y FUD. Si cosas como las extensiones de archivo aún pueden cambiar, tal vez debería esperar a mirar WinUI, en cualquier capacidad, hasta que sea más estable . Varias personas me han dicho que investigue Flutter. Tal vez ahí esté un mejor futuro para mí.)
  -- Mi comprensión de uno de los puntos de venta de Xaml Islands en las aplicaciones WPF existentes era que significaba la capacidad de reutilizar las habilidades y los conocimientos existentes al trabajar con XAML. Este cambio sugiere que no se trata solo de XAML, por lo que es otra cosa que se debe aprender, y también es otra barrera potencial para la adopción).

• es innecesario
  -- Si las personas quieren dividir archivos dentro de una solución, ya pueden hacerlo de varias maneras: diferentes proyectos; diferentes directorios; prefijos o sufijos en nombres de archivos; usando múltiples/sub-extensiones; o anidando archivos dentro del explorador de VS Solution. No está claro cómo una nueva extensión u obligar a todos a usar múltiples/subextensiones es mejor que cualquiera de estas opciones.
  -- [Predeterminado] Los espacios de nombres dentro del archivo ya le indican a las herramientas qué dialecto de XAML está en uso y qué debería ser posible con él. (Puede haber algún problema no documentado en esta área, lo que significa que esto no es posible, pero si ese es el caso, se necesita más información sobre por qué cambiar la extensión del archivo es la mejor solución para ese problema).

• Ignora la historia.
  -- Anteriormente trabajé con soluciones que contenían proyectos dirigidos a WPF, Silverlight y Windows Phone. Todos usaban diferentes dialectos XAML, pero nunca me confundí sobre cuál estaba en uso o qué podía hacer dentro de un archivo. Trabajé con soluciones que contienen XAML para UWP y Xamarin.Forms, pero no experimenté la confusión prevista en la suposición detrás de este problema. También hablé con muchos otros desarrolladores con soluciones similares, y nunca escuché a nadie más decir que el uso de diferentes extensiones les ayudaría.
  -- De todas las críticas que he escuchado sobre la existencia de diferentes dialectos de XAML, la confusión basada en el nombre de los archivos nunca ha sido una de ellas.
  -- A los desarrolladores generalmente no les gusta que les digas cómo deben nombrar y estructurar archivos y proyectos sin una buena razón. Puede ser mucho mejor documentar la guía y las prácticas recomendadas/sugeridas para escenarios como trabajar con proyectos que contienen archivos con contenidos similares.
  -- Una razón importante por la que el uso más amplio de múltiples extensiones en un archivo nunca ha despegado es que el Explorador de archivos (o cualquier cosa que enumere el contenido del sistema de archivos, incluidos los selectores y el cuadro de diálogo proporcionados por el sistema operativo) puede generar más confusión cuando ( están configurados para (que es el valor predeterminado) ocultar las extensiones de archivo conocidas. Esto puede hacer que MyClass.winui.xaml parezca MyClass.winui lo que genera preguntas y confusión sobre qué es el archivo, de dónde proviene, por qué se muestra, etc.
  -- Agregar múltiples/subextensiones aumenta la longitud del archivo y, por lo tanto, aumenta las posibilidades de encontrarse con problemas relacionados con MAXPATH. Tal vez algún día esto no sea un problema, pero aún no hemos llegado a ese punto. Odiaría ver que los desarrolladores se vean obligados a dar a sus archivos (y clases, ya que los dos se mantienen sincronizados) nombres menos descriptivos porque las herramientas ahora necesitan seis caracteres adicionales para la(s) extensión(es).

• Crea más trabajo para los desarrolladores de herramientas. (Tanto dentro como fuera de Microsoft).
  -- Más caso para manejar.
  -- Más escenarios para documentar y probar.
  -- Menos tiempo dedicado a la corrección de errores y nuevas funciones. Con las herramientas XAML actuales percibidas como carentes de otras tecnologías y lentas para crear herramientas personalizadas, ¿por qué hacer algo que haga que la creación de nuevas herramientas sea más lenta?

• Se corre el riesgo de sentar un precedente muy malo.
  -- Si esto sucediera, ¿por qué no sería apropiado reemplazar todos los archivos .xaml actuales con .wpf , .uwp , .xamarinforms , etc.? ¿O .xaml2006 , .xaml20009 , .xaml-uwp5 si el espacio de nombres subyacente, en lugar de dónde se usan, es el problema clave? Habría un beneficio potencial mínimo (como en este caso), pero muchos lo verían como la forma en que Microsoft sugiere nombrar los archivos. (No me sorprendería si alguien no hiciera tales propuestas solo al ver la discusión aquí).
  -- No estoy al tanto (pero me alegra que me corrijan) de cualquier herramienta proporcionada por MS que maneje archivos de manera diferente en función de las subextensiones, pero hacer esto probablemente obligaría a Visual Studio (¿y a otros?, ¿incluido Windows Shell?) a necesitar ser capaz de manejar estos escenarios. Luego, una vez que la capacidad está allí, puedo imaginar la tentación de introducir una amplia gama de sugerencias de nombres complejas pero innecesarias que se proponen e introducen como demasiado para algunos desarrolladores, lo que genera confusión para el resto de nosotros.

En resumen, la propuesta traería confusión y más trabajo por un beneficio teórico en circunstancias limitadas. Si hicieras esto, renunciaría al desarrollo de Windows.

Gracias a todos por prestar su voz. ¡Te escuchamos! Recopilamos suficientes comentarios, por lo que podemos decir firmemente que cambiar la extensión .xaml es imposible .

No es nuestra intención fragmentar el ecosistema o romper herramientas de terceros (y hay muchas). Estamos de acuerdo en que XAML es el lenguaje y WinUI 3 es un marco de interfaz de usuario que usa XAML. Por todas estas razones, y otras más, tiene sentido continuar usando la extensión xaml.

Nuestro equipo aún tiene que hacer algunos deberes y evaluar otras alternativas que deberíamos consultar con la comunidad más adelante. Por ejemplo:

1. Hacer nada. La experiencia de desarrollo de XAML Islands será tal como es: archivos XAML en un proyecto diferente (quizás esto no sea gran cosa). WInUI 3 usará el mismo espacio de nombres, y no importa porque será el único lenguaje XAML que se use en el proyecto.

2. Usa espacios de nombres para diferenciar entre las IU basadas en XAML. Hoy en día, WPF XAML y UWP XAML usan los mismos espacios de nombres, quizás WinUI 3 debería usar un espacio de nombres diferente como lo está haciendo Xamarin Forms ("http://xamarin.com/schemas/2014/forms"), por lo que los compiladores, las herramientas y los diseñadores puede diferenciar archivos. Por otro lado, esto creará dialectos, aunque esto está sucediendo hoy. En teoría, esto facilitará que los desarrolladores copien y peguen ejemplos XAML de documentos/blogs, aunque, lamentablemente, hay muchos ejemplos que no incluyen espacios de nombres.

3. Haz algo, pero solo por las Islas. No es necesario diferenciar en todos los marcos de interfaz de usuario. Podemos usar convenciones. Por ejemplo, en el futuro, una aplicación WPF con XAML Island puede contener archivos XAML en una carpeta específica (¿carpeta de islas?). Esto es similar a la localización de UWP (Strings/en-US/Resources.resw).

Gracias de nuevo por sus comentarios . Abriré nuevas discusiones cuando maduremos más ideas.

Incluir una línea de estilo snippit o doctype para un archivo de isla debería ser suficiente para las herramientas.

Si le gusta la idea .ui.xaml porque es un buen compromiso. Sigue siendo una extensión XAML válida y también puede ayudar a seleccionar el editor y los iconos correctos. También es más eficiente que abrir y analizar docenas o cientos de archivos XAML solo para encontrar un tipo.

@marb2000 WinUI 3 es un marco de interfaz de usuario que usa XAML

Debería ser: WinUI 3 es un marco de interfaz de usuario que puede usar XAML. Dado que no requiere el uso de XAML y no necesita una dependencia del lenguaje XAML.

Estamos de acuerdo en que XAML es el lenguaje

Eso es bueno, y muchos espacios de nombres que se denominan XAML deben cambiarse de nombre en WinUI: cualquier cosa que no tenga que ver con el lenguaje XAML.

La falta de énfasis en UWP ha sido dolorosa de presenciar. Ahora, cuando realiza una búsqueda en el canal 9 de contenido para UWP, obtiene contenido de Xamarin. Es una estratagema tan obvia. ¡Deje de intentar transformar UWP en otra cosa! Reinvierte, duplica y haz que funcione. UWP no necesita una corrección de rumbo, necesita que los equipos de Xamarin y Office se incorporen. La política interna de Microsoft está acabando con UWP.

@Noemata ¿Es una nota oficial?