Maui: Experiencia de usuario multiplataforma para .NET 5

Me gusta esta idea. Sin embargo, en la práctica, es algo que es más probable que lo maneje el equipo de Xamarin.Forms.
Tal vez, el equipo Core contribuiría con algunas construcciones de bajo nivel para hacer que el marco UX sea "mejor" (como lo que hace CoreFxLab).

Editar: ¿Podría WebAssembly convertirse también en una plataforma compatible?

Me gusta la idea. He visto personas (incluyéndome a mí) sufriendo con múltiples tecnologías de interfaz de usuario para múltiples entornos.

Estoy bastante seguro de que en un futuro previsible veremos .net core portado a dispositivos Android e iOS utilizando la aplicación nativa como reemplazo de corehost . Dicho esto, se requerirán capacidades de interfaz de usuario.

Para las bibliotecas de dibujo 2D xplat (incluido el dibujo acelerado), tenemos Skia, por ejemplo.

En todos los escenarios, creo que XAML-Standard será una buena opción para lograr una forma estándar de "describir" la interfaz de usuario junto con las pautas de Fluent Design.

Sin embargo, soy escéptico de que haya planes de .Net Team para invertir tiempo en algo más que traer de vuelta algunas primitivas xplat System.Drawing.X ...

@4creators Quizás esta discusión sea de su interés

@ vibeeshan025 WebAssembly no es un reemplazo de JavaScript, por lo que la mayoría de sus comentarios no tienen ningún sentido. Seguirá necesitando JavaScript para conectar un WebAssembly con el DOM. Entonces, no, no puede simplemente compilar algo en wasm y esperar que reemplace lo que haya hecho antes con JavaScript. Así no es cómo funciona. No será una tecnología de interfaz de usuario.

Hola chicos, solo quiero poner mi 5c aquí.
System.Drawing.X es esencial para el desarrollo de .NET Core. (Acabo de llegar aquí desde https://github.com/dotnet/corefx/issues/20325)

A partir de la interfaz de usuario: pregunte a los desarrolladores web (front-end). Usan muchos trucos modernos como la recarga en caliente.
Personalmente, me gusta cómo están progresando las cosas en torno a React/ReactNative. Sería genial usar C# para escribir React y luego usar varios motores de renderizado para diferentes plataformas.

FWIW, Mono está adoptando WebAssembly , por lo que si funciona en Mono, funciona (o funcionará) en WebAssembly. Esa es la idea/comprensión actual, al menos.

Además, tengo que repetir el sentimiento sobre la probabilidad de que .NET/MSFT realice esta tarea. Todo su enfoque/coeficiente intelectual se ha colocado en core/internals/framework/just-get-it-working y creo que seguirá siendo así durante un año más o menos. Pero quién sabe, podría estar (gratamente) sorprendido.

Mi opinión sobre esto es que algún esfuerzo externo va a ganar impulso y tal vez MSFT, ala Xamarin, lo compre, pero más centrado en la interfaz de usuario (a diferencia del marco/herramientas, que es la fuerza central de Xamarin en mi opinión). Así, algo como Avalonia o Noesis , que ofrecen su propuesta de valor a través de canales open source y de pago, respectivamente. Por cierto, ambos están integrados/soportan Mono.

El estándar Xaml se ha movido un poco con el lanzamiento del estándar XAML (versión preliminar) para Xamarin.Forms y la actualización sobre el progreso del proyecto que se esperaba desde hace mucho tiempo. Hay una discusión muy interesante en PR dotnet/designs#111 sobre los objetivos del proyecto que parece ir en dirección a beneficiar esta propuesta.

Silverilght es una gran solución, el código ya existe

1. Código de Silverlight de fuente abierta
2. Hacer que se ejecute sobre el tiempo de ejecución de dotnet core
3. use moonlight para la distribución de linux
4. cree una alternativa de dotnet core para "Electron" que le dará la bienvenida al mundo (menos uso de memoria + gran mejora del rendimiento + bondad xaml)
5. compilación nativa (si algún día el proyecto corert ve la luz)

Lo encontré relevante- http://platform.uno

@gulshan Interesante, gran proyecto, ¿es compatible con la mayor parte de la función UWP? ¿Cómo pudieron implementar un conjunto tan rico de características en muy poco tiempo con solo 4 colaboradores?

@ vibeeshan025 tienen una empresa que lo financia IIRC...

Otro futuro que vale la pena explorar: HTML/CSS + .net (en lugar de JS/TS). Ya está siendo juzgado aquí-
https://github.com/SteveSandersonMS/BlazorElectronExperiment.Sample

Después de investigar, parece que tcl/tk podría ser una opción de interfaz gráfica de usuario para todas las plataformas. No estoy seguro de si tcl/tk cuando está en Windows invoca las cosas reales de gdiplus, pero podría ser una opción para traer WPF y Winforms a Linux, Mac, Windows, Android?, iOS?, ¿y tal vez formularios web? No estoy seguro si tcl/tk es compatible con esos 3 últimos todavía. Si lo hace, hace que la GUI sea mucho más fácil de mantener con una sola base de código.

Posibles bibliotecas GUI para usar:

• TclBridge (no parece ser gratuito ni de código abierto)
• el Mono (probablemente el mejor tal vez)
• Eagle (no estoy seguro de lo bueno que es)
• Tal vez otros también.

Tuve la idea de usar tcl/tk del módulo tkinner de cpython.

Tampoco estoy seguro de si .NET Core admite la carga de recursos desde * .resources (resx compilado) o incluso desde * .resx todavía. Si lo hace sería genial.

Microsoft.DesktopUI.App actualmente v3.0.0-alpha-26921-3 está disponible con compilaciones diarias de Windows .NET Core SDK . Tengo curiosidad por saber qué se necesitaría para ponerlo en funcionamiento en Linux bajo algunas capas de traducción para GDC y DirectX.

Necesita mucho más que UX multiplataforma, debe ser un marco de desarrollo de aplicaciones multiplataforma.
Limitarlo solo a la UX es un error. Como mínimo, debería tener toda la funcionalidad de SilverLight + RIA-Services.
Cuando escribe enormes sistemas personalizados para empresas más grandes que vivirán durante décadas, debe mantener abiertas todas las opciones ya que no tiene idea de qué requisitos se agregarán en un año (o en 10 años), por lo que un entorno cerrado y limitado como UWP nunca se considerará, lo mismo con algo que se ejecuta dentro de un navegador. Tiene que haber acceso completo, ilimitado y nativo a cada función, API y servicio en las diferentes plataformas.
Y cuando desarrolla un sistema en el que escribe tanto el servidor como el cliente, entonces no quiere usar REST o algo así (que está destinado a usarse cuando escribe el servidor y alguien más escribe el cliente), en su lugar, debe estar en el espíritu de RIA, donde define la API del servidor y luego automáticamente simplemente la llama desde el cliente usando las mismas (===) clases y métodos que los del servidor. Todo debe estar fuertemente tipeado. La validación de datos comienza con los límites estrictos obtenidos de los campos en el servidor SQL (o cualquier fuente de datos que esté utilizando) y se extiende por DataAnnotations, que se propagan hasta el cliente automáticamente (teniendo en cuenta la localización).

Esto es lo que se necesita, nada menos es aceptable:
Crear un modelo de desarrollo de aplicaciones de cliente .NET ubicuo

Han pasado 20 años desde que se lanzó Visual Basic 6 y no estamos ni cerca de la productividad que teníamos entonces en 1998.Microsoft necesita presentar su visión sobre cómo se debe hacer un sistema personalizado más grande en un "mundo de Microsoft" y cómo recuperarán la productividad que teníamos hace 20 años.

Microsoft necesita organizarse y dar un paso al frente y aceptar la responsabilidad que tienen. Microsoft debe darse cuenta de que todos sus clientes, socios y desarrolladores que han invertido mucho en tecnología MS durante décadas están profundamente decepcionados y su confianza en MS es muy baja. MS necesita comenzar a respetar a sus clientes, socios y desarrolladores y reconstruir su reputación y respeto, pero viendo lo que ahora están haciendo con Skype y cómo tratan a sus clientes y usuarios de Skype, tengo pocas esperanzas de que esto suceda.

Y olvídese de Xamarin, Microsoft ni siquiera lo usa ellos mismos , y prefiere optar por un marco de memoria de un solo subproceso como el marco ElectronJS (basado en Chromium, Node.js, JavaScript y CSS), que usar Xamarin, que poseen y tener control total y que produciría código nativo real para cada plataforma.

@Bartolomeus-649

Han pasado 20 años desde que se lanzó Visual Basic 6 y no estamos ni cerca de la productividad que teníamos entonces en 1998.

Y la difusión del uso de computadoras e Internet, así como la diversidad de plataformas (SO / movilidad / factores de forma) no es tan baja como en 1998.

Lo que siento que estás pidiendo es "alguien que resuelva todos tus problemas". Las razones por las que existe esta diversidad son múltiples, o todos estaríamos usando el mismo dispositivo con el mismo sistema operativo. Construir una "abstracción sobre todo" es difícil y, por lo general, solo le brinda el conjunto de características más pequeño posible. Xamarin sigue teniendo el mejor enfoque aquí, lo que le permite usar API específicas de la plataforma siempre que sea posible. Pero incluso las buenas abstracciones para aplicaciones móviles pueden no ser útiles para aplicaciones de escritorio de alta productividad.

En cuanto a los otros puntos que está planteando, creo que en su mayoría son opiniones u observaciones personales que se aplican a su trabajo específico y no declaraciones de aplicación general.

Espero que obtengamos mejores experiencias multiplataforma, pero no creo que vaya a ser fácil o que resista la prueba del tiempo. Incluso si WebAssembly y los shells tipo Electron, PWA y amigos evolucionan hacia la solución de referencia en los próximos 5 años, es posible que estemos haciendo algo completamente diferente en 20 años (y luego nos quejamos de lo fáciles que fueron las cosas en 2018 😂 ).

Microsoft ha estado a la altura de nuestras expectativas y marcos UX de código abierto. Ahora podemos iniciar proyectos comunitarios para trasladarlos a otras plataformas. Desafortunadamente, MSFT ha declarado explícitamente que no planea trabajar en ningún puerto, por lo que parece que este trabajo se deja a la comunidad.

@richlander @karelz @AdamYoblick @llongley @kmahone

Mi pregunta es si nosotros, la comunidad, podríamos trabajar en puertos de Linux y macOS dentro de los repositorios existentes, es decir, en sucursales separadas, ¿o deberíamos crear repositorios separados para respaldar dichos proyectos? Esta es una decisión muy importante ya que el uso de repositorios existentes nos permitiría integrar puertos con la infraestructura MSFT CI que, de lo contrario, la comunidad tendría que configurar desde cero.

¿Hay alguna razón por la que Xamarin.Forms/Avalonia/Platform.Uno no se adapte a sus necesidades? Parece que un nuevo intento de traer XAML multiplataforma aporta poco valor a la comunidad en su conjunto.

No 4creators, sino mis 2¢/impresiones:

• Xamarin.Forms parece centrarse principalmente en escenarios móviles.
• Lo mismo para Platform.Uno
• Avalonia aún no está lista para el horario de máxima audiencia. Demasiado buggy para mí como para querer confiar en él. (La última vez que fui a verificarlo, la aplicación de demostración ni siquiera se integraría en la versión estable actual, no inspira confianza exactamente).

No estoy diciendo que un puerto multiplataforma de WPF o Winforms sea la solución aquí. (Un puerto multiplataforma compatible con API de Winforms ni siquiera es una gran idea en primer lugar, en mi opinión. Sin comentarios sobre WPF). Sin embargo, tampoco creo que las soluciones existentes sean adecuadas para el desarrollo de aplicaciones de escritorio.

Buenos puntos. Aún así, deberíamos centrarnos en mejorar las soluciones existentes en lugar de construir otra, que cuesta mucho más que la primera.

Por cierto, ¿algún problema con NoesisGUI?

la comunidad podría funcionar en puertos Linux y macOS

@4creators Cree bifurcaciones de su propiedad y sobre las que tenga control total.

infraestructura de CI

La infraestructura de .NET Core CI se está moviendo hacia el uso de Azure DevOps regular en lugar de la actual solución personalizada basada en Jenkins. Azure DevOps tiene una oferta gratuita para proyectos de código abierto que puede aprovechar.

Hablando solo para dotnet/winforms:

Winforms ya usa AzureDevOps, y cualquier PR en maestro ejecutará la compilación PR CI automáticamente.

Sin embargo, estoy bastante seguro de que cualquier trabajo debe hacerse en un tenedor. No planeamos otorgar acceso de escritura a dotnet/winforms solo para que las personas puedan crear sus propias sucursales. Con todas las contribuciones públicas, eso contaminaría bastante nuestro repositorio. :)

Por cierto, ¿algún problema con NoesisGUI?

De alguna manera, NeosisGUI se salvó de mis notas que guardo en varios marcos de interfaz de usuario, por lo que tuve que volver a mirarlo.

No lo he usado, aunque he tenido la intención de probarlo. Mi impresión es que está diseñado para admitir la interfaz de usuario del juego, por lo que podría no ser adecuado para las herramientas. (Aunque mirando la lista de controles, esto podría ser una mala suposición). Para la interfaz de usuario del juego, nuestras necesidades no justifican el costo futuro. Tampoco es compatible con Nintendo Switch por el motivo que sea. (Aunque aparentemente es un trabajo en progreso ).

@ 4creators Creo que este problema tiene un título incorrecto debido a la confusión de dos problemas.

Primero, permitir que los marcos de interfaz de usuario de .Net usen .Net Core en lugar de otros tiempos de ejecución de .Net . WPF puede ejecutarse en .Net Core ahora y podrían hacer que Xamarin.iOS/Android/Mac/GTK también se ejecute en .Net Core. Esto tiene beneficios de rendimiento y mantenimiento en comparación con el uso de Mono o .Net Framework.

Sin embargo, hacerlo no crea un nuevo marco de interfaz de usuario multiplataforma . Y los hilos a los que hace referencia y la mayoría de las publicaciones aquí tratan sobre la creación de un nuevo marco de interfaz de usuario multiplataforma. El tiempo de ejecución no es el problema principal aquí. Sin embargo, estos subprocesos son extremadamente confusos porque no abordan las dificultades reales de implementar la interfaz de usuario multiplataforma, que las implementaciones reales (Xamarin.Forms en gran medida usan controles nativos y Avalonia usa representación común) han abordado.

Es mejor trabajar para mejorar las capacidades de escritorio de Xamarin.Forms agregando los controles de escritorio relevantes (no es difícil) o contribuir a que Avalonia sea estable, si lo prefiere. Cualquier plataforma nueva (incluso si se basa en una plataforma única existente) llevará años de trabajo para llegar a la calidad alfa, y la única justificación para rehacer Xamarin.Forms y Avalonia en lugar de contribuir a ellos es que ambos lo están haciendo. incorrecto.

Estoy de acuerdo en la última parte. Sin embargo, el equipo de Xamarin ha dicho explícitamente que reemplazar Mono con .NET Core no es factible, ya que están optimizados para diferentes cargas de trabajo y será necesario realizar un trabajo de integración significativo y no trivial.

Creo que este tema está mal titulado, debido a la confusión de dos temas.

@charlesroddie En mi opinión , no realmente. El punto no es tener algún marco UX disponible en la plataforma .NET Core, sino The UX, que es una parte del ecosistema DotNet creado y mantenido en conjunto con otras partes. Los planes futuros de MSFT para el ecosistema .NET se basan en .NET Core con .NET Framework en desuso por ser un componente heredado de Windows que no se recomienda para el desarrollo de nuevas aplicaciones. Actualmente no hay planes para migrar Xamarin.Forms a .NET Core con algunos de los motivos indicados anteriormente por @Happypig375 y el otro motivo es la falta de decisión sobre cómo proceder con la compatibilidad con xplat en dispositivos móviles. Sin embargo, asumo que debido al esfuerzo de desarrollo invertido en .NET Core, la futura plataforma xplat utilizada por MSFT estará basada en .NET Core.

Mono no está lo suficientemente optimizado para muchas cargas de trabajo, incluso en Linux, y ya no se han desarrollado nuevas funciones importantes además de ese tiempo de ejecución. BCL se comparte actualmente entre Mono y .NET Core. Esto apunta a una alta probabilidad de desaprobación de Mono en el futuro.

Según estas suposiciones, creo que vale la pena tener una única plataforma UX basada en .NET Core como parte de su ecosistema. Por lo tanto, el título del problema es exactamente como debería ser, ya que no solicito un marco UX que sea xplat y esté basado en el estándar CLI, sino un marco UX que es parte del ecosistema .NET Core diseñado y respaldado por el equipo de DotNet.

.Net Standard garantiza que los diferentes tiempos de ejecución de la interfaz de usuario puedan formar parte del mismo ecosistema sin problemas. Aunque .Net Core tiene ventajas sobre otros tiempos de ejecución, que eventualmente pueden depreciarse, no es necesario vincular el tiempo de ejecución con encontrar el enfoque correcto para la interfaz de usuario multiplataforma. Simplemente complica demasiado la pregunta.

Es ir demasiado lejos decir que una plataforma UX está "basada en" un tiempo de ejecución particular. @ Happypig375 Actualmente no está en los planes de Xamarin cambiar a .Net Core (los planes son, en cambio, permitir que Mono se vuelva más similar a .Net Core compartiendo código). Pero no debería ser más difícil que mover WPF a .Net Core.

(Por cierto, no es cierto que Mono no tenga características nuevas, ya que se está actualizando para admitir .Net Standard 2.1, y el trabajo actual en webassembly se está realizando en Mono en lugar de .Net Core. Pero eso es aparte, ya que este trabajo se puede portar a .Net Core).

Hoja de ruta de WinUI 3.0: ¡necesitamos su opinión!

Parece que esta propuesta de desarrollo podría abrir nuevas posibilidades de xplat una vez que todos los componentes necesarios sean de código abierto.

Deberían considerar llamarlo MicrosoftUI 1.0 si ese es el caso, @4creators. 😆

> * https://github.com/Microsoft/microsoft-ui-xam
-------------------------------------------------^ missing l

Creo que este problema se aborda en este repositorio.