Microsoft avanza en la conversión de WinUI, el framework de UI de Windows 11, a código abierto
(neowin.net)- Microsoft anunció un plan por fases para convertir a código abierto WinUI, el framework de interfaz de usuario de Windows 11.
- WinUI no puede abrirse de inmediato por su estructura compleja y gran cantidad de código propietario, por lo que será necesario separar las partes compartibles de las que no lo son.
- La apertura a código abierto se realizará en cuatro etapas:
- 1ª etapa: Aumento de la frecuencia de mirror: después del lanzamiento de WASDK 1.8 (a finales de agosto), se sincronizarán con mayor frecuencia los commits internos con GitHub para compartir transparencia y progreso del desarrollo.
- 2ª etapa: Compilación local de desarrolladores externos: los desarrolladores externos podrán clonar el código y compilarlo localmente, y también se proporcionará documentación de configuración y dependencias.
- 3ª etapa: Contribución y pruebas externas: se habilitará que los colaboradores de la comunidad envíen Pull Requests y ejecuten pruebas locales, además de liberar la infraestructura de pruebas y ordenar las dependencias internas.
- 4ª etapa: Cambio a un sistema de desarrollo centrado en GitHub: finalmente, GitHub será el centro de desarrollo principal, gestión de issues y comunicación con la comunidad, y el sistema interno de mirror se eliminará de manera gradual.
- La hoja de ruta de código abierto de WinUI se mantiene públicamente en el tablero del proyecto de GitHub.
- Desarrolladores y usuarios pueden contribuir al avance de WinUI mediante feedback, redacción clara de issues y votos sobre ideas existentes.
3 comentarios
Ni COM ni WebView me gustan... Ojalá hubiera una GUI que sirviera de verdad.
De las interfaces de usuario de Windows que he probado hasta ahora, la que más me gustó fue Qt4. Desde Qt5, la sensación cambió bastante.
La verdad es que no recuerdo que MFC fuera especialmente malo... jajaja.
Opinión de Hacker News
Me preocupa el futuro de la tecnología de interfaz de usuario nativa de Windows. Los desarrolladores de sistemas operativos, por lo general, hacían aplicaciones nativas que funcionaban bien y de forma consistente en el propio producto que usaban. Pero en Windows 11 ocurrió lo contrario. Desde Windows 10 había al menos una app de correo y calendario integrada que funcionaba bien, pero en la última actualización de Windows 11 esas apps desaparecieron y se reemplazaron por un wrapper de WebView lento que tarda segundos en ejecutarse.
Si uno mira una community call de WinUI, parece que la mayoría de los recién llegados no tiene experiencia en Windows, y la gerencia tampoco se preocupa por eso, así que nadie domina los fundamentos. Son preguntas que cualquier desarrollador de Windows debería saber responder, y aun así no responden y se ve que ni siquiera entienden por qué se hizo esa pregunta. Por esa razón, en Windows 11 aparecen por todo lados instancias de WebView2 desbordándose.
En los problemas de la UI de Windows 11 se siente que se está poniendo demasiado foco en apps y funciones nuevas, y no se actualizan las herramientas antiguas. Por ejemplo, el Panel de control sigue casi con el mismo skin desde Windows 7. Si profundizas, aparecen herramientas viejas escondidas en los rincones, como un meme de pegar un clip a Homer Simpson. Por fuera parece novedoso, pero al usarlo sus límites se ven rápido.
Me da la sensación de que en algún momento podrían reescribir MSO (Office) totalmente con tecnologías como Dart y WASM. En una forma completamente independiente del toolkit nativo, podrían reproducir todas las funciones de Excel y volverlo accesible en cualquier parte como parte de un plan premium de O365. Al final podría terminar transformándose en algo tipo ChromeOS, donde solo se necesita UI nativa ligera para lugares como la pantalla de bloqueo o inicio de sesión y lo demás se maneja de forma liviana.
Si entiendes las luchas de poder y la política interna de Microsoft, puedes entender por qué pasa esto. Los departamentos compiten entre sí por tener ventaja.
Windows se siente como una mezcla de al menos 10 frameworks de UI distintos. Windows 11 da sensación de estar recorriendo un museo natural. Hay apps que quedan completamente con diseño de la época de Windows 2000 como si fueran de MSC, y también hay UI tosca y de colores intensos influenciada por el estilo Metro. El estilo moderno de Win11 puede verse bien, pero en realidad parece como ponerle labial a un cerdo. El menú contextual del clic derecho es un ejemplo típico: se ve lindo, pero le faltan funciones y tienes que pulsar Ver más para ver más opciones del estilo anterior. En conjunto, está todo revuelto.
No se percibe genuinidad en anuncios tipo 'alineación con los objetivos de Microsoft' o 'asignar recursos con prudencia'. Al final parece una política de sacar el framework afuera y retirar recursos esperando que desarrolladores externos, llenos de entusiasmo, se esfuercen en el mantenimiento.
La expresión 'perdedores apasionados' es demasiado negativa. Aunque esté de acuerdo con no interesarme en la UI de Win11 o con una visión cínica de que esta apertura sea solo para reducir costos, quiero mostrar respeto a quienes intentan seguir con este trabajo.
En pocas palabras, esto suena al discurso corporativo de 'sin soporte garantizado, sin plan de actualizaciones más allá de bugs de seguridad, utilicenlo como puedan'.
Me dan ganas de bromear y decir: '¿cuándo sale Apache Windows?' Hablando en serio, el toolkit de UI de escritorio ya no es ni ventaja competitiva ni barrera de entrada. En Windows solo hay 3 o 4 estilos diferentes distribuidos oficialmente. Pero la seguridad y estabilidad siguen siendo elementos imprescindibles para que Windows sobreviva en empresas, finanzas y sector público.
Entiendo cuando una empresa abre su framework de UI. Por ejemplo, los frameworks de Atlassian o AWS, al usarse en Jira/AWS, tienen sentido para probar en B2B SaaS. Pero con este framework no sé por qué habría que usarlo. Si no es para hacer solo apps nativas de Windows, creo que ya hay mejores opciones.
Creo que WinUI es un fracaso.
En la comunidad de desarrollo de Windows hay muy pocos que se preocupen por WinUI; los que quedan atrapados son básicamente quienes ya invirtieron en WinRT/UWP y no pueden salir. Desde Windows 8 se rompieron demasiados puentes y se perdió la confianza de la comunidad. En la práctica, parece que Microsoft más bien quiere pasar el problema a la comunidad que corregirlo.
Si empresas como DevExpress o Progress Telerik tampoco invierten en desarrollar controles WinUI por su cuenta, eso también es señal de que no creen en el futuro de WinUI. En este momento, para apps empresariales solo WinForms y WPF son alternativas realistas. En serio, no he visto una app hecha con WinUI3 que se use en producción.
Francamente, quién se tomará en serio ahora cualquier framework de UI de Microsoft. Los frameworks en los que ya se trabajaba siempre quedaron a medias y se abandonaron en ese estado, luego la atención pasa al framework nuevo y brillante del momento, y todo termina olvidado. En cambio, los frameworks open source multiplataforma suelen estar mucho más completos en fundamentos y funcionalidad, y su mantenimiento también es mejor. Este WinUI de todos modos terminará siendo otro caso más de UWP ignorado y dejado de lado.
Ya es difícil contar cuántos frameworks de UI hay en Windows; se siente demasiado confuso. No está claro qué se espera de abrirlo como código abierto. Me pregunto si es solo por imagen de estar abierto o si realmente hay beneficios reales para los desarrolladores orientados a Windows.
WinUI es una versión evolucionada de UWP, y UWP en sí es una evolución de WinRT. La intención de WinUI es clara y es una tecnología que ha madurado durante mucho tiempo (ahora en versión WinUI 3). MAUI es más para cross-platform que un competidor directo. Aun así, sin reestructurar todo el OS, especialmente las herramientas de administración, con WinUI, no hay una forma fácil de ganar confianza a largo plazo.
Con la cantidad de siglas y explicaciones de antes, al principio pensé que era sátira. WinUI, UWP, WinRT, XAML, Avalon, WPF, Project Reunion, Win2D, MFC, wxWidgets, Qt, etc. Hay demasiadas versiones y nombres de frameworks mezclados, y solo con explicarlos ya se vuelve largo y confuso.
Quizá Microsoft, como siempre, está enfocándose en la tendencia nueva (¡ahora la IA!) y buscando una forma de retirar tecnologías antiguas sin que haya mucha oposición. Lo más probable es que quienes se oponen sean solo una minoría.
En realidad, en Windows hay tres frameworks de UI y solo dos están vivos de verdad. Los demás no son más que la evolución repetida de las dos líneas Win32/nativo y WPF/Managed. WinUI3 nació para cubrir ese hueco.
A largo plazo, MFC sigue siendo la opción más probable de sobrevivir más tiempo. Hoy no hay actualizaciones, pero creo que vivirá sin problema otros 20 años.
Ojalá Microsoft hubiera seguido evolucionando WPF. Lo he usado durante mucho tiempo en proyectos diversos, y aunque tenga curva de aprendizaje, Data Binding, ViewModel y XAML todavía se sienten satisfactorios. Sin embargo, para que WPF sea ideal haría falta mejorar algunas cosas. Probé frameworks nuevos de Microsoft y open source (Avalonia, Uno, etc.) recientemente, pero algunos no corren ni en muestras o el estilo de desarrollo no encaja. Al final termino volviendo al WPF familiar. La mayor idea de mejora para WPF es crear el sistema de Data Binding mediante generación de código en tiempo de compilación de .NET en vez de Reflection en runtime. Con este enfoque sí sería posible un build AOT real y el rendimiento mejoraría drásticamente, además de muchos beneficios como tipado de tipos de XAML, soporte cross-platform, etc. Intenté hacerlo en open source yo mismo, pero no había tiempo y había demasiadas tareas.
Lo del segundo párrafo encaja exactamente con Avalonia. Avalonia ya soporta AOT, errores de binding en tiempo de compilación y capacidades cross-platform. Si no has visto una actualización en un tiempo, consulta Avalonia compile-time data binding docs y el proyecto XamlX.
Con este método también sería posible el trimming de ensamblados. Para un despliegue independiente hoy en día se agregan más de 200 MB de librerías .NET, pero con este método podría reducirse bastante.
Cuando evalué WinUI3 antes, la experiencia de desarrollo fue muy mala. Para depurar una app que quería desplegar, tenía que instalarla realmente en el sistema, y eso terminaban metiéndose muchos elementos inútiles en el menú Inicio y el registro se volvía un desastre. Incluso en el código de ejemplo, al hacer clic en un botón la app crasheaba de inmediato. Yo sigo haciendo apps de Windows con Win32+WTL.
Como mucha gente lo señaló, los frameworks de UI para Windows durante mucho tiempo no se han consolidado bien y solo se aumentó la confusión. Lamentablemente, el open source cross-platform también está igual. GTK también estuvo desordenado por un tiempo, y Qt tiene muchas funciones pero su sistema de licencias es demasiado pesado para uso profesional. (Durante la etapa de Nokia, la esperanza de MS con Elop, y luego el cambio de propietarios de Qt, etc., se desvanecieron). Hay soluciones decentes en ciertos campos, como Dear Imgui, pero en general casi no hay alternativas de frameworks de UI nativos o cross-platform con licencia permisiva, compilación nativa, buen set de widgets y soporte de renderizado 3D con Vulkan.
Me gustaría que en Windows 11 se volviera a agregar una barra de tareas vertical nativa. Esta función existía desde Windows 98, pero desapareció en el 11. Hay herramientas de terceros como Windhawk (forzar taskbar horizontal) o StartAllBack (recrear código de Windows 10), pero no son perfectas.
Hacer open source un framework de UI no expandirá las funciones de la barra de tareas. En este tipo de área, la contribución externa solo sería posible si se abre la propia barra de tareas, es decir explorer.exe, no el framework de UI.
Por cierto, la barra de tareas vertical estuvo como opción desde la época de Windows 95.
La función de barra de tareas pertenece a explorer.exe. El anuncio de open source que se discute ahora no tiene relación con explorer.
Dudo que el equipo de Windows esté construyendo con WinUI una UI de escritorio nativa de verdad.
Hoy el trabajo de UI para Windows se hace con Win32, GDI, DirectDraw, entre otros. Gracias a CsWin32 y al C# moderno (ref returns), la accesibilidad mejoró bastante frente a antes. Antes casi siempre había que armar un proyecto aparte en C++, pero ahora basta escribir en nativeMethods.txt las funciones necesarias y codegen se encarga. Win32 es definitivamente de nivel más bajo que otros frameworks de UI, pero al mismo tiempo Microsoft no lo puede tocar o descartar fácilmente. A largo plazo, no hay nada que haya sobrevivido con tanta estabilidad como esta API. La plataforma web tampoco se compara desde una visión de largo plazo.
Aún así, en muchas partes sigue siendo necesario C++. Es por la obstinación del equipo de Windows con COM. Windows Runtime Components fue la oportunidad para subir el nivel del ecosistema .NET, pero la dejaron pasar. Extensiones de shell, extensiones de menú contextual, etc., deben hacerse en C++ y para hacer eso desde .NET terminas creando stubs de C++ e invocando el proceso .NET.
Más que discutir frameworks de alto nivel, es más interesante hablar de APIs de bajo nivel. Sé que toda la pila de rendering de Windows está sobre GDI/DirectX y que Win32, al final, también está sobre GDI. Si se discute una pila de UI de Windows más cercana al metal, creo que tendría más sentido empezar desde DirectX.
Desde el punto de vista del usuario, Win32 también es suficientemente alto nivel. Hasta ahora, la única toolkit que dibuja bien botones, scrollbars, etc., es Win32.
Ojalá la comunidad construyera un framework realmente bueno para desarrollo nativo de Windows. Pero la realidad es que no hay escala comunitaria suficiente para hacerlo.
Lo que más extrañaba de la vieja UI de Windows era Que Microsoft ayudaba a crear apps que encajaran de forma natural como si las hubiera hecho directamente Microsoft. Después de introducir tecnologías web, la consistencia de la experiencia de UI de Windows se rompió mucho. El problema no es solo que Microsoft no modernizara las apps antiguas, sino que también los nuevos tools no daban librerías que siguieran la guía de estilo. Eso empezó a verse desde la época de Vista, y en MSDN también se redujeron poco a poco los ejemplos ricos del tipo 'así prueben esta función'.