¿Podemos hablar sobre la compatibilidad con tipos de datos que aceptan valores NULL en controles y valores predeterminados? Como ejemplo, hay DatePicker que devuelve DateTimeOffset y CalendarDatePicker que devuelve DateTimeOffset ?.

• ¿Por qué uno de estos es anulable y el otro no? ¿Esto se debe a que DatePicker se desarrolló utilizando API anteriores en el marco de tiempo de Windows 8?
• ¿Deberíamos considerar agregar una propiedad de configuración para permitir / no permitir nulos en los controles?
• ¿Debería considerarse una propiedad DefaultValue para nuevos controles como NumberBox, debería mantenerse NaN como predeterminado o deberíamos cambiar a un doble que acepta valores NULL con el valor nulo predeterminado?
• ¿Existen limitaciones de WinRT / OS XAML con la devolución y el soporte de valores anulables que evitarían que la propiedad Value NumberBox sea anulable? Si es así, ¿cómo se implementó CalendarDatePicker?
• Esto está directamente relacionado con las discusiones de NumberBox en # 1721 y # 1708

Además, ¿cuál es la hoja de ruta para solucionar los problemas abiertos en NumberBox que no dependen de WinUI 3.0? Sería genial comenzar a usar este control en WinUI 2.4 en lugar de tener que esperar más. En mi opinión, aún no está completamente horneado y me incomoda incluir esto en aplicaciones de producción.

Otra idea interesante para discutir sobre la que me he preguntado: ¿Cuál será la política de Microsoft sobre cambios importantes ahora que WinUI 3.0 se está convirtiendo en código abierto?

En el pasado, Microsoft prácticamente nunca ha realizado cambios importantes. Por lo general, esto es algo bueno hasta que todo el desorden se acumula después de algunos (o 10) años. Tampoco es el estándar para proyectos de código abierto. Por ejemplo, eventualmente ListBox debería eliminarse para ListView y MessageDialog para ContentDialog, etc. Estoy seguro de que también hay muchas pequeñas limpiezas más agradables en la API.

Sé que las empresas odian los cambios, por una buena razón. También DEBE haber un reemplazo directo relativamente fácil (funcionalmente equivalente) disponible para facilitar la migración a las nuevas API. Esto tendría que ser evaluado caso por caso y se debería tomar una decisión.

Me pregunto si podríamos establecer lanzamientos importantes (por ejemplo, WinUI 4.0) que permitan cambios importantes. Esto permitirá que el proyecto siga creciendo sin tener que vivir con todos los errores del pasado. Esencialmente, Microsoft ya ha decidido hacer esto con .NET 5 basándolo en .NET Core y descartando lo que era el .NET Framework completo.

Esto podría ser bueno para documentar una vez que se discute.

Según el progreso realizado desde la última llamada, ¿cuándo cree el equipo de manera realista que WinUI 3 estará listo para su lanzamiento?

• Compilación 2020 (abril-mayo)
• Ignite 2020 (octubre-noviembre)
• ~ 2021

Además, ¿qué tan dependiente es su trabajo del equipo de .NET que está armando una nueva solución AOT y .NET 5?

Por último, ¿hay presión en el lado de Windows para tenerlo listo para el lanzamiento de Windows10X y / o antes de eso para que los desarrolladores creen aplicaciones especializadas?

¿Habrá / debería haber una herramienta para convertir fácilmente proyectos de WinUI 2.X a WinUI 3.0 (ya que hacer esto manualmente puede ser mucho trabajo para proyectos grandes)?

El elefante en la habitación - WinRT (# 1856)

El elefante en la habitación - WinRT (# 1856)

Se acerca un modelo de aplicación sin espacio aislado, que se ejecutará de la misma manera que WPF (incluidas las API de Win32), pero con acceso a las API de WinRT modernas, y la interfaz de usuario de código abierto y los controles con el nuevo XAML que se ejecuta en Direct X 12.

Se acerca un modelo de aplicación sin espacio aislado, que se ejecutará de la misma manera que WPF (incluidas las API de Win32), pero con acceso a las API de WinRT modernas, y la interfaz de usuario de código abierto y los controles con el nuevo XAML que se ejecuta en Direct X 12.

Guau. ¡¡¡¡Wow wow!!!!

¡Eso es más que asombroso! ¿Tenemos una ETA para esto, se discutirá en la convocatoria?

¡Es increíblemente asombroso!

Se acerca un modelo de aplicación sin espacio aislado, que se ejecutará de la misma manera que WPF (incluidas las API de Win32), pero con acceso a las API de WinRT modernas, y la interfaz de usuario de código abierto y los controles con el nuevo XAML que se ejecuta en Direct X 12.

Guau. ¡¡¡¡Wow wow!!!!

¡Eso es más que asombroso! ¿Tenemos una ETA para esto, se discutirá en la convocatoria?

¡Es increíblemente asombroso!

Fue lo primero que aprendimos sobre WinUI. ETA es para este año, sospecho que se dará una fecha definida en // Build / - pero no dude en preguntar durante la llamada.

https://github.com/microsoft/microsoft-ui-xaml/blob/master/docs/roadmap.md

@jtorjo Vea la hoja de ruta de WinUI . Consulte también https://github.com/microsoft/microsoft-ui-xaml/issues/1045 para obtener más información (como plantillas de proyectos VS).

@mdtauk @ Felix-Dev Volveré a leer esos documentos. Recuerdo haber preguntado esto antes, siempre que pueda usar win2d fácilmente desde mi aplicación (no sandboxed), ¡estaré más que feliz!

@jesbis Perdón por la pregunta de novato: ¿cómo me uno a la llamada?

Estamos configurando la información para la llamada de mañana más tarde hoy. Publicaré las instrucciones en unas horas.

El retraso se debe a que es la primera vez que usamos un nuevo sistema de transmisión; después de esto, es de esperar que sea más fluido y esté listo antes 🙂

Solo tuve un pensamiento interesante (para mí de todos modos).

Echando un vistazo a la transmisión en vivo de ASP.NET Community Standup de hoy, vi esencialmente a 4 desarrolladores de MS haciendo una transmisión de codificación en vivo, aunque era más una demostración técnica. Ocasionalmente, también sintonizo @csharpfritz en Twitch, quien realiza sesiones de codificación en vivo.

Entonces, mi pensamiento fue: después de que se lance WinUI 3 y el código base (o la mayor parte) sea de código abierto, ¿algún miembro del equipo estaría dispuesto a transmitir en vivo ocasionalmente parte de su trabajo en WinUI?

Sería una buena oportunidad para aumentar la exposición de WinUI, ayudar a las personas a explorar casualmente el código base y las preguntas podrían responderse de vez en cuando. ~ No recomendaría la participación total en el chat todo el tiempo, ya que sería muy contraproducente, pero tal vez una sesión de preguntas y respuestas de vez en cuando.

No tengo idea de cuáles son las políticas de EM sobre ese tipo de cosas, especialmente durante la jornada laboral. Sería interesante escuchar sus pensamientos.

¡Aquí está el enlace del evento en vivo de YouTube para mañana!

https://youtu.be/MXTVqgB4rW0

¡Gracias por todos los comentarios y preguntas hasta ahora! Intentaremos llegar a todo, o realizar un seguimiento para un seguimiento si no tenemos tiempo.

¿Hay algo en la guía sobre rendimiento / fps de la interfaz de usuario? Una de las mayores quejas que tengo con el Windows 10 moderno es que en una máquina como Surface Book obtienes un rendimiento terrible en pantallas de DPI alto, que empeora aún más cuando combinas transparencia y monitores adicionales. Puede que esté fuera del alcance de lo que es posible, pero ¿hay alguna consideración aquí sobre qué tan fluido y bien funciona, especialmente en estas condiciones?

Considere aumentar la prioridad de las ventanas transparentes / sin bordes (como https://github.com/microsoft/microsoft-ui-xaml/issues/1247). Este es un bloqueador de adopción de WinUI para aplicaciones, como la nuestra .

cc: @crutkas

Considere aumentar la prioridad de las ventanas transparentes / sin bordes (a la # 1247). Este es un bloqueador de adopción de WinUI para aplicaciones, como la nuestra .

cc: @crutkas

Esto probablemente requeriría que se agregue un elemento de ventana de nivel superior a WinUI Xaml con propiedades, similares a WPF. N.º 1323

Sería bueno aprender más sobre el 'futuro de las ventanas' para WinUI; hay muchas solicitudes relacionadas que sería bueno discutir / abordar al menos.

Probablemente se lo hayan preguntado antes.

Para mí, siempre ha sido una cuestión de reutilización del código.
Esto lleva a dos preguntas:

1. ¿Alguien pronto será compatible con .NET Core 3 y C # 8.0?
2. ¿Veremos más pasos del equipo de UWP / WinUI para facilitar el desarrollo de aplicaciones de la Plataforma Uno?

Otro, ¿cuándo veremos los bits faltantes de WPF admitidos en UWP?

Probablemente se lo hayan preguntado antes.

Para mí, siempre ha sido una cuestión de reutilización del código.
Esto lleva a dos preguntas:

1. ¿Alguien pronto será compatible con .NET Core 3 y C # 8.0?
2. ¿Veremos más pasos del equipo de UWP / WinUI para facilitar el desarrollo de aplicaciones de la Plataforma Uno?

Otro, ¿cuándo veremos los bits faltantes de WPF admitidos en UWP?

El código .NET Core debería funcionar en ambos, por lo que una aplicación WPF solo necesitaría cambiar el código UI Xaml y UI.

Las aplicaciones para UWP deberían funcionar bien con un cambio de espacio de nombres para WinUI 3.0: salir de la zona de pruebas puede requerir más trabajo, los detalles aún se desconocen.

Los bits faltantes de WPF no se han confirmado, pero hice un problema al respecto. N.º 719

@weitzhandler

Aunque no es oficialmente compatible y no todas las características de C # 8 funcionarán, ya puede usar la mayor parte de C # 8 con WinUI / UWP. Vea aquí .

Hago esto y no he tenido ningún problema. Los "miembros de interfaz predeterminados e índices y rangos" parecen ser los únicos bits que faltan, aunque no lo he probado todo.

Simplemente amplificando lo que dijo kmgallahan sobre el uso de C # 8. He estado usando muchas de las nuevas funciones, pero realmente quería miembros de interfaz predeterminados, que aún no se han implementado.

Gracias amigos.
Si aún puedo agregar, el tipo csproj antiguo también es un poco molesto.

@jesbis

Acabo de abrir este problema en la Galería de controles XAML. Podría ser algo para discutir durante la llamada si lo desea.

Gracias, intentaremos responder a todas las preguntas.

¿Hay algo en la guía sobre rendimiento / fps de la interfaz de usuario?

@ryvanvel , tenemos una guía de rendimiento aquí:

https://docs.microsoft.com/windows/uwp/debug-test-perf/performance-and-xaml-ui

Y algunas otras publicaciones de blog y videos que podrían ayudar, por ejemplo:

https://blogs.windows.com/windowsdeveloper/2015/10/07/optimizing-your-xaml-app-for-performance-10-by-10/

https://channel9.msdn.com/Events/Build/2015/3-698

https://channel9.msdn.com/Events/Build/2017/P4173

Este error ha estado con Windows 10 hasta donde puedo recordar, espero que se solucione antes: https://github.com/microsoft/microsoft-ui-xaml/issues/597

Lamentablemente no podré sintonizarme a tiempo, ¿habrá una grabación?

Editar: la grabación de la llamada se puede encontrar aquí: https://www.youtube.com/watch?v=MXTVqgB4rW0

@jesbis aquí :

¡Aquí está el enlace del evento en vivo de YouTube para mañana!
https://youtu.be/MXTVqgB4rW0

Siguiendo el enlace de YouTube, parece que solo comenzará al final de esta hora, una hora más tarde que la hora normal, ¿es cierto?

@weitzhandler La hora de inicio está en la parte superior de la publicación. Esta es también la tercera convocatoria, por lo que "regular" es una exageración.

@weitzhandler Estoy bastante seguro de que las tres llamadas hasta ahora estaban programadas para comenzar a las 9 a.m., hora del Pacífico.

Gracias a los dos y perdón por la molestia. Nos vemos pronto.

Tenía curiosidad por saber si el WebView2 impulsado por Chromium también expondrá un evento como WebResourceRequested del actual WebView , para permitir a los desarrolladores filtrar las solicitudes web individuales. Confío mucho en esa característica específica en una de mis aplicaciones y me preguntaba si todavía estaría disponible con el nuevo control y funcionaría de la misma manera.

¡Gracias chicos por todo el trabajo duro! 😄🚀

¿Habrá alguna herramienta para generar archivos PDF? Win2D ya tiene muchas herramientas increíbles, la capacidad de generar PDF desde CanvasRenderTarget será una gran adición.

no lo entendí, ¿cómo instalar el vsix? donde descargar

Tal vez sea solo yo, pero me decepcionó la llamada de hoy. Incluya más personal técnico. El PM debe mantener la discusión enfocada y avanzar según lo programado, pero delegar las respuestas a los expertos (como se hizo más hacia el final).

Supongo que todos en esta llamada son desarrolladores y necesitamos conocer y discutir los detalles. Los PM se centran en temas muy básicos y no pueden entrar en detalles. Por ejemplo, las discusiones al comienzo de la llamada sobre documentación / WebView / ProgressRing son agradables en concepto, pero tan básicas que creo que no son útiles para nosotros. Hemos estado usando XAML durante años / décadas y usted está hablando con una audiencia experta (es importante adaptar las presentaciones a la audiencia).

@SavoySchuler Parafraseando, básicamente dijo: díganos cómo estamos usando los controles, incluya nuestra empresa y nuestras aplicaciones. Necesita esto para separar las necesidades de material de las que es bueno tener. Esto le ayuda a priorizar recursos en funciones. Debe pensar en esto de manera diferente por dos cosas:

1. Características: en este caso, lo que dijo es en gran parte correcto
2. Errores / problemas: en este caso, no, no es necesario que la comunidad le brinde ejemplos para ayudar a establecer prioridades. Al entregar cualquier producto, la calidad es su prioridad número 1. Le estamos contando los errores y usted está diciendo, bueno, sí, es bueno tenerlo. Demuestra que lo necesitas arreglado. Es un error. ¿Quizás nunca envió aplicaciones a los consumidores? Cualquier pequeña cosa mal EN TODO afecta su imagen y percepción, que es la parte más valiosa de una empresa. La industria de las aplicaciones es muy competitiva.

Una vez que la comunidad notifique los errores, debe programarlos para que se solucionen. Deje de enviar controles incompletos sin planes para solucionarlos. Esto empieza a sonar muy familiar, es lo que sucedió con UWP hace años.

En la llamada, mencioné las ventanas dos veces y se mencionó que:

• en realidad se está trabajando en esto para WinUI 3 (a pesar de que el problema se ha congelado https://github.com/microsoft/microsoft-ui-xaml/issues/1247)
• el proyecto Feature Tracking (actualizado ayer) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) solo está rastreando cosas de WinUI 2 ???

¿Podemos aclarar algo aquí? ¿Hay otra ubicación para ver la acumulación de WinUI 3? Es muy importante para fines de planificación que sepamos lo que vendrá y lo que no. ¡Gracias!

@SavoySchuler @jesbis y el resto del encantador equipo de WinUI, personalmente quiero agradecerles por su gran trabajo y enormes esfuerzos y decirles lo agradecido que estoy por hacer de WinUI tan increíble y también por responder todas mis preguntas.

¡Muchas gracias a todos los que pudieron sintonizarnos!

Y lo siento de nuevo por los problemas de audio y de Teams; creemos que identificamos un problema de hardware y, con suerte, tendremos todo resuelto para el próximo mes.

La grabación está en vivo ahora también para cualquiera que no pudo asistir.

Estamos revisando las preguntas e intentaremos llegar a todo lo que nos perdimos en este hilo.

Algunas preguntas para ponerse al día:

¿Habrá alguna herramienta para generar archivos PDF?

@MuziburRahman

No tendremos tiempo para llegar a esto para WinUI 3.0 RTM pero estamos rastreando esto en el backlog con # 672 - ¡no dude en agregar un comentario a ese problema sobre cómo lo usaría!

¿cómo instalar el vsix? donde descargar

@hannespreishuber

Las instrucciones de uso de WinUI 2.x para aplicaciones de producción están aquí: https://docs.microsoft.com/uwp/toolkits/winui/getting-started

Las instrucciones de WinUI 3.0 Alpha para instalar y probar el vsix están aquí:
https://aka.ms/winui/alpha

Tal vez sea solo yo, pero me decepcionó la llamada de hoy. Incluya más personal técnico. PM debe mantener la discusión enfocada [...] Hemos estado usando XAML durante años / décadas y usted está hablando con una audiencia experta (es importante adaptar las presentaciones a la audiencia).

@robloo gracias por los comentarios sobre esto. Podemos incluir más desarrolladores y profundizar más en temas específicos para futuras llamadas si eso es de interés para todos; no queríamos probar eso en la primera llamada, ya que ha pasado un tiempo y queríamos hacer una captura general. hasta.

También hemos recibido comentarios en el pasado de que a veces nos volvemos demasiado técnicos y demasiado profundos porque gran parte de la audiencia aún no está muy familiarizada con WinUI, por lo que también estamos tratando de equilibrar esos comentarios.

Además, si ayuda tener en cuenta: muchos de nuestros PM en los equipos de la plataforma de desarrollo son súper técnicos y tienen experiencia en la escritura de código de producción para las principales plataformas y aplicaciones reales. Algunos de ellos eran desarrolladores a tiempo completo en Microsoft y otras empresas. También seguimos escribiendo código todo el tiempo como PM, simplemente no es nuestro único objetivo 🙂

Finalmente, sobre errores y calidad: la calidad es muy importante para nosotros y dedicamos mucho tiempo a errores, pruebas e infraestructura de calidad. Puede ver la proporción de correcciones de calidad frente a nuevas funciones en el registro de confirmación para WinUI 2, y una vez que sea de código abierto, podrá ver lo mismo para WinUI 3. Dicho esto, ninguna base de código importante está libre de errores y nosotros Siempre hay que equilibrar las prioridades comerciales.

Si los controles parecen estar incompletos, por favor abra los problemas para ellos.

En la llamada, mencioné las ventanas dos veces y se mencionó que:
esto en realidad se está trabajando para WinUI 3 (a pesar de que el problema se ha congelado # 1247)
el proyecto Feature Tracking (actualizado ayer) (https://github.com/microsoft/microsoft-ui-xaml/projects/4) solo está rastreando cosas de WinUI 2 ???
¿Podemos aclarar algo aquí? ¿Hay otra ubicación para ver la acumulación de WinUI 3? Es muy importante para fines de planificación que sepamos lo que vendrá y lo que no. ¡Gracias!

@riverar, ese tablero de proyecto es actualmente para WinUI 2, ya que es el único código en el repositorio actualmente.

Usamos la etiqueta need-winui-3 para los problemas que tendrán que esperar a WinUI 3 antes de que se puedan abordar correctamente, pero todavía no tenemos seguimiento público para nuestro trabajo de WinUI 3.

Continuaremos publicando propuestas de funciones para los elementos principales, como la especificación Chromium WebView en el repositorio de especificaciones separado:

https://github.com/microsoft/microsoft-ui-xaml-specs/blob/master/active/WebView2/WebView2_spec.md

y una vez que podamos abrir WinUI 3 Xaml, podemos comenzar a mover el seguimiento a GitHub, pero la mayor parte de nuestro seguimiento diario de elementos de trabajo probablemente seguirá siendo interno a través del desarrollo de 3.0 por varias razones (tenemos muchas de las dependencias del sistema operativo privado para desenredar, necesidad de interactuar estrechamente con otros equipos de desarrollo de componentes del sistema operativo, etc.)

Sin embargo, puedo decir que la mayoría de esas sugerencias de funciones etiquetadas no se abordarán para la versión 3.0 inicial; nuestras áreas de enfoque principales son:

• obtener WinUI desacoplado del sistema operativo y enviado por separado
• código abierto del marco Xaml
• creando una buena experiencia de desarrollo de aplicaciones de escritorio WinUI (uso de win32, empaquetado, ventanas, etc.)
• habilitando Windows 10X
• habilitar aplicaciones .NET Core / 5 + WinUI

y no queremos retrasar o desestabilizar eso al intentar hacer un montón de desarrollo de nuevas funciones adicionales al mismo tiempo.

A medida que logremos avances concretos en áreas importantes como el soporte de escritorio / ventanas, publicaremos propuestas y actualizaciones en el repositorio.

y una vez que podamos abrir WinUI 3 Xaml, podemos comenzar a mover el seguimiento a GitHub, pero la mayor parte de nuestro seguimiento diario de elementos de trabajo probablemente seguirá siendo interno a través del desarrollo de 3.0 por varias razones (tenemos muchas de las dependencias del sistema operativo privado para desenredar, necesidad de interactuar estrechamente con otros equipos de desarrollo de componentes del sistema operativo, etc.)

¿Sería posible enumerar estos elementos de trabajo internos públicamente, incluso si aparecen como entradas en blanco con algún nombre genérico como Problema interno ? Verlos pasar de Tareas pendientes a En curso y Completar indicaría cierto grado de progreso para todo el proyecto.

Sin embargo, puedo decir que la mayoría de esas sugerencias de funciones etiquetadas no se abordarán para la versión 3.0 inicial; nuestras áreas de enfoque principales son:

• obtener WinUI desacoplado del sistema operativo y enviado por separado
• código abierto del marco Xaml

Este es, por supuesto, el núcleo del esfuerzo, pero puede ser posible resolver varios problemas o problemas con la implementación actual, ya que se está extrayendo del código del sistema operativo.

• creando una buena experiencia de desarrollo de aplicaciones de escritorio WinUI (uso de win32, empaquetado, ventanas, etc.)
• habilitando Windows 10X

Esto será esencial para hacerlo bien y requerirá poner ambas cosas en manos de los usuarios y desarrolladores, con una mente abierta para aceptar comentarios. También será difícil porque el tiempo de ejecución de la aplicación y el modal de la aplicación no son propiedad de este equipo de WinUI, por lo que se debe habilitar la posibilidad de que los comentarios se filtren a los que están a cargo de ellos.

• habilitar aplicaciones .NET Core / 5 + WinUI

El soporte nativo actual viene en forma de código C ++ y API de Win32, pero ¿significa esto que los desarrolladores de C # deben apuntar a .NET? ¿El modelo de aplicación sin espacio aislado permitirá la codificación C # sin .NET?

y no queremos retrasar o desestabilizar eso al intentar hacer un montón de desarrollo de nuevas funciones adicionales al mismo tiempo.

A medida que logremos avances concretos en áreas importantes como el soporte de escritorio / ventanas, publicaremos propuestas y actualizaciones en el repositorio.

Sin CoreWindow (que será UWP solo en el futuro), el sistema de ventanas es una de esas cosas que deberá estar en su lugar desde el primer día. WPF tiene un objeto de ventana en XAML que maneja los controles, el estilo visual, la transparencia, etc. Maneja el cambio de tamaño, la minimización, etc. Los marcos de Win32 más antiguos requieren pintura manual de superficies que no son una cosa para las IU XAML, entonces, ¿cómo se cierra esta brecha? ?

Esto es incluso antes de que lleguemos a los dispositivos de pantalla dual, y cómo un modelo de aplicación que no sea de UWP y la configuración de ventanas se adaptarían a eso.

¿Sería posible enumerar estos elementos de trabajo internos públicamente, incluso si aparecen como entradas en blanco con algún nombre genérico como Problema interno?

Nuestro objetivo es definitivamente mover nuestros procesos (incluido el seguimiento de problemas) al código abierto además del código.

Para empezar, tenemos un hito de

Sin embargo, eso no incluirá todas nuestras tareas de desarrollo diarias de WinUI 3.0 de inmediato; como referencia, actualmente estamos rastreando miles de días de trabajo de desarrollo relacionado para 2020 y aún no estamos listos para mover todo. nuestro seguimiento supergranular a GitHub hoy. Sin embargo, llegaremos a eso con el tiempo, como hicimos con WinUI 2.

Por lo tanto, comenzaremos con problemas a nivel de función (como los que han comenzado hasta ahora, por ejemplo, WebView) y migraremos completamente nuestros procesos a GitHub con el tiempo.

El soporte nativo actual viene en forma de código C ++ y API de Win32, pero ¿significa esto que los desarrolladores de C # deben apuntar a .NET? ¿El modelo de aplicación sin espacio aislado permitirá la codificación C # sin .NET?

¿Está preguntando acerca de .NET Native o no .NET en absoluto? Técnicamente, creo que la especificación de C # como lenguaje no depende de .NET, pero actualmente no tenemos planes para transpilar a C ++ ni nada por el estilo.

Sin CoreWindow (que será UWP solo en el futuro), el sistema de ventanas es una de esas cosas que deberá estar en su lugar desde el primer día. WPF tiene un objeto de ventana en XAML que maneja los controles, el estilo visual, la transparencia, etc. Maneja el cambio de tamaño, la minimización, etc. Los marcos de Win32 más antiguos requieren pintura manual de superficies que no son una cosa para las IU XAML, entonces, ¿cómo se cierra esta brecha? ?

@ marb2000 está trabajando en eso y podrá compartir más información cuando esté disponible.

Esto es incluso antes de que lleguemos a los dispositivos de pantalla dual, y cómo un modelo de aplicación que no sea de UWP y la configuración de ventanas se adaptarían a eso.

Para ser claros, WinUI 3 no traerá todo el escritorio win32 a otras plataformas como HoloLens: las aplicaciones universales y las API seguirán siendo el camino a seguir cuando se dirijan a múltiples dispositivos.

Publicado demasiado pronto. Comentario completo:

@robloo : quiero comenzar por estar de acuerdo con muchos de tus sentimientos y te agradezco que te acompañes a través de nuestro creciente dolor. Estaba muy despistado con todos nuestros problemas técnicos y no manejé esa pregunta tan bien como me hubiera gustado. Permítame intentarlo de nuevo aquí:

Carta y recursos

Sé que pisar un tema como este nunca será popular, pero creo en la transparencia y quiero ser sincero con ustedes como comunidad sobre los desafíos que enfrentamos para que puedan ser parte de la discusión y ayudarnos a decidir cómo los resolvemos. . Este desafío particular se enfoca en la división de tiempos y activos de recursos. Hay tres iniciativas principales en las que nuestro equipo se divide:

1. Avanzando en WinUI 2
2. Entrega de WinUI 3
3. Código abierto de WinUI 3

Como saben, estamos marcados firmemente hacia 2 y 3 porque A) estos son objetivos acoplados y B) el código abierto de WinUI significa que todos pueden dejar de ser bloqueados por los recursos finitos de nuestro equipo porque WinUI finalmente estará facultado para aceptar solicitudes de extracción de la comunidad.

Si nos se marcan demasiado hacia adelante en los objetivos 2 y 3 hasta un punto en WinUI 2 es insuficientemente servir miembros de la comunidad, podemos tener esa conversación y estamos abiertos a la modificación de las prioridades. Solo sepa que la resolución de todos los errores en nuestro backlog retrasaría el lanzamiento de WinUI 3 al mercado en ~ 6 meses. En cambio, si damos prioridad a 2 y 3, que no solo abren WinUI de código abierto, sino que amplían su relevancia para nuestra enorme base de desarrolladores de Win32, podremos limpiar nuestra acumulación de errores _y_ solicitudes de funciones con el poder de la comunidad de código abierto y de nuestro equipo. atención indivisa apoyándonos. Con ese fin, nuestro razonamiento actual es que el plan de enfoque no solo haría avanzar esta plataforma más rápido sino también de manera más integral. Cuando le pedí que nos ayudara a priorizar los errores, la pregunta no era "¿son lo suficientemente importantes para que nuestro equipo los aborde?" pero en cambio, "¿es esto importante que el código abierto de WinUI antes?" En el status quo, tenemos un subconjunto de desarrolladores que trabajan para avanzar en la prioridad 1 y puede su impacto en nuestro historial de compromisos y problemas activos, pero de todos modos enfrentan la necesidad de priorizar dentro de ese objetivo. Esta noción de "dinos qué tan importante es esto para ti" nos ayuda a filtrar las necesidades (p. Ej., Mi producto está bloqueado y no puedo esperar a WinUI 3) frente a sutilezas (p. Ej., Noté este error técnico pero no hay desarrollo existente está bloqueado en él para que pueda esperar a WinUI 3).

La otra cosa que quiero decir claramente es que todo el trabajo de entrar en la presentación de WinUI 2 errores, el llenado de las peticiones de características, etc., será _ _ No se pierde en nosotros. Cuando se lance WinUI 3, tendremos un subconjunto significativo de nuestro equipo libre para regresar a los elementos de trabajo que hacen avanzar la plataforma además de empoderar a la comunidad para que envíe código también. Esto significa que en este momento estamos preparando un trabajo atrasado que toda la fuerza de nuestro equipo abordará con la ayuda de nuestra comunidad UWP existente y, pronto, Win32 también.

Una cosa adicional a tener en cuenta es que mientras estamos migrando el código del sistema operativo a WinUI 3, estamos tomando medidas para simplificar y limpiar el código detrás donde podamos. Esto significa que ciertas adiciones de funciones y correcciones de errores requerirán mucho menos tiempo y esfuerzo si se resuelven en WinUI 3.

NumberBox

Características

Volvamos a NumberBox. De hecho, tiene razón al decir que V1 es un subconjunto de las características deseadas.
Las características planificadas de V1 se retrasaron hasta V2 debido a dependencias de cosas como la validación de entrada (que, por cierto, está en versión preliminar en WinUI 3 alpha). Intentamos ser completos en nuestra especificación reconociendo todo lo que pensamos que merecía ser V1 en la especificación (aquí) y planeamos cumplir plenamente con ese compromiso con una versión WinUI 3 V2 del control.

Al adoptar el espíritu del código abierto, mi deseo (y por favor diga si me equivoco al hacer esto) es preferir completamente lanzar código confiable y útil lo más rápido posible y construir los conjuntos de características de forma incremental. En la aplicación, esto significó preferir lanzar nuestra _muy_ completa V1 en WinUI 2 y seguirla con una versión con todas las funciones con validación de entrada como podemos con WinUI 3.

Insectos

Como dijo @jesbis , ninguna base de código está libre de errores, pero la calidad es lo más importante para nosotros. Estamos comprometidos con la limpieza de errores y tenemos un subconjunto del equipo trabajando para hacer esto WinUI 2. Hasta que el esfuerzo total de nuestros equipos se reúna con el lanzamiento de WinUI 3, esto se moverá más lento de lo que nuestros corazones quieren, pero todavía estamos trabajando en ello. @jesbis señaló, puede ver la proporción de correcciones de calidad frente a nuevas características en el registro de confirmación para WinUI 2, y una vez que sea de código abierto, podrá ver lo mismo para WinUI 3.

Sigo comprometido a ayudar a resolver estos errores con NumberBox y estoy reservando el resto de mi día para responder a problemas abiertos, errores y preguntas en las que puedo ser un activo. También reservaré un día la semana que viene. Siéntase animado a enviarme preguntas en Twitter o participar conmigo aquí en el repositorio.

Próximos pasos

Para nosotros, el código abierto es la promesa de acoger a la comunidad como miembros del equipo como si estuvieran sentados aquí en nuestra oficina de Redmond. Estamos escuchando escuchando. Hablemos de estas decisiones juntos para que podamos enfocarnos en construir cosas increíbles como un gran equipo. 🙂

Nosotros ❤️ WinUI

Al adoptar el espíritu del código abierto, mi deseo (y por favor diga si me equivoco al hacer esto) es preferir completamente lanzar código confiable y útil lo más rápido posible y construir los conjuntos de características de forma incremental. En la aplicación, esto significó preferir lanzar nuestra V1 casi completa en WinUI 2 y seguirla con una versión con todas las funciones con validación de entrada como podemos con WinUI 3.

Este podría ser solo yo, pero creo que si bien es importante enviar el código lo más rápido posible, hay ciertos tipos de problemas que deben resolverse antes de enviar cualquier cosa, por ejemplo, el # 1846 es algo que debería haberse abordado antes de enviar V1 y allí. puede haber algunos otros también.

@yaichenbaum Podría haber elegido mejor mis palabras allí. 🙂

Si AD son _debe tener_ características y EH es _buen tener_ características, mi prioridad es sacar AD y agregar gradualmente EH según sea posible.

La razón por la que hacemos pruebas en una rama de vista previa con socios de validación es para detectar errores como # 1846 antes de que los controles pasen a una versión estable. Lo siento, hemos dejado caer la pelota en este caso, ¡trabajaré con @teaP lo antes posible para ver qué tan rápido podemos resolver esto! 🙂

En un momento de la llamada, se mencionó que las aplicaciones WinUI permitirían el sandboxing a través de AppDomain.

¿Alguien puede hablar sobre cómo WinUI 3.0+ posicionará las capacidades frente a AppDomain para el aislamiento de aplicaciones y el control de recursos?

Además, lo último que supe para .Net Core, el soporte completo para AppDomain no estaba sucediendo.

Tal vez estoy fuera de contacto, pero ¿estás diciendo que .Net 5 tendrá soporte completo para AppDomain?

¡Gracias por organizar esta llamada hoy!

¿Alguien puede hablar sobre cómo WinUI 3.0+ posicionará las capacidades frente a AppDomain para el aislamiento de aplicaciones y el control de recursos?

Lo siento si no quedó claro en la llamada, pero estaba hablando de AppContainer , no de AppDomain.

Ah, está bien, gracias por la aclaración Jesse.

En primer lugar, gracias a @SavoySchuler y @jesbis (y al resto del equipo de WinUI) por organizar la llamada comunitaria de hoy. Aunque hubo algunas dificultades técnicas, ¡esta llamada fue muy reveladora!

Como mencionó @jesbis, existe un problema al rastrear las herramientas y características solicitadas para WinUI 3.0. ¿Sería mejor dividir la solicitud de una herramienta de conversión WinUI 2.xa 3.0 en un problema separado para facilitar el seguimiento? Además, ¿ya hay planes? ¿Hay planes para hacer que la herramienta sea de código abierto para que otros desarrolladores puedan ayudar a desarrollarla?

Otra pregunta más general (que también sería para otros miembros del equipo que no sean de WinUI) es sobre la contribución. ¿Existe algún obstáculo actualmente que impida que las personas contribuyan? ¿Sería útil una mejor guía de introducción para colaboradores?

En mi opinión, si comienza a contribuir al proyecto, el Proyecto VS puede ser un poco abrumador y no hay mucha documentación sobre cómo desarrollar, qué proyecto de prueba debe usarse para qué, etc.

Quizás las mejoras en esa área facilitarían la contribución de las personas 😅

¿Cómo se realiza la capa de renderizado de WinUI 3.0? ¿Hace uso directo de D3D11, D2D, capa de abstracción o qué? ¿Tiene una capa de renderizado de software o utiliza D3D WARP para eso?

@chingucoding

Repetiré los puntos que acabo de mencionar aquí :

• No haber usado el idioma en una eternidad
• No tengo idea de cuánto código está sucediendo en segundo plano para la versión de WinUI 3 que sobrescribirá los cambios realizados hoy
• No hay acceso a un montón de código fuente que sería necesario y / o ayudaría enormemente a resolver problemas.

Editar: daré un ejemplo. # 1555 y # 1849 son problemas aparentemente importantes con un control central (TextBox) que impiden la entrada y selección de texto mientras se realizan múltiples tareas.

Ocupan un lugar destacado en mi lista de cuestiones importantes que deberían resolverse, pero no tengo ni idea de por dónde empezar. Tampoco sé si el código que quiero / necesito para depurar cosas está disponible.

@SaboyaSchuler

Si avanzamos demasiado en los objetivos 2 y 3 hasta un punto en el que WinUI 2 no atiende a los miembros de la comunidad, podemos tener esa conversación y estamos abiertos a cambiar las prioridades. Solo sepa que la resolución de todos los errores en nuestro backlog retrasaría el lanzamiento de WinUI 3 al mercado en ~ 6 meses.

Ciertamente lo entiendo. Sin embargo, NumberBox es un poco diferente aquí en mi mente y ciertamente no estoy diciendo que debamos enfocarnos en todos los errores. En este momento solo hablaré en el contexto de NumberBox. Aunque ciertamente hay algunos otros problemas evidentes que deben abordarse.

NumberBox es un control recientemente desarrollado para WinUI 2.3, no un control heredado que todos deben aceptar en este momento. ¿Por qué no haríamos esto correctamente para empezar? Esta es en gran medida una prueba de fuego del nuevo modelo de desarrollo.

Si AD debe tener características y EH es bueno tener características, mi prioridad es sacar AD y agregar gradualmente EH según sea posible.

Estoy completamente de acuerdo contigo aquí. Pero debe comprender la diferencia entre características y errores. Me preocupa que esté pensando solo en términos de recursos / mano de obra para Microsoft. Sin embargo, ¿ha considerado que los desarrolladores de aplicaciones pierden incontables horas tratando de solucionar errores en los controles? Es mucho más eficiente arreglar estas cosas en la fuente y también ayuda realmente a la percepción de la plataforma / herramientas.

La otra cosa que quiero decir claramente es que todo el trabajo dedicado a archivar errores de WinUI 2, completar solicitudes de funciones, etc., no se perderá en nosotros. Cuando se lance WinUI 3, tendremos un subconjunto significativo de nuestro equipo libre para regresar a los elementos de trabajo que hacen avanzar la plataforma además de empoderar a la comunidad para que envíe código también.

Microsoft tiene un historial realmente malo de lanzar software incompleto y luego pasar a la siguiente y mejor tecnología antes de tener la oportunidad de completar la última. Por favor, perdóname por ser escéptico con tu promesa.

Volvamos a NumberBox. De hecho, tiene razón al decir que V1 es un subconjunto de las características deseadas.
... Al abrazar el espíritu del código abierto, mi deseo (y por favor diga si me equivoco al hacer esto) es preferir completamente lanzar código confiable y útil lo más rápido posible y construir los conjuntos de características de forma incremental.

Totalmente en la misma página que usted en términos de características. Los errores son diferentes. Debe abordar los errores de manera diferente a las funciones y asignarles más recursos. Simplemente se ve mal lanzar un nuevo control como NumberBox y luego decir que no puede asignar recursos para corregir errores hasta dentro de un año.

Le pido que solucione los errores en la V1 del control que no dependen de WinUI 3.0. Algunos son bastante básicos y otros son errores evidentes en el diseño (como el bloqueo de datos enlazados bidireccionales de NaN). Una vez que se compromete a lanzar una función / control, debe trabajar rápidamente para cerrar los errores. SIEMPRE hay errores cuando el software tiene su primera versión amplia, solo necesita planificar los recursos para hacer una rápida corrección de errores V2 (como el resto de los desarrolladores de aplicaciones). Como estamos de acuerdo en que la calidad es la máxima prioridad, solucione los siguientes problemas con NumberBox antes de pasar a otras cosas.

1708: el texto del marcador de posición es absolutamente necesario con cualquier uso de formulario del control y una de las características básicas que ya se encuentran en la especificación. Si esto realmente se ha solucionado para NaN, deberíamos cerrarlo. El soporte nulo es un tema diferente a continuación.

1721 - Un gran problema con UWP fue su soporte incompleto para el enlace de datos en ciertos controles. Muchos desarrolladores de aplicaciones invirtieron en el diseño de MVVM hace años y luego, al intentar pasar a los controles de UWP, descubrieron que el enlace de datos solo se admitía parcialmente. Este es un gran problema y es inaceptable considerando lo fundamental que es MVVM para las mejores prácticas de Microsoft. El antiguo equipo de herramientas para desarrolladores de Windows nunca toleraría esto: este es el pensamiento nativo de Windows aquí.

1839 - Cosas básicas aquí. Estos son solo errores básicos en la plantilla de control y DEBEN corregirse. No hay excusas.

1846: hemos tenido este problema en muchos otros controles anteriormente. ¿Por qué no hay una lista de verificación de versiones que pruebe esto a estas alturas? Una vez más, cosas básicas que deben arreglarse. Afecta la usabilidad de todas las aplicaciones que usan este control.

1852, # 1853, # 1854 - Una vez más, estos no son demasiado complicados y simplemente se pasaron por alto en la primera implementación. Sin embargo, es un requisito legal respaldar la accesibilidad en el software vendido en ciertas regiones o desarrollado para el gobierno. Como plataforma, debe solucionar este problema de inmediato para que los desarrolladores de aplicaciones puedan usar el control. Una vez más, no debería tener que debatir este tipo de cosas contigo, son cosas básicas.

Una cosa adicional a tener en cuenta es que mientras estamos migrando el código del sistema operativo a WinUI 3, estamos tomando medidas para simplificar y limpiar el código detrás donde podamos. Esto significa que ciertas adiciones de funciones y correcciones de errores requerirán mucho menos tiempo y esfuerzo si se resuelven en WinUI 3.

Comprender a un alto nivel. Sin embargo, solucionar los problemas anteriores no retrasará WinUI 3.0 durante 6 meses. Tampoco dependen de WinUI 3.0 para la dirección (excepto potencialmente para # 1721). Estás sentando un precedente peligroso al lanzar NumberBox y luego no ceñirte a él para cerrar la primera ronda de errores. Ya debería haber aprendido esta lección con UWP.

Quizás las mejoras en esa área facilitarían la contribución de las personas

Me encantaría contribuir. No me encanta trabajar con C ++ / WinRT y ciertamente no me siento calificado para tocar el código base como lo he visto. Si los controles se administraran C #, habría tenido muchas más contribuciones. Entiendo por qué la arquitectura es lo que es, pero una de las consecuencias son menos contribuciones de la comunidad. No somos desarrolladores de sistemas aquí, somos desarrolladores de aplicaciones para usuarios finales.

RE: contribuyendo:

Otra pregunta más general (que también sería para otros miembros del equipo que no sean de WinUI) es sobre la contribución. ¿Existe algún obstáculo actualmente que impida que las personas contribuyan? ¿Sería útil una mejor guía de introducción para colaboradores?
En mi opinión, si comienza a contribuir al proyecto, el Proyecto VS puede ser un poco abrumador y no hay mucha documentación sobre cómo desarrollar, qué proyecto de prueba debe usarse para qué, etc.
Quizás las mejoras en esa área facilitarían la contribución de las personas

Nada debería impedir que las personas contribuyan a WinUI 2, que es la base de código actualmente en el repositorio. Si hay un problema de WinUI 2 en el que desea trabajar, háganoslo saber y podemos asignárselo.

Tenemos muchos artículos etiquetados con un buen primer número y se necesita ayuda si alguien quiere ayudar con artículos con los que debería ser (relativamente) fácil comenzar 🙂

Para corregir errores, simplemente puede abrir un PR. Si es una característica nueva importante, entonces también tenemos un poco de proceso para revisar el problema primero y asegurarnos de que la propuesta se ajuste bien a WinUI.

Estoy totalmente de acuerdo en que la guía del colaborador podría ser mejor y en que es difícil comenzar; recientemente hice el ejercicio de tratar de seguirla para implementar una nueva función ( RadialGradientBrush ) y descubrí que podría mejorar mucho; ahora está en mi lista de tareas para mejorar la guía.

Daré un ejemplo. # 1555 y # 1849 son problemas aparentemente importantes con un control central (TextBox) que impiden la entrada y selección de texto mientras se realizan múltiples tareas.
Ocupan un lugar destacado en mi lista de cuestiones importantes que deberían resolverse, pero no tengo ni idea de por dónde empezar. Tampoco sé si el código que quiero / necesito para depurar cosas está disponible.

Esos todavía necesitan ser clasificados (categorizados) por nuestros propietarios de desarrolladores (de ahí la etiqueta "need-triage" - actualmente estoy haciendo un seguimiento de por qué no lo han hecho todavía, lo siento) pero espero eso ya que TextBox no está en WinUI 2 tendrán que esperar a WinUI3.

Una vez que hayan sido evaluados, deberían tener aplicada la etiqueta need-winui-3 , lo que indica que tendrán que esperar a WinUI 3 antes de que podamos abordarlos.

Una vez que WinUI 3 sea de código abierto, cualquiera podrá ayudar a resolver esos problemas también.

No me encanta trabajar con C ++ / WinRT y ciertamente no me siento calificado para tocar el código base como lo he visto. Si los controles se administraran C #, habría tenido muchas más contribuciones.

Sabemos que C ++ es una barrera más alta que C #, pero el plan es que WinUI seguirá siendo una plataforma C ++.

Otro gran proyecto al que contribuir es el Kit de herramientas de la comunidad de Windows, al que es más fácil contribuir ya que es C # y tiene algunos requisitos relajados.

Trabajamos con los mantenedores y, a menudo, usamos el kit de herramientas de la comunidad para incubar nuevos controles que eventualmente migrarán a la plataforma Xaml (lo que implica la reimplementación en C ++).

¿WinUI requiere C ++ / CX? Si es así, ¿parece que esto es un problema para Win32 y otros objetivos futuros?

¿Cómo se realiza la capa de renderizado de WinUI 3.0? ¿Hace uso directo de D3D11, D2D, capa de abstracción o qué? ¿Tiene una capa de renderizado de software o utiliza D3D WARP para eso?

La representación del marco WinUI Xaml se implementa principalmente en el motor de composición de Windows 10 . Las API de la capa de composición también serán parte de WinUI 3.

Al final, eso generalmente significa renderizado acelerado por hardware usando Direct3D, Direct2D y DirectWrite, con renderizado de software en algunos casos donde tiene sentido.

También puede incluir su propio contenido de DirectX personalizado mediante API de interoperabilidad.

¿WinUI requiere C ++ / CX? Si es así, ¿parece que esto es un problema para Win32 y otros objetivos futuros?

No, la plataforma WinUI está escrita en C ++, ¡pero sus aplicaciones definitivamente no tienen por qué estarlo!

Con WinUI 2 hoy puede crear aplicaciones para UWP usando .NET (C #, VB.NET) o C ++.

Con WinUI 3, nuestro objetivo es que pueda crear aplicaciones que utilicen las API de UWP y / o win32 utilizando el próximo .NET 5 o C ++.

@jesbis Creo que puede estar malinterpretando un poco la intención de mis preguntas.

1) Sé que WinUI está escrito en C ++, sin embargo, ¿algún código de WinUI requiere extensiones VC ++ / CX solo para Windows? Si requiere extensiones CX, veo que esto puede causar problemas de portabilidad en el futuro si WinUI quisiera expandirse a otras plataformas. Esto podría dificultar que el equipo de UNO adopte el código, por ejemplo.

2) Sobre el sistema de renderizado. Un par de cosas aquí.

2.a) ¿La "capa visual" es una API de abstracción eliminada lo suficientemente lejos de las API de DirectX como para que luego pueda admitir un backend de Vulkan, por ejemplo? (Estoy seguro de que esta pregunta será respondida cuando se publique la fuente, pero me pregunto)

2.b) Mi pregunta sobre la rasterización de software fue más en la línea de: ¿WinUI 3.0 admitirá la representación completa del software (no solo la representación de texto o lo que sea)? A veces, el software para compartir pantalla tiene problemas con las aplicaciones aceleradas por GPU (al menos con D3D9 / WPF) y forzar la renderización del software soluciona el problema en esas situaciones). O si la aplicación se ejecuta en una máquina virtual sin GPU de hardware.

Las instrucciones de WinUI 3.0 Alpha para instalar y probar el vsix están aquí:
https://aka.ms/winui/alpha

hizo eso con Edge New, apareció el enlace de descarga doenst, lo repitió con Chrome, descargue allí

hizo eso con Edge New, apareció el enlace de descarga doenst, lo repitió con Chrome, descargue allí

@hannespreishuber, el enlace de descarga debe estar en la última página de la encuesta. ¿Quiere decir que la encuesta no funcionó en Chromium Edge pero sí en Chrome?

el enlace de descarga debe estar en la última página de la encuesta. ¿Quiere decir que la encuesta no funcionó en Chromium Edge pero funcionó en Chrome?

Hice una encuesta en ambos, pero la última página fue diferente, tal vez mi culpa.

Hice una encuesta en ambos, pero la última página fue diferente, tal vez mi culpa.

De acuerdo, gracias, probamos la encuesta en ambas versiones de Edge y pareció funcionar, así que si alguien tiene problemas con la descarga, háganoslo saber y también informe el problema en Edge si el contenido de la página se visualiza de manera diferente a Chrome (Configuración> Ayuda y Comentarios> Enviar comentarios) 🙂

Sé que WinUI está escrito en C ++, sin embargo, ¿algún código de WinUI requiere extensiones VC ++ / CX solo para Windows? Si requiere extensiones CX, veo que esto puede causar problemas de portabilidad.

@ zezba9000 hemos implementado controles y características de WinUI 2 (el nuevo código actualmente en el repositorio) usando C ++ / WinRT, que es el estándar C ++ 17, pero el resto de WinUI 3 es una base de código mucho más grande y antigua que actualmente seguirá dependiendo en WRL, etc. No nos estamos enfocando en la portabilidad en este momento, pero estamos abiertos a discutirlo en el futuro.

¿Es la "capa visual" una API de abstracción eliminada lo suficientemente lejos de las API de DirectX como para que luego pueda admitir un backend de Vulkan, por ejemplo? (Estoy seguro de que esta pregunta será respondida cuando se publique la fuente, pero me pregunto)

Tampoco nos estamos enfocando en la portabilidad en este momento para la capa visual. Hay algunos acoplamientos sueltos entre la capa Visual y las API de DirectX (sin contar la implementación), pero en su mayoría está abstraído. Además, para aclarar sobre el código abierto: nuestro objetivo inicial para el código de código abierto y nuestros procesos de desarrollo diarios es el marco Xaml, que no incluirá el código abierto de la capa visual en este momento.

Mi pregunta sobre la rasterización de software fue más en la línea de: ¿WinUI 3.0 admitirá la representación completa del software (no solo la representación de texto o lo que sea)? A veces, el software para compartir pantalla tiene problemas con las aplicaciones aceleradas por GPU (al menos con D3D9 / WPF) y forzar la renderización del software soluciona el problema en esas situaciones). O si la aplicación se ejecuta en una máquina virtual sin GPU de hardware.

Sí, la renderización sobre el uso compartido de pantalla, en máquinas virtuales, etc. debería funcionar. Para la mayoría de los contenidos no debería haber diferencias visibles. Si observa el código de WinUI 2 en el repositorio, es posible que también vea el uso de una API que usamos para consultar si ciertos efectos son compatibles / "rápidos" en tiempo de ejecución y recurrir a una representación más simple de ciertos efectos en algunos casos, pero las aplicaciones no deberían No es necesario hacer nada especial para admitir el procesamiento de software cuando se utilizan los controles y funciones predeterminados de la plataforma.

Estoy completamente de acuerdo contigo aquí. Pero debe comprender la diferencia entre características y errores. Me preocupa que esté pensando solo en términos de recursos / mano de obra para Microsoft. Sin embargo, ¿ha considerado que los desarrolladores de aplicaciones pierden incontables horas tratando de solucionar errores en los controles? Es mucho más eficiente arreglar estas cosas en la fuente y también ayuda realmente a la percepción de la plataforma / herramientas.

Estoy de acuerdo al 100%: ni siquiera quiero recordar la cantidad de horas que paso trabajando con errores de UWP / WinRT.

Jesse,

Lo que más me preocupa es el desarrollo de aplicaciones empresariales. Actualmente estoy usando WinUI 3.0 Alpha para crear una prueba de concepto que demuestre cómo Xaml, GPRC, múltiples ventanas y el verdadero multihilo pueden ofrecer a la empresa y al usuario empresarial una experiencia de aplicación más productiva.

¿Por qué? Porque necesitamos una alternativa a las aplicaciones de pantalla pequeña / basadas en navegador. Tengo mucho más que decir sobre ese tema, pero voy a KISS aquí.

Lo que me gustaría del equipo de WinUI y, de hecho, de Microsoft es adoptar y apoyar la creación de aplicaciones de escritorio para empresas.

Hubo 3 razones principales por las que las aplicaciones web se adoptaron en la empresa con tanta rapidez: soporte multiplataforma, seguridad y fácil implementación. Para ser una alternativa viable, las aplicaciones de escritorio necesitan respuestas a esas preguntas.

Parece que la mayor parte de la industria del desarrollo de software se centra en la entrega de aplicaciones para el factor de forma del navegador y / o móvil / tableta.

Las aplicaciones empresariales se ejecutan en estaciones de trabajo con gran cantidad de CPU, tamaño de pantalla, memoria, almacenamiento, gráficos y ancho de banda en comparación con las aplicaciones “móviles primero”. Los usuarios de estas aplicaciones LOB pueden participar durante horas y horas a la vez. Necesitamos una guía de diseño de aplicaciones para abordar estos factores.

Hay otras dimensiones en las aplicaciones empresariales que no reciben mucha discusión: longevidad y conjunto de habilidades. Nuevamente, hay mucho que decir aquí, pero voy a resumir. Las empresas invierten dinero en la creación de aplicaciones y planean usar esas aplicaciones durante un tiempo "prolongado". Esto significa que la tecnología subyacente debe recibir soporte durante décadas. Me gustaría que WinUI fuera la próxima tecnología de larga duración que reemplace a Win32 / MFC y WinForms.

Los departamentos de TI luchan constantemente por encontrar SE con las habilidades adecuadas. La tecnología web ha hecho que esto sea aún más desafiante. Me gustaría ver una nueva pila de C #, Xaml y SQL (C # XS) que identifique un enfoque en la creación de aplicaciones de escritorio.

También hay un punto menor que me gustaría hacer con respecto al estilo. Las aplicaciones empresariales WinUI deben requerir un mínimo de estilo "listo para usar" para que sean funcionales. Además, y esto podría estar dirigido directamente a Fluent, pero no oculte los controles (como las barras de desplazamiento). Los usuarios comerciales tienen una gran cantidad de pantalla en estado real y no les importa cuán “hermosa” sea una interfaz de usuario si no saben que hay más en una página.

Necesitamos un control de cuadrícula de datos robusto (gratuito). No puedo enfatizar eso lo suficiente.

Tengo más ideas para compartir si está interesado, pero me detendré aquí y resumiré:

• Microsoft necesita proporcionar una solución integral de desarrollo de aplicaciones de escritorio.
• WinUI / Fluent necesita abordar los requisitos del usuario comercial, como función / formulario, UX para escritorio, muestras de código / plantillas de proyectos que demuestran múltiples ventanas, verdadero multi-subproceso, validación de datos, páginas "tipo formulario".
• Microsoft debe dejar en claro que están ofreciendo WinUI para crear aplicaciones de LOB comerciales de larga duración y altamente productivas. Además, por qué .Net 5 + WinUI NO será otro infierno de DLL.
• Deje en claro que WinUI es el reemplazo de Win32 / MFC y WinForms.
• Empuje C # XS como un conjunto de habilidades para TI.
• Datagrid (gratuito)

Espero que te haya resultado útil.

@robloo Descansa tranquilo, ¡no es necesario debatir! 🙂 Me comprometí a corregir este error en mi comentario inicial y eso sigue siendo cierto. Creo que también cometí un error antes al continuar generalizando. Hablemos de los errores que enumeraste. Dos se archivaron justo antes de nuestras principales vacaciones aquí (no puedo hablar por @teaP , pero estuve desconectado la mayor parte de diciembre) y pasamos por un cambio de gestión en nuestro lado de ingeniería (¡felicidades @ranjeshj!). No es excusa y me disculpo que estos dos errores no fueron atendidos más rápidamente durante estos cambios y ausencias. Los demás que se enumeran aquí se han presentado en los últimos 10 días o menos.

Para tenerlo señaló que NumberBox en particular, es un culpable y que éstos están apilando nos ayuda a ser estratégica con nuestro tiempo, así que gracias por ayudarnos a ver esto. He programado tiempo para principios de la próxima semana para revisar nuestra lista de errores pendientes de NumberBox con nuestro dev de NumberBox @teaP y nuestro gerente de ingeniería (recién titulado) @ranjesh para que podamos resolverlos colectivamente lo antes posible.

@SavoySchuler ¡Gracias!

@SavoySchuler , parece que estás atrapado en una posición difícil para elegir entre:

a) Corregir errores en WinUI 2.xy retrasar el lanzamiento de WinUI 3.0
o
b) Deje WinUI 2.xa la comunidad y dedique recursos internos a WinUI 3.0 para lograr la fecha de lanzamiento más temprana.

Supongo que muchos de los usuarios de WinUI 2.x existentes querrán que corrija los errores primero, ya que están afectados actualmente, pero tal vez esto podría mitigarse ofreciendo una expectativa realista de cuándo WinUI 3.0 _ podría_ estar disponible, con suficientes recursos ( y asumiendo que WinUI 3.0 ofrecerá arreglos adicionales sobre 2.x).

Personalmente, no me gustaría ver un retraso en el lanzamiento de WinUI 3.0, y creo que es razonable que la comunidad se involucre en la resolución de cualquier problema que sea crítico en WinUI 2.x (después de todo, es de código abierto). Algunas personas tienen la expectativa de que, debido a que es un proyecto de Microsoft, deberían hacer todo el trabajo. Desafortunadamente, eso no es realista, ni tampoco cómo funcionan otros proyectos de código abierto.

@jesbis , es interesante escuchar sobre la capa visual con respecto a WinUI 3.0. ¿Está diciendo que para las versiones iniciales, WinUI 3.0 dependerá de las clases Windows.UI.Composition ? ¿Existe la posibilidad de agregar más funciones al sistema operativo para admitir la capa visual antes de la extracción en WinUI 3.0?

Como referencia, cosas que me interesan:

• Modelo Win32 "AppContainer". Somos totalmente compatibles con sandbox en otros sistemas operativos, pero nos gustaría tener acceso a API "modernas".
• La capa visual ( Windows|Microsoft.UI.Composition )
• Cadenas de intercambio DXGI en la capa visual / SwapChainPanel
• API de administración de ventanas (AppWindow, etc.)

@infoequipt ¡ gracias por las notas detalladas! Definitivamente útil. @ marb2000 para mayor visibilidad

es interesante escuchar acerca de la capa visual con respecto a WinUI 3.0. ¿Está diciendo que para las versiones iniciales, WinUI 3.0 dependerá de las clases de composición de Windows.UI?

@MarkIngramUK no, perdón por cualquier confusión, mi punto anterior era solo sobre el código abierto.

Microsoft.UI.Composition será parte de WinUI 3 y Microsoft.UI.Xaml dependerá de ello. Ese ya es el caso con WinUI 3 Alpha.

Estamos trabajando hacia el código abierto de Xaml, lo que significa que el código del marco de Xaml vivirá en este repositorio y nuestro equipo de ingeniería hará todo nuestro trabajo diario en Xaml en GitHub en el futuro. Sin embargo, el paquete Microsoft.UI.Composition del que depende Xaml todavía se desarrollará internamente y solo se actualizará en forma binaria.

Gracias por la aclaración @jesbis muy apreciada. ¿Qué métodos de distribución utilizará para esto? Somos una aplicación multiplataforma, por lo que usamos CMake y tenemos una dependencia de Windows.UI.Composition, por lo que nos encantaría una forma de incorporar fácilmente los nuevos dll, lib, encabezados, etc.

¿Hay implicaciones de rendimiento para extraer la capa visual del sistema operativo? Es decir, si solo depende de la capa visual, ¿habría una desventaja en la actualización a una nueva biblioteca?

¿Existe un plan para eventualmente abrir Microsoft.UI.Composition de código abierto?

@MarkIngramUK Estoy de acuerdo en gran medida con lo que está diciendo y con lo que @SavoySchuler está diciendo en una vista de 'panorama general'. Sin embargo, como señaló, es más difícil para nosotros, los usuarios de WinUI 2.0, aceptar errores, ya que tenemos aplicaciones de producción en este momento. Necesitamos encontrar un compromiso entre corregir algunos errores que no retrasen WinUI 3.0 y también mantener WinUI 3.0 en el camino correcto. Hubo una frustración adicional de que NumberBox era un control completamente nuevo que parecía ser descuidado de inmediato, con un comentario de que Microsoft no volvería a él durante más de un año. Independientemente, ciertamente estoy de acuerdo con que WinUI 3.0 es la prioridad y no quisiera que se retrasara en una capacidad significativa.

Probablemente debería decir que aprecio todo el trabajo que Microsoft está haciendo aquí y sus esfuerzos por ser más transparentes y comunicativos con la dirección.

¿Qué métodos de distribución utilizará para esto? Somos una aplicación multiplataforma, por lo que usamos CMake y tenemos una dependencia de Windows.UI.Composition, por lo que nos encantaría una forma de incorporar fácilmente los nuevos dll, lib, encabezados, etc.

@MarkIngramUK ¿Consumir paquetes NuGet funcionaría para usted? Es decir, lo que estamos haciendo con WinUI 2.xy WinUI 3 Alpha. Todavía estamos trabajando en algunos detalles de distribución con el equipo de Visual Studio. En este momento, WinUI 3 Alpha contiene los binarios Xaml y Composition en 1 paquete, pero los separaremos para admitir Xaml de código abierto y poder compilar Xaml por separado.

¿Hay implicaciones de rendimiento para extraer la capa visual del sistema operativo? Es decir, si solo depende de la capa visual, ¿habría una desventaja en la actualización a una nueva biblioteca?

Estén atentos 🙂 La evaluación comparativa de rendimiento y el trabajo están en nuestra hoja de ruta para finales de este año, por lo que es demasiado pronto para tener cifras.

¿Existe un plan para eventualmente abrir Microsoft.UI.Composition de código abierto?

Está en nuestra lista de trabajos pendientes para considerarlo potencialmente, pero no tenemos un plan para ello.

@MarkIngramUK si pudiera preguntar: ¿qué beneficio esperaría obtener de que sea de código abierto?

La composición y el código de renderizado pueden volverse un poco confusos, así que tengo curiosidad por saber si la gente estaría realmente interesada en contribuir o usar como referencia.

Para nosotros, los usuarios de WinUI 2.0, es más difícil aceptar errores, ya que ahora tenemos aplicaciones de producción. Necesitamos encontrar un compromiso entre corregir algunos errores que no retrasen WinUI 3.0 y también mantener WinUI 3.0 en el camino correcto. Hubo una frustración adicional de que NumberBox era un control completamente nuevo que parecía ser descuidado de inmediato, con un comentario de que Microsoft no volvería a él durante más de un año. Independientemente, ciertamente estoy de acuerdo con que WinUI 3.0 es la prioridad y no quisiera que se retrasara en una capacidad significativa.
Probablemente debería decir que aprecio todo el trabajo que Microsoft está haciendo aquí y sus esfuerzos por ser más transparentes y comunicativos con la dirección.

@robloo gracias! Realmente estamos tratando de ser transparentes y es bueno saber que eso es valioso 🙂

Solo para reiterar lo que Savoy mencionó, tenemos desarrolladores trabajando en WinUI 2.x (como también se puede ver en el registro de relaciones públicas), por lo que definitivamente todavía estamos invirtiendo en WinUI 2 y 3 en paralelo; es solo que la mayoría de nuestros los recursos están en WinUI 3. Estoy de acuerdo en que NumberBox en particular necesita algo de atención y nuestro líder de desarrollo de controles Xaml lo está investigando ahora.

@robloo ¡Eres el mejor! 😄 Perdón nuevamente por la confusión: lo único sujeto a ese retraso de ~ 1 año mencionado fueron los modos de validación de entrada adicionales de NumberBox porque están bloqueados en nuestro trabajo de validación de entrada total programado para 3.0. De lo contrario, @ranjeshj y yo estaremos en la lista de errores de NumberBox a partir de la próxima semana. 🙂

¡Creo que @jesbis tiene todo lo demás cubierto!

@jesbis ,

@MarkIngramUK ¿Consumir paquetes NuGet funcionaría para usted? Es decir, lo que estamos haciendo con WinUI 2.xy WinUI 3 Alpha. Todavía estamos trabajando en algunos detalles de distribución con el equipo de Visual Studio. En este momento, WinUI 3 Alpha contiene los binarios Xaml y Composition en 1 paquete, pero los separaremos para admitir Xaml de código abierto y poder compilar Xaml por separado.

Seré honesto, no estoy tan familiarizado con NuGet, pero al mirar esta respuesta SO , parece que solo funcionará si usa CMake para generar archivos de proyecto VS, que no es como trabajamos normalmente (normalmente solo abre la carpeta , que usa Ninja como generador). Es una pena que no pueda enviar la fuente, ya que también podría usar vcpkg . Como referencia, construimos todas las bibliotecas desde la fuente (lo que evita cualquier problema potencial de ABI, especialmente dado que también construimos con Clang / LLVM en Windows).

¿Existe un plan para eventualmente abrir Microsoft.UI.Composition de código abierto?

Está en nuestra lista de trabajos pendientes para considerarlo potencialmente, pero no tenemos un plan para ello.

Tengo interés en esto, así que me encantaría involucrarme en la discusión cuando eso suceda.

@MarkIngramUK si pudiera preguntar: ¿qué beneficio esperaría obtener de que sea de código abierto?

La composición y el código de renderizado pueden volverse un poco confusos, así que tengo curiosidad por saber si la gente estaría realmente interesada en contribuir o usar como referencia.

Los pensamientos iniciales están contribuyendo / expandiendo (como mencioné anteriormente, tenemos una dependencia en Windows.UI.Composition, pero no en Xaml Framework / UWP), aunque pensando en voz alta, portando la capa visual a un backend Vulkan o Metal para cross- La plataforma puede ser emocionante, pero solo le he dado literalmente 30 segundos de consideración. Además, el código abierto aliviaría la inquietante preocupación de adoptar otro marco que Microsoft eventualmente abandonará en unos pocos años (nuestras aplicaciones actuales se basan en WPF, nuestras aplicaciones anteriores se crearon en MFC, teníamos componentes web que usaban Silverlight, por lo que , puede ver de dónde vengo aquí ...).

NumberBox

¡Hola a todos! @teaP , @ranjeshj y yo trabajamos hoy en todos nuestros elementos abiertos de NumberBox.

• Ya cerramos algunos.
• @teaP envió un PR combinado para varios más ( filtrado de etiquetas aquí ).
• Tenemos un curso de acción decidido para el resto (con la excepción de # 1721) y responderemos con correcciones lo antes posible. # 1721 requiere más trabajo en nuestro para diagnosticar el mejor camino a seguir. Seguiremos trabajando para resolver este.

Gracias a todos por trabajar con nosotros. 🙂 Nosotros ❤️ WinUI!

¿Existe un "calendario" para las llamadas de la comunidad WinUI? Ej .: en forma de un calendario público que podemos agregar / integrar a nuestro calendario en vivo / google / *, para actualizaciones automáticas de los detalles de la llamada.

Los eventos de YouTube están programados con anticipación, por lo que puede agregar un recordatorio de Google aquí en "próximas transmisiones en vivo":

https://www.youtube.com/channel/UCzLbHrU7U3cUDNQWWAqjceA

También teníamos una invitación del calendario .ics, pero estaba causando problemas a algunas personas y no había forma de actualizarlo, así que lo abandonamos por ahora.