Estos son mis pensamientos iniciales sobre las preguntas que hizo en el contenido del tema.

Vengo desde una perspectiva de diseño y usuario, con solo un poco de experiencia en desarrollo, que se interesó mucho en el desarrollo de Silverlight / Windows Phone 7 en su día y ahora se siente un poco quemado.

¿Qué plantillas te interesarían más?

Creo que antes de solicitar una lista de ideas de plantillas, es necesario realizar algún tipo de auditoría de las aplicaciones más grandes y más utilizadas en cada marco, por lo que WPF, UWP, WinForms, MFC, etc.

Examine la "silueta" de estas aplicaciones y descubra los escenarios comunes de UX.

Fuera de mi cabeza, hay:

• Menú principal (todos los marcos)
• MDI (varios documentos en una sola ventana) (MFC principalmente)
• Pestañas y cuadrícula de datos (WPF, WinForms, MFC)
• Cinta (aplicaciones de Win32 Office, 3ds max, paint, wordpad, Explorador de archivos, etc.)
• Utilidades de la bandeja del sistema (MFC, WinForms)
• Navegadores
• Asistentes (WPF, MFC)
• Aplicaciones MDI complejas (software de Adobe, Visual Studio)
• Reproductores multimedia
• Visualización de datos LoB (WPF y Web)
• Aplicaciones sociales (React Native, PWA - Skype, Facebook, Twitter)

Todos o algunos de estos podrían beneficiarse de la integración del sistema WinRT / UWP con Notifications / Action Center.

Todas estas plantillas de Nuevo Proyecto deben evitar los espacios de nombres Windows.Xaml integrados, el tema de control de WPF y los estilos visuales de WinForms en favor de nuevas plantillas y estilos visuales que coincidan con los diseños de control de FabricWeb / Fluent.

También debería haber una manera fácil para que los desarrolladores con aplicaciones WPF y WinForms existentes agreguen una dependencia WinUI 3.0 que les brinde los nuevos diseños de control con una declaración de uso simple o una entrada de manifiesto.

Islas XAML

A medida que Xaml Islands se vuelve más fácil de hacer posible, reemplazar los controles de vista web antiguos, los selectores de color, los cuadros de diálogo basados ​​en XAML podría ser tan fácil como Agregar nuevo ... y elegir un cuadro de diálogo o un control estándar al que puede llamar el código C # y C ++ existente, y tienen su propio código subyacente.

Plantillas de aplicaciones y páginas modernas como aplicaciones Xbox Next, NavigationView, Master / Details, Hubs, Modern Ribbon, NavigationViewTop y Pivot, todas podrían estar disponibles para todas las plataformas de presentación de Windows, con las islas XAML en su lugar y contenido de muestra.

Cualquiera de estos escenarios que actualmente no es posible en UWP XAML, debe ser con controles y plantillas para facilitarlos.

¿Sería útil que Visual Studio u otra herramienta actualizaran automáticamente los espacios de nombres por usted?

Debería ser una pregunta cuando alguien abre su proyecto en la última versión de Visual Studio con un SDK de Windows 10 actual. Presione el botón y reemplazará los espacios de nombre y el uso, o los marcará si no es un control con el que está familiarizado.

En proyectos nuevos, debería ser el predeterminado y el paquete nuget debe instalarse junto con las versiones futuras del SDK de Windows.

¿Cuál sería su solución preferida para usar componentes UWP con WinUI 3?

Al igual que con la respuesta de actualización automática, las páginas y los proyectos nuevos deben incluirla de forma predeterminada y un mensaje que pregunte si quieren pasar automáticamente a WinUI | Agregue comentarios de Tareas para actualizar los espacios de nombres | No se mueva a WinUI .

¿Para qué tipo de aplicaciones estaría más emocionado de usar WinUI 3.0?

Como usuario, quiero que todas las aplicaciones que se ejecutan en Windows compartan una interfaz de usuario y una experiencia de usuario comunes, independientemente del marco que se haya utilizado.

Quiero que las aplicaciones se instalen sin alterar el registro y dejar basura. (tan centenario)

Quiero que todas las aplicaciones se puedan instalar desde dentro de la tienda, o desde un instalador tipo Centennial. Virtualice las carpetas del sistema y de Windows para cada aplicación.

¿Modernizar una aplicación C ++ MFC con Fluent UI?

Acrylic debería estar disponible para las aplicaciones WPF, WinForms y MFC, e incluirse en las nuevas plantillas predeterminadas a través de una dependencia o manifiesto de WinUI 3.0. Los controles comunes y los estilos de ventana deben usar acrílico y barras de título extendidas (que se pueden anular para volver a los valores predeterminados actuales)

Las aplicaciones Win32 no UWP de Microsoft deben volver a compilarse con WinUI 3.0 para que todas usen marcos de ventana acrílicos, menús principales, ThemeShadows, menús contextuales , campos de texto, barras de progreso, etc.

Y luego, las aplicaciones existentes necesitan una solución simple para instalar WinUI 3.0+, que luego actualiza el aspecto de todos los controles, o la capacidad de aplicarlo selectivamente un cuadro de diálogo a la vez, hasta que se actualice toda la interfaz de usuario.

re: namespaces, esperaría que simplemente cambiaran según el objetivo, incluso si requiere espacios de nombres condicionales.

Aquí están mis respuestas:

Creando una nueva aplicación

¿Qué plantillas te interesarían más?

• Me encantaría ver c ++ / winRT win32 + xaml y .net core + xaml primero allí, las plantillas de UWP en segundo lugar, la aplicación win32 empaquetada no debería venir como una plantilla, ya que las plantillas de paquetes de aplicaciones actuales deberían funcionar como ya lo hacen con la actual aplicaciones win32 / .Net.
• Además, me encantaría ver plantillas de elementos como "Nueva ventana XAML" con código de caldera para mostrarlo en una aplicación de aplicación principal win32 o .net existente (por ejemplo: hacer que la aplicación de bandeja del sistema existente a la Docker Desktop, pueda mostrar una nueva ventana Xaml de nivel superior)

Agregar WinUI 3.0 a aplicaciones Win32 existentes

• La compatibilidad no retroactiva es la razón exacta por la que nunca usé islas xaml en un proyecto real (aunque lo usé para divertirme en cosas personales). Desacoplar el marco de la interfaz de usuario de la API de Windows es uno de los mejores anunciados con la hoja de ruta de WinUI 3.0 (junto con la capacidad de las aplicaciones de destino no empaquetadas / no uwp para aprovecharlo)

Actualización de su aplicación UWP Xaml existente a WinUI 3.0

Puede sonar duro, pero siento que la aplicación xaml de UWP es un nicho (desde la caída de Windows Phone, no hay más tracción hacia UWP como plataforma de destino), e incluso si sería bueno tener herramientas / interoperabilidad, no Creo que debería ser el foco principal de WinUI 3.0.
Por lo tanto, tanto las herramientas de actualización del espacio de nombres (que en realidad podrían hacerse mediante una búsqueda y reemplazo global) como la combinación de UWP xaml y WinUI xaml no me parecen críticas.

Además, solo quiero mencionar que este es un movimiento muy bienvenido, ¡y tener todo el marco de la interfaz de usuario de código abierto en Github es increíble! ¡Muchas gracias por hacer esto!

En primer lugar, ¡este es un gran movimiento! Desafortunadamente, no puedo dejar de lado el hecho de que me siento un poco herido por la forma en que Microsoft ha tratado a los últimos desarrolladores de su plataforma. Por el momento, solo uso UWP para aplicaciones orientadas al

1. WPF es mucho más maduro que WinUI (validación, controles existentes, etc.), por lo que para empresas WPF es una mejor opción
2. UWP es ideal para múltiples categorías de dispositivos (móviles, tabletas, computadoras de escritorio, etc.), ahí es donde se encuentran los consumidores.

Es genial ver que el punto 1 podría abordarse con WinUI, por lo que me entusiasma el progreso de WinUI. Desafortunadamente, 2 ya no es aplicable (no más dispositivos geniales, solo computadoras de escritorio). Hace que uno se pregunte, en el momento en que se envía este material (¿1 año a partir de ahora?), ¿Qué necesitarían los desarrolladores en esa etapa?

Creo que las cosas del consumidor ya no son parte de la ecuación, ese barco ha navegado con la "estrategia" de reducción. Entonces, lo único para lo que podría ser bueno son las aplicaciones empresariales.

En general, estaría más interesado en una buena estrategia de migración de WPF a WinUI para intentar migrar nuestra enorme base de código WPF a Windows 10. La desventaja de tener que actualizar las aplicaciones orientadas al consumidor (actualmente UWP) es que dependen en gran medida en desarrolladores de componentes externos (por ejemplo, kit de herramientas win, etc.). Creo que ya no hay una opción viable para actualizarlos, ya que la mayoría de los desarrolladores (que conozco) perdieron el interés en el desarrollo de clientes para consumidores / Windows.

Respuestas a las preguntas

Creando una nueva aplicación

¿Qué plantillas te interesarían más?

Me encantaría ver .net core / xaml / C # aquí, ya que creo que esa es la combinación de idiomas más utilizada disponible. Pero tal vez una plantilla de migración sería mejor aquí (intente que todos se unan lo más rápido posible, cuanto más tiempo lleve, más doloroso será).

Agregar WinUI 3.0 a aplicaciones Win32 existentes

Creo que esto es extremadamente bueno, y lo usaríamos mucho (pero, de manera realista, falta al menos un año ya que los clientes empresariales todavía usan Windows 7, incluso cuando finalice el soporte de MS, las empresas estarán en Windows 7). Luego, podemos migrar lentamente WPF a WinUI 3.

¿Conocía las islas Xaml para modernizar las aplicaciones de escritorio?

Sí, pero demasiados clientes tienen (o tenían) Windows 7, por lo que no era una opción para los desarrolladores empresariales. Y para los consumidores, puede usar UWP de todos modos.

¿Esta compatibilidad con versiones anteriores ampliada en Windows 10 hace que Xaml Islands sea más útil para usted?

Es un buen comienzo porque en el momento en que se envía este material, funcionaría en todas las versiones compatibles de Windows 10 en la empresa.

Actualización de su aplicación UWP Xaml existente a WinUI 3.0

Las aplicaciones de consumo para la EM se acabaron, todo debido a las decisiones que tomó la EM, no hay más espacio para esto. Simplemente me saltearía toda esta opción y me olvidaría de ella. Es triste porque dediqué miles de horas a aplicaciones para UWP, pero creo que debemos acelerar esta muerte para que sea menos dolorosa.

Toda la historia prometida estuvo siempre actualizada, compatible con todos los dispositivos. Creo que todos sabemos en qué dirección fue esa promesa.

¿Sería útil que Visual Studio u otra herramienta actualizaran automáticamente los espacios de nombres por usted?

Si se trata solo de espacios de nombres, una búsqueda / reemplazo también debería funcionar.

¿Qué importancia tiene para usted la compatibilidad total entre los componentes UWP Xaml existentes y las aplicaciones WinUI 3.0?

Ya no es importante, estoy dispuesto a asumir la pérdida de miles de horas de desarrollo, no quedan usuarios de todos modos.

¿Crea o usa bibliotecas de control UWP Xaml o componentes WinRT que no podría volver a compilar y actualizar fácilmente junto con el código de la aplicación?

No.

¿Cuál sería su solución preferida para usar componentes UWP con WinUI 3?

Islas UWP (tipo de componentes alojados)

General

¿Qué opinas del plan general 3.0 descrito anteriormente y en la hoja de ruta? ¿Le permitiría usar WinUI para sus aplicaciones de Windows nuevas y existentes?

Probablemente necesite un poco de maduración, pero me veo usando este material en 1 o 2 años para el desarrollo empresarial. Dependiendo de lo difícil que sea migrar, elegiremos WinUI o web (dependiendo de cómo "evolucione" el propio Windows).

¿Para qué tipo de aplicaciones estaría más emocionado de usar WinUI 3.0? ¿Crear una nueva aplicación Win32 y empaquetarla con MSIX? ¿Agregar nuevas vistas a una aplicación WPF? ¿Modernizar una aplicación C ++ MFC con Fluent UI?

Probablemente solo agregue nuevas vistas a una aplicación WPF y comience a migrar lentamente.

Me gusta mucho esta hoja de ruta. UWP debe liberarse de sus ataduras, y esta es una excelente manera de hacerlo.

Actualización de su aplicación UWP Xaml existente a WinUI 3.0

Esto es muy importante para mi empleador. Tenemos una aplicación de escritorio compleja para UWP en la tienda. Ahora necesitamos Desktop Bridge para obtener acceso a las API de win32 que no son compatibles con .NET Native.

me gustaría

• acceso directo a todas las API de win32;
• utilizando un modelo de ejecución de win32 simple y antiguo. Estoy de acuerdo con algunos sandboxing similares a Desktop Bridge (por ejemplo, virtualización del registro);
• poner nuestra aplicación en la tienda (msix) como está ahora;
• seguir usando WNS (notificaciones push);
• una experiencia de actualización indolora de UWP a un nuevo tipo de aplicación Xaml Desktop. No me importa hacer algún trabajo manual. Tal vez prefiera una buena documentación sobre las herramientas aquí.

¿Qué importancia tiene para usted la compatibilidad total entre los componentes UWP Xaml existentes y las aplicaciones WinUI 3.0?

Los estilos existentes aún deberían funcionar. Puedo vivir con algunos cambios visuales menores. Pero no con cambios de comportamiento.

¿Crea o usa bibliotecas de control UWP Xaml o componentes WinRT que no podría volver a compilar y actualizar fácilmente junto con el código de la aplicación?

No.

¿Cuál sería su solución preferida para usar componentes UWP con WinUI 3?

Si no se pueden volver a compilar (tercero): enfoque similar a las islas Xaml. De lo contrario, debería ser posible portarlos fácilmente a WinUI 3.

General

¿Para qué tipo de aplicaciones estaría más emocionado de usar WinUI 3.0? ¿Crear una nueva aplicación Win32 y empaquetarla con MSIX? ¿Agregar nuevas vistas a una aplicación WPF? ¿Modernizar una aplicación C ++ MFC con Fluent UI?

• Aplicaciones de escritorio win32, empaquetadas con MSIX.
• Aplicaciones de plataforma cruzada de Uno;)

No introduzca nuevos espacios de nombres para cosas como _INotifyDataErrorInfo_; debe usarse en modelos de vista que generalmente son multiplataforma y no deben depender de WinUI. Debe definirse dónde se encuentran otras cosas como esta (es decir, _INotifyPropertyChanged_ o _INotifyCollectionChanged) _

Solo me gustaría saber si el objetivo final es crear una pila de interfaz de usuario multiplataforma. Entenderlo puede que no se comprenda completamente cómo llegamos allí. Sin embargo, si esa es la intención ... sería mejor marcar esto sin las referencias de Win al comienzo de este esfuerzo. Tendrá menos dolores de cabeza a largo plazo si lo hiciera.

¿Sería mejor etiquetar como XamlUI o similar? Los espacios de nombres Microsoft.UI. * Están bien, solo marque el repositorio y como

Gracias por contactarnos. Espere lo que está por venir en este espacio: sonrisa:

Para mí, todos los detalles técnicos son menos importantes.
UWP, WPF o cualquier marco solo para Windows, por increíble que sea, no será suficiente siempre que no se ejecute en todas las plataformas (al menos Windows, Droid, iOS y web), y es compatible con cualquier tamaño de pantalla.

TBH me decepcionó en la última compilación al descubrir que MS no tiene planes de hacer multiplataforma UWP o XAML. Uno no obtuvo ningún reconocimiento oficial más que un discurso. Aún más frustrante, diría que doloroso, fue descubrir que MS le está dando tanto amor a React Native y a los frameworks impulsados ​​por HTML / JS OTRA VEZ (WinJS), mientras descuida a los desarrolladores de pila de .NET responsables.
Me gustaría ver a MS creando oficialmente una pila de UI multiplataforma como Uno, y proporcionando las herramientas, plantillas y soporte integrado adecuados.

Y por cierto, he estado trabajando con XF desde su adquisición por MS, y desearía que tuviera una alternativa, por las siguientes razones: a. Sin soporte web, b. Muy inclinado a la movilidad, sin amor por las computadoras de escritorio c. Su jerarquía de bibliotecas se siente descuidada, definitivamente en comparación con la biblioteca de control de WPF / UWP d. No usa MS XAML.
Aquí está la solicitud de función que publiqué en Microsoft Developer Community: .NET UI Standard .

¡Gracias a todos!

Necesitamos una interfaz de usuario XAML que también se ejecute en la Web (ensamblado). Al menos un subconjunto de UWP.
¿Por qué no adoptar la plataforma UNO y hacer el renderizado web usando SkiaSharp?
Podría ser Silverlight 6 , la contraparte web de WinUI

Respuestas rápidas a las preguntas

¿Qué plantillas te interesarían más?

Proyectos de .NET core SDK, o algún formato de proyecto MSVC simplificado.
Los archivos de proyectos antiguos son demasiado complicados para editarlos manualmente y existen muchos problemas de interacción entre el sistema de proyectos antiguo y el nuevo. Deberíamos abandonar por completo el antiguo sistema de proyectos para proyectos nuevos.

¿Conocía las islas Xaml para modernizar las aplicaciones de escritorio?

No. Estoy reescribiendo mi aplicación con un cambio de modelo de datos completo, por lo que no hay una migración progresiva.

¿Esta compatibilidad con versiones anteriores ampliada en Windows 10 hace que Xaml Islands sea más útil para usted?

Todavía hay muchos usuarios en Windows 7 y Xaml Islands no puede ayudar.

¿Qué importancia tiene para usted la compatibilidad total entre los componentes UWP Xaml existentes y las aplicaciones WinUI 3.0?

No. Todos mis componentes están escritos por mí mismo, o de MUX y WCTK, por lo que puedo realizar una migración manual rápida.

¿Sería útil que Visual Studio u otra herramienta actualizaran automáticamente los espacios de nombres por usted?

No tanto, porque mi proyecto no es grande (~ 20 páginas y ~ 10 controles personalizados por ahora).

¿Cuál sería su solución preferida para usar componentes UWP con WinUI 3?

Me gustaría que hubiera una versión enviada con el sistema operativo, para permitir la creación de herramientas muy pequeñas y el envío en KB . La herramienta simplemente no se ejecuta en un sistema operativo inferior, ya que el supuesto usuario puede contactarme inmediatamente (por ejemplo, a través de algún software de chat).

¿Para qué tipo de aplicaciones estaría más emocionado de usar WinUI 3.0? ¿Crear una nueva aplicación Win32 y empaquetarla con MSIX? ¿Agregar nuevas vistas a una aplicación WPF? ¿Modernizar una aplicación C ++ MFC con Fluent UI?

Crear una nueva aplicación solo para Windows 10 y enviarla sin la tienda.
La firma confiable es costosa para los desarrolladores individuales, y la carga a la tienda no se aplica a aplicaciones específicas de dominio, no a aplicaciones a largo plazo.

Mi estilo personal para la plataforma UI

Cadena de herramientas Xaml

El lenguaje xaml de alguna manera no es serio y me enfrento a muchos problemas como "¿cómo debo representar esto?". WPF xaml y UWP xaml no son totalmente compatibles, así que necesito recordar sus diferencias. Xaml no es totalmente compatible con las características de .NET, por lo que a veces necesito escribir algunos trucos desagradables en mi modelo y una clase de ayuda.

Viniendo con x:Bind , las cosas empeoran aún más. Los escenarios simples son fáciles de usar, pero es muy complicado hacer cosas que son más que un acceso a la propiedad. Por ejemplo, no admite la sobrecarga de métodos, por lo que debo compilar para verificar qué sobrecarga se elige para esta expresión de enlace. Ni siquiera puedo hacer un cambio simple, o una conversión "visible cuando alguna propiedad es falsa", y se requiere un método auxiliar. La documentación no dice nada sobre estos escenarios detallados, por lo que creo que debería haber una posición para la discusión del diseño del lenguaje xaml y hacer de xaml un lenguaje diseñado en serio como C #.

El editor xaml también es difícil de usar. Es razonable que el diseñador intente ejecutar algún código para mostrar los efectos reales, pero el editor de texto debería estar al tanto de los metadatos. Abrir un archivo xaml en la vista de código fuente es lento porque activa el diseñador y arroja algunas excepciones de interacción para xaml totalmente correcto, como NullReferenceException y Cannot convert __ComObject to some type . Toca ProjectReference través de bibliotecas compiladas y da como resultado un error complicado incluso cuando se realiza una simple edición en el área no pública de la API en la biblioteca de dependencias, generalmente la implementación del modelo de datos. Así que creo que debería haber un compilador xaml totalmente integrado de Roslyn y que tenga en cuenta los metadatos y el código fuente.

Un mejor modelo de ventanas

Es habitual que la aplicación con información completa y estado completo utilice un modelo de ventanas múltiples en lugar de un modelo de navegación. Actualmente en UWP, crear una nueva ventana usando ApplicationView es doloroso porque hay problemas de subprocesos. El nuevo AppWindow comparte el hilo de la interfaz de usuario, y no estoy seguro de su rendimiento de la interfaz de usuario.

Reescribir Visual Studio en WinUI en algún momento futuro puede demostrar que es un sistema de interfaz de usuario maduro.

Interfaces de enlace de datos

Estamos muy cansados ​​de crear modelos que implementen INotifyPropertyChanged . Escribí una tarea personalizada de MSBuild para convertir un xml en accesos de propiedad expandidos, pero no ayuda cuando quiero hacer algo personalizado en el setter cuando la propiedad cambia.

Y hay problemas de subprocesos. Mis datos provienen totalmente de un servidor de red en segundo plano, por lo que la captura de contexto por await no me puede ayudar. En WPF y Binding , es como está porque Binding resuelve el subproceso por sí mismo. Al cambiar a x:Bind , tengo que resolverlo dentro del generador de eventos, porque x:Bind solo opera en el hilo de llamada. Las cosas empeoran aún más cuando tengo varias vistas de aplicaciones que tocan los mismos datos, lo que significa que no hay un despachador de UI global disponible y la única solución es capturar SynchronizationContext.Current en el registro del evento. Para las colecciones, ItemsSource tampoco es seguro para subprocesos, y se requiere la misma solución alternativa.

Definitivamente debería haber una cadena de herramientas para resolver los problemas de modelado, subprocesamiento y extensión de modelos enlazables mutables. Y una solución genérica incorporada para la colección enlazable debería proporcionar un mecanismo para "propiedad especificada de cualquier hijo cambiado".

IObservableVector<T> es un tipo genérico falso que puede usar object solamente, INotifyCollectionChanged no es genérico. Simplemente impleméntelo para la colección incorporada como ObservableCollection<T> no es suficiente, especialmente para escenarios complicados, orientados a ISupportIncrementalLoading / IItemsRangeInfo . La plataforma debe proporcionar una implementación abstracta predeterminada con las mejores prácticas, lo que permite al usuario implementar un método abstracto de llenado de datos.

@shaggygi @weitzhandler @TonyHenrique

Si va a haber un futuro multiplataforma para UWP / XamlUI3.0 abstrayendo la sintaxis XAML, desde el renderizador de Windows, y el resto del tiempo de ejecución de Windows sería una forma de manejarlo.

Si pudiera haber una mentalidad casi de plug-in con el proyecto, podría haber un renderizador de Android o iOS / AppKit, y un AppKit Shim de Android / iOS para pasar las API de ART a C # y VB, así como al lenguaje C ++, C existente. apoyo.
Xamarin podría ayudar aquí.

Microsoft no necesita ser el que trabaje en esos renderizadores de plataforma alternativa.

Pero centrándose en Windows por ahora ... WinUI 3.0 podría abarcar Fabric Web / React Native / WPF / WinForms / MFC. PWA también será un ciudadano de primera clase para el desarrollo de aplicaciones, por lo que hay historias multiplataforma para aplicaciones que no están hechas para Windows / .NET / UWP directamente.

Lo que se necesita ahora es proporcionar una historia para que los desarrolladores de C # / .NET / UWP lleven sus aplicaciones e inversiones al panorama más amplio de plataformas.

Mis 2 centavos: soy un desarrollador de Xamarin.Forms y (como muchos otros) estoy interesado en ver todos los dialectos XAML fusionados en uno que funcione en todas partes, incluido el espacio móvil. No estoy seguro de cómo sería eso, pero ese es al menos mi deseo al respecto.

Quizás WinUI 3.0 en adelante, pero hay demasiadas aplicaciones WPF para esperar que todas reescriban y traduzcan todo ese XAML. Los nuevos proyectos de WPF podrían usar el dialecto WinRT XAML más moderno. Puede introducir el equivalente de un DocType en XAML para que puedan coexistir diferentes dialectos en el mismo proyecto.

Más fácil decirlo que hacerlo, por supuesto.

@mdtauk Creo que una vez que la plataforma Xaml sea realmente de código abierto, tendremos una comprensión más clara de en qué se basa en la parte inferior de la pila (ya sabemos que las principales dependencias específicas de la plataforma son DirectX11, Direct2D y Windows Media Foundation, pero quién sabe qué parte del SDK de Windows se usa allí) y cómo está estratificado (para que podamos tener una idea real sobre la viabilidad de cualquier portabilidad).
Además, todavía tenemos que ver bajo qué tipo de licencia se distribuirá el código fuente. No estoy seguro de que se haya decidido todavía.

Android usa Vulkan y creo que es compatible con OpenGL
iOS y macOS usan Metal

En cuanto a los códecs de medios, puede ser posible utilizar API nativas basadas en C para sustituir.

@simonferquel Se volverá más claro cuando el código se refactorice y se registre. Y es posible que se requieran algunos expertos en iOS y Android para liderar esos esfuerzos.

Creo que cambiar el espacio de nombres fue un enfoque razonable cuando winui era una colección de controles. Sin embargo, ahora que básicamente reemplaza la plataforma, creo que esto ya no está justificado. Esto ya funciona de la misma manera para WPF / Winforms, donde el código se puede mover de .net Framework a .net core sin cambiar los espacios de nombres en el código. La plataforma debería poder cargar automáticamente las versiones winui de las DLL necesarias cuando esté habilitada. De esta manera, se puede preservar la compatibilidad de código fuente y binario (he utilizado con éxito las bibliotecas de .net framework en las aplicaciones principales de .net).

¡Solo quería dar las gracias a todos por los comentarios hasta ahora! El equipo de WinUI está analizando cuidadosamente todas las respuestas y puntos.
También es probable que separemos algunos temas específicos para hablar sobre puntos específicos que han surgido (por ejemplo, compatibilidad con los marcos y componentes de UWP existentes) una vez que hayamos organizado nuestras ideas.

Solo quiero agradecerle a MS por escuchar más y brindar a los desarrolladores de .net herramientas increíbles, pero no puedo evitar sentirme decepcionado con el futuro de UWP Xaml después de la conferencia de compilación.
Al leer este blog y muchos artículos en la red, tiene la sensación de que UWP se está volviendo exclusivamente "empresarial" e incluso eso es discutible, ya que muchas empresas se están volviendo más independientes del sistema operativo, lo que permite a los trabajadores usar, por ejemplo, MacBook Pro.

Permítanme aclarar que estoy muy involucrado en UWP nativo y Xamarin Forms (Android, iOS) y me encanta la plataforma, pero después de que MS anuncie el soporte nativo para React, estoy a punto de abandonar el barco.

Sé que debo hacer que mi aplicación para UWP sea más independiente de la plataforma en el escritorio, por lo que esperaba poder crear una "aplicación híbrida" con mi aplicación uwp actual como shell e incorporar cada vez más tecnologías web front-end mediante el uso de React en la mezcla. . Algo como la función de "Conjuntos" propuesta que, según tengo entendido, ahora está retrasada debido a prioridades más altas dentro de Edge, habría sido ideal para mi solución actual, ya que desdibuja por completo las líneas entre UWP nativas y tecnologías web al ejecutar tecnología nativa y web en "Ventanas / pestañas de borde". Este enfoque "híbrido" me permitirá incorporar lentamente la tecnología web en mi plataforma actual, pero también le da a las "aplicaciones nativas" una pestaña en el "navegador", por así decirlo. (desde la perspectiva del consumidor) Esto también me proporciona una vía de escape si las "aplicaciones nativas de uwp" fallan a largo plazo en el escritorio.

La razón por la que pensé anteriormente es que UWP no me proporciona una escotilla de escape, ya que puede convertirse fácilmente en la próxima víctima de Silverlight si no hay capacidad multiplataforma pronto. MS está cubriendo sus apuestas asegurándose de que no pierdan la tendencia PWA o su mano se está volviendo a favor del soporte nativo de React en Windows. El problema es que hice una apuesta con la esperanza de que en ese momento hubiera una "ruta" para UWP / c # /. Net en el navegador o plataforma cruzada y que pudiera reutilizar la mayor parte de mi inversión en esas plataformas.

Recuerdo que cuando todos los desarrolladores gritaron: compre Xamarin, MS tardó una eternidad en hacerlo. Creo que la mayoría de los desarrolladores que están familiarizados con el ensamblaje web saben que recientemente lograron ejecutar una “versión completa” de Windows Server en ensamblaje web y dirán que compre la plataforma Uno y que sea enorme con una inversión significativa. Si un sistema operativo completo puede ejecutarse en un ensamblaje web, MS debería brindar a cada desarrollador de .net una ruta de migración a la capacidad multiplataforma para proteger sus inversiones existentes.

Se podría decir que Blazor está ahí, pero, francamente, antes de invertir más tiempo en una nueva plataforma, prefiero aprender React o podría decir que los EM tenemos recursos limitados para todo esto. Seguramente cuando pagas $ 7.5 mil millones por Github, todo se vuelve relativo.

Creo que es fundamental que MS comprenda el daño a la reputación que causa una ruta de migración fallida a la capacidad multiplataforma para las inversiones existentes en UWP / Win32. La capacidad multiplataforma debería ser sinónimo de .NET 5 y no lo es. No estoy seguro de si los pequeños pasos hacia la plataforma cruzada en este caso funcionarán para MS y créanme, siempre he sido un gran fan de xaml / .net / c #

¿Qué plantillas te interesarían más?

¿Te refieres también a plantillas de proyectos o plantillas de elementos?

¿Sería útil que Visual Studio u otra herramienta actualizaran automáticamente los espacios de nombres por usted?

¿Sería esto solo una búsqueda y reemplazo (menos valor) o también incorporaría dependencias de actualización a la nueva versión (más valioso pero no estoy seguro de cómo saberlo)?

Re: compatibilidad con versiones anteriores para nuevas funciones

¿Ser compatible con versiones anteriores de Creators Update (15063) será un punto de referencia fijo o el plan en el futuro será admitir la versión actual y el número X de versiones anteriores?

¿Qué significará esto para cualquiera que cree una extensión o control propio o funcionalidad que quiera compartir públicamente? ¿Necesitarán también admitir ese nivel de compatibilidad con versiones anteriores? ¿Incluso en Windows 8.1?

Re: migrar espacios de nombres

¿Será posible migrar una UWP existente en etapas (estoy pensando en páginas) o será necesario actualizar toda la aplicación a la vez? Si es toda la aplicación de una vez, la adopción será más lenta.

¿Qué pasa con la migración de aplicaciones WPF? - ¿La estrategia de migración es usar islas XAML que podrían usar WinUI 2.xo 3.x? ¿Se pueden usar ambos en la misma aplicación?

Sí, dividir este tema en varios temas más enfocados ayudará a capturar ideas con mayor claridad y evitar las tangentes.

Reemplace todas las instancias de UWP con los nombres adecuados, ya que no está claro a qué se refiere.

@mrlacey :

¿Te refieres también a plantillas de proyectos o plantillas de elementos?

¡Las plantillas de artículos o bibliotecas también son interesantes! Hay algunos puntos importantes en las respuestas hasta ahora acerca de proporcionar un código estándar y de inicio adicional, que es algo más que podríamos considerar agregar con el tiempo, tal vez como Windows Template Studio .

¿Sería esto solo una búsqueda y reemplazo (menos valor) o también incorporaría dependencias de actualización a la nueva versión (más valioso pero no estoy seguro de cómo saberlo)?

Buena pregunta: ¿qué tipo de actualizaciones de dependencias lo harían más valioso? por ejemplo, ¿encontrar nuevas versiones de paquetes de NuGet compatibles?

¿Ser compatible con versiones anteriores de Creators Update (15063) será un punto de referencia fijo o el plan en el futuro será admitir la versión actual y el número X de versiones anteriores?

Prevemos que el rango de versiones de soporte cambiará con el tiempo en función del uso. En lugar de limitarnos a un número específico de versiones, es probable que sigamos analizando los datos de uso y admitamos las versiones de Windows 10 más activas del mercado.

¿Qué significará esto para cualquiera que cree una extensión o control propio o funcionalidad que quiera compartir públicamente? ¿Necesitarán también admitir ese nivel de compatibilidad con versiones anteriores? ¿Incluso en Windows 8.1?

Actualmente, no prevemos imponer ningún requisito adicional o "certificación" para los controles personalizados. El control de versiones dependerá de usted. Sin embargo, la historia general de versiones de la Actualización de mayo de 2019, WinUI 3.0 y las versiones futuras de WinUI es definitivamente un tema en el que queremos profundizar más pronto.

¿Será posible migrar una UWP existente en etapas (estoy pensando en páginas) o será necesario actualizar toda la aplicación a la vez? Si es toda la aplicación de una vez, la adopción será más lenta.

Gran pregunta, gracias por señalar eso. Este es también un tema en el que queremos profundizar más pronto.

Reemplace todas las instancias de UWP con los nombres adecuados, ya que no está claro a qué se refiere.

@riverar : ¿hay algún uso o sección específica que no esté claro?

Usamos el término " UWP Xaml " para referirnos a la plataforma Xaml que se envía como parte de Windows 10 y el SDK de UWP, para distinguirla de otras plataformas basadas en Xaml (por ejemplo, WPF).

También nos referimos al " modelo de aplicación para UWP " (empaquetado e instalación, administración de datos y estado, ciclo de vida en tiempo de ejecución, etc.), a diferencia de un modelo de aplicación Win32.

Incluso en equipos de escritorio con Windows, los usuarios pasan mucho tiempo navegando por Internet.
Creo que necesitamos una forma de desarrollar aplicaciones web decentes, utilizando el (subconjunto de) UWP vNext XAML + .NET (C # / F # / VB.NET)

Desarrollé en WPF + ClickOnce durante muchos años, luego comencé a buscar en UWP. Me gusta UWP, pero él (o la próxima versión) necesita poder ejecutar un EXE independiente, mejores API de Windows (permiten crear una aplicación de estilo Winamp Windows personalizada incluso si QUEREMOS), más API de impresión, interoperabilidad fácil con C dll , OCX, al menos un subconjunto de los componentes debe ejecutarse en la Web.

Cuando vi UNO, pensé: Microsoft podría comprar esta empresa y unir a estos desarrolladores con los equipos de UWP y Xamarin. Me alegraría si la próxima versión de UWP se convirtiera en algo de Azure, que se ejecuta en Web, Windows, Mobile e IoT. En mi opinión, incluso Azure Portal podría escribirse en UWP vNext.

Microsoft puede hacerlo. Lo hiciste con Silverlight, lo hiciste con WPF, lo hiciste con UWP, lo hiciste con Xamarin. Ha llegado el momento del marco GUI XAML definitivo. Y, en mi opinión, Web debe ser compatible, al menos en un subconjunto de la funcionalidad.

_INotifyDataErrorInfo_

No introduzca nuevos espacios de nombres para cosas como _INotifyDataErrorInfo_; debe usarse en modelos de vista que generalmente son multiplataforma y no deben depender de WinUI. Debe definirse dónde se encuentran otras cosas como esta (es decir, _INotifyPropertyChanged_ o _INotifyCollectionChanged) _

Sobre este tema. Windows.UI.Xaml.Interop ya tiene una interfaz INotifyCollectionChanged y Windows.UI.Xaml.Data tiene INotifyPropertyChanged. Estos dos se moverán a los espacios de nombres de Microsoft. Quizás los ensamblados System.Runtime.WindowsRuntime puedan hacer alguna asignación de WinUI a .Net

Lo único que quiero agregar si aún no se ha agregado es que apoyo al 100% el modelo de paquete MSIX / Appx y Win10 ha hecho un trabajo fantástico arreglando la mierda que fue la instalación y eliminación durante la vida útil de Windows. Sin embargo, siempre tuve problemas para crear una aplicación "UWP" debido al extraño subconjunto de opciones de API disponibles que se hicieron en la caja de arena de AppContainer. Como desarrollador de C ++, eso fue frustrante y cada año verlo abrir más la caja de arena para permitir el conjunto completo de API de Win32 ha sido un alivio.

Entonces, si WinUI 3.0 me permite crear una aplicación con acceso al 100% de la pila de Win32, ¡esto será dorado! Intenté usar XamlIslands en este momento, y es una trampilla de escape fantástica, pero ha sido inestable para mí y me queda algo de trabajo antes de que realmente cruce la línea de meta.

Obteniendo plantillas de proyecto que me permitan crear una aplicación Win32, sin estar metido dentro de un proceso de AppContainer, y me permitan acceder a todos los avances que ha hecho con la interfaz de usuario, entonces WinUI 3 será perfecto para mí.

@ eklipse2k8 Todavía es necesario un sistema de permisos para acceder a los archivos y dispositivos de un usuario, incluso en una zona de pruebas relajada. También creo que debería haber reglas para mantener en el área de usuario y evitar la elevación al acceso de administrador y kernal, sin algún tipo de prueba oficial y requisitos de firma de código.

Hola Microsoft,

No sé cuánto influirá esta publicación en el tema de la representación de ClearType , DirectWrite y el futuro de la interfaz de usuario de Windows, pero soy uno de los pocos pequeños pero vocales y apasionados que tienen serias quejas con los subsistemas de representación de fuentes en Windows.

Está bien documentado en casi todas partes sobre las frustraciones (o satisfacción) de la encanta el suavizado de fuentes y otras que lo odian absolutamente.

No estoy aquí para discutir si uno es mejor que el otro. Tampoco estoy aquí para discutir los trucos del registro, los 'sintonizadores de fuentes' o cómo puedo modificar la configuración del sistema operativo para que las fuentes se vean mejor. Créame, lo he hecho todo; incluso yendo tan lejos como para hacer una investigación para escribir un controlador en modo kernel para parchear funciones DirectWrite en modo kernel.

Estoy aquí porque tengo una condición médica óptica muy común llamada miopía / miopía . Puedo ver las cosas claramente de cerca. Pero solo a la distancia de los brazos, mi visión está justo en el borde de mi agudeza visual y donde el texto comienza a volverse borroso.

Más allá de la distancia de los brazos, necesito usar lentes correctivos. : anteojos: Estoy seguro de que todos lo sabemos, las pantallas de las computadoras de escritorio están a la distancia de los brazos. De ahí el problema.

• Las fuentes que se ven suaves, me parecen borrosas.
• Las fuentes con bordes afilados (ajustadas a píxeles) me parecen más claras.

Cuando las fuentes se ajustan a píxeles, los bordes afilados son una señal visual para mi cerebro de que mi visión es clara y enfocada . Sin embargo, cuando encuentro un texto con una letra suave, esa señal visual engaña a mi cerebro para que piense que mi visión está desenfocada.

Como compañero desarrollador que pasa largos períodos de tiempo escribiendo código y mirando texto, es frustrante y duele muchísimo. Esta es la razón principal por la que sigo ejecutando Windows 7 y no Windows 10 . Casi toda la interfaz de usuario principal de Metro de Windows 10 utiliza el suavizado de fuentes en todas partes.

Para ilustrar este problema de suavizado de fuentes, veamos el complemento services.msc MMC en Windows 7 :

¿Ves algún texto borroso que parezca desenfocado? Aquí. Acerquémonos un poco más ...

Dios mío, se siente como si estuviera mirando un texto bizco en un autoestereograma .

Resulta que, en este caso específico, examinando la jerarquía de control de esta ventana, el complemento MMC aloja un control DHTML / ActiveX de Internet Explorer que muestra texto borroso en el panel "seleccione un elemento para ver su descripción". El menú nítido (ajustado a píxel), "Ayuda" y la lista de servicios se representan con las primitivas USER32 y GDI32 normales.

Este pequeño ejemplo destaca uno de los mayores problemas con la representación de fuentes en Windows. Resulta que IE8 respetará la configuración global del sistema operativo que desactiva ClearType y el suavizado de fuentes. Sin embargo, si instala IE9 o superior, IE9 + felizmente ignorará todos y cada uno de los esfuerzos para deshabilitar el suavizado de fuentes. IE9 + simplemente no le importa y obliga a todos los usuarios a ver texto en sitios web (y en controles ActiveX) con texto suavizado por fuentes.

El problema empeora para los usuarios como yo porque a medida que pasa el tiempo, el nacimiento de Windows 8 y Windows 10, Metro Apps, WPF y UWP han adoptado el mismo enfoque que IE9 +. Todas estas tecnologías de interfaz de usuario ocultas ignoran las configuraciones globales del sistema operativo que deben respetarse en nuestras máquinas. Si deshabilitamos ClearType y el suavizado de fuentes a nivel de todo el sistema operativo, esperamos que las API de ClearType y DirectWrite (y, en consecuencia, las aplicaciones Metro, WPF y UWP) no dibujen con suavizado de fuentes.

Sé que no soy el único con este problema.

Hace un tiempo, Google Chrome hizo lo mismo con su versión v31 e intentó seguir el enfoque IE9 + y cambió toda la representación de fuentes a DirectWrite ignorando la configuración global de todo el sistema. Este cambio enfureció a Internet. Consulte Chromium Issue 319429 . Finalmente, después de mucho rechinar de dientes, Google invirtió el rumbo y corrigió el problema en Chrome 37 para aquellos usuarios con discapacidad visual miope y ahora respeta la configuración de todo el sistema operativo que deshabilita el suavizado de fuentes.

Gracias a los poderes fácticos y las fuerzas del mercado, Microsoft perdió la guerra de los navegadores y ahora está adoptando el motor de renderizado Chromium, pero mantengo la respiración contenida en que el equipo de Edge respetará las configuraciones de suavizado de fuentes deshabilitadas.

Solo estoy aquí para defender que Microsoft necesita una configuración global que debe respetarse , para todas las aplicaciones en el sistema operativo, en todas las pilas de UI , para aquellos con problemas de agudeza visual.

Y como recordatorio amistoso, este es un problema de accesibilidad para la interfaz de usuario de Windows en general, no una preferencia visual.

Sobre la base de la prevalencia mundial de la miopía, se puede estimar que más del 22% de la población mundial actual, es decir, 1.500 millones de personas son miopes. https://www.ncbi.nlm.nih.gov/pmc/articles/PMC3930268/

Gracias,
Brian

: walking_man:: walking_woman: Personas desaparecidas - Caminando en Los Ángeles

Esto significa que el marco Xaml completo se desarrollaría en GitHub y se enviaría fuera de banda como paquetes

NuGet es genial, pero también se agradecería la compatibilidad con vcpkg (y CMake ) (para aquellos de nosotros con grandes bibliotecas multiplataforma existentes).

¿Qué plantillas te interesarían más?

En orden de preferencia:
Win32 + Xaml Desktop + WinUI
Win32 + Islas Xaml + WinUI
UWP + WinUI

¿Conocía las islas Xaml para modernizar las aplicaciones de escritorio?¿Esta compatibilidad con versiones anteriores ampliada en Windows 10 hace que Xaml Islands sea más útil para usted?

Sí, Xaml Islands es interesante, pero como nos dirigimos a los consumidores y no a los clientes empresariales, la compatibilidad con versiones anteriores ampliada no es un factor decisivo: la mayoría de los clientes están razonablemente felices de actualizar su sistema operativo (y dadas las escalas de tiempo para implementar cambios basados ​​en el nuevo WinUI Xaml, tenerlo bloqueado hasta 1903 probablemente significaría que ya ha estado fuera de un año).

El espacio de nombres raíz para las API de entrada, composición y Xaml en WinUI será diferente del espacio de nombres raíz del SDK de Windows UWP:

¿Sería útil que Visual Studio u otra herramienta actualizaran automáticamente los espacios de nombres por usted?

Esto no me afecta, ya que no tenemos una aplicación para UWP (actualmente usamos WPF para ventas directas y WPF + Desktop Bridge para la tienda), pero cambiar los espacios de nombres es algo que se realiza una sola vez, e incluso en las bases de código más grandes, una búsqueda y reemplazo global de Windows::UI::Xaml no es tan abrumador (todos estamos usando el control de versiones, ¿no?).

El camino más rápido para lanzar WinUI 3.0 sería no admitir la mezcla:

Eso está bien para mí, deberían tratarse como bibliotecas incompatibles separadas. Apunta a UWP Xaml o WinUI Xaml. Como se mencionó anteriormente, la conversión única no debería ser tan difícil.

Sin embargo, una de nuestras mayores preocupaciones son los problemas de compatibilidad y el trabajo que podrían crearse para las aplicaciones y las bibliotecas de componentes de UWP existentes, especialmente si está creando o consumiendo bibliotecas de control de UWP Xaml.
Por ejemplo, las versiones existentes de Windows Community Toolkit no se podrían utilizar en las aplicaciones WinUI 3.0, por lo que tanto el Toolkit como las aplicaciones que lo utilicen deberían actualizarse antes de usar WinUI 3.0.

Microsoft necesita elegir una tecnología y ceñirse a ella. Durante años, nos han prometido los últimos y mejores marcos de interfaz de usuario de escritorio (Win32, ATL, WTL, MFC, WinForms, WPF, UWP Xaml y ahora WinUI Xaml). Si bien la elección es excelente, conduce a una fragmentación de la funcionalidad y el conocimiento del desarrollador. Es mucho más fácil tener una sesión / una página web / una respuesta de stackoverflow sobre la implementación de una función en Windows, frente a 7 diferentes según la tecnología. Si WinUI Xaml es el futuro, el kit de herramientas de la comunidad debe actualizarse para aprovecharlo.

¿Qué importancia tiene para usted la compatibilidad total entre los componentes UWP Xaml existentes y las aplicaciones WinUI 3.0?

He estado esperando hacer algo con UWP Xaml porque la funcionalidad simplemente no está allí (en comparación con Win32 / WPF), y supongo que no estoy solo en ese sentido. Como tal, la compatibilidad total no es un problema.

¿Crea o usa bibliotecas de control UWP Xaml o componentes WinRT que no podría volver a compilar y actualizar fácilmente junto con el código de la aplicación?

No.

¿Cuál sería su solución preferida para usar componentes UWP Xaml con WinUI 3?

N / A

1. ¿Qué opinas sobre el plan general 3.0 descrito anteriormente y en la hoja de ruta ? ¿Le permitiría usar WinUI para sus aplicaciones de Windows nuevas y existentes?

No se menciona Xaml Desktop en la hoja de ruta. ¿Esto es competencia de WinUI?
Le mencioné esto antes a la gente de // Build /, pero la razón por la que no se adoptó UWP Xaml antes es que era imposible crear una aplicación que utilizara las bibliotecas de C ++ existentes. Por ejemplo, cuando un usuario elige un archivo con FileOpenPicker , el resultado se entrega como un IStorageFile y no hay forma de pasarlo a una biblioteca de terceros existente para abrir (por ejemplo, libpng , libjpeg , etc.). Es por eso que hemos tenido que seguir con WPF, por lo que si Xaml Desktop o Win32 + Xaml Islands nos permiten vivir sin estas restricciones, entonces sí, nos permitiría usar WinUI para una nueva aplicación.

1. ¿Para qué tipo de aplicaciones estaría más emocionado de usar WinUI 3.0? ¿Crear una nueva aplicación Win32 y empaquetarla con MSIX ? ¿Agregar nuevas vistas a una aplicación WPF? ¿Modernizar una aplicación C ++ MFC con Fluent UI?

Creación de una nueva aplicación Win32 con WinUI (y empaquetado con MSIX).

Si tiene alguna pregunta, hágamelo saber, me complace seguir hablando.

En realidad, espero que haya una forma de llamar a Compact Overlay desde WPF / WinForms.
Solo necesitamos un sistema de permisos de administrador como "Dibujar sobre el permiso de otras aplicaciones" en Android.

Espero que este modelo de aplicación + empaque (UWP + AppX, Win32 + MSIX) lo permita (Abstracción completa dentro de Sandbox)

¿No se supone que Windows tiene las posibilidades más avanzadas e ilimitadas, con la mejor seguridad?
No por característica lisiada por seguridad.

Gracias por abrirse a la comunidad para recibir comentarios sobre la hoja de ruta.

¿Qué importancia tiene para usted la compatibilidad total entre los componentes UWP Xaml existentes y las aplicaciones WinUI 3.0?

En este punto, tenemos bastantes aplicaciones para UWP en uso para clientes empresariales en este momento, y espero que la ruta de migración no sea tan difícil. Si hay cambios importantes, sería muy bueno tener una herramienta de migración similar a .Net Framework a .Net Core que genere qué tan compatible sería nuestra ruta de migración, esto debería informar cualquier cosa que pueda necesitar cambios ( por ejemplo, API que podrían estar obsoletas o comportarse de manera diferente) y una opción para cambiar automáticamente el espacio de nombres si es posible. De esta manera, la ruta de migración de UWP a WInUI no será tan volátil para los desarrolladores empresariales estadounidenses.

¿Conocía las islas Xaml para modernizar las aplicaciones de escritorio?
¿Esta compatibilidad con versiones anteriores ampliada en Windows 10 hace que Xaml Islands sea más útil para usted?

Sí, pero no fue un gran problema ya que, en el futuro, todas nuestras aplicaciones de escritorio recientemente desarrolladas utilizan la comunicación UWP a través de un backend de API, y la mayoría de nuestros clientes ya están ejecutando Windows10.

¿Qué opinas del plan general 3.0 descrito anteriormente y en la hoja de ruta? ¿Le permitiría usar WinUI para sus aplicaciones de Windows nuevas y existentes?

El equipo de escritorio ya está emocionado por las noticias de WinUI 3, pero como se indicó anteriormente, teme la migración de todas nuestras aplicaciones para UWP si el camino no es tan sencillo.

En cuanto al XAML general, dado que todo el marco de la interfaz de usuario de XAML vivirá desacoplado de Windows, como otros han dicho, haga que sea posible intercambiar los renderizadores. Esto abrirá la posibilidad de ejecutar WinUI XAML en otras plataformas, lo cual es un factor determinante enorme hoy en día cuando las personas eligen una pila con la que quedarse, como se evidencia con la popularidad de los frameworks Electron y JS que se aprovechan de ellos para las pequeñas empresas que no tienen la mano de obra para desarrollar específicamente bases de código nativas para cada plataforma.

También agregue que con WinUI 3 en adelante también debería mejorar el dialecto XAML, tal vez introducir un espacio de nombres de versión / Doctype para especificar qué versión de XAML se está usando para mantener la compatibilidad con versiones anteriores para aplicaciones más antiguas. Hay mucho que hacer para hacer que XAML sea menos detallado o fragmentar un texto estándar, como tener que escribir INotifyPropertyChanged con configuradores privados de respaldo para uno en lugar de ser solo un atributo de propiedad simple, decir NotifyPropertyChangedAttribute y dejar que el El paso de compilación inyecta la implementación para evitar la sobrecarga del tiempo de ejecución o DependencyProperties para controles personalizados para simplificar la creación de componentes. Quizás también tome algunas de las mejoras en el equipo de Razor para algunas de las partes buenas que tienen.

Estas solicitudes pueden o no ser factibles, pero me encanta XAML y me encantaría que continúe mejorando, así que mencionaré algunos de los puntos débiles (pero aún útiles) que yo y algunos miembros de nuestro equipo tuvimos cuando desarrollamos para ellos.

@mdtauk No me opongo a la seguridad de archivos, pero el kernel subyacente debería evitar que escriba en lugares para los que no está autorizado, en lugar de usar un conjunto completamente nuevo de API y abandonar la API de archivos win32. Además, sé que esto se está saliendo del tema, pero la API StorageFile / StorageFolder son reemplazos horribles, ni siquiera tienen en cuenta la seguridad de los archivos. Son lentos y siempre se le envía a través del intermediario de archivos en tiempo de ejecución. Además, nunca debería haber sido una restricción que las aplicaciones de espacio aislado necesiten un permiso especial aprobado por MS para escribir en la carpeta de documentos del usuario. Solo, por ejemplo, cuán horrible fue la historia del archivo para el esfuerzo de AppContainer, era imposible crear una base de datos sqlite en cualquier lugar excepto en la carpeta LocalData oculta del usuario. Para un sistema de escritorio donde los usuarios quieren crear, guardar y abrir archivos, y guardar como, yadda yadda, puso la carga sobre los desarrolladores de software que necesitaban para volver a capacitar a sus usuarios sobre cómo administrar el contenido de los usuarios.

En cuanto al acceso de administrador, la versión de octubre de 2018 agregó "permite la elevación" como un derecho, lo cual tiene sentido. Una aplicación podría permitir que un usuario se ejecute como administrador si necesita ese amplio acceso a nivel de sistema para algún conjunto de funciones. No todos estamos construyendo pequeños editores de fotos y aplicaciones de diagramas de flujo.

@MarkIngramUK Gracias por sus comentarios, solo una aclaración. El concepto de Xaml Desktop que se presentó en un adelanto en // Build 2019 ha cambiado de nombre a WinUI Desktop. Este nuevo proyecto de Visual Studio usará un modelo de aplicación Win32, con WinUI como marco de presentación, y puede ser nativo o administrado (usando .NET Core 3).

Gracias @ marb2000 , ¿está esto dentro del plazo de WinUI 3.0?

@ marb2000 por WinUI Desktop, ¿te refieres a aplicaciones Win32 con Xaml Islands? ¿En qué sesión de compilación se mostró esto?

Una cosa que el equipo de WinUI debe tener en cuenta con el cambio de nombre de WinUI 3.0: si cambia el nombre de cualquiera de los tipos que se proyectan en .NET, las proyecciones no funcionarán (y no estamos planeando agregar más, ya que no es un sistema extensible mantenible). Aquí hay una lista de los tipos que proyectamos: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Cualquier cambio en tipos diferentes a estos requerirá que los usuarios envuelvan sus objetos en nuevos objetos que implementen las nuevas interfaces o copien sus datos en los nuevos tipos. En particular, los tipos INotifyPropertyChanged y INotifyCollectionChanged son de interés con respecto a las islas XAML y brindan soporte en sentido descendente.

INotifyDataErrorInfo

No introduzca nuevos espacios de nombres para cosas como INotifyDataErrorInfo; debe usarse en modelos de vista que generalmente son multiplataforma y no deben depender de WinUI. Debe definirse dónde se encuentran otras cosas como esta (es decir, INotifyPropertyChanged o INotifyCollectionChanged)

Sobre este tema. Windows.UI.Xaml.Interop ya tiene una interfaz INotifyCollectionChanged y Windows.UI.Xaml.Data tiene INotifyPropertyChanged. Estos dos se moverán a los espacios de nombres de Microsoft. Quizás los ensamblados System.Runtime.WindowsRuntime puedan hacer alguna asignación de WinUI a .Net

Gracias por la respuesta, pero ¿por qué lo necesita en el espacio de nombres de Microsoft si .NET Standard ya lo tiene en System.ComponentModel? https://docs.microsoft.com/en-us/dotnet/api/system.componentmodel.inotifydataerrorinfo?view=netstandard-2.0

@ meir-pletinsky. NET es solo un marco que puede usar para crear aplicaciones con UWP XAML. Quieren que la validación del campo de texto esté disponible para los desarrolladores, sin importar qué marco utilicen

@mdtauk , no, WinUI Desktop (anteriormente Xaml Desktop) le permite usar Xaml con Win32 directamente, sin el uso de la isla.

@ marb2000 Sería fantástico si el Proyecto de empaquetado de aplicaciones le permitiera crear un AppX con una ventana de Win32 e incluir componentes de WinRT de la misma manera sencilla que lo hace un proyecto de UWP. Hay muchas cosas que no funcionan sin editar manualmente los archivos vcxproj, como agregar recursos y el compilador cppwinrt que genera los encabezados de los componentes WinRT incluidos.

Otro proyecto que es importante para esta nueva UI es el _PropertyChanged.Fody_ de Simon Cropp que permite la implementación automática de INotifyPropertyChanged (probé con C # / F #). Ver https://github.com/Fody/PropertyChanged

Permite un código simple como este:

[AddINotifyPropertyChanged]
public class Person
{
    public string Name { get; set; }
    public string FamilyName { get; set; }

    public event PropertyChangedEventHandler PropertyChanged;
}

que podemos usar para enlazar a la interfaz de usuario.

Una cosa que me gustaría ver en WinUI 3.0: actualmente, el compilador XAML de UWP ( genxbf.dll ) solo puede ser invocado directamente por MSBuild cuando se hace referencia a él desde un archivo csproj, vbproj o vcxproj. Esto se debe a que no existe una herramienta de línea de comandos que se pueda utilizar para invocar esta funcionalidad. Esto me parece una decisión muy extraña, ya que nada más en la descarga del SDK de Windows 10 requiere Visual Studio. (El complemento WDK también incluye objetivos de Visual Studio, pero todos esos objetivos invocan herramientas de línea de comandos que se pueden utilizar independientemente de VS.) Agradecería mucho la adición de, por ejemplo, XbfCompiler.exe y XbfCodeGen.exe al directorio bin del SDK. (El primer EXE compilaría archivos XAML en archivos XBF, y el último generaría los archivos de código subyacente que se requieren para hacer referencia a los tipos XAML desde el código). Esto sería principalmente útil en proyectos de C ++ que usan CMake u otro, no visual Studio, pero también podría usarse para proyectos de C # y VB.NET si es necesario. ¡Gracias!

@MarkIngramUK , ¿sabe dónde podría aprender más sobre WinUI Desktop? Esas sesiones de Build 2019 no están disponibles para ver en línea. Suena como información importante a la que debería vincularse en este repositorio

@mdtauk Se mencionó en un llamado Sneak Peek, que es solo para los asistentes a Build. Afaik no hay grabación. Tampoco estuve allí, pero hay una diapositiva, tal vez la mejor diapositiva :-), disponible en Twitter: https://twitter.com/RudyHuyn/status/1126273995366490113

@mdtauk La hoja de ruta de WinUI 3 tiene la información y los diagramas más recientes que están aún más actualizados de lo que se mostró en el adelanto de Build. No existe tal cosa como "XAML Desktop" ni "WinUI Desktop" ... eso fue solo una elección de palabras confusas en una diapositiva que fue fotografiada. El concepto que se está comunicando (y la hoja de ruta intenta explicar esto con mayor claridad) es que para WinUI 3 estamos trabajando para que pueda tener una plantilla de proyecto que cree una nueva aplicación tradicional de escritorio / modelo Win32 utilizando WinUI 3 para su interfaz de usuario. (al igual que hoy en día hay plantillas para marcos de interfaz de usuario como WinForms, WPF, MFC, etc. además del modelo de escritorio / Win32 tradicional) además de una plantilla de proyecto de aplicación de modelo UWP / WinRT actualizada que usa WinUI 3. ¿Eso ayudar a aclarar?

La hoja de ruta 3.0 parece bastante razonable para la siguiente estrategia: permitir que cualquier aplicación cliente de Windows use XAML y los controles "modernos" de WinUI.

Sin embargo, esta estrategia parece miope si se considera la realidad del mercado actual: para una gran cantidad de desarrollo de aplicaciones, Android e iOS son los objetivos principales, y es bueno tener Windows. Para el desarrollador de .NET, Xamarin le ofrece una compatibilidad decente con Android e iOS, pero su compatibilidad con Windows es inferior a la media. Por lo tanto, para las aplicaciones nativas para dispositivos móviles o de escritorio, Win UI 3.0 no simplifica el desarrollo multiplataforma para los desarrolladores de .NET.

Lo que realmente me gustaría ver es un dialecto XAML avanzado con aspiraciones verdaderamente universales. Debería poder escribir una aplicación .NET usando XAML y hacer que esa aplicación se ejecute en Windows, iOS y Android. La aplicación debe ser verdaderamente de primera clase en cada plataforma y tener acceso a elementos nativos según sea necesario. Como se mencionó, Xamarin es un buen comienzo, pero su dialecto de XAML es muy diferente, tiene poca compatibilidad con Windows y nada del trabajo que está haciendo ayuda.

Entonces, tldr, es bueno que continúe brindando una plataforma de interfaz de usuario moderna para Windows. Es bueno que esté facilitando su uso desde diferentes tipos de aplicaciones. Es malo que no esté aspirando al soporte multiplataforma.

Opcionalmente, deshabilite u opte por no participar en los comportamientos del ciclo de vida de las aplicaciones móviles heredadas, como suspender + desechar.

La realidad es que UWP es un entorno de escritorio y, al menos para los juegos, el usuario a menudo puede minimizar la aplicación, lo que generalmente lleva a suspender / eliminar la aplicación. Esta es una experiencia discordante y muy diferente de cualquier aplicación o juego de escritorio win32. Solicitar un aplazamiento extendido, que probablemente aún caducará, no es suficiente para lidiar con esto sin problemas.

Si bien este ciclo de vida es útil para algunas aplicaciones, es perjudicial para otras. Idealmente, una aplicación de escritorio o un juego debería poder declarar una capacidad que permita que la aplicación se excluya del modelo de ciclo de vida de suspensión + desecho, lo que evitaría que finalmente se suspenda cuando se minimice.

@natemonster

Por: https://docs.microsoft.com/windows/uwp/launch-resume/run-minimized-with-extended-execution

En dispositivos de escritorio, las sesiones de ejecución extendidas creadas con ExtendedExecutionReason.Unspecified tienen un límite de tiempo consciente de la batería. Si el dispositivo está conectado a la alimentación de la pared, no hay límite para la duración del período de tiempo de ejecución extendido. Si el dispositivo funciona con batería, el período de tiempo de ejecución extendido puede durar hasta diez minutos en segundo plano.

Un usuario de tableta o computadora portátil puede obtener el mismo comportamiento de ejecución prolongada, a expensas de la duración de la batería, cuando la opción Permitir que la aplicación ejecute tareas en segundo plano está seleccionada en Uso de la batería por la configuración de la aplicación.

@TonyHenrique cuando mencionas a Fody , ¿es porque quieres crear una conciencia de ello, o estás diciendo que debería estar integrado en WinUI?

¡Las plantillas de artículos o bibliotecas también son interesantes! Hay algunos puntos importantes en las respuestas hasta ahora acerca de proporcionar un código estándar y de inicio adicional, que es algo más que podríamos considerar agregar con el tiempo, tal vez como Windows Template Studio.

@Jesbis Soy un colaborador principal de Windows Template Studio y estoy observando la hoja de ruta de WinUI con miras a lo que hacemos en el futuro y cómo presentamos el soporte para WPF. ;)

¿Qué tipo de actualizaciones de dependencia lo harían más valioso? por ejemplo, ¿encontrar nuevas versiones de paquetes de NuGet compatibles?

Ser capaz de detectar actualizaciones de NuGet sería más útil, pero existen otros posibles problemas de compatibilidad con la realización de actualizaciones. Daría baja prioridad a la detección de nuevas versiones y la conversión automática. Hay tantas consideraciones que sería un gran proyecto por derecho propio y prefiero ver tiempo invertido en la plataforma que en una herramienta como esta.

@mrlacey Mencioné a Fody porque creo que es una solución interesante y necesitamos una mejor manera de evitar el código repetitivo _INotifyPropertyChanged_. Sería bueno tener una solución compatible con MS para este concepto de objeto reactivo que genera automáticamente un evento cuando cambia alguna propiedad.
Funciona en clases de C # e incluso en F # Records (pero tuvo algunas dificultades).
Entonces, en la hoja de ruta de WinUI también debería haber esto.

Nota: Sería bueno si también pudiéramos usar los registros F # para definir nuestras entidades de datos y enlazar luego directamente a la interfaz de usuario XAML. Sería genial si pudiéramos usar F # Records + Fody + DataBinding sin problemas.

[<PropertyChanged.AddINotifyPropertyChangedInterfaceAttribute>]
[<CLIMutable>]
type Person =
    {
        ID: Guid

        mutable Name: string
        mutable Addresses: ObservableCollection<Address>
    }

Esto sería más familiar para las personas que vienen de C #.
Otro enfoque sería el método Elmish. Creo que ambos son interesantes y podrían apoyarse.

@tonyhenrique / @mrlacey Creo que las cosas de Fody (OAP) deberían estar fuera de alcance. El equipo de WinUI ya tiene suficiente en su plato, y creo que es mejor tener el tejido en proyectos separados (ciclos de lanzamiento mucho más rápidos en caso de mejoras).

Y creo que esto es en realidad un detalle de implementación de .NET (IL) de los modelos, en realidad no tiene nada que ver con WinUI (aunque puede escuchar los eventos de cambio). Mi sugerencia es mantenerlos separados. Por ejemplo, yo uso Catel y tiene sus propias tejedoras Fody para asegurarse de que todo se teje correctamente.

Lo que realmente me gustaría ver es un dialecto XAML avanzado con aspiraciones verdaderamente universales. Debería poder escribir una aplicación .NET usando XAML y hacer que esa aplicación se ejecute en Windows, iOS y Android. La aplicación debe ser verdaderamente de primera clase en cada plataforma y tener acceso a elementos nativos según sea necesario.

Existe una propuesta de larga data para ir en esa dirección: UX multiplataforma para .NET 5 - título original Cross platform UX for .NET Core 3.0 . El apoyo abrumador de la comunidad es obvio y podemos esperar que MSFT se dé cuenta de que esta es la mejor dirección para desarrollar cualquier marco de interfaz de usuario que funcione en .NET. No hay prácticamente ninguna razón para mantener bases de código separadas para diferentes grupos de plataformas y crear por la fuerza conjuntos de habilidades de desarrollador separados basados ​​en diferentes marcos de UX compatibles con .NET.

Al crear una UX única para todas las plataformas, cancelamos todas las ineficiencias en el desarrollo de framewrk y reducimos las barreras para la adopción por parte de los desarrolladores.

@mfeingol / @ 4creators , me conformaría con

La aplicación debe ser realmente de primera clase en cada plataforma.

en Windows para empezar ...

Es 2019, quiero una interfaz de usuario nativa y rápida, y no quiero tener que considerar seriamente hacer una interfaz de usuario con CreateWindowExW , GDI, etc.

Ahora que con WinUI3.0 y superior el código está desacoplado de Windows 10, ¿hay planes en el futuro para que WinUI funcione en Linux y Mac?

¿Las interacciones de @jesbis Touch se mantendrán en WinUI 3.0?

Gracias por la aclaración, había asumido que la forma en que funcionaría 3.0 era incluir Xaml Islands en WinUI, en lugar de usar el kit de herramientas de la comunidad.

Al convertirse en XAML más Win32, tiene más sentido, especialmente con Windows Core OS reescribiendo su shell en XAML.

Según tengo entendido ahora, este rico acceso a la API de Win32 está en C y C ++ | con cualquier cosa en C # que dependa de .NET (todo sea ahora .NET Core).

¿Quizás debería haber una forma segura y sencilla de acceder a estas API de Win32, así como a más puntos de entrada para mostrar la interfaz de usuario de una aplicación?

• Menú flotante XAML de la bandeja del sistema para aplicaciones WinUI 3

• IU de selector simple para Hololens / Xbox / Surface Hub / IoT, etc.

• cuadros de diálogo de archivos comunes personalizables de XAML actualizados y selectores de carpetas

• acceso simple de C # .NET a las API de Win32

• configuración compacta para todos los elementos XAML, que coinciden con el tamaño de control de Win32 y WPF (esto ayudará a Frameworks a sentarse cómodamente juntos)

• combinación de estilos de control / fuentes / pinceles de acento / acrílico cuando se usa WinUI

• definición clara de qué dispositivos requieren el ciclo de vida de WinRT / Mobile

• Estilos de control de Xbox Next integrados para el desarrollo y las pruebas de aplicaciones de Xbox en Windows

• Almacenamiento y empaquetado único exe / MSI / APPX y descarga compatible de forma predeterminada, SIN INSTALADORES, virtualización del sistema de archivos de tipo centenario de forma predeterminada

• WinForms WinUI 3.0: interfaz de usuario simple, acceso a MFC, mouse y teclado solamente

• WPF WinUI 3.0: interfaz de usuario densa, renderizado 3D, reconocimiento de DPI, toque simulado y compatibilidad con tinta básica

• Xaml WinUI 3.0: toque completo, MR, gamepad, entintado, voz, mouse, teclado. IU densas y simples. Nuevo soporte de ventanas. Representación 3D de MR. Ciclo de vida administrado opcional o ciclo de vida de escritorio. Lo mejor de todos los mundos predeterminados para aplicaciones de bandeja de entrada de shell y reelaboradas, con versiones Win32 de aplicaciones de bandeja de entrada como bloc de notas, mapa de caracteres, pintura, explorador de archivos, de código abierto y disponibles en la tienda.

¿Las interacciones táctiles se mantendrán en WinUI 3.0?

@ r7dev sí, el plan es mantener el mismo nivel de soporte táctil.

F # se ignora en la hoja de ruta de WinUI 3.0. Microsoft vuelve a ignorar uno de sus productos.

Pensamientos de la API de Win32

Algo en lo que también pensé es la razón por la que win32 también se ha quedado. Creo que existe la suposición de que esto se debe a proyectos heredados, pero en realidad es bastante más profundo que eso. Win32 ABI es muy fácil de conectar con el idioma que elijas, nodejs, python, rust, go, ruby, c #, c ++, etc., etc. Si mi proyecto principal está en rust, por ejemplo, y quiero generar una ventana para administrar la salida, como desarrollador de rust, es superpoderoso acceder al conjunto de API win32 y construir una interfaz en el mismo idioma.

En OS X, para acceder a AppKit solo necesitaba unir la API objc_msgSend C y obtener acceso a toda la infraestructura obj-c. Todos esos idiomas anteriores hicieron un muy buen trabajo al salvar eso y facilitaron la escritura en el idioma de su elección y produjeron algo convincente.

Entonces, si desea que WinUI 3.x sea el verdadero camino a seguir para acceder a la IU de Win32 de baja latencia, poca memoria y alta calidad, debe considerar la facilidad con la que otros mantenedores de idiomas pueden aprovechar la infraestructura.

Coherencia de la interfaz de usuario

Si realmente está planeando desacoplar la interfaz de usuario del sistema, ¿cuál es el plan para que la interfaz de usuario permanezca consistente con cada actualización del sistema operativo? Cuando Apple realiza ajustes en las sombras y los degradados en AppKit o iOS, las aplicaciones que dependen de los marcos del sistema heredan todos esos ajustes y se mantienen consistentes. También le resultará difícil agregar experiencias en todo el sistema porque es posible que las aplicaciones que están bloqueadas en las infraestructuras de la interfaz de usuario hace 3 años no funcionen bien con algún nuevo servicio del sistema, por lo que tendrán otra capa de compatibilidad a medida que pase el tiempo.

Siempre habrá funciones que deben habilitarse, puedo pensar en el modo oscuro como algo que si la aplicación no estuviera diseñada para él, realmente no tendría sentido ofrecerlo como una opción, pero todavía hay ajustes a los componentes del sistema que cambiarían con el tiempo.

Tamaño binario

¿Cuál es la historia planeada para entregar todos estos UI.dlls con nuestros proyectos? ¿Serán estas cosas 40 MB de tiempo de ejecución que deben enviarse con nuestros proyectos? ¿Qué pasará si se abandona un proyecto? ¿Empezarán a parecer obsoletos porque utilizan marcos de interfaz de usuario antiguos?

Uno de los beneficios de C ++ es que tiene una cantidad mínima de sobrecarga de biblioteca dependiendo del código base. Ciertamente, si todas las aplicaciones de ahora en adelante requieren WinUI 3.x, eso será 40 MB x número de aplicaciones.

Tamaño binario

WinUI ya es una dependencia, como lo es .NET. Ya es una biblioteca para todo el sistema. :)
No tiene archivos DLL duplicados y no los tendrá.
https://www.microsoft.com/store/productId/9N00JJ7S3L39

@ eklipse2k8

"Algo en lo que también pensé es la razón por la que win32 también se ha quedado. Creo que se supone que esto se debe a proyectos heredados, pero en realidad es bastante más profundo que eso. Win32 ABI es muy fácil de conectar con el idioma que elijas. , nodejs, python, rust, go, ruby, c #, c ++, etc. etc. Si mi proyecto principal está en rust, por ejemplo, y quiero generar una ventana para administrar la salida, como desarrollador de rust, es superpoderoso acceda al conjunto de API win32 y cree una interfaz en el mismo idioma ".

Sin embargo, esta es una bolsa mixta, ya que, al implementar el soporte de WinRT para un nuevo idioma, es un gran obstáculo que superar, una vez que lo hace, termina con enlaces de tipo autogenerados para cualquier API nueva. He estado trabajando en un proyecto de Rust que une Win32 y WinRT recientemente (usando las API de composición en una ventana de Win32), y las partes de Win32 definitivamente han sido más complicadas en general a pesar de que tuve que trabajar torpemente con las restantes. falta de soporte de Rust para algunas características de WinRT como la herencia de clases. (Definitivamente ayuda que ahora sea posible usar Composición dentro de Win32, ya que permite mejorar gradualmente el soporte para esta función en lugar de tener que abordar todo el modelo de la aplicación de una vez)

Probablemente el mayor problema es que la documentación para los detalles de WinRT ABI de bajo nivel está algo desorganizada, y hay muy poca comprensión o conocimiento de ellos en el mundo / comunidad, aunque espero que esta situación mejore con el proyecto xlang.

¿Qué plantillas te interesan más?

Actualmente prefiero comenzar desde un proyecto de Aplicación en blanco (Universal Windows). También me gustan las plantillas con un marco preconfigurado, pero solo cuando quiero probar algo rápidamente. Una plantilla de "Menú principal" y una plantilla MDI para UWP también serían buenas (ya que esas plantillas también existen para WinForms)

¿Conocía las islas Xaml para modernizar las aplicaciones de escritorio?
¿Esta compatibilidad con versiones anteriores ampliada en Windows 10 hace que Xaml Islands sea más útil para usted?

Sí, conozco la isla Xaml. Si puedo, intentaré ceñirme a una aplicación WPF pura o una aplicación UWP pura. No estaba en una situación en la que necesitaría tal característica.

¿Sería útil que Visual Studio u otra herramienta actualizaran automáticamente los espacios de nombres por usted?

¡Sí, seguro que funciona de forma fiable! Estoy sorprendido por los muchos comentarios que no aprecian una característica tan agradable. Además, esta característica podría verificar si una actualización a WinUI 3.0 es factible, adoptar el código XAML, ajustar los espacios de nombres e instalar los nugets de WinUI requeridos.

¿Qué importancia tiene para usted la compatibilidad total entre los componentes UWP Xaml existentes y las aplicaciones WinUI 3.0?

Esperaría cambiar solo los espacios de nombres del control para que funcionen completamente con WinUI 3.0. No quiero invertir mucho tiempo en actualizar a WinUI 3.0

¿Crea o usa bibliotecas de control UWP Xaml o componentes WinRT que no podría volver a compilar y actualizar fácilmente junto con el código de la aplicación?

Estoy usando bibliotecas de control UWP Xaml de terceros (como Windows Community Toolkit, https://github.com/kakone/VLC.MediaElement). Creo que podría actualizar controles simples de bibliotecas de terceros como un Dockpanel por mí mismo a WinUI 3.0.

¿Cuál sería su solución preferida para usar componentes UWP Xaml con WinUI 3?

• Cree una plantilla de proyecto "Aplicación en blanco con WinUI 3.0" en Visual Studio para UWP. La dependencia de WinUI 3.0 se instalará como nuget (como en WinUI 2.0).

The fastest path to releasing WinUI 3.0 would be to not support mixing [...] . Definitivamente preferiría una solución de este tipo siempre que tenga todos los controles básicos. Esperaría que todas las clases de Windows.UI tengan una clase equivalente en el espacio de nombres Microsoft.UI.

El tema principal en WinUI 3.0 fue todo sobre los controles y la compatibilidad con Windows 10 que se pueden usar desde UWP y WPF o WinForms a través de la isla XAML, si estoy en lo correcto. ¿Existe la posibilidad de que el marcado UWP XAML obtenga de alguna manera características adicionales?

• Faltan activadores de estilo
• Falta el estilo `BasedOn = {StaticResource {x: Type TextBlock}}
• Las plantillas de datos definidas con tipos de datos no se aplican automáticamente como en WPF (solo a través de la clave)
• ¿Por qué cada segundo Windows.UI.Xaml.Controls control (TextBlock, Border, ...) se declara como sellado ? No haga esto en WinUI 3.0 con UWP.
• Extensiones de marcado para paridad WPF
• Esto ya se mencionó, pero lo mencionaré una vez más. Es triste que UWP no utilice System.ComponentModel.IDataErrorInfo. De esa forma, no puedo compartir mi proyecto de modelo con la solución para UWP.
• ReportControl (para aplicaciones empresariales)

¡Tengo muchas ganas de WinUI 3.0 y su compatibilidad con versiones anteriores!

F # se ignora en la hoja de ruta de WinUI 3.0

¿Existe la posibilidad de que el marcado UWP XAML obtenga de alguna manera características adicionales?

@ Happypig375 , @ mfe-:

La hoja de ruta solo cubre la versión 3.0 inicial y, para la versión inicial, nos centramos principalmente en la paridad y la compatibilidad con versiones anteriores de las funciones existentes, con una pequeña cantidad de funciones nuevas.

Si cree que otras funciones nuevas, como una mejor compatibilidad con F # o nuevas capacidades de marcado, son importantes, abra una nueva solicitud de función para que podamos rastrearlas por separado.

¿Por qué cada segundo control Windows.UI.Xaml.Controls (TextBlock, Border, ...) se declara como sellado? No haga esto en WinUI 3.0 con UWP.

Quitar el sello de los controles es en realidad una de las pocas funciones nuevas que esperamos incluir en la versión 3.0 😊

Cuando se trata de idiomas, sería bueno mezclar y combinar (lo que debería estar bien si todo se compila antes del empaquetado)

F # se usa para cierta lógica de back-end - C # para Databinding y código de UI - C ++ para controles y tal vez algunos ganchos de Win32 de gama baja o incluso para iniciar un cuadro de diálogo de WinForms.

Todos los lenguajes de código son iguales, intercambiables, con WinUI 3.0 manejando toda la interfaz de usuario

Eso es xlang 😉

Eso es xlang 😉

@MarkIngramUK Hmm, pensé que era un puente entre idiomas, que abstrae cada idioma, en lugar de permitir archivos de código de varios idiomas en un solo proyecto.

He tenido problemas para entender el propósito de xlang: pasar por alto las actualizaciones que han estado sucediendo en el repositorio (pero todavía las tengo en mi lista de observación)

¿Xlang funciona antes o después de la compilación? ¿Es su propio lenguaje abstracto que se puede proyectar, o simplemente se ubica entre archivos de código existentes?

Sí, no puedes mezclar idiomas en un solo proyecto. Es un puente, pero sigue siendo útil para esos fines.

@MarkIngramUK Supongo que si su código se puede compilar y luego se incluye.

Sería bueno poder usar C # para acceder a las funciones nativas de Win32, sin PInvokes y otros trucos de .NET

@jesbis , honestamente, estoy más interesado en los aspectos multiplataforma de este proyecto ...

Creo que al principio, deberían cambiarle el nombre a algo más _generic_ y no estrictamente a "Windows".

Entendí que la implementación inicial debería centrarse estrictamente en Win32 y respaldar las aplicaciones UWP / Xamarin y Windows, pero solo OSS y hacer que desde el principio se llame como un marco "solo para Windows", definitivamente no obtendrá mucha tracción como UWP no lo hizo y los desarrolladores de otras plataformas nunca se interesarían por él.

Si el objetivo en .Net 5 es "One .Net Everywhere", que es básicamente lo que todos esperaban desde .Net 1.0, las bases para el marco de "Anything but Win UI" deberían comenzar entre plataformas.

Un muy buen ejemplo de cómo hacerlo bien es Google Flutter. Flutter está en sus inicios, pero obtuvo MUCHA tracción debido al hecho de que su núcleo (también conocido como Flutter Engine) es 100% multiplataforma y funciona en todas partes (¡incluyendo IoT, Win, OSX y ahora incluso Web!).

Ese es solo mi 2c. Me encantaría volver a trabajar en Xaml, pero si se mantiene en la misma línea que en UWP, me temo que no obtendrá la tracción correcta y será otro intento de reescribir WPF que eventualmente necesitará otro intento en el futuro y así sucesivamente.

Por favor, no me tome enfadado y no tome mi comentario como una mala crítica. Solo deseo que los esfuerzos en la interfaz de usuario en el mundo .Net obtengan algo como Flutter, .Net Core 3.0 / .Net 5 e incluso Blazor.

Para el registro, eventualmente comencé un proyecto para reescribir / portar el motor Flutter completamente en C # y .Net Core debido a la falta de opciones en .Net World ...

Por cierto, CoreUI es un buen nombre ...

Felicitaciones a Jake Helfert por esa sugerencia 😄

💃

Por cierto, CoreUI es un buen nombre ...

Felicitaciones a Jake Helfert por esa sugerencia 😄

💃

CoreUI puede confundirse con .NET Core

WinUI está muy enfocado en Windows, pero el marco XAML dentro de él, podría obtener renderizadores para Metal (iOS y macOS) o Vulkan (Android), y FabricWeb podría ser la forma PWA / ChromeOS de manejar las otras plataformas.

Si el equipo alguna vez elige traer la plataforma de presentación, Xland o Xamarin podrían manejar el tiempo de ejecución para aplicaciones multiplataforma.

Acerca de la migración de la interfaz de usuario de la bandeja de entrada de UWP a WinUI 3.0, citaré una publicación de blog reciente de @dotMorten (https://www.sharpgis.net/post/2019/05/14/The-future-UWP):

Nota básica divertida: lo que le está sucediendo a UWP no es que esté siendo eliminado: Microsoft está girando para llevar las mejores partes a donde las necesitamos. En realidad, esto sucedió antes, pero desafortunadamente no se usó como una oportunidad para realizar un pivote. ¿Recuerdas Silverlight? Adivina de dónde vino el CLR multiplataforma de .NET Core. Y gran parte del código de Silverlight también terminó en UWP. Si solo hubieran girado y dicho "Sí, estamos de acuerdo en que Silverlight no tiene sentido en el espacio de los consumidores, pero está prosperando en el espacio empresarial, así que desarrollemos sobre eso y lo evolucionaremos hacia .NET Core y Windows Store". Desafortunadamente, eso no fue tan fácil, y muchas personas todavía sufren de trastorno de estrés postraumático y desconfían de cualquier cosa que haga Microsoft que parezca estar acabando con cualquier tecnología.

Realmente creo que es importante recordar que ser percibido como la eliminación o el restablecimiento de marcos existentes sin darles a los desarrolladores y bases de código un buen camino a seguir no solo afecta a los desarrolladores en el marco existente; puede arrojar una nube sobre los esfuerzos futuros mientras todos se preguntan por qué el Lo nuevo no tendrá la misma suerte. Esto no pretende ser un comentario sobre ningún enfoque de migración propuesto específico, sino más bien una respuesta a los comentarios en el sentido de que la migración no importa porque no muchas personas están utilizando el marco de interfaz de usuario de la bandeja de entrada existente. ¡Esa no es la única consideración!

@weitzhandler WinUI 3.0 se trata de combinar varios marcos Win32, .NET Core y UWP con un solo marco XAML e interoperar con WPF, WinForms y MFC ++

XAML en Windows se representa en Direct X.

Si desea tomar ese mismo XAML, combinado con .NET Core, y hacerlo funcionar en otras plataformas. Debería escribir nuevos renderizadores para esas plataformas. iOS y macOS usan Metal como su equivalente de Direct X. Android usa Vulkan. No tengo idea de cómo maneja Linux el renderizado, supongo que es solo Open GL.

Microsoft no querrá hacerlo ellos mismos porque no tiene sentido para ellos. Pero WinUI 3.0 será de código abierto, por lo que otros podrían optar por tratar de hacerlo multiplataforma.

@mdtauk

Gracias por aclarar eso. Flutter es probablemente el futuro para mí.

Eso es solo lo que tengo entendido, podría estar equivocado.

Flutter supuestamente recibirá soporte de Windows en el futuro. Y el soporte de React Native también llegará a Windows. Además, existen PWA si invierte en ese mundo Web HTML y Javascript.

Para mí, toda la historia de WinUI puede tener más sentido si también tienen en cuenta la posibilidad de permitir que al menos un subconjunto básico se ejecute en plataformas cruzadas (macOS, iOS, Android), incluida la Web, y también ofrecen una mejor compatibilidad con F # y plantillas de proyectos (incluidas Enlace bidireccional XAML a registros F #, y también una forma Elmish más funcional)

XAML debe ser independiente del entorno, al igual que HTML, sin ocupar más de 100 MB, incluso para las aplicaciones de herramientas más básicas, como lo hacen las aplicaciones HTML. Esto significa un marco XAML que está escrito en C / C ++ o C # puro y se puede alojar en WASM, Win32, UWP, iOS, Android, macOS, Linux, etc.con un mínimo esfuerzo cuando se trata de portar. Necesita un backend de renderizado agnóstico como el que utilizan los motores de juegos para empezar.

Ninguno si este XAML enfocado en UWP está resolviendo algún problema que mi empresa o yo personalmente hemos tenido durante años con XAML ... y eso es portabilidad. TBH MS está yendo completamente mal con la interfaz de usuario y no llegará a ninguna parte rápidamente (está desperdiciando mucho tiempo valioso para mucha gente). Este hacker de UWP XAML simplemente no les sale bien a las personas a las que se lo muestro ... lo cual es triste porque solo significa un retroceso interminable contra la adopción de XAML y no tengo más argumentos en este momento.

La única forma de guardar XAML en mi opinión es:

• Cree una nueva base de marco agnóstica / portátil para .NET Core y C / C ++.
• Cree una capa de abstracción de renderizado agnóstica que cualquiera pueda ampliar mediante solicitudes de extracción.
• Al igual que HTML, mantiene el XAML enfocado en conceptos de aplicaciones de ventana única (tal como se hace también en los juegos) PERO permite funciones de escritorio extendidas para ventanas múltiples, etc. (Esto permite que la aplicación se ejecute en casi cualquier contexto, tal como lo hace la interfaz de usuario de un juego)

En pocas palabras, hay dos condiciones que deben combinarse en una antes de que se exceptúe la adaptación de XAML.

1 MS necesita respaldar el proyecto XAML o la gente teme que se caiga.

2 Debe ser multiplataforma o todos se quedarán atrapados con tiempos de ejecución HTML inflados.

De todos modos, eso es lo mío y si WinUI 3.0 está diseñado correctamente, tal vez sea posible la migración. En este punto, no sé qué sentir.

Hay algunos comentarios sobre ser multiplataforma aquí, y no estoy tan seguro de que WinUI deba ser multiplataforma para tener éxito. De todos modos, no funcionaría bien en Mac o Linux, ya que es lo suficientemente diferente como para que no se sienta nativo en ninguna de esas plataformas. Este proyecto es propiedad de un equipo que tiene un gran conocimiento sobre cómo funcionan los componentes internos de Windows, y sería una distracción para ellos salir y descubrir cómo hacer que algo también funcione realmente bien en Mac o Linux en el mismo grado.

Además ... Fluent en Mac se sentiría torpe, solo mire iTunes, Apple tuvo que portar todo su sistema de interfaz de usuario a Windows, y definitivamente se siente fuera de lugar. La representación de fuentes es diferente, las curvas de animación y las sombras y las opciones de color se sienten tan fuera de lugar en Win10. Quiero decir, está bien y seguro que se puede usar, pero prefiero Spotify, que no intenta emular ninguna interfaz de usuario de escritorio y solo usa un navegador web bajo el capó. En Mac, ver el reflector de revelación con componentes cuadrados en un escritorio lleno de esquinas redondeadas y sin efecto de revelación chocaría con tanta fuerza.

No, creo que este proyecto debería centrarse en ofrecer la mejor forma de su clase para hacer software nativo de Windows, para desarrolladores que quieran / necesiten crear software de Windows. Deje que los equipos de Electron / Typecript resuelvan las cosas de la plataforma cruzada.

Hay algunos comentarios sobre ser multiplataforma aquí, y no estoy tan seguro de que WinUI deba ser multiplataforma para tener éxito. De todos modos, no funcionaría bien en Mac o Linux, ya que es lo suficientemente diferente como para que no se sienta nativo en ninguna de esas plataformas. Este proyecto es propiedad de un equipo que tiene un gran conocimiento sobre cómo funcionan los componentes internos de Windows, y sería una distracción para ellos salir y descubrir cómo hacer que algo también funcione realmente bien en Mac o Linux en el mismo grado.
Además ... Fluent en Mac se sentiría torpe, solo mire iTunes, Apple tuvo que portar todo su sistema de interfaz de usuario a Windows, y definitivamente se siente fuera de lugar. La representación de fuentes es diferente, las curvas de animación y las sombras y las opciones de color se sienten tan fuera de lugar en Win10. Quiero decir, está bien y seguro que se puede usar, pero prefiero Spotify, que no intenta emular ninguna interfaz de usuario de escritorio y solo usa un navegador web bajo el capó. En Mac, ver el reflector de revelación con componentes cuadrados en un escritorio lleno de esquinas redondeadas y sin efecto de revelación chocaría con tanta fuerza.
No, creo que este proyecto debería centrarse en ofrecer la mejor forma de su clase para hacer software nativo de Windows, para desarrolladores que quieran / necesiten crear software de Windows. Deje que los equipos de Electron / Typecript resuelvan las cosas de la plataforma cruzada.

No creo que nadie realmente quiera un diseño Fluent completo en otras plataformas, sino más bien poder maximizar el código común entre plataformas.

Esto es algo que ya ha sido abordado por el equipo de Microsoft Design. El sitio web de Fluent dice explícitamente "diseñe y cree aplicaciones personalizadas que sean de forma nativa iOS y, al mismo tiempo, Fluent de forma única". Los documentos de Fluent muestran que se debe usar un estilo de control nativo.
https://www.microsoft.com/design/fluent/#/ios
https://developer.microsoft.com/en-us/fabric#/controls/ios/button

Lo que se debe evitar es tener que diseñar y mantener interfaces de usuario completamente independientes para cada plataforma. Eso no significa que deba verse idéntico en la superficie, pero debe compartir un diseño común, y los diseñadores de UI deben poder reutilizar tanto como sea posible. El estilo real no necesita (y no debería) coincidir con el estilo del sistema Windows 10.

En esencia, lo que se busca es una manera fácil de hacer que las aplicaciones de Windows se ejecuten en otras plataformas, sin tener que rehacer toda la interfaz de usuario, no llevar el diseño Fluent a otras plataformas. Eso permitiría a las personas escribir para Windows primero y luego llevar su aplicación a otras plataformas sin mucho trabajo.

@KyleNanakdewa Bueno, si lo están

Creo que este proyecto debería centrarse en ofrecer la mejor forma de hacer software nativo de Windows.

Este argumento podría ser convincente si Microsoft no tuviera ya un kit de herramientas XAML multiplataforma existente que ofrezca un dialecto de XAML muy diferente al de WinUI.

Además, existen PWA si invierte en ese mundo Web HTML y Javascript.

Sí ... "ese mundo" que está reemplazando rápidamente todo lo que sabemos sobre el desarrollo nativo de SO / Store / Hosted. 😆

https://onezero.medium.com/the-end-of-app-stores-is-rapidly-approaching-b972da395097

Considere que "ese mundo" existe en _todos_ los dispositivos modernos con un renderizador HTML5:

• Apple con 1.4 mil millones
• Droid con 2.5 mil millones
• Windows 10 con 800 millones

Notará que Windows ahora tiene la participación de mercado más pequeña, lo que significa que cualquier oferta que se adapte específicamente a esta plataforma llegará al mercado más pequeño. Hacerlo solo reduce el alcance de mercado potencial máximo de una aplicación, lo que, a su vez, reduce su límite máximo de ingresos potenciales.

Compare esto con Flutter, que con _una_ base de código llega a _todos_ los mercados antes mencionados, junto con la web , que como se mencionó se compone en conjunto de los tres, maximizando así el alcance del mercado y los ingresos potenciales para los desarrolladores de aplicaciones al tiempo que reduce los costos necesarios de construcción. aplicaciones para hacerlo.

Si bien soy un gran admirador de los esfuerzos aquí para abrir el código, colaborar y solicitar comentarios de la comunidad , todavía no he visto nada de estas discusiones (que también disfruto 😁) que me indiquen con confianza que los esfuerzos aquí serán competitivo - y por lo tanto _ rentable_ - en comparación con los gustos de Flutter (que por cierto también se está preparando para las PWA ).

El control de diagramas es esencial en cualquier experiencia de escritorio moderna basada en datos que pronto será oficial NET CORE 3 (septiembre de 2019) y eventualmente. NET 5 (noviembre de 2020)

Veo el control de código abierto de Networkview proporcionado como un caso de uso efectivo sobre cómo trabajar con Xaml para transferir WPF al control de la interfaz de usuario de Win. Esta interfaz de usuario de Win portado servirá como un buen gremio para que otros porten otros controles de WPF un poco más complejos a la interfaz de usuario de Win.

Vemos un caso de uso 2 en 1 en el que nuestra aplicación debe admitir el modo tableta en el futuro sistema operativo Windows Core. Sospechamos que Winform en .NET Core 3 no ayudará ... otra fuerte justificación de por qué el control del diagrama de la interfaz de usuario de Win NO es solo un ejercicio de PoC, sino que debe ser parte de los controles principales de win ui en una clase FIRST similar al control de Grid avanzando ...

Si cree que otras funciones nuevas, como una mejor compatibilidad con F # o nuevas capacidades de marcado, son importantes, abra una nueva solicitud de función para que podamos rastrearlas por separado.

Parece que @migueldeicaza está tomando el asunto en sus propias manos: https://github.com/microsoft/microsoft-ui-xaml/pull/736

Quiero hacerme eco de los pensamientos de CreateWindowExW !) Y debe ser un escaparate de lo que puede hacer en Windows. WinUI en macOS o Android siempre ofrecería una experiencia que nunca podría igualar la experiencia nativa. Escribimos aplicaciones multiplataforma y escribimos UI nativas en cada plataforma. De esa manera, los clientes obtienen la mejor experiencia en la plataforma que elijan. Si las personas quieren una solución multiplataforma, está bien, deberían buscar otra biblioteca para ese propósito, tal vez una que incluya WinUI en la plataforma Windows.

Y con respecto a PWA, estos no representan el uso completo del sistema de interfaz de usuario de Windows, recomendar centrarse en "aplicaciones de ventana única" descartaría inmediatamente cualquier pieza de software profesional (excepto juegos). Ya existen soluciones para PWA y multiplataforma; no necesitamos otra.

Obligatorio XKCD:
https://xkcd.com/927/

@MarkIngramUK Creo que lo que se habla de la plataforma cruzada se trata más de poder codificar en .NET y XAML para declarar la interfaz de usuario, ¡¿luego hacer que esa aplicación se ejecute en Android, iOS, macOS, Linux ?! - sin tener que cambiar el código subyacente o abandonar el XAML.

Ahora bien, si hubiera representadores XAML para estas otras plataformas, la forma en que interpretan el XAML podría ser como Xamarin Forms, que pasa a las plataformas de interfaz de usuario nativas, o simplemente dibujar en el búfer de la tarjeta gráfica y dibujar los píxeles en la pantalla, manteniendo la mayor parte del mismos estilos de controles.

WinUI 3.0 debería seguir siendo un proyecto centrado en Windows para unificar las diversas API y ABI con una plataforma de interfaz de usuario moderna basada en XAML. Pero eso no significa que Xamarin o las personas no puedan tomar el código de representación y crear versiones para otras plataformas.

Todo lo que se necesitaría realmente (en un alto nivel de pensamiento) es asegurarse de que el código que representa XAML en la pantalla en Windows esté contenido, de modo que otros representadores puedan intervenir para escenarios multiplataforma.

WinRT / UWP / XAML necesitará un poco de refactorización para sacarlos del sistema operativo Windows 10, por lo que la forma en que se realiza esa refactorización, para permitir una expansión futura, es algo a tener en cuenta. Ya sea que la plataforma cruzada se convierta en una realidad o no.

@MarkIngramUK Estoy de acuerdo con @mdtauk

No debería haber ninguna razón por la que no podamos usar xaml para describir los componentes de la interfaz de usuario en otras bibliotecas, incluida React. Si observa un proyecto como http://www.cshtml5.com , usan xaml que se convierte a html.
Tampoco creo que nadie alude al hecho de que el objetivo final es que la interfaz de usuario se vea igual en otras plataformas, pero lo que personalmente quiero es algo en el lado de la interfaz de usuario que pueda usar para aprovechar mi inversión existente en, por ejemplo, UWP.

El punto es simplemente este. Si hago una propuesta a un cliente empresarial y presento una aplicación para UWP increíble que es fantástica en todos los aspectos. Si ese cliente empresarial tiene 1 usuario que utiliza, por ejemplo, una MacBook Pro, inmediatamente tengo un problema, ya que el cliente empresarial preferirá llevar algo que funcione en todas partes (denominador más bajo => sitio web) que mi "aplicación nativa", incluso si se ejecuta. en Windows 10.

Entonces la accesibilidad es clave. El hecho de que MS siga esperando que hagamos inversiones en "aplicaciones nativas" en 2019 sin ninguna hoja de ruta hacia la capacidad multiplataforma es una locura.

Es probable que cualquier proyecto nuevo desde una perspectiva empresarial siga la lógica anterior para la accesibilidad y, por lo tanto, todos los proyectos nuevos estarán sesgados hacia la web y todo porque no hay una hoja de ruta que incluya la capacidad multiplataforma en XAML / UWP.

Entonces, avanzamos rápidamente de 2 a 3 años a partir de ahora, sin nuevas inversiones de las empresas en UWP / win32 y usted está sentado con otro "Silverlight" que a nadie le importa.

MS incluso puede decirme que XAML estará obsoleto mañana y que la "nueva" biblioteca de interfaz de usuario es, por ejemplo, React. Siempre que se pueda pegar c # a esta nueva biblioteca, reduciré mis pérdidas, descargaré XAML y adoptaré esta nueva biblioteca de interfaz de usuario multiplataforma. Al menos mi inversión tiene durabilidad y es accesible a largo plazo.

Al no brindar claridad sobre este tema específico en torno a la capacidad de interfaz de usuario multiplataforma, MS está creando incertidumbre en torno a su "pila nativa" y, por lo tanto, la mayoría de las empresas preferirán atravesar un incendio con una pata de palo que abrazar lo desconocido.

Y con respecto a PWA, estos no representan el uso completo del sistema de interfaz de usuario de Windows

Bastante justo, y estoy de acuerdo. Mi punto principal con PWA fue demostrar que su participación de mercado eclipsa a cualquier mercado en particular, ya que está compuesto en conjunto por todos los mercados.

Dicho esto, supongo que parte de la confusión aquí de mi parte es el espacio de nombres para reflejar Microsoft.* , cuando en realidad parece que todavía debería ser Windows.* (o incluso Microsoft.Windows.* ) .

Ya existen soluciones para PWA y multiplataforma; no necesitamos otra.

Desafortunadamente, este no es el caso del desarrollo de .NET, que es parte de la confusión y la angustia entre plataformas en torno a este anuncio y la discusión posterior.

por lo tanto, maximiza el alcance del mercado y los ingresos potenciales para los desarrolladores de aplicaciones, al tiempo que reduce los costos necesarios de creación de aplicaciones para hacerlo.

A veces, el rendimiento y los detalles de UX pueden marcar una gran diferencia. Skype ha maximizado el alcance del mercado utilizando el marco Electron a costa de sacrificar el rendimiento y el resultado es el desastre comercial.

Respecto a las soluciones multiplataforma (xplat).
Las soluciones Xplat son una abstracción de múltiples sistemas subyacentes nativos. Mi comprensión de WinUI es que será el sistema nativo de Windows.

Si WinUI también fuera xplat, ¿cómo incorporaría elementos que son exclusivos de Windows? ¿No le impediría eso hacer cosas nuevas e innovadoras? ¿O eso significaría que está en Microsoft para portar cualquier cosa nueva o que se diferencie de Windows a otras plataformas también? ¿Qué pasa con las cosas que no se pudieron portar porque el otro sistema operativo subyacente no las admitiría? ¿No deberían agregarse a Windows?

Si construye algo con tecnologías nativas de Windows, es razonable suponer que Microsoft lo admitirá durante un período de tiempo y proporcionará un camino hacia los sistemas basados ​​en Windows más nuevos en el futuro. (Reconociendo SilverLight como una excepción). No creo que sea razonable suponer que si construye algo con tecnologías nativas de Windows y luego quiere ejecutarlo en un sistema operativo de la competencia, entonces depende de Microsoft / Windows hacerlo fácil. Si crearas una aplicación para iPad con Swift y quisieras llevarla también al escritorio de Windows, ¿esperarías que Apple cambiara el desarrollo de iOS para hacerlo más fácil?

Si disfruta o prefiere usar tecnologías nativas de Windows, eso es genial. Lo que no puede hacer es aplazar la decisión comercial que toma al elegir esas tecnologías a otra persona. Todas las opciones tecnológicas tienen consecuencias y nadie sabe qué se necesitará en el futuro o qué pedirán sus clientes. Pedir que el software desarrollado específicamente para Windows también pueda ejecutarse en otros lugares puede dar la impresión de que el objetivo es evitar tomar una decisión tecnológica que podría tener posibles consecuencias negativas en cualquier momento en el futuro. Basado en la naturaleza de la tecnología y la velocidad del cambio, no creo que eso sea realista.

Dicho esto, si desea construir una solución xplat (y hay muchas personas que lo hacen y las razones para eso) porque desea apuntar a múltiples sistemas operativos ahora, o puede querer hacerlo en el futuro, entonces esa es una solución razonable y comprensible. guión.
Para eso Microsoft tiene Xamarin. O, si prefiere algo con XAML más parecido a UWP, hay Uno. (También hay muchas otras opciones).
Si, como yo, desea ver que Xamarin tenga un mejor soporte nativo para crear aplicaciones de Windows, no creo que la respuesta sea que WinUI intente hacer varias cosas.

WinUI es algo más que XAML y controles específicos. Incluye detalles de cómo esos controles y las aplicaciones que se crean con ellos se integran con el sistema operativo subyacente.
Si la planificación de WinUI se centra en hacer que el desarrollo de Windows en Windows sea lo mejor posible, entonces ese es un buen caso para tener innovación y un buen soporte futuro. También es probable que aumente las posibilidades de que las personas quieran seguir usando Windows y, por lo tanto, es importante que tenga un soporte sólido de múltiples soluciones xplat.

Respecto a las soluciones multiplataforma (xplat).
Las soluciones Xplat son una abstracción de múltiples sistemas subyacentes nativos. Mi comprensión de WinUI es que será el sistema nativo de Windows.

Lo siento, pero no me siento así ...

Mire Flutter ... Tiene un motor central que puede renderizar cualquier cosa en cualquier plataforma que admita.

Además de eso, tiene componentes que están completamente implementados en Dart usando la capa administrada por el motor y que representan (dibujar / renderizar) en fidelidad de píxeles la plataforma y el lenguaje de diseño que desea usar, por ejemplo, Material.io y Cupertino de Apple.

Entonces, en mi humilde opinión, ese sería el mejor enfoque para hacer algo multiplataforma y que al mismo tiempo represente las capacidades de la plataforma subyacente.

No creo que sea razonable suponer que si crea algo con tecnologías nativas de Windows y luego desea ejecutarlo en un sistema operativo de la competencia, entonces depende de Microsoft / Windows hacerlo más fácil.

Bien ... creo que el punto aquí que otros están haciendo es que esto parece un poco atrasado / sordo en estos días, especialmente en el contexto de comenzar una nueva aplicación. ¿Por qué alguien crearía una aplicación nativa de Windows cuando solo alcanza un pequeño porcentaje del mercado? Este no es un buen uso del capital.

Si es para mantener aplicaciones heredadas de Windows o para crear específicamente una aplicación de Windows, entonces sí, estoy de acuerdo con todo esto y tiene sentido. Sin embargo, dado que parece haber cambios importantes y más inversiones involucradas, la propuesta de valor de hacer esto frente a usar Flutter aún no se ha explicado.

Eso es precisamente lo que estoy diciendo ...

Por ejemplo, los integradores de flutter para escritorio tanto en Win10 (WPF y UWP) como en OSX están por llegar.

Están 100% administrados por el tiempo de ejecución de flutter, pero solo usan (por ejemplo) WPF / UWP para obtener la administración de ventanas y el puntero Graphics . Todo el resto lo gestiona el motor ...

Hemos adaptado el motor de aleteo a un dispositivo ARM integrado y debo decir que fue una experiencia increíble. ¿Por qué? Porque nació para ser portátil y ejecutarse en cualquier lugar al permitir que el "embedder" se ocupe de los detalles de implementación específicos de la plataforma en primitivas como GPU, renderizado de software, gestión de entrada, etc.

Por eso digo que WinUI por medio de UWP: The empire strikes back no va a funcionar a largo plazo.

MSFT debe venir con algo multiplataforma, abierto y portátil. Al igual que hicieron con .Net Core, con Blazor, etc ... Reinvent UWP / XAML no irá a ninguna parte.

Creo que XAML tiene un buen potencial si se usa correctamente en un sentido en el que se usa para "describir" (o declarar, como dicen algunos) la interfaz de usuario. El "motor" construye el árbol de renderizado a partir de él y luego envía los comandos de renderizado a la plataforma subyacente.

Al igual que MSFT hizo recientemente con Chromium como núcleo de Edge, creo que WinUI (o como se llame) podría aprovechar Skia, ya que tiene backends para GL, DX, Vulkan, Software Rendering, FB, etc. que tiene un ENORME potencial de agregar otras plataformas más adelante ...

@galvesribeiro ,

Mire Flutter ... Tiene un motor central que puede renderizar cualquier cosa en cualquier plataforma que admita.

Además de eso, tiene componentes que están completamente implementados en Dart usando la capa administrada por el motor y que representan (dibujar / renderizar) en fidelidad de píxeles la plataforma y el lenguaje de diseño que desea usar, por ejemplo, Material.io y Cupertino de Apple.

Genial, tan pronto como Apple publique una actualización para macOS y la interfaz de usuario se actualice (tal vez cambie el radio de la esquina del botón o cambien los degradados de fondo, etc.), su aplicación Flutter no se actualiza y continúa luciendo como el sistema operativo anterior, a diferencia de un nativo controlar cuál obtendría los beneficios de forma gratuita.

@MarkIngramUK ese es el trabajo en el equipo para respaldar las actualizaciones.

Al igual que el equipo de Xamarin proporciona actualizaciones desde el día 0 + 1, este equipo podría hacer lo mismo. El equipo de Google también hace eso ...

Al usar el control "nativo", está de nuevo en el mundo de Xamarin donde solo lo hacía, envoltorios (también conocidos como Renders) ...

No estamos hablando de enlaces de C # a controles nativos (como lo hace Xamarin) ... Estamos hablando de un marco de interfaz de usuario completo como lo hace con Flutter ...

Para el registro, nadie usa el tema "predeterminado" para ninguna plataforma. Todos ellos crean su experiencia de usuario única sobre los lenguajes de diseño de cada plataforma.

Si está tan preocupado por que siempre se vea como el componente nativo, su aplicación probablemente nunca tendrá una buena audiencia como se vería ... Meh ...

Creo que estamos hablando de dos proyectos diferentes aquí. WinUI debe ser el reemplazo de Win32. La gente está pidiendo una solución multiplataforma, lo cual es razonable, pero no creo que deba ser este proyecto.

Además, Flutter te permite usar el "tema" en todas las plataformas. Para que pueda ejecutar Cupertino en su PC con Win10. Un GRAN ejemplo es el diseño de materiales. Es un lenguaje de diseño, no un conjunto de controles. Se puede usar en cualquier lugar ... Simplemente sucede que algunas plataformas (como Android) tienen sus controles nativos implementándolo ...

@MarkIngramUK

Solo estoy aclarando por qué WinUI no debería ser solo un reemplazo de Win32, eso es todo.

Si ese es el caso, estoy bastante seguro de que caerá en un futuro previsible al igual que UWP ...

Estoy de acuerdo en @MarkIngramUK WinUI debe centrarse en proporcionar una interfaz de usuario unificada para Windows, sin importar si usa C #, API de WinRT, ABI de Win32, C ++, F #, VB, .NET Core.

WinUI 3.0 implica extraer todo ese código y renderizar XAML del sistema operativo Windows, y convertirlo en un marco, independiente del ciclo de actualización del sistema operativo, y hacerlo de código abierto.

La forma en que se levanta y se vuelve a empaquetar aún está en el aire. Solo los internos de Microsoft saben cómo lo harán. Con el fin de admitir el futuro soporte multiplataforma para XAML, solo espero que se reflexione un poco sobre cómo se podría lograr en el futuro, ya que lo están sacando de Windows.

.NET Core ya está disponible en otras plataformas. Entonces ese es el código C # detrás ya transferible. Ahora es solo XAML y la interfaz de usuario y los controles, que necesitan una ruta a iOS / macOS / Android / Linux (y lo que pueda venir en el futuro)

Tal vez fuera del alcance de WinUI 3.0, pero definitivamente vinculado a este proyecto y esfuerzo.

@jesbis @terrajobst @jevansaks

¿Cuáles son los planes de Microsoft para incorporar un marco de interfaz de usuario en .NET Core que se procese en computadoras de escritorio, dispositivos móviles (Droid, iOS) y la web?
La incertidumbre sobre esto ha estado sucediendo durante mucho tiempo.

@weitzhandler , ya tienen una hoja de ruta , con el siguiente párrafo:

Un destino nativo de Windows para marcos web y multiplataforma
WinUI 3 está mejor optimizado para que las bibliotecas y los marcos se basen en ellos .
Por ejemplo, estamos planeando basar la nueva implementación de C ++ React Native Windows de alto rendimiento en WinUI 3.

Tenga en cuenta la parte enfatizada, "para construir". Como he dicho anteriormente, no hay ninguna razón por la que esto no pueda ser Windows primero, con otras bibliotecas construidas sobre él.

OK entonces...

/me keep working on FluSharp

lo cual es razonable, pero no creo que deba ser este proyecto.

Hay sed @MarkIngramUK , perdón por nuestras proyecciones. 😅

con el siguiente párrafo

No dice mucho. No revela la clara intención de MS de hacer xplat el desarrollo de C # y .NET. Quizás diga que HTML JS y CSS shi {son mejores equipos para ti que C # si quieres ser portátil.

Por el momento, Xamarin y Xamarin Forms es la historia de Microsoft para el desarrollo de C # y .NET Core fuera de Windows.

React Native para Windows viene para código Javascript y UI nativa (que usará WinUI 3.0 XAML)

Por el momento, Microsoft no tiene planes anunciados para llevar XAML de WinUI 3.0 a otras plataformas.

WinUI el proyecto está tratando de unificar los marcos de desarrollo de Win32, WPF, MFC, UWP, .NET Core, bajo un solo marco de presentación XAML moderno.

Creo que después de eso, se debería trabajar en encontrar formas de renderizar XAML escrito para WinUI 3.0, en plataformas como macOS, iOS, Android, etc., pero eso no está en la agenda hasta ahora.

Una vez que el trabajo de WinUI 3.0 comience aquí, será de código abierto, por lo que hará posible el trabajo multiplataforma en el futuro, si hay suficiente necesidad. Y puede que no sea Microsoft quien finalmente ponga a disposición estas rutas multiplataforma, podría ser la comunidad de código abierto.

¿Algún plan para convertir a F #, el hijastro pelirrojo de .NET en un ciudadano de primera clase? Y luego la gente se pregunta por qué la gran mayoría de los desarrolladores de .NET no tocan F # con un poste de diez pies.

Por el momento, Xamarin y Xamarin Forms es la historia de Microsoft para el desarrollo de C # y .NET Core fuera de Windows.

Sí, Xamarin.Forms se está portando a macOS, GTK, UWP y WPF, además de tener diseño de material en todas partes, lo que lo convierte en el .NET UI Framework de facto, pero es tan lento y con errores que me pregunto qué está pensando Microsoft. sobre sus desarrolladores. ¡Solo mire la lista de problemas! Una vez que comenzó el desarrollo serio, los errores se atacan de izquierda a derecha. Espero que con WinUI finalmente podamos tener una mejor experiencia de desarrollo.

Re: F #

Si cree que otras funciones nuevas, como una mejor compatibilidad con F # o nuevas capacidades de marcado, son importantes, abra una nueva solicitud de función para que podamos rastrearlas por separado.

Sí, siempre es F # el que se rastrea por separado y se ignora nuevamente. Solo mire UWP y .NET Native: ambos no tenían F # en mente y la comunidad en general tuvo que resolverlo todo. 🙄 Después de 4 años, F # todavía no es compatible con .NET Native.

Para sugerencias / preguntas de F # , creé un problema dedicado:
https://github.com/microsoft/microsoft-ui-xaml/issues/740

No dude en dirigir las discusiones de F # allí.

Definitivamente no estamos ignorando los comentarios al respecto; tener un problema dedicado solo nos ayuda a organizarlo y rastrearlo.
El equipo está discutiendo cómo podría encajar en la hoja de ruta para 3.0 y más allá y actualizará el nuevo problema con cualquier desarrollo.

RE: interfaz de usuario multiplataforma:

Gracias a todos por los puntos planteados hasta ahora y por la pasión por .NET y Xaml.
Solo quiero decir nuevamente que estamos escuchando atentamente todos los comentarios y compartiremos nuestros pensamientos y actualizaciones a medida que avancemos.

Solo para reafirmar la hoja de ruta actual y algunos puntos que han surgido:

WinUI es la plataforma de interfaz de usuario nativa para Windows (incluidas las aplicaciones nativas, no solo .NET) y para la versión inicial 3.0, nos enfocamos principalmente en hacerlo independiente del sistema operativo y trabajar para prepararlo para el desarrollo de código abierto en una versión más rápida. ciclo. Queremos asegurarnos de que el alcance sea lo suficientemente factible para que podamos obtener una vista previa este año.

Uno de nuestros otros objetivos actuales a corto plazo es permitir que WinUI sirva como un objetivo nativo para que otras plataformas lo utilicen en Windows: por ejemplo, también estamos trabajando para garantizar react-native-windows , una implementación nativa de C ++ React de alto rendimiento para Windows: usa WinUI y los controles de WinUI se pueden usar para crear vistas de IU nativas en aplicaciones React Native.

Seré perfectamente honesto. Tengo una aplicación de escritorio nativa de Windows que escribí en 2006 en WinForms que todavía estoy vendiendo en línea hoy.

No tengo planes de migrar esta aplicación a WPF, UWP ni usar ninguna tecnología exclusiva de interfaz de usuario de Windows. No me importa lo convincentes que se vean las demostraciones de Windows. Si alguna vez decido volver a trabajar en esta aplicación, la próxima versión principal será algún tipo de implementación multiplataforma que pueda ejecutarse en MacOS, Linux y Windows.

Actualmente, probablemente se vería como Blazor + .NET Core + Electron.

Creo que @ Mike-EEE hace grandes puntos. La plataforma UX que me permite aprovechar mis habilidades de C # para llegar a la mayor cantidad de audiencia es la tecnología más probable que elegiré.

Microsoft debería centrarse en capacitar a los desarrolladores para que aprovechen sus habilidades existentes para llegar a una mayor audiencia con sus aplicaciones. Creo que es una estrategia ganadora y mantendrá a Microsoft en el juego.

La escritura en la pared es que el software del sistema operativo se está volviendo más como una mercancía. Es decir, las personas pueden elegir cualquier sistema operativo que quieran y obtener las aplicaciones que quieran usar. Creo que esto se hará más evidente a medida que avance el tiempo, ya que los proveedores de software del mundo continúan centrándose en la multiplataforma.

En economía, una mercancía es un bien o servicio económico que tiene fungibilidad total o sustancial: es decir, el mercado trata los casos del bien como equivalentes o casi sin importar quién los produjo. https://en.wikipedia.org/wiki/Commodity

Microsoft tiene que decidir, ¿quiere ser parte de la historia de las herramientas para desarrolladores? ¿O Microsoft invierte millones de dólares en una nueva pila de UX solo para Windows que terminará uniéndose al cementerio de pilas de UX que cada vez menos personas usan?

Este proyecto es propiedad de un equipo que tiene un gran conocimiento sobre cómo funcionan los componentes internos de Windows, y sería una distracción para ellos salir y descubrir cómo hacer que algo también funcione realmente bien en Mac o Linux en el mismo grado.

Es una posición difícil en la que estar seguro. Pero los tiempos han cambiado. El mundo de hoy es muy diferente al mundo que era en 1995. A mi modo de ver, hay un par de opciones:

Podría contratar a más personas para ampliar ese conocimiento más allá de Windows.

O bien, utilice el conocimiento de ese equipo para crear sistemas de UX dentro de Windows que mejoren la compatibilidad para que los marcos de aplicaciones de IU multiplataforma se ejecuten mejor en Windows.

Al igual que lo hizo WSL para ejecutar Linux en Windows.

• Utilice el conocimiento del equipo para hacer que GTK corra 200 veces más rápido.
• Utilice el conocimiento del equipo para hacer que las aplicaciones QT se ejecuten 200 veces más rápido.
• Utilice el conocimiento del equipo para hacer que las aplicaciones de Electron se procesen más rápido que cualquier otro sistema operativo.

Hay mucho trabajo que se puede hacer para mejorar la historia de compatibilidad de UX multiplataforma de Windows. Pero invertir en una pila de UX completamente nueva y esperar que todos cambiemos (sin ninguna historia multiplataforma) es una apuesta bastante grande. Debes romper este hábito creando nuevos frameworks UX solo para Windows.

Solo mis dos centavos. :bolsa de dinero:

: horse_racing:: cowboy_hat_face: Lil Nas X - Old Town Road (Película oficial) con Billy Ray Cyrus

@bchavez

Debes romper este hábito creando nuevos frameworks UX solo para Windows.

-- No solo eso. Incluso el hábito de romper la propia portabilidad XAML interna de Windows. WPF, Siliverlight, UWP todo en su propia bifurcación ... Este tipo de cosas está alejando a más y más personas de las herramientas de desarrollo de Windows en general, que personalmente me gustaría seguir usando en el futuro. Cuanto más retroceso de las herramientas de desarrollo de Windows, cada vez menos C # es relevante y para mí es lo que me importa cuando me pongo manos a la obra.

RE: interfaz de usuario multiplataforma:

... WinUI es la plataforma de interfaz de usuario nativa para Windows (_ incluidas las aplicaciones nativas _, no solo .NET) y para la versión 3.0 inicial, estamos principalmente enfocados en hacerlo independiente del sistema operativo y trabajar para prepararlo para el código abierto desarrollo en un ciclo de lanzamiento más rápido. Queremos asegurarnos de que el alcance sea lo suficientemente factible para que podamos obtener una vista previa este año.

Agregue un +1 para la idea de actualizar el aspecto visual de los controles WinForms, MFC, WPF que se ejecutan con WinUI 3.0 para que coincidan mejor con los estilos de control Fluent / FabricWeb.

Claro que hay diferentes tamaños de control (cualquier cosa que no sea WinRT XAML probablemente debería coincidir con sus métricas con la versión compacta de los controles de UWP) pero con un aspecto pulido coherente y consistente.

Agregue una dependencia de WinUI 3.0 en WinForms y los controles cambiarán.

Las aplicaciones WinUI 3.0 WPF detectan y usan temas de control Fluent.Light.xaml o Fluent.Dark.xaml.

@weitzhandler Entiendo tu sentimiento. Espero nunca tener que tocar javaScript y similares para hacer esta GUI multiplataforma. No me gusta ni siquiera pensar en comenzar un proyecto usando electrones, angulares, dardos, aleteo.
Espero que pronto podamos tener una solución con .NET 5, que traerá el sueño de Universal XAML. Microsoft XAML puede WIN, Web, Mobile, Desktop e IoT.
Silverlight casi lo hizo, para muchos casos de uso .

Debes romper este hábito creando nuevos frameworks UX solo para Windows.

WinUI 3.0 nunca se lanzará si tenemos que esperar (inevitablemente comprometido en todas las plataformas) soporte multiplataforma. WinUI debería ser el marco de interfaz de usuario de nivel más bajo en Windows, y si desea la capacidad multiplataforma, construya sobre eso (o use React Native, Xamarin, etc.).

Debes romper este hábito creando nuevos frameworks UX solo para Windows.

Solo me gustaría aclarar que no estamos tratando de crear un nuevo marco de interfaz de usuario con WinUI 3.0.

Nuestro objetivo inicial es:

• eliminar las barreras para usar las tecnologías nativas modernas existentes (Windows 10 Xaml UI y compositor) al desacoplarlas del sistema operativo y permitirles trabajar en los modelos de aplicaciones existentes (win32 y UWP), idiomas, otros marcos (a través de islas) y versiones de Windows

• actualizar nuestro proceso de ingeniería para que sea de código abierto

WinUI 3.0 nunca se lanzará si tenemos que esperar (inevitablemente comprometido en todas las plataformas) soporte multiplataforma.

Hombre ... Si realmente crees en eso, te refieres a que los frameworks exitosos como Flutter no funcionan ...

Tampoco me gusta Dart, pero SÍ lanzaron un producto bastante descendente que está evolucionando y ganando tracción MUY rápido.

Estoy frustrado de que WinUI se convierta solo en una cosa de Windows ...

.Net necesita un marco de interfaz de usuario que coincida con la genialidad de las capacidades multiplataforma de .Net Core, como acabamos de obtener para Web con Blazor (del lado del cliente y del servidor).

Creo que, por ahora, todavía tenemos que depender de los esfuerzos impulsados ​​por la comunidad.

Entiendo lo que su equipo está intentando hacer @jesbis ... Es solo que muchos de nosotros estamos cansados ​​de ver la interfaz de usuario en .Net / C ++ / UWP / MFC / Windows como una cosa _silo_'ed que solo se ejecuta en Windows mientras que todo el mundo (ofc, excepto Apple y OSX) van en sentido contrario, ofreciendo a los desarrolladores mejores y mejores soluciones multiplataforma. Como mencionaste React y Rect-Native (para que conste, tampoco me gusta, solo menciono que están evolucionando).

Entonces, lo que tenemos ahora son solo iniciativas impulsadas por la comunidad como Avalonia o incluso Uno y otros marcos (como FluSharp en el que estoy trabajando como se mencionó) que evolucionan MUY LENTO por razones obvias ...

Mi sugerencia es que, en lugar de simplemente sacar el XAML y el compositor de la base de código de Windows y convertirlo solo en Windows, obtenerlo y realizar las abstracciones adecuadas para que pueda funcionar en múltiples plataformas. Al igual que tuvimos con .Net Core, que inicialmente era solo para Windows, pero los esfuerzos impulsados ​​por la comunidad hicieron que funcionara bastante rápido en Linux, OSX e incluso en dispositivos ARM ...

(inevitablemente comprometido en todas las plataformas) soporte multiplataforma

Realmente no creo que esto sea un problema, dado que el diseño multiplataforma es, y siempre ha sido, un aspecto clave de la interfaz de usuario XAML de UWP y Fluent Design. Definitivamente, hay algunos controles en los que el diseño visual es diferente entre las versiones de Windows; esto se maneja sin problemas, obtiene una interfaz de usuario nativa que coincide con el sistema operativo del dispositivo.

Por ejemplo, Acrylic y Reveal integrados en los controles, colores de acento en Pivots y NavigationViews: estas cosas no aparecen en Creator's Update, pero sí en FCU y versiones posteriores. No se requieren cambios.

Obviamente, hay mucha más complejidad detrás de escena para renderizar la interfaz de usuario en un sistema operativo completamente diferente, pero en términos de diseño real de la interfaz de usuario, no creo que haya ninguna consideración nueva que deba tomarse, que nunca. con UWP y WinUI.

Creo que la gran preocupación es cuáles son realmente los planes a largo plazo. Según las respuestas de @jesbis , parece que solo se están enfocando en el corto plazo en este momento, y los planes a largo plazo aún están abiertos a discusión.

Eso es comprensible, el alcance de tal proyecto es enorme. Podría entender absolutamente si no fuera el plan a corto plazo, sino el plan final. La transparencia es importante aquí, está claro que nadie quiere apoyar una plataforma sin un futuro claro.

Está claro que MS en su conjunto se centra en la multiplataforma; lo vemos con Fluent Design (que ahora tiene ejemplos para iOS, Android y web), una gran cantidad de aplicaciones creadas por MS en otras plataformas, por lo que la interfaz de usuario compartida es realmente solo un gran eslabón perdido. Y es por eso que sería tan decepcionante no ver que suceda.Creo que a mucha gente le gusta la idea de una plataforma de aplicación universal hecha por MS, pero no tiene sentido apoyarla, si no tenemos un solución completa para ello.

El punto es ... Al igual que con material.io y Cupertino, podríamos (¡y no me sorprende que Google no lo esté haciendo ya!) Tener el "tema" en flutter para un lenguaje de diseño fluido ...

Y ese es mi punto cuando dije que un marco de interfaz de usuario verdaderamente multiplataforma no se preocuparía por eso y simplemente funcionaría, como lo hace Flutter ... No veo dónde tenemos compromisos al respecto ...

@weitzhandler Tampoco me gusta el HTML para aplicaciones nativas. De lo contrario, estaría usando Electron con React 😄

Simplemente no estoy siendo pasional aquí, sino que soy racional.

Realmente estoy esperando el WinUI 3.0 y lo usaría de inmediato para un nuevo proyecto de escritorio de Windows C ++ / WinRT. Y espero que la próxima versión principal después de la 3.0 introduzca un tiempo de ejecución portátil para alojar las aplicaciones WinUI (como el tiempo de ejecución de Flutter). Para un número significativo de aplicaciones LOB y aplicaciones similares a Photoshop, la GUI puede ser la misma en cada plataforma, pero la clave es el rendimiento y la reutilización del código fuente. Y también creo que el proyecto xlang es una gran idea y promete buenas noticias en el futuro.

Sugiero que los usuarios de aquí se tomen el tiempo para escuchar a Scott Hunter después de BUILD 2019 sobre cómo Win UI, Xamarin Form, UNO, Web Assembly podrían combinarse.

.NET Core 3 y más allá con Scott Hunter @ .NET Rock

Tanto Xamarin Forms (XAML) como UNO (XAML) se crearon con la visión de multiplataforma. En el caso de UNO (además de iOS, Android, XAML para Web mediante Web Assembly).

UWP se creó sin una visión más allá del ecosistema de Microsoft, por ejemplo, Web, Android, iOS. Todo el impresionante esfuerzo de diseño de Fluent tiene poca aceptación debido a la lenta adopción de UWP

Como señaló @ Mike-EE, el droide y iOS tienen 2 ~ y 1,5 ~ mil millones, mientras que Win10 tiene 0,9 mil millones. La mayoría de los desarrolladores aún se muestran reacios a pasar de WinForm y WPF a UWP.

¿POR QUÉ? ¡Los controles de UWP, de comercial y de Microsoft, son INCOMPLETOS ! en comparación con los de WinForm y WPF. Microsoft no se esfuerza por ayudar en esa transición. XAML Island no abordará esto MIENTRAS MICROSOFT tenga BLIND SPOT, ya que los desarrolladores NECESITAN hacer la transición a UWP desde winForm y WPF.

Con estos controles UWP faltantes, ahora se está haciendo un esfuerzo significativo para llevar la interfaz de usuario de Win a React Native para Web. ?????? Necesitamos estos controles de interfaz de usuario de Win para UWP que faltan para

Uno de esos controles es el control de diagrama . Todas las aplicaciones empresariales con uso intensivo de datos necesitan un control de diagramas para UWP.

==> Entiendo la necesidad de desacoplar la interfaz de usuario de UWP. Esto solo tiene sentido para difundir la marca Fluent Design a otras plataformas, por ejemplo, iOS, Android, Web.
==> Concéntrese en ofrecer un mejor control de modelo 3D y controles de diagrama (ambos 2D / 3D)

Solo tiene sentido quedarse y esperar a NET5 cuando TODO BCL de (mono se fusiona con el nativo de Windows, para Web Assembly, etc.), porque VEO EL FUTURO DE HOLOLENS UI 3D creativa.

Para eso, necesitamos Control de diagrama 2d / 3D para UWP y control de modelo 3D que no solo debería mostrar el modelo, sino permitir que el desarrollador acceda a la animación de esqueleto / vértice.

@jesbis Le insto a que ponga a más personas en estos USP (puntos de venta únicos) de Win UI para UWP.

@weitzhandler

Este problema se creó para discutir la hoja de ruta de WinUI 3.0 .

@jesbis hizo una declaración aclaratoria :

WinUI es la plataforma de interfaz de usuario nativa para Windows (incluidas las aplicaciones nativas, no solo .NET) y para la versión inicial 3.0, nos enfocamos principalmente en hacerlo independiente del sistema operativo y trabajar para prepararlo para el desarrollo de código abierto en una versión más rápida. ciclo. Queremos asegurarnos de que el alcance sea lo suficientemente factible para que podamos obtener una vista previa este año.

Sus dos primeros comentarios fueron sobre el tema.

Los siguientes seis fueron una combinación de improductivo y despectivo, y está a punto de romper el Código de conducta de código abierto de Microsoft .

Esta debería seguir siendo una conversación productiva y profesional con Microsoft.

// No sigo esta conversación para escuchar a un tipo desahogarse todo el día.

Creo que hay algunos comentarios geniales aquí, aunque parece que podría haber dos discusiones separadas. Seré breve porque la mayor parte se ha dicho antes.

Multiplataforma y web

.NET Core es genial. Finalmente podemos apuntar a cada plataforma y punto de contacto con excelentes herramientas y un lenguaje increíble.
Lo único que falta es una pila de UI, excepto Blazor (aunque HTML / CSS apesta). Para una máxima comparabilidad, sería genial tener un marco que permita a los desarrolladores de escritorio migrar a la web y más allá con las mismas habilidades, herramientas y lenguaje (Xaml y C #). Tbh, Silverlight hizo algo genial allí, simplemente funcionó). No estoy seguro de si WinUI debe ser ese marco, pero plantee el problema internamente. Básicamente, Flutter para desarrolladores de .NET, y apuntar a la web sería la mayor ventaja.

No estoy seguro de si Xamarin podría ser esa plataforma, pero si es así, asegúrese de que Xaml esté alineado tanto como sea posible en WinUI y Xamarin.

WinUI

Esto tiene que suceder. Debe haber una pila Xaml común para crear las mejores experiencias posibles en la plataforma Windows. Idealmente, los vacíos que faltan de WPF en términos de controles y funcionalidad deberían ser llenados.

HoloLens y más allá

Con la llegada de Lite y los nuevos factores de forma súper emocionantes como HoloLens, se podría argumentar que UWP no está listo para ello en términos de interfaz de usuario. Sí, podemos ejecutarlos en un HoloLens, lo cual es bueno, pero me gustaría ver una forma de optimizar realmente las aplicaciones para 3D sin usar Unity completo.

WinUI está muy por delante de Xamarin. Pero Microsoft Team acaba de sacar Xamarin 4.0 ...
Personalmente, soy más como Xamarin, ya que es la denominación más baja para Cross Platform, habrá un número creciente de aplicaciones nativas para SaaS en el futuro.

Aparte de Xamarin, hay alguna alternativa.
1) ¿Por qué no adoptar la plataforma UNO y hacer el renderizado web usando SkiaSharp?
2) @ zezba9000 Necesitas un backend de renderizado agnóstico como el que utilizan los motores de juegos para empezar. De hecho, lo reconozco un poco ...

Tal vez Microsoft empuje más a WinUI, porque no hay seguimiento de código fuente abierto en el interior a diferencia de otras soluciones multiplataforma: Xamarin, UNO, podrían tener bibliotecas UNIX ...

De todos modos, que la fuerza te acompañe.
PD: El patrocinador de Github es de Microsoft, así que patrocina algún desarrollador notable de Mac / Linux para la bifurcación multiplataforma de WPF / Winforms.

@jkoritzinsky , Una cosa que el equipo de WinUI debe tener en cuenta con el cambio de nombre de WinUI 3.0: si cambia el nombre de cualquiera de los tipos que se proyectan en .NET, las proyecciones no funcionarán (y no estamos planeando agregar más ya que no es un sistema extensible que se pueda mantener). Aquí hay una lista de los tipos que proyectamos: https://github.com/dotnet/coreclr/blob/master/src/inc/winrtprojectedtypes.h

Cualquier cambio en tipos diferentes a estos requerirá que los usuarios envuelvan sus objetos en nuevos objetos que implementen las nuevas interfaces o copien sus datos en los nuevos tipos. En particular, los tipos INotifyPropertyChanged y INotifyCollectionChanged son de interés con respecto a las islas XAML y brindan soporte en sentido descendente.

Estoy de acuerdo y me alegro de que hayas mencionado este problema, aunque me gustaría agregar que creo que estas proyecciones son un poco desafortunadas. No proyectamos todas las API que probablemente deberían ser (pensando en las API de System.IO), por lo que deberíamos remediar eso o pensar de manera diferente. Una cosa que me viene a la mente es no agregar tipos que sean similares, pero diferentes, a los tipos .NET en un espacio de nombres diferente. En su lugar, deberíamos permitir que nuestros desarrolladores de C ++ también usen System.ComponentModel.INotifyDataErrorInfo. Esto es algo así como lo que hicimos con C ++ / CLI, pero esto no requeriría cargar el CLR para una aplicación C ++ pura. No sé si eso sería más confuso, pero parece que estamos filtrando las diferencias fundamentales y subyacentes en las tecnologías .NET y WinRT en la capa API, lo que hace que las cosas se sientan incoherentes.

@ meir-pletinsky. NET es solo un marco que puede usar para crear aplicaciones con UWP XAML. Quieren que la validación del campo de texto esté disponible para los desarrolladores, sin importar qué marco utilicen

Esto es justo en el dinero, tenemos desarrolladores de C ++ que nos importan. Aunque como mencioné anteriormente, me encantaría que no causáramos confusión en la comunidad .NET solo para que esto suceda.

@mdtauk , no, WinUI Desktop (anteriormente Xaml Desktop) le permite usar Xaml con Win32 directamente, sin el uso de la isla.

Creo que @ meir-pletinsky se refería a .NET / C ++, a menos que me esté perdiendo algo.

@MarkIngramUK Creo que estamos hablando de dos proyectos diferentes aquí. WinUI debe ser el reemplazo de Win32. La gente está pidiendo una solución multiplataforma, lo cual es razonable, pero no creo que deba ser _este_ proyecto.

¡Sí, estoy totalmente de acuerdo! Para mí, WinUI se trata de definir la interfaz de usuario más moderna, de rendimiento y la mejor interfaz de usuario para Windows. Xamarin debería ser la historia multiplataforma de Microsoft y debería evolucionar para estar por encima de WinUI.

@mdtauk

Agregue un +1 para la idea de actualizar el aspecto visual de los controles WinForms, MFC, WPF que se ejecutan con WinUI 3.0 para que coincidan mejor con los estilos de control Fluent / FabricWeb.

Claro que hay diferentes tamaños de control (cualquier cosa que no sea WinRT XAML probablemente debería coincidir con sus métricas con la versión compacta de los controles de UWP) pero con un aspecto pulido coherente y consistente.

Agregue una dependencia de WinUI 3.0 en WinForms y los controles cambiarán.

Las aplicaciones WinUI 3.0 WPF detectan y usan temas de control Fluent.Light.xaml o Fluent.Dark.xaml.

Realmente no quiero ver a MS invirtiendo tiempo y recursos en esos marcos para que se vean como aplicaciones nativas de Windows 10. Es por eso que habrá WinUI 3.0. ¿Desea el aspecto y el funcionamiento de Windows 10 en las aplicaciones WPF / WinForms? Utilice WinUI 3.0.
MS debería invertir sus recursos en cerrar las brechas existentes (y bloquear) entre UWP / WinUI y sus contrapartes Win32, que volver a visitar sus marcos anteriores. Especialmente dado que WinUI está destinado a convertirse en _el_ marco de presentación para Windows ...

Me gustaría pedir una aclaración sobre las intenciones de WinUI y Microsoft sobre UI / UX:

1. ¿WinUI reemplaza TODOS los siguientes (¿hipotéticamente?): Win32, ATL, MFC, WinForms, Silverlight (lo sé), WPF, UWP y / o islas XAML? Reconozco que estas tecnologías seguirán existiendo y seguirán siendo compatibles durante un tiempo indefinido ; Solo quiero entender claramente que esto es lo que Microsoft dice que es "el camino a seguir", y que (por ejemplo), deberíamos considerar WinForms y WPF de la misma forma que consideramos Win32 o MFC.

2. ¿WinUI se deriva de UWP? (O, ¿qué tan similares son los dos?) ¿Qué tan similar (o diferente) es WinUI en comparación con UWP, XAML Islands o WPF?

Como desarrollador profesional de C # y C ++, comencé a trabajar con WinForms, luego me mudé a WPF y luego regresé a WinForms simplemente porque podía diseñar UI / UX para fines comerciales en WinForms aproximadamente el doble de rápido que en WPF. WPF brindó mucha más flexibilidad, rendimiento y se veía mucho mejor, pero la alteración de XAML que se produjo tan pronto como alguien tocó la interfaz a través del Diseñador en lugar de editar manualmente el XAML fue terrible. En algunos casos, creo que WinForms (usando el Diseñador) fue mucho más rápido que construir manualmente un formulario o control XAML que fuera similar.

Personalmente, me encantaría una interfaz de usuario que esté disponible e idéntica en todos los productos de Microsoft. Un marco que pueda ser aprovechado por Win32 o .NET de manera similar significaría aplicaciones consistentes y de aspecto moderno para TODOS los desarrolladores de Microsoft, y también significaría que las preguntas y problemas comunes se pueden resolver en sesiones que apuntan a una sola tecnología, por ejemplo, al hacer una pregunta sobre un control, la respuesta sería idéntica (si no casi idéntica) para un desarrollador Win32 O un desarrollador .NET. Eso haría que aprender "WinUI" sea útil para cualquier pila para cualquier desarrollador, y también haría que el acceso a la información en línea (StackOverflow, etc.) sea mucho más valioso, independientemente de dónde esté desarrollando. Aunque no uso Xamarin, si se pudiera hacer que Xamarin siguiera estos pasos (¿como una extensión de WinUI?), Entonces la declaración anterior podría aplicarse no solo a los desarrolladores de Windows, sino también a aquellos que se dirigen a Android, iOS, etc.

¿Para qué tipo de aplicaciones estaría emocionado de usar WinUI?

Si mi comprensión de WinUI es correcta, y es "el camino a seguir", reemplazando Win32, MFC, Forms, WPF, etc., y el mismo marco está disponible para el desarrollo nativo o .NET, entonces reemplazaré ansiosamente la composición. en _ TODAS _ las aplicaciones que soporto. ¿Interfaces de usuario modernas y consistentes que funcionan (y se comportan) de la misma manera independientemente de la plataforma o pila? ¿No es eso lo que todos queremos? No creo que nadie quiera recordar cómo crear CreateWindowEx () y ejecutar un bucle de mensajes para enviar eventos en Win32 mientras se manejan eventos de una manera completamente separada en WinForms o WPF. Es hora de algo "moderno". Realmente espero que eso sea lo que es WinUI (3.0).

Compatibilidad con sistemas operativos y soporte de nivel inferior

Creo que es genial que WinUI se esté centrando en desvincular la composición del sistema operativo, pero hay una gran cantidad de clientes que ni siquiera tienen Windows 10 todavía. Sé que es un punto de dolor y todos deseamos que nuestro público objetivo esté ejecutando lo último, pero es un problema real que todos enfrentamos a diario. ¿Qué discusión se está teniendo sobre hacer que WinUI esté disponible para plataformas más antiguas más allá de 1703, que creo que es la plataforma más antigua a la que se dirige actualmente?

¿Es una opción hacer WinUI enlazable estáticamente o incrustable (como .NET Core / 5)? Tendremos que apuntar a Windows 8.1, Windows 8, Windows 7, incluso Windows PE. ¿Cómo podemos utilizar WinUI con esos requisitos?

@shidell :

¿WinUI se deriva de UWP? (O, ¿qué tan similares son los dos?) ¿Qué tan similar (o diferente) es WinUI en comparación con UWP, XAML Islands o WPF?

WinUI 3.0 será, en cierto sentido, la próxima versión de los componentes de la plataforma UI de Windows 10 / UWP, incluida la plataforma Xaml, la composición y la entrada. Viene de esa base de código.

Debería ser muy similar a las API de la plataforma Xaml de Windows 10 / UWP, aparte de lo que se menciona en la hoja de ruta : es decir, un espacio de nombres raíz diferente, mejor soporte para mezclar y combinar con otras tecnologías (por ejemplo, usando un modelo de aplicación win32 en lugar de UWP), y algunas nuevas características aditivas.

¿WinUI reemplaza TODOS los siguientes (¿hipotéticamente?): Win32, ATL, MFC, WinForms, Silverlight (lo sé), WPF, UWP y / o islas XAML? Reconozco que estas tecnologías seguirán existiendo y seguirán siendo compatibles durante un tiempo indefinido; Solo quiero entender claramente que esto es lo que Microsoft dice que es "el camino a seguir", y que (por ejemplo), deberíamos considerar WinForms y WPF de la misma forma que consideramos Win32 o MFC.

WinUI es donde se encuentra nuestro principal desarrollo activo y progreso para la interfaz de usuario de la aplicación nativa en Windows. También es lo que usan el propio Windows y las aplicaciones y dispositivos nativos de Microsoft.

Las islas Xaml serán parte de WinUI y le permitirán usar WinUI para crear nuevas vistas en aplicaciones existentes (por ejemplo, WPF, WinForms).

¿Qué discusión se está teniendo sobre hacer que WinUI esté disponible para plataformas más antiguas más allá de 1703, que creo que es la plataforma más antigua a la que se dirige actualmente?
¿Es una opción hacer WinUI enlazable estáticamente o incrustable (como .NET Core / 5)? Tendremos que apuntar a Windows 8.1, Windows 8, Windows 7, incluso Windows PE. ¿Cómo podemos utilizar WinUI con esos requisitos?

Gracias por compartir los comentarios sobre esto. Para 3.0, nos enfocamos en las plataformas en la hoja de ruta (1703+, con algo de soporte en 8.1). Definitivamente entendemos que los desarrolladores también tienen clientes en otras versiones, y eso es algo que planeamos evaluar en el futuro.

Impresionante: parece que WinUI es "el camino a seguir" y, dado este conocimiento, decir que estoy emocionado sería quedarse corto.

En particular, creo que es fantástico que las islas XAML permitan a los desarrolladores extender WinUI a tecnologías más antiguas, como WPF y WinForms. Eso es un gran puente "hacia adelante" mientras se trabaja en proyectos antiguos o se amplían.

Impresionante: parece que WinUI es "el camino a seguir" y, dado este conocimiento, decir que estoy emocionado sería quedarse corto.

En particular, creo que es fantástico que las islas XAML permitan a los desarrolladores extender WinUI a tecnologías más antiguas, como WPF y WinForms. Eso es un gran puente "hacia adelante" mientras se trabaja en proyectos antiguos o se amplían.

Me gustaría pensar que si se creara un proyecto WinForms, MFC o WPF con WinUI 3.0 incluido, podrían simplemente representar páginas / contenido / ventanas XAML sin tener que usar una isla XAML en un formulario / ventana WPF / ventana HWND.

La capacidad de usar solo XAML puro, o usar una isla para colocar XAML en las superficies proporcionadas por el marco, realmente convertiría a WinUI 3.0 en "La única interfaz de usuario para gobernarlos a todos".

realmente haría de WinUI 3.0 "La única interfaz de usuario para gobernarlos a todos"

... en Windows. 😉

WinUI 3.0 será, en cierto sentido, la próxima versión de los componentes de la plataforma UI de Windows 10 / UWP, incluida la plataforma Xaml, la composición y la entrada. Viene de esa base de código.

En ese sentido, @jesbis , me pregunto si puede hablar sobre cómo será la integración entre WPF y UWP. En particular, con conceptos como extensiones de marcado que hemos estado solicitando en UWP durante años, con muy poco éxito.

Se hizo un intento , por supuesto, pero no ha la implementación de WPF a pesar de que tomó más de dos años completos para desarrollarse.

Además, una gran cantidad de servicios que estaban disponibles en el marcado de WPF aún están disponibles e implementados en UWP. ¿El esfuerzo está aquí para garantizar que el nuevo marcado WinUI 3.0 basado en UWP tenga total fidelidad con WPF? Disculpas si esto se explica en alguna parte, pero todavía tengo que analizar el mensaje para verlo (y agradezco cualquier recurso para corregir / complementar mi comprensión).

realmente haría de WinUI 3.0 "La única interfaz de usuario para gobernarlos a todos"

... en Windows. 😉

Al menos para la ventana de lanzamiento de WinUI 3.0. Espero que pueda ser el comienzo de un proceso para llevar la representación XAML a otras plataformas ...

Me pregunto si puede hablar sobre cómo será la integración entre WPF y UWP. En particular, con conceptos como extensiones de marcado que hemos estado solicitando en UWP durante años, con muy poco éxito. [...] ¿Está el esfuerzo aquí para garantizar que el nuevo marcado WinUI 3.0 basado en UWP tenga total fidelidad con WPF?

La fidelidad total de @ Mike-EEE con WPF no es un objetivo para 3.0. Sin embargo, estamos rastreando una serie de elementos de trabajo para cerrar brechas a lo largo del tiempo (por ejemplo , mejoras en la extensión de marcado # 686 soporte de modelo 3D).

Si hay otras características específicas en WPF que le gustaría / necesitaría usar en WinUI, no dude en abrir nuevos problemas de propuesta de características para ellos, o comentar en el reciente número 719 de " Características de WPF que deberían estar en WinRT XAML ". No tenemos recursos infinitos, pero definitivamente estamos tratando de tener en cuenta los aportes de la comunidad en nuestra planificación. Una vez que todo sea de código abierto, también habrá una oportunidad para que cualquiera pueda ayudar potencialmente a contribuir con funciones.

Eso es alentador, @jesbis , gracias por compartir eso. He actualizado los votos relevantes en UserVoice para señalar a los suscriptores ese problema.

Supongo que mi principal preocupación es si la fidelidad completa de WPF no es un objetivo, mientras que tener WinUI utilizado dentro de WPF _es_ un objetivo, entonces encontrará fricciones con la adopción de WPF, ya que tiene el modelo Xaml superior (y original).

Es decir, no parece haber una propuesta de valor obvia para incorporar WinUI3.0 en WPF, de la misma manera que las islas Xaml no tienen una propuesta de valor obvia. Al final del día, parecería que está intentando incorporar un modelo Xaml regresado / inferior / subdesarrollado al modelo Xaml establecido y superior, lo que simplemente no tiene ningún sentido.

Para casos de uso en WinForms, MFC, etc., sí, este enfoque tiene sentido para WinUI3.0. Sin embargo, con WPF, tiene un modelo de presentación superior y un paradigma de desarrollador / diseñador que simplemente no ha sido igualado por ninguna otra iniciativa de MSFT o proveedores externos.

@ Mike-EEE basado en la charla de Scott Hunter , me parece, lo que podría estar equivocado, que el objetivo de "UN BCL para gobernarlos a todos" tiene una prioridad más alta que "Una interfaz de usuario para gobernarlos a todos".

Al reemplazar MONO subyacente Xamarin Forms XAML y UNO XAML en Web a través del ensamblado Web con un BCL común que tiene AoC, las aplicaciones basadas en Xamarin Forms XAML, Uno XAML en la Web TODOS SE BENEFICIARÁN del rendimiento de velocidad.

Este rendimiento de velocidad ES CRÍTICO para cualquier persona que se preocupe por el futuro de su carrera invirtiendo en C # para plataformas cruzadas en vistas de una competencia intensa proveniente de otras tecnologías, por ejemplo, flutter, react, etc.

Con suerte, en este viaje hacia .NET5 = un BCL común para gobernarlos a todos , la estandarización XAML se cuida, parcial o completamente, a lo largo del proceso, PERO no es el objetivo principal de .NET5.

Otra prioridad además de la necesidad de estandarización XAML es la difusión de la marca Microsoft a través de un diseño fluido en todas las plataformas (móvil, escritorio y web). [En términos técnicos, desacoplamiento a través de Win UI 3.0, que se nos pide una y otra vez que enfoquemos el propósito de la hoja de ruta de WinUI 3.0]

AL FINAL, cuánto UWP, que se origina en Win UI, realmente juega un papel en este UN BCL PARA GOBERNARLOS A TODOS antes de NOV2020 cuando se lance .NET5, TAMBIÉN NO ES un objetivo de alta prioridad en mi opinión.

Desde el punto de vista del marketing, desafortunadamente no se traduce en tecnología que nos importa profundamente, es que la marca de Microsoft a través del diseño fluido es omnipresente y la aplicación que promueve ese diseño es RÁPIDA EN TODAS PARTES.

Así es como veo la estrategia a largo plazo de Microsoft para "recuperar la cuota de mercado" debido a la falta de presencia móvil.

Esto es obvio, excepto que VEO UN POTENCIAL MUCHO MAYOR que se encuentra en Hololens 2 y más allá. Para eso, NECESITAMOS ASEGURARSE de que las APLICACIONES UWP con WinUI 3.0 vengan con controles de Diagrama 3D y un visor de modelos 3D avanzado.

Lo siento chicos, sigo presionando esto porque quiero usar el tiempo limitado que tengo en la MEJOR DE LA MEJOR TECNOLOGÍA. :-)

Respecto al período de transición de WinUI 3.0

Sugeriría que Microsoft trabaje directamente con los mantenedores de Windows Community Toolkit (algunos de los cuales funcionan para MS) para:

1. Pruebe para ver si hay obstáculos imprevistos mientras redirige el kit de herramientas a WinUI 3.0 (incluida la aplicación de muestra).
2. Pruebe el cambio de nombre automático del espacio de nombres a través de Visual Studio u "otra herramienta" para ver qué tan bien funciona.
3. Informe públicamente sobre cómo fue el proceso (publicación de blog / problema de GitHub / lo que quiera).
4. Proporcione un fragmento de texto para copiar y pegar sobre WinUI 3.0 y la transición que los encargados del mantenimiento del proyecto pueden agregar a sus archivos Léame de GitHub / Nuget / otros, o al menos una URL con información concisa al respecto. Esto ayudará a que los usuarios de esos proyectos se pongan al día rápidamente con WinUI 3.0 y les explicará lo que deberán hacer para completar la transición.
5. Describa un proceso de transición sugerido y un cronograma que los encargados de mantenimiento de proyectos / bibliotecas pueden optar por adoptar.

En lo que respecta al último elemento, debe cubrir sugerencias como:

• Cree un nuevo número de versión principal que indique que se utilizará con aplicaciones WinUI 3.0 (como WCT v6.0).
• Opcionalmente (?) Cree una rama para contener el código heredado que admitirá proyectos que aún no se han actualizado a WinUI 3.0.
• Proporcione un período de tiempo (por ejemplo, 3/6/12 meses) durante el cual se proporcionará soporte para proyectos heredados (es decir, fusionando correcciones de errores y demás de la rama principal). Esto podría tener fechas específicas para "sincronizar" el período de apoyo en los proyectos / bibliotecas de la comunidad.

Por último, creo que será importante identificar qué se puede hacer si necesita admitir Windows 10 versión 1507 y 1607 LTSB. Estas son las únicas 2 versiones compatibles de W10 que estarán disponibles y con las que WinUI 3.0 no será compatible en el momento del lanzamiento.

Originalmente, iba a sugerir probar el proceso con la Calculadora de Windows 10, ya que es una aplicación de código abierto de calidad de producción. Sin embargo, luego me di cuenta de que esta aplicación debe ejecutarse en 1507 y 1607 LTSB durante otros 6-7 años. Obviamente, habrá cierta controversia en torno al soporte de este tipo de aplicaciones, especialmente cuando se trata de proyectos comunitarios más pequeños. Si realmente necesitan este apoyo, entonces se les debe proporcionar una estrategia clara a largo plazo sobre cómo hacerlo.

Respecto a WinUI 4.0 / 3.x / vNext

Como indican los comentarios aquí, la comunidad tiene una lista de deseos bastante larga para futuras versiones de WinUI. Realmente deberíamos capitalizar el impulso y el entusiasmo que se están acumulando aquí documentando públicamente algunos de los planes a más largo plazo.

Dado que la mayoría de estos elementos están fuera del alcance de la versión 3.0, creo que debería crearse un nuevo problema más temprano que tarde para comenzar a recopilar comentarios de la comunidad sobre WinUI 4.0 / 3.x / vNext. En todo caso, esto ayudará a identificar los tipos de trabajo que el equipo de WinUI está considerando y lo que está fuera del alcance de WinUI y / o la responsabilidad de otros equipos de MS.

Un ejemplo del último punto: realmente me gustaría ver estas cosas:

• Compatibilidad con .NET Core 3.0 para proyectos de UWP (responsabilidad del equipo de .NET, según tengo entendido)
• Soporte completo para aplicaciones de Windows (UWP y Win32) desde Visual Studio App Center (obviamente no es algo de lo que el equipo de WinUI sea responsable)
• Pautas de Fluent Design más concretas, similares a las que puede encontrar en los documentos de Material Design (nuevamente, responsabilidad del equipo por separado)
• Uso de WinUI 3.0 y diseño fluido en las aplicaciones W10 incluidas (equipos separados y algunas de esas aplicaciones deben admitir versiones LTSB)

Al identificar estos elementos fuera de alcance, podemos redirigir a la comunidad hacia los puntos adecuados de retroalimentación y / o explicar lo que está sucediendo en esas áreas.

Fuera de esas cosas, la lista de deseos dentro del alcance puede comenzar a juntarse y la comunidad puede comenzar a mostrar su apoyo por lo que más desean de WinUI en el futuro.

Sería genial si F # tuviera un soporte a la par con C #, por ejemplo, tener las mismas plantillas de proyecto que C #.

Me gustaría que WinUI (UWP vNext) tenga un objeto de ventana adecuado como WPF, con los métodos Top, Left, Width, Height, StartupPosition, IsTopMost, AllowTransparency y Show () / ShowDialog ().

(_No estoy seguro de cómo funcionaría (o se permitiría) esta ventana en dispositivos de pantalla pequeña, como teléfonos móviles e IoT_)

@TonyHenrique hay una nueva API de ventanas para UWP en 1903, pero está lejos de estar terminada.

Está mirando nuevamente la representación de XAML dentro del alcance de WinUI 3.0.

Las cosas que siento que están un paso por debajo de la representación de WPF son:

• Texto que no usa ClearType, sino que favorece el suavizado de escala de grises;
• Falta de precisión de píxeles para cosas como trazos de borde;

Puedo entender cuando Windows Phone 7 y Windows Phone 8 tuvieron que compartir un sistema de renderizado: el tipo de tecnología de pantalla y la velocidad de renderizado empujaban hacia un mejor rendimiento. Pero con WinUI girando primero a Desktop y pantallas más grandes, tal vez sea el momento de restaurar estas cualidades en el motor de renderizado XAML.

Y si cosas como Hololens y Xbox requieren una consideración especial, ¿por qué no ofrecer un modo de rendimiento que se puede activar a nivel de plataforma en aquellos dispositivos que necesitan la renderización como está ahora?

¿Qué pasa con la plantilla f #?

A menos que funcione de forma inmediata en las plantillas de proyecto estándar de Windows Forms y WPF destinadas a .NET Framework 4.5 o posterior, no podemos adoptar la biblioteca WinUI.

Requerir solo la última versión de Windows 10 y / o la aplicación para UWP es lo mejor para adoptar el diseño Fluent.

Sugeriría que Microsoft trabaje directamente con los mantenedores de Windows Community Toolkit (algunos de los cuales funcionan para MS)

@kmgallahan
¡Gran sugerencia! Definitivamente esto está en el plan. Nuestro equipo a menudo trabaja en estrecha colaboración con los mantenedores de Windows Community Toolkit y es una de las cosas que nos gustaría usar como proyecto de prueba.

Está mirando nuevamente la representación de XAML dentro del alcance de WinUI 3.0.

@mdtauk
Es probable que cualquier cambio de renderizado esté fuera del alcance de 3.0, pero abra un problema para que podamos revisar la idea para versiones posteriores. Definitivamente, un gran enfoque ha sido el rendimiento universal que, como puede notar, llevó a algunos cambios de renderizado en Windows 8+. El interruptor de modo de rendimiento es una idea interesante.

¿Qué pasa con la plantilla f #?

@edgarsanchez , @khoshroomahdi
¡Parece que estamos recibiendo mucho interés en F #! Nos encantaría saber más sobre por qué quiere F #: no dude en comentar en el número de F # sobre por qué lo quiere y para qué lo usaría: # 740

A menos que funcione de forma inmediata en las plantillas de proyecto estándar de Windows Forms y WPF destinadas a .NET Framework 4.5 o posterior, no podemos adoptar la biblioteca WinUI.

@jozefizso
¿Has mirado en las islas Xaml? Esta función le permite usar WinRT Xaml en aplicaciones WPF y Windows Forms para que pueda comenzar a mejorarlas con vistas / páginas Xaml modernas:
https://docs.microsoft.com/windows/apps/desktop/modernize/xaml-islands

Estamos planeando que WinUI 3.0 incluya islas y sea compatible con versiones anteriores de Creators Update y más recientes, que son al menos las últimas 5 versiones de Windows.

¿Podría Xaml Islands trabajar en Creators Update y versiones posteriores con WinUI 3.0 satisfacer sus necesidades?

Es probable que cualquier cambio de renderizado esté fuera del alcance de 3.0, pero abra un problema para que podamos revisar la idea para versiones posteriores. Definitivamente, un gran enfoque ha sido el rendimiento universal que, como puede notar, llevó a algunos cambios de renderizado en Windows 8+. El interruptor de modo de rendimiento es una idea interesante.

Hecho # 768

Las islas XAML requieren Windows 10, versión 1903 y la biblioteca de Windows Community Toolkit requiere que el proyecto sea UWP. Eso es un no ir.

Las islas XAML requieren Windows 10, versión 1903 y la biblioteca de Windows Community Toolkit requiere que el proyecto sea UWP. Eso es un no ir.

WinUI 3.0 no irá a Windows 7/8 / 8.1, pero esos sistemas operativos llegarán al final de su vida útil muy pronto. Y todavía puede usar WPF y WinForms para esos por ahora. Esto es para cuando sus usuarios se hayan mudado a Windows 10

En cuyo caso, el proyecto será UWP para Windows 10, por lo que no tiene sentido admitir WPF / WinForms. Esto solo se mueve en un círculo y fragmenta las herramientas de desarrollo.

@jozefizso Es más preciso decir que UWP está cambiando para permitir que se parezca más a WPF y WinForms, y la interfaz de usuario XAML se está acercando a las plataformas WPF y WinForms.

Aplicaciones para UWP con interfaz de usuario XAML moderna que salen de la zona de pruebas restrictiva y pueden conectarse a las plataformas WPF y WinForms.

Así es como lo entiendo.

Las islas XAML requieren Windows 10, versión 1903

En cuyo caso, el proyecto será UWP para Windows 10

Con WinUI 3.0, estamos planeando que las islas estén disponibles a partir de 1703 (mucho más atrás).

También estamos trabajando para que WinUI se pueda usar con un modelo de aplicación Win32 en lugar de UWP (informalmente llamado "escritorio WinUI"), por lo que no necesariamente tendrá que ser una aplicación UWP.

También estamos trabajando para que WinUI se pueda usar con un modelo de aplicación Win32 en lugar de UWP (informalmente llamado "escritorio WinUI"), por lo que no necesariamente tendrá que ser una aplicación UWP.

Esto es lo que más me emociona. Una aplicación nativa con la API completa de Windows disponible, ya sea Win32 o Windows Runtime, capaz de tener una interfaz de usuario de alto rendimiento a través de Xaml.

También estamos trabajando para que WinUI se pueda usar con un modelo de aplicación Win32 en lugar de UWP (informalmente llamado "escritorio WinUI"), por lo que no necesariamente tendrá que ser una aplicación UWP.

Esto es lo que más me emociona. Una aplicación nativa con la API completa de Windows disponible, ya sea Win32 o Windows Runtime, capaz de tener una interfaz de usuario de alto rendimiento a través de Xaml.

Tome una aplicación WinForms, mantenga el código subyacente, pero reemplace el formulario con una ventana XAML y tenga acceso a todos los pinceles y controles XAML.

WPF sería un poco más complicado si solo usara WinUI XAML en su lugar, pero al menos los controles de WPF podrían diseñarse para que coincidan con los de WinUI

1. Se debe cambiar el nombre del espacio de nombres. "Xaml" no es apropiado porque Xaml se refiere a un lenguaje de marcado, que se está utilizando incorrectamente como lenguaje de marketing (que cambia con frecuencia) para los componentes nativos de UWP. "Xaml" debe reemplazarse por "WinUI". Puede ver cuánta confusión se genera incluso en este hilo, donde a menudo no está claro si "Xaml" se refiere al lenguaje .xaml oa los componentes de la interfaz de usuario.
2. En la medida en que esto acerque a WPF y UWP, esto es bueno. Cada uno tiene características que no están presentes en el otro, y tiene sentido tener una "interfaz de usuario de Windows" que combine las dos. Puede haber alguna duplicación de funciones, pero esto también puede ser una ruta de transición WPF -> UWP.
3. El desacoplamiento de las versiones de Windows tiene sentido, pero también está bien suponer un Win10 relativamente actualizado, dado que Win7 habrá superado el EOL cuando este trabajo haya terminado.

Xaml es el nombre del marco de la interfaz de usuario. Por lo tanto, Windows.UI.Xaml ...

Xaml es el nombre del marco de la interfaz de usuario

Xaml era una tecnología en WPF que permitía a los desarrolladores describir y construir de manera poderosa no solo escenas de presentación dentro de sus aplicaciones, sino también las propias aplicaciones. Es decir, podría describir los elementos de la interfaz de usuario _así como los POCO_. Si fuera .NET, podría describirse detalladamente con Xaml y cargarse en el contexto de una aplicación.

Para que no olvidemos (y parece que lo hemos hecho) que Xaml significa Lenguaje de marcado de aplicaciones extendido, lo que significa que es un lenguaje de marcado que le permite describir de manera elegante y eficiente los componentes de _aplicación_ .NET. Si bien se utilizó principalmente para describir los elementos de la interfaz de usuario, en la práctica no fue relegado ni limitado como tal.

Personalmente terminé usando Xaml para describir la configuración completa de mi aplicación, eliminando y reemplazando App.config, y sí, incluso Web.config, la complejidad, excepto en los casos de las API externas que lo requerían absolutamente.

Xaml es _no_ UI. Son dos conceptos totalmente diferentes, pero desafortunadamente se han combinado durante años bajo UWP. Por mi parte, me encantaría ver el término "Xaml" desenredado de estos esfuerzos, pero no estoy muy seguro de que se consideren tales medidas, y mucho menos se emprendan.

@charlesroddie Estoy de acuerdo en que el nombre es realmente arbitrario. Solo una tangente, si alguna vez inspecciona los rastros de la pila de cosas que se originan en el espacio de nombres WUXaml, en realidad está internamente en un espacio de nombres DirectUI. Me encantaría saber la historia de Win8 si alguien estuvo aquí durante esos días, porque imagino que hubo una historia diferente. DirectComp para componer capas, DirectManipulation para un desplazamiento suave y bandas elásticas, y luego Direct2D / DirectWrite como motor de gráficos vectoriales con DirectUI en la parte superior para unir todo. Luego, por alguna razón, parte de ella se volvió a portar a Win7, solo los bits Xaml se expusieron a través del sistema WinRT, mientras que todas las demás API se dejaron como interfaces de comunicaciones crípticas con fábricas y patrones extraños que necesitabas para ver ejemplos que explican cómo invocar.

En realidad, ahora que lo pienso, sería realmente bueno si, al igual que WUComposition expuso DirectComp y DirectManipulation a través de WinRT (o es una reescritura), Direct2D / DirectWrite también tuviera un hogar formal aquí. Todos trabajan juntos para permitir varios niveles de escotillas de escape y puntos de contacto de fidelidad si lo está buscando. Win2D está realmente a medias y tampoco es una buena API.

Windows.UI.Composition es una reescritura de DirectComposition, creo. Las API son similares pero no iguales.

Deja de asumir que todos los monitores ya son sRGB.
Trate todos los colores de las aplicaciones heredadas como sRGB y realice la conversión para cada monitor durante la composición.

Esto puede estar un poco fuera de tema, pero suponga que ya tiene una gran aplicación Win32 escrita en C ++, desea modernizar el sistema de interfaz de usuario, por lo que es posible que desee usar WinUI o Comp con una dependencia mínima, como usar Comp solo sin conjunto de control de caja, o incluso sin XAML .

Sin embargo, eso ya es posible ahora, no necesitamos esperar a WinUI 3.0 para eso.

Gracias a todos por los comentarios sobre los nombres. Como se señaló, hoy tenemos una distinción entre la "plataforma Xaml" y el "lenguaje Xaml" (con sus propias especificaciones / dialectos diferentes) que puede

Use Windows.UI.Composition en una aplicación C ++ Win32 sin XAML para modernizar aplicaciones existentes (como Photoshop). Ya tienen una arquitectura de interfaz de usuario.

Esto puede estar un poco fuera de tema, pero suponga que ya tiene una gran aplicación Win32 escrita en C ++, desea modernizar el sistema de interfaz de usuario, por lo que es posible que desee usar WinUI o Comp con una dependencia mínima, como usar Comp solo sin conjunto de control de caja, o incluso sin XAML.

Gracias por los comentarios sobre esto. Creo que, con suerte, esto debería ser posible al final con WinUI 3, similar a una aplicación "sin marco" que usa Windows.UI.Composition que ya puede hacer hoy. Tendremos esto en cuenta al determinar cómo estructurar los paquetes y las dependencias de WinUI NuGet.

Deja de asumir que todos los monitores ya son sRGB.
Trate todos los colores de las aplicaciones heredadas como sRGB y realice la conversión para cada monitor durante la composición.

@ reli-msft, ¿podría abrir una edición separada para rastrear eso?

@jesbis 👉 # 67

Apple anunció hoy SwiftUI ...

¿Qué tal si Xaml Direct recibiera plantillas de Visual Studio para permitir a los desarrolladores elegir crear aplicaciones usando código en lugar de XAML y código subyacente?

No creo que haya un cambio de marca importante en las cartas, pero definitivamente estamos discutiendo los nombres y los espacios de nombres.

Gracias @jesbis . Aprecio que se involucre tanto en este hilo. Por lo general, parece que alguien hará una publicación / anuncio como este y luego lo dejará por muerto (o para que otros lo administren escasamente), por lo que es alentador ver que usted, como autor del hilo, no solo está comprometido sino que también está atento a lo que otros están diciendo. Especialmente cuando esos otros soy yo. 😆

Y tiene razón: existe 1) plataforma de interfaz de usuario y 2) mecanismo de lenguaje / marcado / descripción. En mis comentarios críticos, diré que nunca doy suficiente crédito por la (primera) plataforma de interfaz de usuario, ya que sé que el equipo de Windows ha realizado un gran trabajo en torno a esto. Eso nunca ha sido un motivo de preocupación para mí, personalmente. Es la segunda área que atrae mi ira y consternación (y la de otros), y lo vemos en los problemas de UserVoice que han surgido a lo largo de los años.

Dicho todo esto, al menos pediría (ruego, incluso 😅) que consideren más los esfuerzos de marca para categorizar mejor estas dos esferas. Creo que "Xaml Direct" es el pináculo de la confusión aquí, ya que su nombre implica "Markup Language", ¡está justo en el nombre! - pero no hay nada de eso en su uso real. Terriblemente confuso y engañoso, y al límite del abuso de la marca, diría.

Y hablando de Xaml Direct, @mdtauk :

¿Qué tal si Xaml Direct recibiera plantillas de Visual Studio para permitir a los desarrolladores elegir crear aplicaciones usando código en lugar de XAML y código subyacente?

¿Como en algo como CSharpForMarkup ?

Sugeriría un nombre mucho mejor y adecuado que Xaml Direct. Por supuesto, _cualquier_ nombre sería. 😉

Y hablando de Xaml Direct, @mdtauk :

¿Qué tal si Xaml Direct recibiera plantillas de Visual Studio para permitir a los desarrolladores elegir crear aplicaciones usando código en lugar de XAML y código subyacente?

¿Como en algo como CSharpForMarkup ?

Sugeriría un nombre mucho mejor y adecuado que Xaml Direct. Por supuesto, _cualquier_ nombre sería. 😉

@ Mike-EEE https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.core.direct

Está diseñado para que middleware escriba la interfaz de usuario XAML desde el código, pero ¿qué pasaría si hubiera plantillas para usarlo en lugar de archivos XAML? Solo un pensamiento para dejarlo ahí ...

@mdtauk ¡SÍ! SwiftUI se parece a Xaml pero está hecho en código. Realmente amo la idea de todo en el código de la forma en que React lo hace. Es una especie de vieja escuela dividir los archivos de diseño y luego vincularlos con algún tipo de código subyacente, y encuentro que es difícil de mantener.

Un amigo acaba de mencionar que necesitan el motor de diseño SwiftUI para funcionar con la pantalla de 120 hz del iPad Pro. Así que eso es en lo que se han centrado. Realmente fascinante.

Hice un nuevo número # 804 donde la discusión sobre los cambios inspirados en SwiftUI podría ir a @ eklipse2k8

NO OLVIDE agregar plantillas para Visual Basic.😀

¡Deje que WPF construya _on_ las capas inferiores de WinUI 3!

@ reli-msft ¿qué beneficios le gustaría obtener de la actualización de WPF?

Si hay características específicas de WPF en las que confía y que le gustaría ver en WinUI, entonces nos encantaría escuchar más en el hilo "Características de WPF que deberían estar en WinRT [WinUI]": https://github.com/microsoft / microsoft-ui-xaml / issues / 719

Cierre a favor de un nuevo problema anclado # 888

Estoy verdaderamente deseando que llegue esto. Resolverá muchos problemas especialmente relacionados con la versión.

@weitzhandler [el 16 de mayo de 2019

Para mí, todos los detalles técnicos son menos importantes.
UWP, WPF o cualquier marco solo para Windows, por increíble que sea, no será suficiente siempre que no se ejecute en todas las plataformas (al menos Windows, Droid, iOS y web), y es compatible con cualquier tamaño de pantalla.

Según WinUI y XAML en general, me encantaría ver mejoras en los siguientes aspectos, algunos de los cuales me resultan molestos y ralentizan mi trabajo.

• MUCHOS más convertidores integrados Debería haber un montón de convertidores, algunos de los cuales incluso deberían usarse como una extensión de marcado para reducir la verbosidad. Esto también debe incluir la negación de la acción aritmética simple, el convertidor de objeto a booleano (falso por valor semántico, es decir, cadena vacía, colección vacía, visibilidad oculta, etc. por contexto).
• Igual que el anterior pero con comportamientos. Debe haber un puerto fácil entre el enlace y los eventos / acciones. Sería mucho más fácil si eso hubiera estado integrado y el desarrollador no tuviera dudas sobre qué NuGet no probado usar.
• Todo lo que falta en WPF, como algunos tipos de enlaces, extensiones de marcado, vistas genéricas y otros.

¡Gracias!

MUCHOS más convertidores incorporados

Desde el motor analítico de Babbage y la teoría de la computación universal de Turing, ha sido posible que una sola computadora pueda ejecutar cualquier programa que cualquier computadora pueda ejecutar. Desea volver a una época en la que tenemos que crear una nueva computadora para cada cálculo que desee hacer.

Todo el negocio de los convertidores debería ser abandonado sin ceremonias.

convertidor de objeto a booleano

los booleanos son booleanos. Otros objetos no son booleanos. Y no existe una conversión natural de objetos a valores booleanos. Los tipos son importantes en .Net y otros sistemas no tipificados no deben exponerse a los usuarios.

Sí, y los sistemas no tipificados existentes, como las vinculaciones, también deberían descartarse.

Todo el negocio de los convertidores debería ser abandonado sin ceremonias.

Quiero decir, ¿cuáles son tus alternativas?
Mi punto de dolor con los convertidores es solo que tienes que volver a escribirlos tú mismo / elegir de NuGet, y que son muy detallados. Que además de no ser flexibles no permiten expresiones como aritmética o negación, etc.

los booleanos son booleanos. Otros objetos no son booleanos.

Tienes razón, pero cuando se trata de la interfaz de usuario, realmente no importa.
Quieres mostrar / ocultar cosas según el estado convencional del objeto. No todo debería tener una propiedad de visibilidad dedicada.

Los sistemas no tipificados existentes, como las vinculaciones, también deben descartarse.

¿Eh? De hecho, creo que tiene una ventaja. El acoplamiento flojo entre V y VM puede ser bueno.

Los sistemas no tipificados existentes, como las vinculaciones, también deben descartarse.

El acoplamiento flojo entre V y VM puede ser bueno.

Quizás para proyectos pequeños, pero hay mejores abstracciones para un acoplamiento flexible que literalmente apagar la asistencia del compilador. Si alguna vez tuvo que mantener una aplicación grande con decenas a cientos de vistas y desea refactorizar algo que pueda usarse en varios sitios, no hacer que el compilador verifique la exactitud de las rutas de enlace es una degradación importante en la experiencia del desarrollador. Hay una razón por la que tenemos sistemas de tipos en nuestros lenguajes, los grandes proyectos son literalmente imposibles de mantener sin herramientas para ayudar al programador, actualmente los lenguajes de interfaz de usuario se están quedando atrás mucho.

Los enlaces compilados ayudan mucho para eso.

@weitzhandler Quiero decir, ¿cuáles son tus alternativas?
... No todo debería tener una propiedad de visibilidad dedicada.
¿Eh? De hecho, creo que [las fijaciones] tiene una ventaja. El acoplamiento flojo entre V y VM puede ser bueno.

En un buen marco reactivo, puede definir variables observables (en el código) como name:Mutable<string> y luego asignarlas a let visibility = name.map(fun s -> s <> "") y luego vincularlas para ver propiedades con visibility.bind someView.set_IsVisible o name.bind(fun s -> someView.IsVisible <- s <> "") .

Utilizo https://github.com/ReedCopsey/Gjallarhorn pero hay varios marcos reactivos.

Tenga en cuenta que: 1. todo está escrito, a diferencia de los enlaces. 2. Las cosas (funciones, propiedades, vistas) se denominan objetos, no pasando nombres de cadenas, 3. las funciones son solo funciones, mucho menos torpes que los convertidores, 4. texto estándar vinculante, donde las propiedades de los objetos simples deben recibir un extra "propiedades enlazables", etc., se pueden eliminar.

Las vistas aún se pueden escribir en Xaml, especialmente si son diseños simples en su mayoría estáticos, con la desventaja de las cadenas mágicas en todas partes, pero la ventaja de tener un diseñador para brindar una vista en vivo. Mejor sería tener un código que ofrezca una vista en vivo. Muy posible con intérprete.

Hablando de marcos reactivos, consulte Chain Reactive y diga si debería abrirlo.

Hola, ¿el equipo de ms puede resolver todos los errores / características en uservoice ?
Si lo hiciera, sería un gran paso, más que WinUI 3.0.

@ hupo376787 Creo que obtuviste

Pero ES un problema que no hay lugar para una discusión abierta sobre las plataformas de desarrollo de Windows en las que microsoft y los desarrolladores pueden participar, y ES un problema que el grupo de microsoft relevante no mantiene ningún mecanismo de retroalimentación, no habiendo actualizado o respondido a eso. uservoice durante varios años.

@charlesroddie Sí, parece que la voz del usuario está abandonada. Enviaré mi voz a Feedback Hub. Quizás la Sra. Los ignore, pero haré mi trabajo.

UserVoice se retirará por completo este mes.

Para productos específicos, los repositorios de GitHub (como este) son el mejor lugar para recibir comentarios, ya que los equipos de ingeniería relevantes los están utilizando activamente.

Para recibir comentarios que no estén relacionados con un producto de repositorio específico, utilice el Centro de comentarios. Hay una categoría de "Plataforma de desarrollador" con varias subcategorías específicamente para comentarios sobre API y herramientas de desarrollador.

Sé que hay mucho historial y comentarios previos actualmente sobre UserVoice (de los que aún realizaremos un seguimiento), pero tanto GitHub como Feedback Hub brindan una ruta más directa a nuestros equipos de ingeniería y seguimiento de elementos de trabajo que UserVoice, así que espero que esto debería ser un cambio positivo. Estamos en proceso de actualizar varios enlaces de soporte y comentarios.

¡Vemos todo lo que proviene de cualquiera de los canales y realmente apreciamos los comentarios y los informes de errores!

@jesbis Está bien, lo tengo.

Para WinForms, al usar la nueva plantilla de proyecto de WinUI, ¿seguirá funcionando la ventana de propiedades y podrá establecer las propiedades de los controles de WinUI? Puedo codificar HTML todo el día sin problema (Asp.net MVC generalmente), pero cuando hay tantas configuraciones disponibles para los controles, he disfrutado usando la ventana de propiedades durante los últimos 20 años.

@ Dean-NC Supongo que estás preguntando sobre el diseñador XAML, no WinFoms / Windows Forms, ¿verdad? Si es así, sí, el Panel de propiedades seguirá funcionando para los controles de WinUI cuando seleccione un elemento en el diseñador XAML.

@ marb2000 Supongo que pensé ingenuamente que WinUI 3 traería los nuevos controles a WinForms en el sentido de que sería en su mayoría sin problemas, y que podría tener un formulario con controles heredados y de WinUI, y que la ventana Propiedades funcionaría para controles heredados y WinUI.

Leí toda la publicación anterior y he estado siguiendo esto con mucho entusiasmo (como desarrollador de WinForms), pero supongo que he entendido mal el flujo de trabajo de alto nivel de cómo funcionará esto (nuevamente, desde el punto de vista de WinForms ).

He dicho durante mucho tiempo que WinForms aún podría ser una gran cosa en los próximos años, pero su mayor debilidad es que sus controles básicos parecen anticuados (el cuadro de texto no permite el relleno, por lo que se ve delgado, pequeño radio y botones de casilla de verificación , etc.). Solo los conceptos básicos de los controles de Win 10 (cuadro de texto, radio, casilla de verificación) contribuirían en gran medida a darle nueva vida a WinForms.
¿Hay algún artículo, o le importaría dar una breve descripción de cómo sería el flujo de trabajo para un nuevo proyecto de WinForms que quiera usar tanto los controles heredados como los nuevos?
Gracias.

@ marb2000 Supongo que pensé ingenuamente que WinUI 3 traería los nuevos controles a WinForms en el sentido de que sería en su mayoría sin problemas, y que podría tener un formulario con controles heredados y de WinUI, y que la ventana Propiedades funcionaría para controles heredados y WinUI.

Leí toda la publicación anterior y he estado siguiendo esto con mucho entusiasmo (como desarrollador de WinForms), pero supongo que he entendido mal el flujo de trabajo de alto nivel de cómo funcionará esto (nuevamente, desde el punto de vista de WinForms ).

He dicho durante mucho tiempo que WinForms aún podría ser una gran cosa en los próximos años, pero su mayor debilidad es que sus controles básicos parecen anticuados (el cuadro de texto no permite el relleno, por lo que se ve delgado, pequeño radio y botones de casilla de verificación , etc.). Solo los conceptos básicos de los controles de Win 10 (cuadro de texto, radio, casilla de verificación) contribuirían en gran medida a darle nueva vida a WinForms.
¿Hay algún artículo, o le importaría dar una breve descripción de cómo sería el flujo de trabajo para un nuevo proyecto de WinForms que quiera usar tanto los controles heredados como los nuevos?
Gracias.

Es más probable que pueda tomar el proyecto de su aplicación, agregar ventanas y páginas de WinUI y usar la interfaz de usuario XAML moderna para reemplazar su interfaz de usuario totalmente o poco a poco.

Y hay islas XAML para insertar XAML en las IU existentes de Winforms y WPF

Su equipo de Blazor debería trabajar con Uno para incluir algunos de sus modelos de alojamiento en Uno (en particular, el lado del servidor), y / o para obtener la capa visual / renderizadora de Uno UI (y por lo tanto WinUI 3) utilizable por Blazor ... y / o tal vez Islas Xaml para Blazor?

Me siento un poco fuera de lugar aquí porque la mayoría de los comentarios provienen de desarrolladores que trabajan principalmente en el espacio xaml. Por lo general, parecen estar buscando una mejor versión de lo que ya tienen. Eso podría ser bueno para los usuarios existentes, pero no sé si atraerá a muchos desarrolladores que han rechazado UWP hasta la fecha.

Mi equipo ha desarrollado solo una aplicación para UWP. No estaremos desarrollándonos más.

El obstáculo insuperable es la falta de un redactor de informes tabulado integrado. Hemos probado todos los redactores de informes de terceros del mercado que dicen que son compatibles con UWP. Desafortunadamente, ninguno de ellos funciona bien con UWP. Su oferta de UWP suele ser un truco rápido de su variante WPF / WinForms y no funcionará correctamente.

Usamos Stimulsoft Reports en nuestro producto UWP. Tiene muchos errores y nos han dicho que no corregirán los errores ya que su aceptación de UWP es muy baja.

Veo que tiene visualización de datos en la lista. Pero la razón por la que todavía hay millones de aplicaciones grises de acorazado es que a muchas empresas no les importan mucho las imágenes de las aplicaciones internas. Quieren columnas de números con subtotales.

Entonces, si WinUI está destinado a atraer finalmente los formularios a los desarrolladores de datos, entonces necesitamos un escritor de informes tabulados incorporado.

Espero que esto no ofenda a la gente visual :-)

Estoy totalmente de acuerdo. ¿Cómo podemos desarrollar aplicaciones comerciales modernas sin un sistema de informes que se pueda integrar fácilmente con la aplicación? es un cañón enorme que evitará que los desarrolladores se muevan.

Los usuarios comerciales deben poder interactuar con datos tabulados y luego imprimirlos o exportarlos a otros formatos. También necesitan poder crear facturas, cotizaciones, extractos y otros documentos instrumentales.

Tengo entendido que las empresas siguen siendo el mayor consumidor de Windows. ¿Por qué no se está desarrollando algo tan fundamental para el ecosistema de Windows para UWP?

¡Gracias por los comentarios @VagueGit y @Elmarcotoro ! Los controles empresariales son una brecha para nosotros en este momento. Pero su tiempo es bueno, estamos recopilando comentarios para el diseño de un control DataGrid. Lea y envíe sus comentarios aquí: # 1500.

Del mismo modo, además del control de datos tabulares cuadrados, necesitamos un control de gráficos UWP de código abierto para compartir de manera creativa y democratizada relaciones complejas a través del control de diagramas.

Para un sistema de informes, creo que Telerik UI es la mejor opción actualmente. Un proverbio chino que dice "Algunas personas se especializan en algunas profesiones mientras que otras en otras profesiones". Telerik, DevExpress u otra persona, son buenos para informar.

Por la falta de varios controles, no debemos culpar a este equipo, sino a toda la estrategia de MS. Desde el comienzo de Satya abandonaron el móvil, prefieren iOS y Android mejor, porque jefes como ellos. Todo el ecosistema de UWP se vuelve débil y débil.

Por ahora, hay un argumento llamado "UWP está muerto" en Twitter, creo que MS debería aclarar esto y declarar su camino hacia la uwp.

Por ahora, hay un argumento llamado "UWP está muerto" en Twitter, creo que MS debería aclarar esto y declarar su camino hacia la uwp.

Lo acaba de publicar en el hilo de la hoja de ruta ...

@jevansaks Gracias por la información sobre el control Datagrid. Esto no se ocupa de los problemas de impresión de informes y paginación, exportación y demás. Estos son escenarios de negocios de la vida real que deben abordarse, no si algún botón se anima (tan agradable y genial como esto puede ser).

@ hupo376787
"Para un sistema de informes, creo que Telerik UI es la mejor opción en la actualidad".

Por lo que puedo ver, Dev Express son los únicos que actualmente brindan una pila completa para crear y ver informes para UWP, y sus precios parecen estar en el lado premium. Todos los demás, incluido Telerik, tienen lagunas en sus herramientas, lo que significa que no se pueden crear informes para UWP. Estoy dispuesto (esperando) a que me corrijan en esto.

Para un sistema de informes, creo que Telerik UI es la mejor opción actualmente. Un proverbio chino que dice "Algunas personas se especializan en algunas profesiones mientras que otras en otras profesiones". Telerik, DevExpress u otra persona, son buenos para informar.

@ hupo376787 , tenga especial cuidado de verificar sus datos antes de dar a entender que una publicación es incorrecta. Telerik Reporting tiene un diseñador de informes para WPF y WinForms, pero no para UWP.

DevExpress también tiene un diseñador de informes para WinForms y WPF, pero no para UWP

Por lo tanto, compruebe sus datos antes de cometer un error que se conservará a perpetuidad y se difundirá ampliamente. Oye, parece que algún día podría ser un viejo proverbio 😉

@ hupo376787 , tenga especial cuidado de verificar sus datos antes de dar a entender que una publicación es incorrecta. Telerik Reporting tiene un diseñador de informes para WPF y WinForms, pero no para UWP.

DevExpress también tiene un diseñador de informes para WinForms y WPF, pero no para UWP

Por lo tanto, compruebe sus datos antes de cometer un error que se conservará a perpetuidad y se difundirá ampliamente. Oye, parece que algún día podría ser un viejo proverbio 😉

De acuerdo, creo que tenemos una comprensión diferente de los informes. Me refiero a https://www.telerik.com/universal-windows-platform-ui y https://www.devexpress.com/products/net/controls/win10apps/.

Me equivoqué, Dev Express no proporciona informes para UWP. ¡Parece que ningún desarrollador de herramientas de terceros lo hace! Me comuniqué con Dev Express a través de su chat para saber si tenían una hoja de ruta para proporcionar informes para UWP.
Ellos dijeron,
"XtraReports Suite utiliza la funcionalidad proporcionada por el conjunto System.Drawing y lo que nos impide implementar el mismo conjunto de herramientas para las aplicaciones de ventana universal es que este conjunto no está disponible allí (https://stackoverflow.com/questions / 31545389 / windows-universal-app-with-system-drawing-and-possible-Alternative). Por lo tanto, aún no hemos establecido nuestros planes futuros en esta área ".

@jevansaks , parece que hay una falta de comunicación entre el equipo de interfaz de usuario de Microsoft y estos proveedores de herramientas de terceros. Estaríamos encantados de utilizar herramientas de terceros, pero parece que la plataforma UWP dificulta que estas empresas integren las herramientas que tienen para otras plataformas en UWP.

Me pidieron que me pusiera en contacto con su [email protected] con nuestros requisitos de informes, puede ser útil para el equipo de Win UI 3.0 ponerse en contacto con ellos y ver si hay una forma de ayudarlos en la implementación. No veo cómo conseguirás desarrolladores de negocios en la plataforma universal sin las herramientas de informes adecuadas.

https://www.devexpress.com/subscriptions/reporting/

Informes: solo desde la perspectiva de WinForms, he usado tanto Telerik como DevExpress (incluso sus últimas versiones), y aunque Telerik era bueno, creo que DevExpress no solo tiene un mejor diseñador y experiencia en general, sino que tiene muchas más características sutiles que me permitió hacer diseños más complejos que Telerik. Creo que la tecnología de renderizado DevExpress es más avanzada.

Puede ser útil para el equipo de Win UI 3.0 ponerse en contacto con ellos y ver si hay una forma de ayudarlos en la implementación.

Gracias por la llamada. También nos comunicaremos con ellos.

Gracias por la llamada. También nos comunicaremos con ellos.

¿Puede valer la pena hablar con todos ellos y ver cuáles son los bloqueos? Telerik, Grapecity, DevExpress, etc.

Gracias por la llamada. También nos comunicaremos con ellos.

¿Puede valer la pena hablar con todos ellos y ver cuáles son los bloqueos? Telerik, Grapecity, DevExpress, etc.

Seguro, ese es nuestro plan.

Somos un poco diferentes a la mayoría de los desarrolladores que crean para Windows. Desarrollamos principalmente aplicaciones de kiosco (aplicaciones destinadas a ser ejecutadas por usuarios que no sean el propietario de la computadora, y generalmente en pantalla completa sin ningún acceso al sistema más amplio). Las aplicaciones generalmente se crean según los requisitos específicos del cliente, sin intención de distribuirlas a través de la tienda o equivalente.

Debido a que las aplicaciones se ejecutan en pantalla completa, hay un valor muy limitado en los controles integrados que mantienen la apariencia de otras aplicaciones de Windows; en cambio, tienden a tener una marca alta para cada cliente. Todavía necesitamos una gran cantidad de _comportamiento_ y controles comunes de las aplicaciones estándar de Windows, pero normalmente hacemos mucha personalización de las plantillas de control de cada una o al menos anulamos sus estilos principales. Durante mucho tiempo, creamos muchas aplicaciones como backends de WinForms con interfaces Flash integradas para la interfaz de usuario.

En términos generales, casi todas las aplicaciones que escribimos integran algún tipo de backend basado en la web con alguna pieza de hardware (por ejemplo, una impresora, un escáner de código de barras, un lector de banda magnética, un escáner RFID, una cámara, hardware de pago con tarjeta, pago en efectivo al estilo de las máquinas expendedoras). componentes, etc.), y la gran mayoría de esos componentes históricamente han venido con Win32 SDK y no con UWP.

Por esas dos razones, la mayoría de nuestras aplicaciones históricas son aplicaciones de WinForms, y la mayoría de nuestras aplicaciones modernas son de WPF. Hemos creado algunas aplicaciones para UWP (en gran parte para beneficiarnos de las capacidades realmente agradables del modo de acceso asignado / quiosco de Windows), pero normalmente es difícil trabajar en ellas en comparación con WPF y, de todos modos, no podemos obtener SDK de hardware compatibles. .

Sin embargo, estamos muy intrigados por las islas XAML, que nos permiten escribir aplicaciones compatibles con Win32 con una interfaz de usuario moderna (aunque la ventaja de UWP sobre WPF para nosotros no siempre es clara, especialmente si no estamos usando controles estándar o específicos de Microsoft efectos como Fluent, etc.).

Para responder a sus preguntas específicas:

¿Qué plantillas te interesarían más?

C # con .NET Core, Win32 con WinUI 3.0 superpuesto sería bueno.

¿Conocía las islas Xaml para modernizar las aplicaciones de escritorio?

Sí, y estuve relativamente contento con ellos cuando jugué con ellos, aunque no es probable que usemos un control _single_, tanto como para tomar una decisión para toda la interfaz de usuario personalizada.

La razón principal por la que lo sabía era porque obtendríamos soporte de Lottie para las aplicaciones Win32.

¿Esta compatibilidad con versiones anteriores ampliada en Windows 10 hace que Xaml Islands sea más útil para usted?

Realmente no; casi siempre controlamos las PC de destino y podemos asegurarnos de que siempre obtengamos la última versión compatible.

¿Sería útil que Visual Studio u otra herramienta actualizaran automáticamente los espacios de nombres por usted?

Si.

¿Qué importancia tiene para usted la compatibilidad total entre los componentes UWP Xaml existentes y las aplicaciones WinUI 3.0?

Muy mínimo. El principal dolor de cabeza de compatibilidad que tendríamos sería cambiar las claves de StaticResource para diseñar elementos centrales.

¿Crea o usa bibliotecas de control UWP Xaml o componentes WinRT que no podría volver a compilar y actualizar fácilmente junto con el código de la aplicación?

Sí, hemos utilizado la biblioteca de control Syncfusion UWP en el pasado.

¿Cuál sería su solución preferida para usar componentes UWP Xaml con WinUI 3?

La solución preferida sería tener más controles estándar disponibles en WinUI en lugar de apoyarse en fuentes externas (por ejemplo, visores de documentos), pero espero que esas bibliotecas de componentes externos sean más progresivas en la actualización de sus bibliotecas de lo que seríamos al cambiar a WinUI 3 de todos modos en su mayor parte.

¿Qué opinas del plan general 3.0 descrito anteriormente y en la hoja de ruta? ¿Le permitiría usar WinUI para sus aplicaciones de Windows nuevas y existentes?

Estoy emocionado de ver que los controles de UWP están más claramente desacoplados de la aplicación de UWP y el modelo de seguridad que históricamente nos ha bloqueado debido a razones de compatibilidad de hardware, especialmente porque WinUI se está diseñando y desarrollando al aire libre.

Con una orientación tan clara sobre cómo Microsoft nos recomienda crear interfaces de usuario de aplicaciones, esperaría que todas nuestras aplicaciones terminen con interfaces de WinUI, independientemente del backend que podamos admitir.

¿Para qué tipo de aplicaciones estaría más emocionado de usar WinUI 3.0? ¿Crear una nueva aplicación Win32 y empaquetarla con MSIX? ¿Agregar nuevas vistas a una aplicación WPF? ¿Modernizar una aplicación C ++ MFC con Fluent UI?

Principalmente acerca de obtener acceso a bibliotecas de controles mantenidas de manera más activa en mis aplicaciones más antiguas, con documentación más agradable y obvia (o incluso acceso al código subyacente para el control estándar) hace que sea mucho más fácil averiguar cuándo puedo adaptar un control estándar y cuando necesito rodar mi propio control de usuario. Por ejemplo, en una aplicación reciente creada en WPF, tenía un par de selectores de fechas; conseguir que ese control funcione bien para el tacto y personalizar el tamaño, la fuente, el icono emergente, etc. fue extremadamente molesto. Me inclinaría a usar WinUI para ese tipo de aplicación por _default_ en el futuro dada la hoja de ruta anterior, porque:

1. Puedo estar razonablemente seguro de que existe un control de selector de fecha nativo que es al menos moderadamente amigable con el tacto
2. Puedo examinar las plantillas nativas / listas para usar de ese control, etc., fácilmente para ver lo que necesito anular para que coincida con las pruebas de diseño para la apariencia del cliente (como un ejemplo más o menos representativo, podría querer para encontrar la forma más limpia de diseñar el estilo del tipo (tamaño de fuente, peso, familia) del encabezado de un control TextBox independientemente de su texto de entrada; ¿el HeaderTemplate estándar usa recursos estáticos mágicos que puedo redefinir o necesito anular la plantilla en sí? Si anulo la plantilla, ¿cómo se ve el marcado de la plantilla predeterminada? ¿Hace / admite algo que no había considerado?).

Veo que esto se ha cerrado, pero hay un par de cuestiones que plantean nuestros usuarios y que creo que valdría la pena plantearlas. Son mejoras de productividad para los usuarios que trabajan con grandes cantidades de datos.

Caja de texto:
Si un usuario necesita editar un TextBox, primero tiene que hacer clic en TextBox para mostrar el botón de borrar y luego hacer clic en el botón de borrar para borrar el TextBox. Esto es muy ineficiente cuando se trabaja con grandes cantidades de datos. Sería bueno si cuando los usuarios hacen clic o tabulan en el TextBox, el texto se puede resaltar listo para ser escrito.

Vista de cuadrícula / Vista de lista:
Gridview y ListView no parecen permitir al usuario tabular eficazmente a través de la colección.
ListView permite que Tab se mueva a los controles de la misma fila, pero no pasará a la siguiente fila de controles. En su lugar, ListView pierde el foco y Tab se mueve al siguiente control en el árbol visual.

Estos son dos problemas planteados por nuestros usuarios como muy molestos.

@Elmarcotoro

Le recomiendo que cree un nuevo problema para cada una de las mejoras que mencionó. Luego, el equipo de WinUI realizará una clasificación para determinar si requerirán que se publique WinUI 3 antes de implementarlo o no.

Este problema existía principalmente para obtener comentarios sobre las 2 "Preguntas generales" en la parte superior de la publicación.

Admite el modelo de alojamiento Blazor nativo en WinUI. Esto permitiría utilizar un control Blazor directamente en la web Cliente / Servidor, o directamente en WinUI. La hoja de ruta de Blazor tiene este concepto futuro sin utilizar un control WebView. De esta manera, la interfaz de usuario del control se ejecuta de forma nativa con la parte .Net Standard del código que también se ejecuta de forma nativa.

Admite el modelo de alojamiento Blazor nativo en WinUI

Discutido en el lado Blazor, FWIW:
https://github.com/dotnet/aspnetcore/issues/11082

Seguro, ese es nuestro plan.

@jevansaks Sería genial participar también.

Me gustaría una mejor consistencia de los menús de bandeja / menús de iconos con WinUI 3.0. Cada aplicación tiene un espaciado diferente, y las aplicaciones Win32 no siguen la representación de la fuente / espaciado / temas de manera consistente. ¡Solucione esto ya!

WinUi en el escritorio es completamente inútil para mí debido a la falta de cualquier posibilidad de administración de ventanas: mostrar / ocultar ventanas, posición de las ventanas, tamaño de las ventanas, acoplar / desacoplar ...

@alexandrevk todavía es una vista previa. ¿Viste el diseño de la API de ventanas? https://github.com/microsoft/ProjectReunion/issues/157

¡Gracias @dotMorten por vincular a la publicación del anuncio de ventanas!

@alexandrevk : estamos reuniendo API para Reunion que le permitirán realizar este tipo de operaciones de ventanas desde Win32 y UWP con contenido de WinUI, así como cuando use otros marcos / contenido de cadena de intercambio en su ventana. Algunas de estas características de ventanas pueden luego abstraerse en la clase de ventana WinUI para facilitar el acceso también, pero eso está más adelante. Las especificaciones de las funciones para el área de ventanas están en proceso, estad atentos.

Hablando estrictamente como un usuario invidual (es decir, no corporativo / empresa) y solo c ++, incluso si solo soy una voz solitaria que grita al vacío, siento la necesidad de decir que siempre que cualquiera de estos nuevos sistemas de interfaz de usuario sea vinculado a UWP y ese horrible sistema de empaquetado en el que se construyen, entonces me temo que siempre estará en la oscuridad, hagas lo que hagas. (Hablando de la experiencia de WinRT, todavía no he probado WinUI pero me parece más o menos igual).
Seguramente se debe saber que muy poco o nadie usa aplicaciones para UWP. (en realidad odiado por la mayoría de los afaik) así que si va a ser llamado 'nativo' entonces por qué no es realmente 'nativo', es decir: algunos #incluyen, enlazar un .lib o dos y construir su aplicación en ESTÁNDAR c ++.
Tener que recurrir a cosas como Qt cuando el cross-plat no es un problema, solo para evitar envolver win32 por milésima vez se está volviendo un poco viejo para ser justos.
De todos modos solo mis 2 centavos, de alguien que usa el idioma todos los días, pero probablemente no tenga lugar para comentar aquí.

@ nl-n debería estar feliz de saber que uno de los grandes acuerdos con WinUI es que no requiere ejecutarse como una aplicación para UWP. De hecho, esto ha sido posible desde la versión preliminar 2.
_Actualmente_ requiere empaquetado como msix, pero msix es en realidad una forma bastante decente de distribuir (y actualizar) sus aplicaciones.

@dotMorten Ese es uno de los grandes problemas: requerir carga lateral / instalación a través de la tienda. No conozco a una sola persona que no deshabilite / elimine la tienda antes (o justo después) de instalar Windows, entonces, ¿cómo se supone que las distribuiremos?
Sé que eso es algo retórico, pero sirve al punto. Debería poder comprimir el directorio de compilación y distribuirlo (o un instalador si se justifica).
Luego está el problema de compatibilidad, muchas personas todavía se niegan a instalar W10, así que también está eso ...
Sin embargo, es bueno escuchar que esa es la dirección en la que se dirige 3.0, por mucho que odie xaml, sería una adición bienvenida.
¿Quizás podríamos obtenerlo sin necesidad de instalar toda la carga de trabajo de UWP de 50 GB en VS también? 🙏 (exagerando lo sé, pero aún así)

Para citar @MarkIngramUK cerca del comienzo de este hilo:

Es 2019, quiero una interfaz de usuario nativa y rápida, y no quiero tener que considerar seriamente hacer una interfaz de usuario con CreateWindowExW , GDI, etc.

lo cual (curiosamente) literalmente tengo que hacer ahora mismo, y sí, es tan doloroso como suena :)

@ nl-n, ¿quién dijo algo sobre la tienda? MSIX no es realmente diferente de instalar desde MSI. Es solo un instalador de aplicaciones. Haga doble clic en él para instalar. No se necesita tienda. También garantiza una desinstalación 100% limpia (a diferencia de MSI, que hace un desastre gigante)

No conozco a una sola persona que no deshabilite / desmantele la tienda

Sin embargo, no es común.

¿Cómo se supone que los distribuiremos?

En primer lugar, debe informar a los usuarios que no deshabiliten la tienda)

Debería poder comprimir el directorio de compilación y distribuirlo

MSIX se puede instalar sin tienda. Con las últimas versiones de Windows, el usuario no necesita habilitar nada para eso. Por supuesto, si el paquete se firmó antes con un certificado de confianza. Pero sí, si el usuario eliminó la tienda de la PC, también podría eliminar MSIX / APPX AppInstaller. En ese caso, probablemente no quieran toda la variabilidad de las aplicaciones.

mucha gente todavía se niega a instalar W10,

Es su elección. Dijo Nuff.

carga de trabajo completa de 50 GB para UWP en VS también

El SDK único tiene aproximadamente 3 GB. No es necesario descargar todos a partir de 10240 uno.

@ nl-n, ¿quién dijo algo sobre la tienda? MSIX no es realmente diferente de instalar desde MSI. Es solo un instalador de aplicaciones. Haga doble clic en él para instalar. No se necesita tienda. También garantiza una desinstalación 100% limpia (a diferencia de MSI, que hace un desastre gigante)

Eso fue de la descripción que visual studio le da, 'para descarga / instalación a través de la tienda de microsoft', la única otra información que he encontrado en msix es de msdn, que básicamente dice: los paquetes de msix son aplicaciones 'appx' en espacio aislado / virtualizadas , que es prácticamente un asesino para cualquier cosa que trabaje directamente con el winapi. ¿Y requieren firma para ser instalable? ...

Supongo que también podrían ser cables cruzados, demasiada temática diferente, y no sé mucho sobre UWP.

Sin embargo, no es común.

Más común de lo que piensas, y con razón 😄

De todos modos, no era mi intención descarrilar, así que volveré a escribir mis cosas de CreateWindowExW por ahora 🤣