Creo que Xamarin se fusionará con .NET 5;
Sería genial si adoptaran UWP XAML como estándar y trabajaran a partir de ahí, Microsoft y UNO lo convierten en el mejor para escritorio, móvil, navegador web (Azure) e IoT.
podrían llamarlo
UWP vNext (basado en WinUI)/ Silverlight 6 (UNO)

Creo que el esfuerzo de Blazor fue un primer paso para llevar .NET oficialmente al WebBrowser, utilizando su representación predeterminada actual, es decir. el HTML DOM
Pero creo que pronto incluso podrán ofrecer otro motor de renderizado, un complemento ligero para WinUI, algo que orbite Silverlight, UNO Platform y Xamarin... como Flutter/WPF

Sería genial si adoptaran UWP XAML como estándar y trabajaran a partir de ahí.

Todo lo que ustedes quieren ya está sucediendo con Uno. MS haría bien en comprar a esos muchachos y luego contratarlos para guiar el desarrollo final de Uno.

Este es probablemente el lugar equivocado para solicitar una función como esta. Por mucho que me gustaría estar de acuerdo con todo en esta solicitud, creo que el equipo de WinUI y muchos desarrolladores senior en la comunidad de Windows sostienen que WinUI se define de manera muy estrecha.

En un mundo ideal, WinUI sería como Material Design. Habrá formas de tenerlo en cualquier plataforma con todo tipo de biblioteca que lo implemente. Sin embargo, WinUI no es un lenguaje de diseño y tampoco lo es Fluent Design. Microsoft, al no estar en el espacio modelo, ha hecho que su oferta de interfaz de usuario esté bastante por detrás de la competencia.

WinUI es una biblioteca de interfaz de usuario para aplicaciones de Windows, y esto es tan claro como parece. El lenguaje de diseño no está separado de la implementación, y la implementación es exclusiva de la plataforma debido a características como la composición que dependen en gran medida de la dependencia de la plataforma. Esto es malo desde la perspectiva de un desarrollador móvil/multiplataforma, pero el esfuerzo aquí es realmente para las aplicaciones de Windows.

Esta es también la razón por la que probablemente Uno Platform nunca pueda ser realmente WinUI en todas partes, a menos que porten DX 11 a todas las plataformas.

Le sugiero que busque en Comet (marco de desarrollo multiplataforma basado en .Net). Está en su etapa inicial, pero el concepto no es diferente a Flutter. También usa Skia (como una opción) para dibujar la interfaz de usuario con un patrón de interfaz de usuario componible/declarativo, por lo que los desarrolladores pueden implementar bibliotecas de interfaz de usuario como Material Design y hacer que se vea completamente igual en todas las plataformas.

No, no debería ser multiplataforma. Se llama interfaz de usuario de Windows por una razón. Vamos a obtener un sistema de interfaz de usuario que funcione en todos los Windows (plataformas e idiomas) para empezar, ¿eh? Eso ni siquiera se ha logrado todavía. Todavía estamos divididos entre .net framework, .net core, uwp y luego la historia de C++, que al menos tiene uwp, pero ningún desarrollador de juegos lo usa, porque UWP/WinRT todavía tiene algunos problemas: distribución, barra de tareas forzada y ventanas emergentes en la barra de título. cuando está en pantalla completa (yikes).

Pensar en multiplataforma sería un desperdicio colosal de recursos. Hágalo bien en Windows primero, por favor. Y saque .net 5, arregle UWP y la historia de las ventanas, y coloque DirectX en C#. Y arreglar el GC. Todavía hay mucho por hacer en el escenario estrecho, solo en Windows.

Y al OP.

• UWP es universal. Decir que no es universal es una afirmación falsa (nunca tuvieron la intención de apuntar a Android, gracias a Dios). La promesa original ha sido cumplida. Todos los dispositivos Windows ejecutan UWP. Windows Mobile era un sistema operativo separado, tenían que deshacerse de él. Todas las nuevas plataformas de Windows serán Windows (10 o 10X). Eventualmente basado en CoreOS, supongo. Y todos ejecutarán aplicaciones de Windows. El hecho de que no tengamos un teléfono con Windows en este momento es incidental. Tenemos todos los otros tipos de dispositivos. Y pronto tendremos Neo y Duo.

• Restricciones de sandbox: estas son cosas buenas. El acceso a todo el sistema de estilo Win32 debe eliminarse en general. Si tiene un requisito específico, debe presentar su requisito para que podamos discutir cómo podría o debería hacerse dentro de un contenedor UWP y si se le debe permitir hacerlo de la manera que sugiere. Y averigüe si UWP necesita esa característica. Porque puedo pensar en algunas aplicaciones avanzadas que podrían escribirse en UWP sin problema. Puedo tiene programa! Necesita discutir detalles.

• .net nativo está siendo reemplazado y la historia de la distribución cambiará con .net 5. Creo que es justo decir que Microsoft está trabajando en esto. Seguramente conocen los problemas. Pero debe presentar problemas específicos para abordar los problemas subyacentes reales aquí.

• "No acople WinUI a DirectX" - ¿WTF? Absolutamente debería combinarse con DirectX, que es la pila de gráficos nativos de Windows. Por favor, ni siquiera consideres nada más. Absolutamente no quiero encontrar superficies de renderizado OpenGL debajo del capó. Eso rompería la compatibilidad y causaría todo tipo de caos.

@Gavin-Williams

Maravilloso, hagamos una actualización ligeramente evolutiva sobre WPF.

UWP es universal

"Todos los dispositivos Windows ejecutan UWP" no significa nada sin dispositivos móviles. HoloLens es un nicho, Surface Hub es un nicho, Windows 10 IoT Core es una broma.

Absolutamente debería combinarse con DirectX.

Como desarrollador, el acoplamiento duro me pone la piel de gallina. ¿Hay alguna razón importante por la que la pila de gráficos no se pueda intercambiar?

Se llama "modularidad". Microsoft siempre ha luchado con eso.

Las restricciones de sandbox son buenas

Sí, lo son, siempre que no limiten severamente el rango de aplicaciones que se pueden construir. ¿Ha intentado cambiar el tamaño de una partición de UWP?

Creo que vale la pena mencionar y recordar que Google está desarrollando Flutter y no lo llaman GoogleUI o AndroidUI. Funciona en todas partes, incluso en la web y el escritorio. Digo esto porque parece haber una propensión a "simplemente hacer que funcione en Windows", pero si existe otra oferta competitiva que sea más barata, más rápida, más fácil de usar, Y funcione en Windows + todo lo demás... ¿qué harán los desarrolladores ( y mercado correspondiente) elegir? Puedo decirle como propietario de una pequeña empresa que sé dónde estoy poniendo mi inversión dadas las dos opciones.

Portar DirectX a otras plataformas parece un gran trabajo, tal vez la solución sea usar OpenGL o Vulkan en lugar de DirectX.

@Gavin-Williams, no sé si está familiarizado con UWP, pero cuando crea/distribuye, apunta a una versión específica (o rango de versiones) de Windows. Esa idea está absolutamente acoplada y es una de las razones por las que UWP no se generalizó tanto como lo hizo WPF.
@nerocui, todo el propósito de un lenguaje de interfaz de usuario es desacoplar el diseño de la interfaz de usuario del dibujo sin formato en una pantalla. Es por eso que ves que HTML puede renderizarse en ARM/x64/x64.

XAML proporciona una excelente abstracción de las primitivas/composición/animación de la interfaz de usuario; la solicitud tiene mucho sentido debido al costo de desarrollo y al alcance de la plataforma.

Respetuosamente no estoy de acuerdo con @SuperJMN. Ciertamente, UWP aún no ha alcanzado la paridad de funciones con WPF. A pesar de sus limitaciones como marco para crear herramientas a nivel de kernel, para prácticamente todas las demás tareas de desarrollo de software, con las capacidades correctas especificadas en el manifiesto de la aplicación, tiene una experiencia de usuario mucho mejor desde múltiples perspectivas (seguridad, facilidad de implementación, instalación/desinstalación). experiencia, etc). La zona de pruebas de seguridad de UWP es una característica importante (esencial). En muchos aspectos, UWP ahora está muy por delante de WPF.

El compilador UWP .Net elimina la necesidad de ofuscar el código y la inestabilidad que esto puede generar en WPF. El rendimiento tiene la posibilidad de mejorar con el tiempo sin cambios en el código a medida que se mejora el compilador. UWP en sí tiene un diseño mucho mejor en términos de cómo aprovecha DirectX y otros recursos a nivel del sistema. También tiene una gran ventaja sobre WPF cuando se integra con otros lenguajes, C++ en particular. La integración de componentes C++ de alto rendimiento con C# es trivial en UWP. El acceso a las superficies de DirectX también ha mejorado mucho.

Los agujeros restantes en UWP se pueden tapar fácilmente. Yo diría que el mayor problema ha sido el fracaso de Microsoft en alcanzar el nivel de calidad asociado con WPF. WPF simplemente funcionó. Microsoft tampoco reconoció la importancia crítica de los requisitos de LOB como Data Grid, INotifyDataErrorInfo, controles que cuentan con estados de validación y una sólida base de datos lista para usar. La mayoría de estos han sido abordados, pero tomó demasiado tiempo. Aún faltan regiones no rectangulares.

La otra falla crítica recae en ciertos desarrolladores de WPF que han optado por mantenerse alejados de UWP. La adopción es esencial para generar impulso. Sin embargo, la saga de la adopción es comprensible dada la cantidad de veces que Microsoft ha fallado en sus iniciativas. Es obvio que Microsoft está balbuceando una vez más. Resucitar WPF al permitir que se conecte a los servicios de interfaz de usuario de UWP parece genial en la superficie, pero distrae la atención de hacer que UWP sea sólido.

Estoy completamente de acuerdo con la afirmación de @SuperJMN de que los desarrolladores han perdido la esperanza de que Microsoft haga lo correcto. Lo correcto difiere según el tipo de software que esté creando. Si se trata de aplicaciones LOB de alto rendimiento que deben crearse rápidamente y exhibir un amplio conjunto de capacidades al tiempo que son seguras y fáciles de instalar, UWP está allí principalmente, excepto en términos de calidad. Esa brecha de calidad es lo que está acabando con UWP más que cualquier otra cosa.

HTML+JS es la solución multiplataforma del día. No necesitamos reinventarlo. Tener un motor de representación XAML de alto rendimiento en IOS y Android tiene más sentido si la intención es hacer que XAML sea más portátil.

Estoy muy de acuerdo en que WinUI debería aspirar a ser multiplataforma en el futuro. Aquí hay algunos pensamientos adicionales.

Prioridades inmediatas

Estoy de acuerdo con algunos de los comentarios de que la prioridad inmediata debe ser garantizar que WinUI 3 funcione en Windows con integración .Net 5 y que se solucionen los errores. Sin embargo, si aún no es demasiado tarde, al tomar decisiones arquitectónicas, se debe considerar el objetivo de ser multiplataforma en el futuro.

Por qué WinUI debería ser multiplataforma

Existen las razones obvias y más importantes: los desarrolladores quieren dirigirse a la mayor audiencia posible sin tener que volver a escribir el código, etc., y C# (o C++, supongo)/XAML es una buena combinación. Sin una historia multiplataforma, se trasladarán a otras tecnologías como Flutter.

Otro motivo es garantizar que Microsoft siga admitiendo WinUI. Es probable que Microsoft solo continúe admitiendo WinUI si sus propias aplicaciones lo están utilizando. Están cada vez más enfocados en hacer que sus propias aplicaciones sean multiplataforma. Es cierto que algunos marcos multiplataforma como React Native y Xamarin usarán WinUI debajo, pero ¿qué sucede si otros marcos como Flutter o la representación basada en navegador ganan? Luego, WinUI se volverá redundante y entrará en modo de mantenimiento como WPF.

¿Cómo se debe implementar multiplataforma?

Aunque Uno es un gran proyecto, en mi opinión tiene más sentido hacer que la capa de renderizado (y entrada) sea multiplataforma y construir sobre eso, que es lo que hacen Flutter y AvaloniaUI, en lugar de envolver los controles nativos. Hay varias ventajas en el enfoque de hacer que las capas de renderizado y de entrada sean multiplataforma. Me parece que la superficie de la API de las capas de renderizado y de entrada es más pequeña que la de los controles (pero supongo que depende de si construyes los controles sobre unos pocos básicos, etc.). En segundo lugar, si confía en envolver los controles nativos, entonces está a merced de la plataforma. Si cambian su API, debe cambiar la suya o implementar una solución alternativa. Si no hace esto lo suficientemente rápido después de las depreciaciones, su marco se romperá. Si desea agregar una nueva función a un control, es posible que deba implementarla para cada plataforma. Realmente no puede tener una "visión" de cómo quiere que evolucione su marco porque está atado a los marcos de la plataforma. También requiere que los desarrolladores realicen pruebas en cada plataforma todo el tiempo, ya que el aspecto y el comportamiento de los controles son diferentes. Además, sería difícil/imposible implementar funciones más potentes como la capa de composición. Hacer que la capa de renderizado sea multiplataforma resuelve todos estos problemas, y si desea una apariencia diferente en cada plataforma, puede agregar un estilo diferente. (Admito que, algunos comportamientos, se mantendrían diferentes en diferentes plataformas, ¡como desplazarse en una Mac!).

Dado que WinUI actualmente está desacoplando los controles y las capas de procesamiento y entrada de la plataforma, parece estar en una posición excepcionalmente buena para hacerlo.

Una forma de abstraer la capa de renderizado sería usar Skia. Sin embargo, no me gustaría que el rendimiento sufriera al forzar esta abstracción. Tengo una sugerencia alternativa que ver para abstraer la capa de representación, que es la propuesta de C++ para gráficos 2D: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0267r9.pdf . Obviamente, han puesto mucho trabajo en la superficie de la API y parece bastante completo. Argumentan que el 'problema' de los gráficos 2D se resolvió esencialmente hace muchos años y tengo que estar de acuerdo con ellos en que su superficie API parece bastante completa. Hay mucha gente en contra de esta propuesta, pero incluso si no se acepta, creo que se podría usar la superficie API. Si escribe un back-end de Direct2D para esta superficie de API, si se acepta la propuesta, evitará que el equipo de MSVC tenga que escribirla. Tal vez el equipo de WinUI podría usar esto como justificación para poder trabajar en él o agregar algunos miembros adicionales al equipo. Además, quizás los autores del artículo estarían dispuestos a ayudar. Puede escribir el back-end para las otras plataformas usando Skia o algo así y, si finalmente se acepta la propuesta, cambie a las implementaciones nativas cuando se realicen.

Finalmente, mirando más hacia el futuro, quería mencionar WASI - https://wasi.dev/ . Esto parece centrado en la programación de sistemas por ahora, pero podría tener el potencial de convertirse en un marco de aplicación multiplataforma completo (tiene multiplataforma y seguridad integrada), con la propuesta de C++ anterior quizás proporcionando un candidato natural para la API de la capa de representación. (Sin embargo, es probable que esto esté muy lejos).

Mirando la evidencia, gente como @SuperJMN tiene mucha credibilidad dado el contenido de sus repositorios. Puedo ver que @SuperJMN probablemente renunció a UWP mientras aún estaba madurando (comprensible). Microsoft haría bien en revisar los repositorios de las personas que comentan aquí. Algunas voces no son particularmente creíbles según el cuerpo de trabajo que presentan al mundo.

@Noemata Solía ​​ser un gran fanático de XAML+MVVM. He trabajado con él en Silverlight, WPF, WindowsPhone, Metro(WinRT). Me quemé cuando se trataba de UWP y Xamarin...

Es difícil ver qué separa esta iteración de todas las otras veces que he mirado una nueva pila XAML.

Microsoft ha lanzado algunas fantásticas aplicaciones de muestra para UWP. Realmente muestran muy bien lo que es posible.

Aquí hay una lista parcial:

https://github.com/Microsoft/Windows-appsample-customers-orders-database
https://github.com/microsoft/InventorySample
https://github.com/microsoft/VanArsdel
https://github.com/microsoft/BuildCast
https://github.com/microsoft/Windows-appsample-shopping

Hay muchos más buenos ejemplos. Ninguno está construido de una manera que se pueda reutilizar o estructurar fácilmente para que las muestras sean cohesivas con otros trabajos.

No recuerdo tanto esfuerzo con las muestras de WPF correspondientes. Esto es mayormente bueno.

¿El problema? Llevó demasiado tiempo llegar a donde estamos ahora con UWP y XAML. Y ahora el mensaje se confunde una vez más. Si Microsoft simplemente hubiera proporcionado plantillas de proyecto decentes con Visual Studio cuando UWP se lanzó por primera vez, seríamos menos negativos sobre UWP. Para obtener las mejores plantillas VS, debe ir aquí:

https://github.com/microsoft/windowsTemplateStudio

No está exactamente listo para usar a pesar de ser un conjunto muy flexible y completo de componentes básicos para aplicaciones UWP. ¿Cómo encuentras todo esto? Ninguna pista. Ir a la búsqueda del tesoro para hacer su trabajo no genera confianza. El equipo de Office que se negó a adoptar WinRT no ayudó. Conducen mucho de lo que entra en el sistema operativo, independientemente de su alcance teórico. Agregue problemas de calidad, errores, la falla de Windows Phone y la inversión inconsistente más mensajes y aquí estamos.

Microsoft ha lanzado algunas fantásticas aplicaciones de muestra para UWP. Realmente muestran muy bien lo que es posible.

@Noemata Estoy de acuerdo, son muestras realmente geniales. Pero desarrollar una aplicación compleja es una locura con UWP. Ciertamente es posible, pero es mucho más difícil. Sí, echo de menos los tiempos de "simplemente funciona" de WPF.

Una de las primeras cosas que MS debería dar como muestra es una aplicación UWP simple que puede publicar fuera de la tienda de MS (y sí, no es tan fácil como parece)

Otra cosa que no me sienta bien es que UWP se pensó con el "móvil primero" en mente, abandonando la experiencia de escritorio correcta.

Corrígeme si me equivoco, pero la mayoría de los desarrolladores usan UWP para desarrollar aplicaciones de escritorio y la interfaz de usuario no coincide con eso. Lo primero que me viene a la mente es la barra de desplazamiento, que, desde el principio, está optimizada para el panel táctil. Pero para los usuarios de escritorio, la experiencia de desplazamiento es muy mala (nota al margen: creo que el equipo de WinUI está trabajando para arreglar esto). He buscado mucho en Google para encontrar una solución que haga que la barra de desplazamiento vuelva a ser "normal"; es simplemente una locura que no pueda simplemente llamar a una función API para hacer eso.

Lo mismo, los botones de radio/cuadros combinados tienen un tamaño mínimo también optimizado para dispositivos móviles. Simplemente se ignora la configuración del ancho de un botón de opción, en realidad debe configurar "MinWidth = 0" para que se tenga en cuenta.

Y el color del botón de texto es blanco, luego negro en el foco, ¿qué pasa con eso? Y el botón de texto tiene una "x" que puede usar para borrarlo, ese es el panel táctil, ¿por qué lo tengo allí cuando no hay un panel táctil?

El cuadro de texto predeterminado tiene la ortografía habilitada, ¿por qué querría eso?

Hay otros problemas, pero he trabajado alrededor de ellos. Pero el mayor problema es que las cosas que deberían llevar 10 minutos, suelen tardar 2 horas o más. Simplemente perdí la capacidad de estimar: cada vez que digo que algo me llevará medio día, me llevará 2 o 3 días.

Saludos a todos,
ya que este es un problema de discusión general y no sé dónde más colocar mis deseos/solicitudes de características de UWP... aprovecho la oportunidad en este hilo:

• Mejor soporte para integrar aplicaciones uwp en el menú contextual del explorador de Windows
  
  
  
  • Apóyenos aquí https://aka.ms/AA6rmrk
  
  
• Falta la extensión de marcado de UWP IServiceProvider y el propio elemento en el que se usa la extensión de marcado
• Falta el activador de estilo UWP
• Problema de plantillas de datos implícitos de UWP. Ver por ejemplo aquí
• no es posible la impresión automática sin la interacción del usuario (solo funciona para POS) ver aquí

Todas las características o problemas anteriores se abordaron en la voz del usuario, que ahora está abandonada. Alguien sabe que paso con esos temas? ¿Deberíamos recrearlos en feedbackhub?

Me encanta la frase "Los desarrolladores olvidados". Conozco a muchos de ellos que tienen talento, experiencia y pasión por las tecnologías. Son desarrolladores veteranos de .Net. No tengo ninguna duda de que, en términos generales, pueden crear mejores aplicaciones que muchos niños que prosperan con el desarrollo de aplicaciones para iOS y Android.
Si WinUI puede proporcionarles un camino agradable y sólido para utilizar su amplia experiencia en C# + .Net + Xaml para crear aplicaciones para Windows, Android, iOS y Web, muchos se subirán al carro y el mundo se beneficiará de su alto nivel. aplicaciones de calidad
La plataforma WinUI + Uno podría ser la mejor opción.

A la extensión de marcado de UWP le falta IServiceProvider y el propio elemento en el que se usa la extensión de marcado

¡Te tengo cubierto aquí @mfe-!

¡Te tengo cubierto aquí @mfe-!

@Mike-EE ¡Guau, eso es increíble! Recuerdo haberme encontrado con esto cuando quería migrar CalcBinding a UWP. Lo que terminé haciendo es una solución en la que agrego campos de solo lectura en el modelo de vista.

"escribir una vez, ejecutar en todas partes".

Microsoft se alejó de esto hace un tiempo.

Buen trabajo todos ¡SOMOS FAMOSOS! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

Los Desarrolladores Olvidados guardan silencio o simplemente son ignorados

Me encanta la frase "Los desarrolladores olvidados".

¡Organicémonos bajo ese nombre! 💪

Solo deseo un marco de interfaz de usuario multiplataforma desarrollado y respaldado por Microsoft. Simplemente no hay nada para el ecosistema .NET, excepto _Uno Platform_ y _Xamarin.Forms_ (si todavía están trabajando para apuntar al escritorio).

E incluso si decido escribir una aplicación comercial solo para Windows desde cero, no creo que Microsoft se comprometa completamente con UWP. Corrígeme si me equivoco, pero ¿no abandonaron las aplicaciones de Office UWP en favor de las PWA de Office Online? Si MS abandona su propio marco de trabajo, ¿por qué debería confiar en UWP? _tos Silverlight_

Afortunadamente, WPF aún no fue abandonado. Pero eso solo aumenta mis dudas.

Buen trabajo todos ¡SOMOS FAMOSOS! 😅

https://www.theregister.co.uk/2020/02/28/winui_cross_platform/

acebo 🤭

¡Súper! Expandámonos a otras grandes revistas, sitios web, etc. 😛

Para aquellos que buscan una solución multiplataforma para desarrollar aplicaciones, no necesitan buscar más allá de Unity:

https://unity.com/

Como todas estas soluciones, terminas con un marco que abarca un mini sistema operativo. Java era el sistema operativo hábilmente disfrazado de lenguaje de programación.

Un navegador moderno es ahora un mini OS. Creo que tenemos suficiente de estos. Se supone que WinUI/UWP es la interfaz de usuario nativa para Windows 10 y posteriores. Podría tener sentido tener un motor XAML que se ejecute en más lugares. No estoy convencido de que vaya contra el viento en contra de cosas como Unity. Prefiero ver un UWP pulido y de alta calidad antes de que Microsoft se vaya y comience a reinventar Silverlight para que podamos alojar XAML en otras plataformas. Todos sabemos lo bien que funcionó. Si no has visto Unity, te lo estás perdiendo. Dicho esto, prepárate para hacer mucha codificación e incluso más depuración.

La próxima semana lanzaré un conjunto de plantillas VS para UWP que te permitirán crear aplicaciones en segundos. Esto se ha utilizado para proyectos "internos". Demostrará el punto de que UWP puede ser un marco RAD listo para usar si solo VS tuviera los bloques de construcción correctos integrados.

La próxima semana lanzaré un conjunto de plantillas VS para UWP que te permitirán crear aplicaciones en segundos. Esto se ha utilizado para proyectos "internos". Demostrará el punto de que UWP puede ser un marco RAD listo para usar si solo VS tuviera los bloques de construcción correctos integrados.

@Noemata ¡ Eso suena genial! ¡Tengo bastante curiosidad!

Si todos desean un marco de interfaz de usuario multiplataforma basado en .Net que pueda adaptarse a cualquier lenguaje de diseño. No busque más, Comet lo es.

https://github.com/Clancey/Cometa

Si tiene algo de tiempo libre, vaya a contribuir ya que aún está en sus primeras etapas.
Comet apunta básicamente a todas las plataformas existentes, y te da la opción de apuntar al control nativo en cada plataforma o usar Skia para dibujar todo para que todos sean consistentes (exactamente como lo hace Flutter).

Utiliza IU declarativa y patrón MVU. Está desarrollado por James Clancey, Arquitecto Gerente Principal de Programas en Microsoft. Aunque todavía no es compatible oficialmente, pero con suficiente tracción comunitaria, puede serlo.

En Comet, la interfaz de usuario es solo una biblioteca, por lo que usted (o tal vez Microsoft pueda) puede desarrollar una biblioteca de WinUI al igual que Comet tiene una biblioteca de Material Design.

Si todos desean un marco de interfaz de usuario multiplataforma basado en .Net que pueda adaptarse a cualquier lenguaje de diseño. No busque más, Comet lo es.

@nerocui , esto suena genial, pero al menos al verlo, no hay un diseñador XAML. Construir interfaces de usuario complejas es probablemente una locura en su etapa actual. Pero parece prometedor.

Si todos desean un marco de interfaz de usuario multiplataforma basado en .Net que pueda adaptarse a cualquier lenguaje de diseño. No busque más, Comet lo es.

@nerocui , esto suena genial, pero al menos al verlo, no hay un diseñador XAML. Construir interfaces de usuario complejas es probablemente una locura en su etapa actual. Pero parece prometedor.

Y no se trata de arrastrar y soltar, se trata de una vista previa en tiempo real de la interfaz de usuario en el diseñador cuando se realiza un cambio en el código.

La próxima semana lanzaré un conjunto de plantillas VS para UWP que te permitirán crear aplicaciones en segundos. Esto se ha utilizado para proyectos "internos". Demostrará el punto de que UWP puede ser un marco RAD listo para usar si solo VS tuviera los bloques de construcción correctos integrados.

¿Esto está usando NoesisGUI? Si es así, faltan MUCHAS funciones que serían necesarias para las aplicaciones LOB. Ahora, WinUI apuntando a Unity sería increíble.

Creé un repositorio para documentar el estado actual de XAML y espero que la gente ayude y contribuya con información y fragmentos de código reales que enumeran cómo realizar tareas en las diversas versiones de XAML.

https://github.com/gatewayprogrammingschool/XAML-Estandarización

Problema simple, vaya más allá de la caja de arena de hoy y adopte lo que se requiere para la plataforma cruzada. Ya lo está haciendo para todos los demás aspectos de Windows/OS, ¿por qué no la interfaz de usuario?

Tome la plataforma cruzada sandbox.

De: anthonyadame [email protected]
Enviado: sábado, 29 de febrero de 2020 20:00:13
Para: microsoft/microsoft-ui-xaml [email protected]
CC: El ninja afilado [email protected] ; Comentar [email protected]
Asunto: Re: [microsoft/microsoft-ui-xaml] Discusión: WinUI debería ser multiplataforma (#2024)

Problema simple, vaya más allá de la caja de arena de hoy y adopte lo que se requiere para la plataforma cruzada. Ya lo está haciendo para todos los demás aspectos de Windows/OS, ¿por qué no la interfaz de usuario?

—
Estás recibiendo esto porque comentaste.
Responder a este correo electrónico directamente, visualizarla en GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024?email_source=notifications&email_token=AD3GCLAISGPMJCQ4AYDPDLLRFG6S3A5CNFSM4K3JAUQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENMOWIY#issuecomment-593029923 , o darse de baja https://github.com/ notificaciones/unsubscribe-auth/AD3GCLDKTTDCWIJ2ED3OKC3RFG6S3ANCNFSM4K3JAUQA .

La integración de componentes C++ de alto rendimiento con C# es trivial en UWP. El acceso a las superficies de DirectX también ha mejorado mucho.

@Noemata Excepto que lo que me importa es no tener que escribir C ++ para empezar, WinDev sigue estropeando todos los intentos que harían que los lenguajes .NET fueran iguales en lo que respecta a las API de C ++, Managed Direct X, XNA, compilación AOT adecuada de .NET código, características COM, ....

Hacer que WinUI 3.0 sea multiplataforma será ese argumento para migrar las aplicaciones .NET/Forms existentes a WinUI.

Al principio será suficiente para soportar macOS, y no hay problema cuando no tiene el mismo rendimiento que en Windows, o no todas las características como las animaciones.

Windows es la plataforma de referencia; por supuesto, tiene que estar acoplado a DirectX para un mejor rendimiento.

En mi opinión, no tiene sentido tratar de reescribir grandes aplicaciones de C# en HTML+JS solo para admitir macOS. Y también para las nuevas aplicaciones de escritorio, C# es la mejor opción.

Para las aplicaciones de escritorio, C# y XAML son mucho más fiables que HTML+JS.

Hacer que WinUI 3.0 sea multiplataforma garantiza el futuro de .NET, C# y XAML.

Hola a todos

Soy un desarrollador por contrato de WPF que trabaja en Londres. He estado creando interfaces de usuario complejas de alto rendimiento con WPF para varias instituciones financieras desde 2006. Aquí está mi opinión sobre esto:

1) Sigo de cerca el mercado laboral en el Reino Unido. El 100 % de los trabajos de WPF anunciados desde 2006 (de los cuales ha habido miles) son para crear aplicaciones de escritorio de comercio financiero de alto rendimiento para el sector financiero. Todavía no se ha anunciado ningún trabajo para un desarrollador de UWP para ninguna industria.

2) Estas aplicaciones comerciales de escritorio no pueden usar UWP o la próxima WinUI; simplemente no es lo suficientemente bueno en comparación con WPF por muchas razones complejas. Además, el diseño fluido no es algo que interese a estos usuarios, solo debe parecerse a una cuadrícula de Excel, sin animaciones, sin estilo, solo datos y un rendimiento sorprendente.

3) Estos clientes no están interesados ​​en absoluto en soluciones multiplataforma. Nadie usa una Mac, y los dispositivos móviles no son algo que les interese.

4) Estos equipos de desarrollo de WPF tienen grandes inversiones (tiempo y dinero) en bibliotecas de control de WPF de terceros, o han desarrollado suites de control personalizadas complejas y de alto rendimiento a través de personas como yo. No van a alejarse de WPF a menos que haya un beneficio muy significativo (que no habrá por lo previsible)

5) Para estas instituciones financieras cualquier aplicación que no necesite ser escrita explícitamente para escritorio/WPF es escrita con tecnologías web y Javascript. No están interesados ​​en nada más exótico que eso: sin aleteo, sin blazor, etc.

Así que esta es la situación en el Reino Unido. Cientos de desarrolladores de WPF que no buscan pasar a nada nuevo en el corto plazo. Cero desarrolladores de UWP (excepto quizás un puñado de bandas de un solo hombre que desarrollan aplicaciones para la tienda, lo que es dudoso al ver el estado de la tienda)

Además, no entiendo toda la histeria sobre la plataforma cruzada. La plataforma cruzada que abarca tanto dispositivos móviles como de escritorio es una tontería. Nunca va a ser interesante. Microsoft probó esto con aplicaciones UWP que se ejecutaban en computadoras de escritorio y teléfonos; fue un desastre, limitando las aplicaciones a la interfaz de usuario más simple que no podía hacer nada complejo o interesante. Los dispositivos de escritorio y móviles están diseñados para diferentes tareas y casos de uso, y necesitan diferentes aplicaciones; todos lo sabemos.

Para mí, quiero ver mucha más inversión de Microsoft en WPF directamente, sin sacrificar la compatibilidad con versiones anteriores. Quiero ver el desarrollo del control de soporte de WPF en C++ no administrado para que podamos trabajar más cerca del metal. Quiero ver una mejor tecnología de vinculación, mejores plantillas de datos, una mejor funcionalidad de plantilla de control, incluida la herencia parcial. Quiero ver mejores herramientas de depuración y analizadores de árboles visuales. Quiero ver que la depuración de XAML se desarrolle más. Quiero una mejor compatibilidad con subprocesos múltiples en la interfaz de usuario. Quiero montones, montones de cosas, al igual que mis compañeros contratistas de WPF del Reino Unido.
La hoja de ruta actual de Microsoft no me da ninguna de las cosas que quiero y todas las cosas que no me importan.

Si Microsoft no apoya esta visión (lo que claramente no hacen ahora), entonces el plan B será que la comunidad moldee WPF en la plataforma que debe ser a través de contribuciones de código abierto, suponiendo que Microsoft acepte un toque más ligero cuando se trata de permitir nuevos código e ideas para formar parte del marco WPF.

@deanchalk Creo que la mayor parte de esto puede haber estado mejor ubicado en el repositorio de WPF para mostrarles que hay interés en WPF, publicarlo aquí dice principalmente que no está interesado en lo que se hace en el repositorio de WinUI / discutido en este número. Si bien esa es una entrada válida, probablemente no conducirá a algo constructivo más allá de una discusión vacía.

@weltkante @deanchalk Hay un problema en el repositorio que solicita "soporte de control heredado" en WinUI: https://github.com/microsoft/microsoft-ui-xaml/issues/1833
Al menos el punto 4) se ajusta a ese problema y probablemente debería volver a publicarse allí para justificar una inversión de Microsoft.

@deanchalk , sigo siendo un gran fanático de WPF. Es una herramienta maravillosa que, afortunadamente, está empezando a recibir el cariño de Microsoft. La forma en que Microsoft eligió abandonar WPF en primer lugar fue muy desafortunada. Siendo UWP el juguete nuevo y brillante, no debería haber impedido inversiones continuas en WPF.

UWP fue, en muchos sentidos, el camino correcto a seguir. Desafortunadamente, las primeras iteraciones ignoraron algunos de los requisitos más críticos para las personas que usaban WPF y podrían haber considerado migrar. No menos importante es el sorprendente estado de fragmentación de XAML dentro de los muros de una sola organización. WPF! = Silverlight! = UWP! = Xamarin. ¡Guau!

Siento menos simpatía por los desarrolladores de WPF que han elegido atrincherarse en WPF en el año 2020. Las cosas han avanzado considerablemente. Las islas XAML con la capacidad de usar la API de WinRT le brindan una ruta bastante sencilla para comenzar su migración a UWP. Y UWP ya no falta si optaste por hacer una conversión mayorista.

El problema más grande sigue siendo la falta de claridad de Microsoft sobre lo que sigue realmente. Todos aquellos que esperaban XAML Nirvana se dieron por vencidos con el fiasco de Silverlight que se está reproduciendo una vez más con UWP.

WinUI es obviamente un UWP reetiquetado, es doloroso presenciarlo. Y es igualmente obvio que Microsoft espera que todos olvidemos qué es/fue UWP.

Aún así, la mano izquierda de Microsoft no siempre está en sintonía con lo que hace la mano derecha. WindowsX ha convertido a Win32 y todo lo que viene con él (WPF/Winforms/etc.) en una perspectiva tenue para las aplicaciones que "podrían" ejecutarse en su sandbox de bajo rendimiento. UWP es, y actualmente sigue siendo, la interfaz de usuario nativa para Windows 10, WindowsX y posteriores. La API de WinRT es una gran mejora con respecto a Win32. Así que supongo que tienes que elegir si quieres pasar a la década de 2020 o quedarte en la década de 2010.

WinUI es obviamente un UWP reetiquetado, es doloroso presenciarlo. Y es igualmente obvio que Microsoft espera que todos olvidemos qué es/fue UWP.

@Noemata WinUI es un nuevo producto basado en las API de UWP (XAML, Composición, Entrada,...). El nombre tiene sentido, ya que podrá usarlo para crear una interfaz de usuario para aplicaciones de Windows sin importar el modelo de aplicación subyacente.

Estoy confundido. Usted mismo está mencionando 10X en el último párrafo. El modelo de la aplicación UWP en sí está recibiendo un impulso con Windows 10X. Ahora, si 10X tendrá éxito es algo que solo el tiempo podrá decir. Pero MS ha sido claro en su mensaje: UWP es la plataforma nativa de 10X (junto con la web), como señaló.

@Noemata hasta 2020 se pone al día con las funciones disponibles en 2010, muchos de nosotros nos vemos obligados a quedarnos en 2010.

Muchos de nosotros simplemente nos cansamos del tren de reescritura que comenzó con la caída de Silverlight, XNA y ver cómo la mano de MS agita las reescrituras que requieren .NET Core, WinUI, mientras se eliminan funciones en el proceso, no gana los corazones de muchos de nuestros clientes, con aplicaciones totalmente funcionales que no ven por qué deberían pagar reescrituras para recuperar menos funciones.

En este momento, gracias a la inteligencia de tener tabletas con Android y Windows 10 X, Xamarin y PWA son lo que esperamos, no WinUI.

@pjmlp , quizás. Tengo curiosidad, ¿qué característica te falta? He transferido algunas aplicaciones de WPF bastante grandes a UWP. El mayor dolor de cabeza fue el sandbox de seguridad y aprender a trabajar con él en lugar de luchar contra él. Anteriormente, faltaban piezas, como Data Grid, conectividad DB, una API decente para comunicaciones de alta velocidad, etc. Falta muy poco ahora. Hay muchas cosas que no pude hacer tan fácilmente en WPF. Para ser justos, actualmente, no hay nada que no pueda hacer en WPF al aprovechar el acceso a la API de WinRT, excepto que tendría un rendimiento más bajo porque UWP compila el código de máquina de una manera más óptima y usa una mejor pila de representación de DirectX. Además, debe ofuscar su código WPF (hacerlo más frágil) si tiene la intención de proteger su IP o prevenir intrusos.

Los teléfonos/tabletas son excelentes dispositivos para el tipo de aplicaciones de soluciones puntuales. No me gustaría componer una sinfonía en un teléfono, o diseñar un rascacielos, y preferiría poder orientar parte de las porciones de soluciones puntuales de mi aplicación de escritorio a dispositivos móviles, que tratar de hacer que los dispositivos móviles funcionen en mi escritorio.

@ Felix-Dev Entiendo qué es WinUI. Me pregunto por qué se requirió otra bifurcación solo porque los desarrolladores de WPF, Winforms y MFC/Win32 no aceptaron. La mejor estrategia habría sido hacer que la migración fuera más atractiva o menos dolorosa o ambas cosas.

Microsoft ha hecho muchas cosas bien con UWP. Hay una gran cantidad de aplicaciones de muestra que cubren todo tipo de casos de uso. Llegaron tarde, al igual que las características que faltaban. ¿Es realmente demasiado tarde?

@Noemata WinUI probablemente habría sucedido de cualquier manera (con o sin WinUI Desktop), ya que desacoplar la pila de UI de UWP del sistema operativo es un paso absolutamente necesario. Hubiera sido mejor si WinUI ya hubiera existido cuando se lanzó Windows 10 por primera vez, pero hay razones por las que no fue así.

En cuanto a si es demasiado tarde... tuvimos muchas discusiones de este tipo en el canal de discordia de la comunidad de UWP y también innumerables intercambios apasionados aquí. Algunos de nosotros pensamos que el barco ya zarpó, mientras que otros todavía creen que existe la posibilidad de que la plataforma UWP/WinUI pueda crecer y madurar para convertirse en una importante plataforma de desarrollo. Mucha gente con muchas ideas sobre cómo podría ser el mejor enfoque para la EM (es decir, ¿ir a xplatform o no?). El hecho es que el equipo actualmente está trabajando arduamente en WinUI 3 y su lanzamiento marcará el comienzo de asumir el verdadero desafío: impulsar WinUI hacia adelante, con la ayuda de la comunidad, para que se convierta en el marco elegido por los desarrolladores que apuntan a Windows. .

@Noemata , en primer lugar, compatibilidad con bibliotecas de componentes de terceros existentes como Telerik, Component One, ...

Entonces, al no tener que reescribir nada para empezar, como se mencionó, estamos hartos de reescrituras.

En lo que respecta a DirectX, no solo no se admiten las clases de modelado 3D de WPF, sino que se espera que escribamos C++, porque Microsoft no se molesta en crear proyecciones de tiempo de ejecución para DirectX, y el agradable dialecto C++/CX fue reemplazado por el prolijo menos capaz, pero mejor compatible, C++/WinRT.

Además de esto, no solo tenemos que desechar el código WPF que funciona perfectamente, sino que tenemos que hacer lo mismo con el código WCF, EF6.

Todavía creo que UWP es una API mucho mejor que Win32, de alguna manera lo que debería haber sido Longhorn, pero la forma en que esto se está desarrollando simplemente ha quemado demasiados puentes, ya que Microsoft ha quemado el presupuesto de reescritura de muchas organizaciones.

@pjmlp , todos esos son buenos puntos con contraargumentos bastante mansos, así que ni siquiera lo intentaré. La falta de soporte para la API 3D de WPF fue un gran golpe para mí personalmente. Tener que aprender un nuevo enfoque no fue divertido y mucho menos capaz dadas las opciones de vinculación de WPF para 3D. Existen alternativas de C# para 3D bajo UWP, solo que mucho menos útiles una vez que haya experimentado los beneficios de enlazar en un modelo 3D.

C++/CX fue otro punto problemático que tardó demasiado en resolverse con C++/WinRT, que podría estar estable la próxima semana en algún momento (todavía está cambiando).

WCF está muerto (lo siento, las nuevas opciones son mucho, mucho mejores). EF6 debería haber tenido una mejor historia de migración. Tienes toda la razón en el fiasco del presupuesto de reescritura @pjmlp , claramente esto es algo que Microsoft solía obtener y ya no le importa considerar dada la rotación loca/inconsistente de la tecnología.

@ Felix-Dev, tú también haces puntos completamente válidos. El desacoplamiento de la interfaz de usuario debería haber estado allí desde el principio. Las personas que solicitan una interfaz de usuario xplatform basada en XAML deben reformular su solicitud y solicitar un motor de representación XAML en la plataforma de su elección con un mini sistema operativo para replicar la superficie de la API (otra Java/Silveright/Uno Platform/Unity/Lo que sea... eventualmente terminando con HTML que las aplicaciones cercanas al metal no pueden comenzar a considerar). No estoy al tanto de las últimas iniciativas internas de MS en este momento. Mirando hacia afuera, WinUI es la bandera ondeante que indica que el barco se está enderezando nuevamente (¿cuántas veces más?). Defender a Microsoft se volvió imposible con la muerte de Silverlight. No volveré a levantar esa espada. Supongo que lo que realmente estoy haciendo es lamentando la muerte de UWP :-(... doloroso. https://www.youtube.com/watch?v=uBiewQrpBBA

Charlie == Microsoft

¿Plataforma cruzada? Microsoft debería simplemente comprar UNO y terminar con tit.

¿Plataforma cruzada? Microsoft debería simplemente comprar UNO y terminar con tit.

Espero que sea cual sea la solución que se presente, no dependa de un navegador web o una vista web de algún tipo. Muestre la interfaz de usuario en la ventana nativa de la plataforma o en la superficie de la interfaz de usuario, pero tenga un aspecto idéntico al de Windows.

¿Plataforma cruzada? Microsoft debería simplemente comprar UNO y terminar con tit.

Espero que sea cual sea la solución que se presente, no dependa de un navegador web o una vista web de algún tipo. Muestre la interfaz de usuario en la ventana nativa de la plataforma o en la superficie de la interfaz de usuario, pero tenga un aspecto idéntico al de Windows.

Así es como lo hace UNO, excepto en Windows 7. Windows 7 es la única excepción, ya que utiliza el navegador web.

Para aquellos desarrolladores de WPF que requieren una solución de escritorio multiplataforma, Wine puede ser una opción viable para usted. He tenido un gran éxito en la migración de grandes aplicaciones WPF (principalmente .NET Core WPF) para ejecutarlas en Linux con Wine. Tengo un artículo que puede ayudarte a empezar:
https://ccifra.github.io/PortingWPFAppsToLinux/Overview.html

También comencé a portar algunas aplicaciones de WinForms a Linux. Hasta ahora no me he encontrado con ningún problema.

Wine también debería permitirle ejecutarse en Mac, Chrome OS y Android. Solo he probado Linux.

Para mí, esto demuestra que usar DirectX como capa de abstracción funciona y es un modelo viable a seguir. Sospecho que incluso funcionaría bien en la Web con WebGL una vez que .NET WASM esté más maduro.

Conseguir que Microsoft ayude con Wine (al menos asegurándose de que no lo rompan) ayudaría mucho. Podrían ayudar a crear una solución verdaderamente nativa con WineLib y, dada su experiencia, no creo que sea demasiado esfuerzo.

AvaloniaUI ya ES multiplataforma. ¿Por qué no pedir ayuda y comentarios a las personas del proyecto para mejorar WinUI?

Bueno, no tanto como Uno Platform. Uno Platform también se ejecuta en la web (WASM). Avalonia carece de esta capacidad.

Avalonia también usa su propio dialecto de XAML, que es algo que Uno está tratando de evitar.

De: Shimmy [email protected]
Enviado: viernes, 27 de marzo de 2020 4:09:30 a. m.
Para: microsoft/microsoft-ui-xaml [email protected]
CC: El ninja afilado [email protected] ; Comentar [email protected]
Asunto: Re: [microsoft/microsoft-ui-xaml] Discusión: WinUI debería ser multiplataforma (#2024)

AvaloniaUI ya ES multiplataforma. ¿Por qué no pedir ayuda y comentarios a las personas del proyecto para mejorar WinUI?

Bueno, no tanto como Uno Platform. Uno Platform también se ejecuta en la web (WASM). Avalonia carece de esta capacidad.

—
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2024#issuecomment-604893750 o cancele la suscripción https://github.com/notifications/unsubscribe-auth/ AD3GCLE3TEC3DZO74OXKX73RJRUMVANCNFSM4K3JAUQA .

La mayor parte de la tecnología de WinUI proviene de Sliverlight, y Sliverlight en realidad ha logrado ser multiplataforma. Por lo tanto, la multiplataforma de WinUI depende de la estrategia, no de la tecnología.

Honestamente... en realidad es tan patético que Microsoft ahora está tratando de ponerse al día... solo se preocupan por la "gran" cuota de mercado, no buscan lo que quieren sus clientes/fans de productos.

Microsoft es la razón por la cual el desarrollo de la APLICACIÓN DE ESCRITORIO ha cambiado al desarrollo WEB obsoleto, incluso cuando la web es tan horrible.

Estoy seguro de que todos los desarrolladores de XAML están de acuerdo en que HTML/CSS es basura.

Pero aún así... HTML, CSS, DOM... con marcos como React, Angular, Vue que están tratando de hacerlo algo un poco más agradable. La gente todavía se enfocaba en esta web obsoleta, no en la nueva plataforma exclusiva de Windows de código cerrado de Microsoft que muere cada 2 a 4 años por una nueva.

La plataforma Win-app basada en XAML debería haber sido de código abierto hace AÑOS. Debería haberse implementado una vez en el SITIO WEB, Windows, Mac, Linux, Android (cualquier plataforma que desee el cliente). Windows Store debería haber sido multiplataforma con un procesador de aplicaciones XAML/UWP. (similar a cómo Google Chrome es multiplataforma con el renderizador HTML/CSS).

Durante la era dorada de Microsoft, una aplicación multiplataforma basada en XAML podría haber destruido la web, entonces no tendríamos que lidiar con este CSS, HTML, DOM e innumerables marcos.

Pero no, la obsesión de Microsoft con el software propietario les hizo perder frente a la web.

Mientras tanto, Flutter de Google se está convirtiendo en lo que siempre quise para XAML.

Espero que WinUI 3 sea una plataforma de destino en MAUI. La plataforma Uno ya ha anunciado que WinUI 3 Preview obtuvo soporte.
Entonces, @jeromelaban / Microsoft, ¿lo que probablemente realmente necesitamos es la unificación de Uno/MAUI? MAUI es menos útil en mi opinión que Flutter o Uno sin un objetivo web (navegador).

Deje también sus comentarios en el repositorio de MAUI .

¡WPF (Silverlight) en todas partes!

Portar DirectX a otras plataformas parece un gran trabajo, tal vez la solución sea usar OpenGL o Vulkan en lugar de DirectX.

Google tiene ANGLE que permite ejecutar OpenGL ES de forma nativa en cualquier plataforma mediante la traducción de llamadas y sombreadores en una API nativa (desktop gl [posiblemente proporcionada por el renderizador de software swiftshader], vulkan, directx, metal). También es una parte central de Chrome y Flutter, junto con Skia.

Microsoft podría hacer un subconjunto pequeño (tal vez solo como punto de partida) de DirectX para aplicaciones GUI y hacer que se traduzca en API nativas como lo hace ANGLE.

En lo que respecta al problema del "soporte de distribución de Linux diferente", los usuarios de Linux a menudo tienen la habilidad suficiente para solucionar la incompatibilidad por sí mismos, e incluso entonces está Flatpak que unifica el empaquetado para escritorios al igual que Docker lo hace para los servidores.

Mencionado en el chat de Lonje https://www.lonje.com/message/1968439855/

Realmente creo que WinUI también debería admitir temas nativos en Mac y Linux y, al mismo tiempo, admitir temas personalizados.
No estoy seguro acerca de los usuarios de Mac, pero a la comunidad de Linux le gusta controlar cómo se ve su escritorio.
Ya tienen Gtk, que creo que sería bueno incluir en el marco WinUi.

Realmente creo que WinUI también debería admitir temas nativos en Mac y Linux y, al mismo tiempo, admitir temas personalizados.
No estoy seguro acerca de los usuarios de Mac, pero a la comunidad de Linux le gusta controlar cómo se ve su escritorio.
Ya tienen Gtk, que creo que sería bueno incluir en el marco WinUi.

Definitivamente es difícil de hacer, ya que WinUI es un lenguaje de estilo, y los marcos XAML subyacentes requieren que usted mismo realice la creación de temas, mientras que también se proporcionan temas predeterminados.

He sugerido en el pasado que el proyecto debe estructurarse de manera que permita a la comunidad desarrollar un Metal Renderer para macOS e iOS, y posiblemente un renderizador Skia para Android.

Se pueden usar los mismos estilos y plantillas predeterminados en todas las plataformas, o se pueden crear recursos y plantillas predeterminadas con estilos de Android y macOS.