Microsoft-ui-xaml: 👩‍💻📞 Llamada a la comunidad de WinUI (19 de febrero de 2020)

Tengo una pregunta sobre el desarrollo de Windows 10X. Para desarrollarlo necesito el emulador, ¿cuándo habrá soporte para procesadores AMD (virtualización anidada)? ¿Podemos contar con la versión de Windows 10 2003?

Más relacionado con WinUI, basado en # 1958, ¿cuál es el futuro de Live Tiles?

El soporte de AMD Ryzen me impide ejecutar el emulador, por lo que cualquier palabra sobre cuándo se rectificará será bueno para escuchar.

@ jp-weber @mdtauk

Esta es la redacción oficial (https://docs.microsoft.com/en-us/dual-screen/windows/get-dev-tools):

Los procesadores AMD no son compatibles en este momento. Se requiere virtualización anidada para ejecutar Windows 10X en el emulador y Windows aún no es compatible con esto en los procesadores AMD. ¡Manténganse al tanto!

Si desea obtener más información, probablemente debería comunicarse con [email protected]. Dudo que WinUI sea el equipo correcto para hacer preguntas específicas al emulador.

Gracias @ Felix-Dev. Eso es correcto, los documentos son el mejor lugar para obtener el estado más reciente en el emulador 10X, y esa dirección de correo electrónico es el mejor contacto para otras preguntas 10X que no son específicas de WinUI.

Bastante justo, tendrá que esperar hasta que Microsoft esté listo para hablar de ello.

En cuanto a Windows 10X, las aplicaciones Win32 se ejecutan en un contenedor VEIL. ¿Qué pasa con las aplicaciones WinUI 3.0 que no son para UWP?

¿Parecerán ejecutarse como lo hacen las aplicaciones nativas para UWP en 10X?

@mdtauk Dado que las aplicaciones de escritorio de WinUI no son aplicaciones nativas de UWP, no creo que se ejecuten en el contenedor de UWP. Creo que se ejecutarán en el contenedor Win32 mencionado, ya que tendrán (todas) las capacidades de las aplicaciones Win32.

También me interesa saber cuál es el plan para el aislamiento de la aplicación WinUI en el futuro. Desde una perspectiva empresarial, necesitamos aislamiento / espacio aislado y control de capacidad (no la participación del usuario). Entonces, poner esto ahí como un tema para Miguel ...

@mdtauk Dado que las aplicaciones de escritorio de WinUI no son aplicaciones nativas de UWP, no creo que se ejecuten en el contenedor de UWP. Creo que se ejecutarán en el contenedor Win32 mencionado, ya que tendrán (todas) las capacidades de las aplicaciones Win32.

Esto es un poco decepcionante. Las aplicaciones Win32 parecen exhibir un comportamiento de ventana diferente y oscurecen la pantalla cuando están en primer plano. Entonces, el cambio también se comporta de manera diferente.

Al usar una interfaz de usuario de Xaml, tenemos la esperanza de que una aplicación de escritorio WinUI sea el mejor escenario de ambos mundos, al menos en la superficie para el usuario.

@mdtauk Como la imagen actual del emulador 10X que se nos ha entregado aún es muy pronto, estoy bastante seguro de que los problemas / comportamiento que notó (yo también lo hice en mis pruebas) se abordarán / modificarán hasta el lanzamiento (es decir, también tengo aplicaciones Win32 que solo no se carga en este momento).

Dicho esto, estaré feliz de que me corrijan en el contenedor de la aplicación WinUI Desktop en 10X. Mi pensamiento actual se basa en lo que nos han dicho sobre WinUI Desktop hasta ahora (modelo de aplicación Win32), la presentación 10X How Windows 10X runs UWP and Win32 apps y las aplicaciones de prueba de puente de escritorio. Desafortunadamente, mis aplicaciones de prueba de la isla XAML no se cargan en el emulador actualmente (atascadas en la etapa App Launch Initialized ), por lo que no puedo verificar qué contenedor usarán. Sin embargo, me sorprendería que no fuera el contenedor Win32, ya que siguen siendo aplicaciones Win32. Todo eso me lleva a creer que las aplicaciones WinUI Desktop se ejecutarán en el contenedor Win32 en 10X.

¡Sin duda es una buena pregunta para hacerle al equipo!

@ Felix-Dev de acuerdo con el mismo video que mencionaste (Cómo Windows 10X ejecuta aplicaciones UWP y Win32) en los minutos 20:18 dice que las aplicaciones híbridas (Win32 / UWP) no son compatibles (¿todavía?) Y tengo entendido que es una aplicación que usa XAML Island es una aplicación híbrida.

P1) ¿Cuándo estará disponible SwapchainPanel en WinUI? Esto es absolutamente esencial para lo que yo y muchos otros hacemos.

P2) Dado que SharpDX ya no es compatible con su creador, ¿Microsoft intensificará y proporcionará compatibilidad entre SharpDX y las superficies de renderizado de hardware de WinUI? ¿MS siquiera ve una historia para el renderizado de hardware con C # sin SharpDX? Y no me importa Unity, me refiero al desarrollo de gráficos de forma libre y sin restricciones, para hacer nuestras propias herramientas de gráficos, motores y juegos que no son de Unity en C #. Y tampoco me refiero a Win2d, necesito una capacidad de renderización completa de hardware (DirectX).

P3) Las aplicaciones carecen de la capacidad de desactivar las ventanas emergentes TaskBar y TitleBar cuando el mouse se mueve al borde superior e inferior de la pantalla. Este es un factor decisivo para muchos juegos (y tal vez algunas aplicaciones) que utilizan el borde de la pantalla en su propia interfaz de usuario para cosas como la panorámica de la cámara o las ventanas emergentes. ¿Cuándo se solucionará esto (esto puede ser un problema de Windows, pero debe ser impulsado por una API, por lo que es relevante para WinUI)?

P4) ¿Podemos hacer que WinUI incluya el modelo de aplicación CoreWindow (IFrameworkView) para cuando queramos omitir Xaml y renderizar directamente en una Swapchain vinculada a una ventana?

Puede sonar un poco extraño, solicitar que WinUI proporcione una superficie que no sea Xaml. Pero creo que CoreWindow pertenece a XamlWindow (llamado Window en UWP) en la misma biblioteca, también separada de UWP para que esté disponible en .net 5. Suponiendo que .net 5 podrá apuntar tanto a uwp como a uwp. Actualmente, no existe un modelo de aplicación C ++ moderno fuera de UWP; los desarrolladores de juegos deben usar el código c heredado (Win32) para escribir capas de aplicación para juegos o aplicaciones de gráficos. Tampoco hay un modelo de aplicación de escritorio moderno en .net core. La solución de UWP para CoreWindow es eficaz y cómoda de usar. Solo necesita existir fuera de UWP (tanto para C ++ / non-uwp como para .net 5). Otro beneficio de extraer CoreWindow de UWP es que proporciona una forma de transferir directamente el código de UWP a .net 5 (y C ++ si alguna vez obtiene un modelo de aplicación moderno que no sea de uwp).

Los desarrolladores de juegos no pueden usar UWP hasta que se cambie el comportamiento de las ventanas y se resuelva la historia de distribución. Ha pasado tanto tiempo que parece que Microsoft ni siquiera comprende el problema. Así que tenemos que intentar sacar estas API fuera de UWP. Si se corrigiera UWP, no sería necesario.

Y más comentarios del número 1215.

Si reemplaza Win32 Window con CoreWindow para escenarios no contenidos / no Xaml, y también proporciona CoreWindow a .Net 5 Non-UWP, entonces podemos tener una aplicación / modelo de ventana unificada en Windows para trabajos que no sean Xaml. Eso tiene más sentido que aferrarse a Win32 PARA SIEMPRE o inventar nuevos modelos de aplicaciones.

¿Por qué deberíamos tener que reescribir la capa de aplicación solo porque queremos cambiar entre ejecución contenida y no contenida (por ejemplo, entre UWP y Win32)? Ese es un problema típico al que se enfrentan los desarrolladores de juegos hoy en día, no pueden comprometerse con UWP porque necesita libertad de distribución de Win32. Por lo tanto, se ven obligados a utilizar modelos de aplicaciones HWnd o .Net Framework. Si el modelo de ventana / aplicación de UWP estuviera disponible para aplicaciones que no contengan uwp, no hay problema, podríamos escribir el mismo código para la capa de aplicación y compilar tanto para MS Store como para otras tiendas desde la misma base de código.

@leoniDEV Mucho de esto sigue siendo especulación sobre qué se entiende exactamente por "aplicaciones híbridas". Vea este hilo de Twitter, por ejemplo, donde se dice que las aplicaciones XAML Island no pertenecen a esa categoría (Matteo Pagani trabaja en Microsoft como Windows AppConsult Engineer ). Un empleado de MS en la comunidad de UWP dijo que el soporte para aplicaciones de UWP que ejecutan un proceso de plena confianza de Win32 no será compatible un día 1, pero está previsto que se agregue más adelante.

@ Gavin-Williams Habrá dos versiones de WinUI: WinUI UWP y WinUI Desktop. Con WinUI UWP, podrá crear aplicaciones para UWP completas que se ejecutarán en el contenedor de UWP en Windows 10X. Luego está WinUI Desktop que permitirá que las aplicaciones Win32 tengan acceso completo a las API de la interfaz de usuario de UWP (XAML, composición, entrada, ... - excluyendo algunas API como CoreWindow ) también. Estos tipos de aplicaciones no tienen que lidiar con la zona de pruebas de UWP u otras restricciones de diseño de la UWP. Sin embargo, como no son aplicaciones para UWP, su aplicación de escritorio WinUI no podrá apuntar a la amplia gama de categorías de dispositivos de Windows 10 que una aplicación para UWP puede.
Vea la imagen a continuación tomada de la hoja de

WinUI se ha escrito en C ++ desde cero, por lo que se puede usar en un contexto de aplicación no administrado.

Como destaqué anteriormente, mi escritura I believe they will run in the mentioned Win32 container se basa puramente en mi conocimiento actual de WinUI Desktop, las aplicaciones de prueba de puente de escritorio y video 10X que ejecuté en 10X. No tengo conocimiento de información privilegiada. El equipo de WinUI seguramente nos hará saber cuál es el plan con las aplicaciones de escritorio WinUI y el contenedor 10X utilizado y estoy feliz de que me corrijan aquí y me digan que sí, las aplicaciones de escritorio WinUI se ejecutarán en el contenedor UWP en 10X.

Me gustaría escuchar más sobre cualquier idea sobre la posibilidad de poder usar otros lenguajes de programación, como Java, Python, JavaScript, etc., al crear aplicaciones con WinUI / Microsoft UI.

Sé que hay un proyecto llamado Xlang (cross-lang), que esencialmente parece lo que debería haber sido .NET, una mejor COM.

¿Cómo se relaciona eso con WinUI?

xlang es esencialmente una versión de código abierto multiplataforma de Windows Runtime (WinRT), aunque no iba a ser totalmente compatible. El propósito de WinRT es lo que dijo, interoperabilidad entre idiomas, y está basado en COM. Las API de WinUI se basan en WinRT, que es la forma en que admite tanto C ++ como C #. Hay otros lenguajes con varios niveles de soporte para WinRT, incluidos Python , Rust (este es uno en el que he trabajado personalmente) y JavaScript , pero hasta donde yo sé, ninguno de ellos (todavía) es compatible con WinUI; admitir WinUI es particularmente difícil porque sus API de composición y XAML dependen en gran medida de una característica del sistema de tipos llamada tipos componibles (esencialmente una forma de herencia de implementación) que otras API de WinRT y UWP no usan y que pueden ser difíciles de asignar a los sistemas de tipos de otros lenguajes.
Kenny Kerr, el creador de C ++ / WinRT, está trabajando ahora en una nueva proyección de Rust WinRT .

De hecho, he estado pensando mucho recientemente sobre cómo Rust podría admitir mejor los tipos componibles (y por lo tanto, WinUI). Ciertamente es posible, pero todavía no estoy seguro de cuán natural puedo hacer que se sienta para los desarrolladores. Básicamente, cualquier lenguaje debería ser compatible con WinRT si alguien se pone a trabajar para crear una proyección, pero dependiendo del diseño del lenguaje, a veces puede ser difícil mapear las construcciones del sistema de tipos de WinRT al sistema de tipos del lenguaje de alguna manera. eso se siente natural.

xlang me parece muerto. C ++ / WinRT nunca estuvo realmente terminado: se quedó con errores y una historia de uso muy extraña, lo que lo hacía indeseable para el desarrollador promedio. Luché durante muchas, muchas horas para que C ++ / WinRT funcionara, y no logré hacer lo que hice en 30 minutos con C ++ / CX. Y C ++ / CX era mucho más fácil de usar. Si Microsoft quiere que el ciudadano medio pueda utilizar estas herramientas en varios idiomas, debe poner un equipo de personas en el problema y no dejar que Kenny Kerr haga todo el trabajo por sí mismo. Tiene grandes ideas. Pero estas herramientas necesitan un gran atractivo, y creo que él necesita ayuda para que estos productos maduren y sean todo lo que pueden ser.

Por ahora, UWP y su sucesor, WinUI, no están listos para aplicaciones LOB.

Hay varios problemas a los que nos enfrentamos

• Bajo rendimiento. Por ejemplo, la propiedad de dependencia de WinUI es 50 veces más lenta que https://github.com/microsoft/microsoft-ui-xaml/issues/1633 .
• Rendimiento de compilación deficiente. Varias veces más lento que wpf
• dotnet nativo
• Muchos cambios importantes entre lanzamientos.
• Modelo de sandboxing y permisos
• Capacidad de personalización limitada para proveedores de fiestas en 3D en comparación con wpf

¿Cree que WinUI puede superar estas limitaciones y convertirse en el próximo marco listo para LOB durante los próximos 10 años? O es hora de avanzar a la aplicación electron blazor)

Tengo un par de problemas con el estado actual de WinUI.

C ++ / WinRT sigue siendo una experiencia de desarrollador muy pobre en comparación con las herramientas de C ++ / CX y la experiencia general del desarrollador. Si se espera que tratemos con componentes WinUI escritos en C ++, es de esperar que tengamos una cobertura de al menos 1: 1 de lo que son capaces las herramientas C ++ / CX.

Ser C ++ 17 estándar no me sirve si mi productividad se ve afectada en comparación con solo usar C ++ / CX, y se necesita el doble de tiempo para escribir un componente UWP o una interfaz de usuario basada en XAML.

Lo que lleva a mi segunda pregunta, la razón principal para tener que lidiar con C ++ en UWP / WinUI, es porque Microsoft ha dejado caer la pelota en cualquier tipo de enlaces DirectX a lenguajes .NET. Entonces, ¿WinUI alguna vez proporcionará soporte para XNA como reemplazo o WPF 3D scenegraph? Aparentemente, aquí solo tenemos silencio de radio y nos vemos obligados a participar en proyectos comunitarios como MonoGame o motores completos como Unity.

¿Cuándo se convertirá finalmente Win2D en parte de WinUI? Actualmente parece estar en modo de mantenimiento con futuro incierto.

Actualmente se está volviendo muy difícil seguir vendiendo el sueño de UWP, ya que la cantidad de listas alrededor de mi caja de jabón sigue disminuyendo.

¿Cuándo llegarán los elementos de la interfaz de usuario de Windows 10X al escritorio de Windows 10?

@carmellolb 2022-2025?

Editar: MS probablemente eliminará esto, porque propone un cronograma para la entrega del producto, que no existe y, por lo tanto, es engañoso;)

@ Felix-Dev "WinUI Desktop ... permitirá que las aplicaciones Win32 tengan acceso completo a las API de la interfaz de usuario de UWP ... excluyendo algunas API como CoreWindow.

¿Excluyendo CoreWindow? Dios mío: esa es la primera y más importante API que debería eliminarse de UWP. Es la API más fundamental que proporciona la funcionalidad básica de la ventana. Debe ser universal, dentro y fuera del contenedor UWP. Hasta que no se publique, no podemos tener una base de código común para la capa de aplicación y estamos atascados con el código c heredado de Win32 en C ++ o lo que sea que el núcleo .net proporcione (¿otra clase de Windows nuevamente?) Para C #.

Microsoft: al igual que proporciona XamlWindow tanto dentro como fuera de UWP, también proporcione CoreWindow tanto dentro como fuera de UWP.

Acerca de la llamada: ¿por qué se alejó de Teams? YouTube no funcionó tan bien en el último.

@ Gavin-Williams

De https://github.com/microsoft/microsoft-ui-xaml/issues/1215#issuecomment -531994216:

Nuestro enfoque es que WinUI 3 usará CoreWindow cuando se ejecute en UWP y Win32 Window (HWind) cuando se ejecute en Desktop (Win32).

WinUI 3 en aplicaciones para UWP podrá utilizar las API de AppWindow. Para Desktop, será necesario crear algo similar. Todavía estamos diseñando esto, así que no tengo más detalles hasta ahora.

El equipo también dijo que está buscando proporcionar API como CoreApplicationViewTitleBar.ExtendViewIntoTitleBar para WinUI Desktop para que podamos obtener lo mejor de ambos mundos. Todo el poder del diseño de ventanas de Win32 (es decir, sin barra de título / barra de título 100% personalizada, ventana de la aplicación <tamaño mínimo requerido, sin botón de barra de tareas, ...) y las nuevas y modernas API de personalización de UWP. (Para UWP, probablemente tengamos que esperar a que AppWindow V2 tenga capacidades de ventanas cercanas a las actuales de ventanas de Win32).

@jesbis Pregunta sobre WinUI Desktop: en el problema https://github.com/microsoft/microsoft-ui-xaml/issues/1939 se ha señalado que la activación de notificaciones de tostadas no funciona para las aplicaciones de escritorio empaquetadas de MSIX en (al menos) 1909 como se menciona en los documentos :

Para las aplicaciones Desktop Bridge, simplemente envíe notificaciones de brindis como lo haría una aplicación para UWP. Cuando el usuario haga clic en su brindis, su aplicación se iniciará en la línea de comandos con los argumentos de inicio que especificó en el brindis.

Si bien tengo que esperar y ver si la solución mencionada se aplicará a las versiones del sistema operativo afectadas para las aplicaciones de

@ Felix-Dev Según la documentación, parece que la isla XAML no implica estrictamente una aplicación híbrida, puede llamar a la API de alojamiento XAML de UWP directamente desde su aplicación Win32 a expensas de perder algunas funciones, como el uso de controles personalizados, si tengo entendido correctamente los documentos (y la nota en los documentos):

Hospedar un control UWP estándar en una aplicación WPF con islas XAML

Componentes requeridos

El proyecto y el código fuente de tu aplicación. El uso del control WindowsXamlHost para hospedar controles UWP estándar de origen se admite en aplicaciones que tienen como destino .NET Framework o .NET Core 3.

Un proyecto de aplicación para UWP que define una clase de aplicación raíz que se deriva de XamlApplication . Su proyecto de WPF o Windows Forms debe tener acceso a una instancia de la clase Microsoft.Toolkit.Win32.UI.XamlHost.XamlApplication proporcionada por Windows Community Toolkit. Este objeto actúa como proveedor de metadatos raíz para cargar metadatos para tipos XAML de UWP personalizados en ensamblados en el directorio actual de tu aplicación.

Although this component isn't required for trivial XAML Island scenarios such as hosting a
first-party UWP control, your app needs this XamlApplication object to support the full
range of XAML Island scenarios, including hosting custom UWP controls.
Therefore, we recommend that you always define a XamlApplication object in any solution
in which you are using XAML Islands.

Luché durante muchas, muchas horas para que C ++ / WinRT funcionara, y no logré hacer lo que hice en 30 minutos con C ++ / CX

Si se espera que tratemos con componentes WinUI escritos en C ++, es de esperar que tengamos una cobertura de al menos 1: 1 de lo que son capaces las herramientas C ++ / CX.

@ Gavin-Williams, @pjmlp , cppwinrt por los problemas que está encontrando? ¿O son problemas específicos de WinUI por los que podría abrir problemas en este repositorio? Estamos trabajando activamente en la compatibilidad con C ++ / WinRT, por lo que sería genial escuchar cualquier detalle sobre lo que no está funcionando bien para usted. Nosotros también lo estamos usando: las nuevas funciones de WinUI están todas en C ++ / WinRT, al igual que nuestras aplicaciones que lo usan (por ejemplo, calculadora ).

Acerca de la llamada: ¿por qué se alejó de Teams? YouTube no funcionó tan bien en el último.

Si te refieres a los problemas de audio: creemos que tuvimos un cable defectuoso el mes pasado y esperamos que mejore mañana. YouTube parecía ser más accesible para la mayoría de las personas, y el estudio de Channel9 tiene mucho mejor audio y video que la sala de conferencias que usábamos para Teams.

RE: CoreWindow, soporte para win32, contenedores: hablaremos sobre nuestra dirección actual durante la llamada de la comunidad de mañana con @ marb2000 :)

También intentaremos llegar a las otras preguntas hasta ahora (por ejemplo, estado actual en la línea de tiempo de SwapChainPanel, Win2D / DirectX, islas, etc.). ¡Gracias por los comentarios y preguntas hasta ahora!

@jesbis Gracias por

No hay problemas que abrir, porque el enfoque de desarrollo de C ++ / WinRT es completamente inverso a la productividad ofrecida por C ++ / CX.

Con C ++ / CX inicialmente pensé que Microsoft finalmente estaba vendiendo Visual C ++ de la manera correcta, 25 años después, Visual C ++ se había puesto al día con la experiencia RAD de C ++ Builder.

En cambio, lo que me da C ++ / WinRT es un regreso a los días de ATL / WTL, donde tengo que escribir MIDL boilerplate, aunque MIDL 3.0 es de alguna manera más agradable que el MIDL original, tengo que escribir manualmente los enlaces UWP repetidos que C ++ / CX maneja. me.

No es que C ++ / CX sea perfecto, la forma en que maneja los controladores de eventos aún falla antes que C # / VB.NET o C ++ Builder para el caso.

De todos modos, UWP está vinculado a Windows, por lo que tener un enlace de C ++ puro no es algo que me compre en C ++ / Winrt, sino que puedo hacer exactamente lo mismo que en C # o VB.NET, sin tener que lidiar con el código que todavía se siente como ATL / WTL.

Y como se mencionó, solo estoy ocupado con C ++ porque las apelaciones para exponer DirectX como un conjunto de componentes de tiempo de ejecución de UWP siguen siendo ignoradas.

Por lo tanto, no creo que los problemas de apertura en cppwinrt mejoren la capacidad de usar C ++ / Winrt en Blend y Visual Studio tan fácil como C ++ / CX, idealmente tan fácil como C # y VB.NET, ya que espero que el equipo de cppwinrt cambie el problema en el equipo de Visual Studio, y tradicionalmente (MFC / ATL / WTL) el equipo de herramientas de C ++ nunca se preocupó por proporcionar las mismas herramientas de alto nivel que disfrutan los lenguajes .NET, aunque otras empresas pueden hacerlo con C ++ (Qt, Embarcadero).

@pjmlp gracias por los detalles. Estoy consultando con algunas personas para ver si hay más información para compartir sobre las herramientas de C ++ / WinRT, aunque probablemente no tenga buenas respuestas mañana. Estamos enfocados en C ++ / WinRT para nuevos desarrollos, pero lo tenemos en nuestra hoja de ruta para tener también plantillas C ++ / CX para WinUI 3 si eso ayuda.

También me interesa saber cuál es el plan para el aislamiento de la aplicación WinUI en el futuro. Desde una perspectiva empresarial, necesitamos aislamiento / espacio aislado y control de capacidad (no la participación del usuario). Entonces, poner esto ahí como un tema para Miguel ...

@infoequipt, ¿ podría explicar lo que quiere decir con aislamiento? Por ejemplo, ¿le gusta el soporte de AppContainer ?

Por ahora, UWP y su sucesor, WinUI, no están listos para aplicaciones LOB.

• Muchos cambios importantes entre lanzamientos.

@Xarlot ¿Qué cambios importantes te estaban causando problemas? Con las API de UWP, intentamos mantener un alto grado de compatibilidad en cada versión.

@ Gavin-Williams Con respecto a la desaprobación de SharpDX , es posible que desee considerar Vortice.Windows , que es una excelente alternativa. @Aminator lo está usando actualmente en su propio motor y editor de juegos totalmente UWP / C # / XAML DX12, DX12GameEngine .
¡Esperamos que se adapte a tus necesidades en tus aplicaciones! 😄

Con respecto a las preguntas para la llamada, tengo una que es un detalle menor, pero ya que estamos en eso: ¿podríamos usar el cambio a WinUI 3 para corregir también algunos pequeños errores de IU heredados que podrían considerarse "cambios importantes", como el StackPanel aplicando la propiedad Spacing incorrectamente a los elementos colapsados?

Es decir. Si tiene algunos elementos contraídos en un StackPanel , seguirá aplicando el espacio entre ellos, lo que le obligará a recurrir al relleno / margen manual entre elementos si tiene algunos de sus elementos que se pueden mostrar / ocultar mediante programación. He solucionado este error específico en un PR para el WrapPanel en el Kit de herramientas de la comunidad de Windows ( # 2838 ), y aparentemente este comportamiento en el StackPanel era un problema conocido reconocido por algunos otros ingenieros de MS así como. 🤔

¡Mantener el buen trabajo! 🚀

@leoniDEV Gracias por señalar esto. Veamos si obtenemos algunas respuestas definitivas mañana 🙂

@jesbis Dos preguntas más sobre WinUI Desktop (relacionadas entre sí):

1. ¿Las aplicaciones de escritorio WinUI tendrán un conmutador integrado entre instancias múltiples (estándar Win32) y instancia única (estándar UWP)? En este momento, si queremos que una aplicación Win32 sea de instancia única, tenemos que implementar este comportamiento nosotros mismos. Es posible que esto no solo requiera un bloqueo de la aplicación (como un mutex para verificar si una instancia ya se está ejecutando), sino también una API Win32 como SendMessage para pasar operaciones desde una segunda instancia de la aplicación a la instancia principal de la aplicación (consulte la pregunta 2). Sería genial si pudiéramos tener la opción de tener el comportamiento de instancia única de las aplicaciones para UWP para las aplicaciones de escritorio de WinUI.

1. ¿Las aplicaciones de escritorio WinUI podrán usar la API Jumplist de UWP ? Actualmente, las aplicaciones de puente de escritorio no pueden usarlas de manera efectiva porque la aplicación aparentemente no se puede activar (consulte el problema de Windows Terminal https://github.com/microsoft/terminal/issues/576 para obtener una breve descripción general de los problemas). Me gustaría tener soporte completo de esta API para las aplicaciones de escritorio de WinUI porque es mucho más fácil trabajar con ellas que las API de Win32 / WPF. Por ejemplo, los íconos de tareas jumplist se pueden configurar fácilmente usando los esquemas de URI ms-appx:/// o ms-appdata:/// lugar de tener que crear un .exe o .dll que contenga las imágenes, luego establecer la ruta a ese archivo binario y también un desplazamiento en el archivo para el icono específico .

   Los documentos resumen las ventajas de la API Jumplist de UWP:

   Alternativamente, use las API de UWP Windows.UI.StartScreen.JumpList en su lugar, que le permiten hacer referencia a los activos de cadena e imagen mediante el esquema de URI de recursos ms relativos al paquete (que también es compatible con el lenguaje, DPI y alto contraste).

El comportamiento de instancia única de las aplicaciones para UWP también hace que trabajar con jumplists sea mucho más fácil. Si tiene una tarea jumplist que debería operar en la instancia de la aplicación en ejecución actual, en WPF / Win32, se lanza una segunda instancia de la aplicación que luego necesita usar, por ejemplo, la API SendMessage Win32 para enviar la operación solicitada a la instancia de la aplicación principal. Al usar el comportamiento de instancia única en UWP, la aplicación en ejecución obtiene fácilmente la tarea de salto invocada. sin todo el trabajo adicional en el caso de Win32.

@pjmlp otra cosa que podría ser de interés si no la ha visto es esta sesión de Kenny Kerr y Scott Jones de la última conferencia de Build, particularmente los últimos ~ 11 minutos donde hablan sobre algunas mejoras prototipadas para bindings y algo de C ++ especificaciones técnicas para agregar reflexión y soporte de metaclase que podrían eliminar por completo los requisitos actuales de IDL y codificación de metadatos:

https://youtu.be/X41j_gzSwOY?t=2659

Si tenemos tiempo, también podemos hablar un poco de esto en la llamada mañana.

Gracias @jesbis , estoy al tanto de esa charla. Todavía está demasiado lejos en el futuro, como puedo decir.

En este momento, parece más probable que transfiera mi código DirectX existente a algo como la biblioteca Vortice, señalada por den sus frutos.

Admiro sus esfuerzos, pero aquí desde las trincheras, después de Silverlight, XNA, WinRT, UAP, UWP, WinUI, .NET Framework, WCF, EF6, finalmente nos cansamos de seguir haciendo reescrituras.

WinUI debería ser mejor que WPF en todos los sentidos, y si nos vemos obligados a usar C ++ por razones, entonces sus herramientas deberían estar al mismo nivel que los desarrolladores de .NET han llegado a amar, para que realmente valga la pena ir más allá de WPF o hacer un apunte para evitar que las empresas quieran ir con aplicaciones de estilo Electron.

Como ya preguntó @ Sergio0694 , ¿se usará WinUi 3.0 no solo para cambiar los espacios de nombres, sino que también contendrá otros cambios importantes que son necesarios para corregir errores, como los espacios aplicados incorrectamente?

Si es así, habría una posibilidad de cambiar el nombre de la propiedad NavigationView.IsBackButtonVisible a BackButtonVisibility ya que el nombre y el tipo actualmente no se alinean realmente (IsBackButtonVisible es una enumeración NavigationViewBackButtonVisible, no un bool). Esto también se discutió aquí .

@chingucoding Recuerdo que el equipo dijo que para WinUI 3.0, los cambios de ruptura deberían ser mínimos para que la migración de aplicaciones existentes (UWP) sea lo más sencilla posible. Sospecho que estos cambios, si se aprueban, se implementarán en versiones posteriores de WinUI 3.x / 4/5 / .....

P: ¿WinUI 3.x admitirá AcrylicBrush con HostBackdrop ? Actualmente se sabe que está roto en el alfa, pero tengo curiosidad por saber si está en la hoja de ruta para ser reparado antes del lanzamiento.

P: ¿WinUI Desktop permitirá a los desarrolladores de aplicaciones de escritorio _ finalmente_ usar AcrylicBrush con HostBackdrop ? Anteriormente usamos el atributo de composición WCA_ACCENT_POLICY con ACCENT_ENABLE_ACRYLICBLURBEHIND pero Microsoft rompió críticamente esto en 19H1 + y nuestra aplicación ha estado sufriendo desde entonces. (También afectó cosas como el Selector de Emoji, pero Microsoft reparó esos componentes para usar un método no acrílico).

Acerca de WebView2:
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2

"La vista previa para desarrolladores está disponible para Win32 C ++ en Windows 10, Windows 8.1, Windows 8 y Windows 7. En el futuro, planeamos admitir WebView2 en .NET y XAML".

Mi pregunta es ... ¿Está previsto que la versión .NET de WebView2 SDK sea aplicable para Win8.1, 8 y 7?
Me preocupa que parhaps WebView2 en .NET solo sea compatible a través de WinUI3. Según tengo entendido, la compatibilidad con la aplicación WinUI3 WinForms solo es aplicable para .NET Core y solo para Win10.
Permítanme explicarles mi situación. Mi cliente tiene muchas de las aplicaciones de escritorio WinForm que usan IE BrowserControl. Pero IE es obsoluto y quiere migrar a los navegadores modernos. Y estas aplicaciones DEBERÍAN ser compatibles con Win7, 8, 8.1. (no me culpes por el soporte del viejo sistema operativo)

Si es posible:

• Win32 ETA en una versión preliminar para WinUI 3.0

• Si el código fuente no está listo para compartir, tal vez dar un exe de demostración ya cumplido de algunos elementos de la interfaz de usuario en ejecución que podríamos descargar y jugar sería genial para mostrárselo a los compañeros de trabajo.

• ¿WinUI 3.0 admite efectos de sombreado personalizados como lo hizo WPF / Silverlight? Si no, ¿hay alguna idea de agregarlos más tarde? ¿La capa de renderizado utilizada por WinUI es capaz de hacer esto?

@leoniDEV Seguí adelante y creé un proyecto de isla XAML como usted resaltó (por lo que no hay un proyecto de UWP separado). Contiene un solo control de bandeja de entrada de UWP (un botón) y funciona bien en 10X. No es de extrañar para la historia del contenedor ... se ejecuta en el contenedor Win32 como se esperaba.

Por lo tanto, parece que, al menos en este momento, todavía no hay soporte completo para las aplicaciones de la isla XAML que consumen un proyecto de UWP separado.

Estoy pensando en hacer v-next de una aplicación WPF heredada. Probablemente pueda usar .NET Core WPF, pero realmente quiero usar WinUI. Tengo problemas con bibliotecas como Prism que aún se derivan de Windows.UI.Xaml (a diferencia de Microsoft.UI.Xaml). Parece que este tipo de problemas son fundamentales. ¿Existe todavía una guía sólida de PnP para WinUI o es demasiado pronto?

¿Es posible hacer que alguien del equipo de shell o del equipo de aplicaciones de la bandeja de entrada hable sobre por qué el menú de inicio y el explorador de archivos en Windows 10x están basados ​​en la web en lugar de usar WinUI?

Todo lo que necesito es una experiencia de transferencia perfecta de nuestra aplicación UWP actual (con extensión de escritorio) a una aplicación de escritorio WinUI (sin la extensión de escritorio). ¿Será esto posible? ¿Cuáles son las trampas en este escenario?

Si esto resulta ser difícil, ¿será posible en el futuro mejorar UWP (para las aplicaciones que se ejecutan en el escritorio) para ejecutar siempre aplicaciones en segundo plano y permitirles llamar a todas las API de win32 a través de P / Invoke y permitir que las dll se carguen? otros dll sin LoadPackagedLibrary (pero con LoadLibrary).

¿Qué posibilidades hay de que WinUI 3.0 esté listo para iniciarse cuando se inicien los primeros dispositivos Windows 10X? Estoy interesado en saltar al mundo de los desarrolladores de Windows y estoy tratando de decidir qué enfoque tiene más sentido en este momento.

¡Gracias a todos por las preguntas y por ver si pudieron asistir! La grabación es en vivo en el mismo enlace.

Hubo muchas preguntas que no pudimos responder; intentaré resumirlas y publicar algunas respuestas aquí pronto.

Buen show chicos, gracias por tomar mi pregunta y por la presentación de Miguel.

Agregaré algunas preguntas más que me quedan con la esperanza de que se aborden.

1. Las aplicaciones tradicionales de Win32 se dibujan en la pantalla en WM_PAINT. Las aplicaciones XAML se mantienen en modo. Dibujamos MUY demasiadas cosas en la pantalla para crear objetos / controles individuales. ¿Seguirá habiendo un equivalente de WM_PAINT que me permita dibujar en la ventana pero con una API más moderna? ¿Win2D o alguna otra API de modo inmediato?

2. La accesibilidad se maneja de manera diferente en Win32 (COM API) frente a, digamos, WPF (Automation Peers). Si escribo una aplicación Win32 + WinUI, ¿podré aumentar o controlar el árbol de accesibilidad más fácilmente? ¿O me quedaré con las antiguas API COM? ¿Cómo combinaría mi contenido dibujado personalizado con controles accesibles en el árbol de accesibilidad?

3. Hoy, imprimimos dibujando en una impresora DC. ¿Hay una nueva impresión con Win32 + WinUI?

4. Todavía estoy un poco desconcertado con respecto a la relación entre un HWND, un CoreWindow y lo que venga a continuación para WinUI. ¿Seguirán existiendo los HWND o reemplazaremos las llamadas a CreateWindow por algo más? Supongo que sí ... pero si ese es el caso, supongo que todavía debe haber un HWND subyacente para los casos en los que debemos entregar uno a componentes externos (HWND principal, por ejemplo).

5. ¿El uso de WebView2 en una aplicación Win32 + WinUI tendrá los problemas de espacio aéreo que encontramos con el control de IE integrado?

Empezando a ponerse al día con algunas preguntas:

¿WinUI es solo un desarrollo para UWP, pero una especificación más moderna? Veo conversaciones sobre WinUI y no estoy 100% seguro de si están hablando de desarrolladores de UWP, libs particulares en desarrolladores de UWP o algo completamente diferente

WinUI es específicamente la capa de la interfaz de usuario y no incluye otros aspectos de la plataforma de la aplicación UWP como el modelo de la aplicación para suspender / reanudar, tareas en segundo plano, etc.

Para las aplicaciones para UWP, puede reemplazar específicamente Windows.UI.Xaml , Windows.UI.Composition y partes de Windows.UI.Input .

¿Las aplicaciones WinUI tendrán un conmutador integrado entre instancias múltiples (estándar Win32) y instancia única (estándar UWP)?

@ Felix-Dev aún no hemos explorado la idea de un mejor soporte de instancia única para aplicaciones win32; si tiene una propuesta, ¡no dude en abrir un problema en este repositorio!

¿WinUI 3.x admitirá AcrylicBrush con HostBackdrop? Actualmente se sabe que está roto en el alfa, pero tengo curiosidad por saber si está en la hoja de ruta para ser reparado antes del lanzamiento. ¿WinUI Desktop permitirá que los desarrolladores de aplicaciones de escritorio usen finalmente AcrylicBrush con HostBackdrop?

@riverar, lamentablemente, esto no está en el plan para WinUI 3.0 RTM. Hay desafíos para admitir esto en una plataforma de interfaz de usuario que está desacoplada del sistema operativo, pero estamos planeando revisar esto después de 3.0.

Acerca de WebView2: Mi pregunta es ... ¿Está previsto que la versión .NET del SDK de WebView2 sea aplicable para Win8.1, 8 y 7?
Me preocupa que parhaps WebView2 en .NET solo sea compatible a través de WinUI3.

@ pnp0a03, el control WinUI Xaml solo es compatible con WinUI 3, pero hay una vista previa para desarrolladores del SDK principal de WebView 2 para Windows 7, 8 y 8.1 para aplicaciones win32:

https://docs.microsoft.com/microsoft-edge/hosting/webview2

Tengo problemas con bibliotecas como Prism que aún se derivan de Windows.UI.Xaml (a diferencia de Microsoft.UI.Xaml). Parece que este tipo de problemas son fundamentales. ¿Existe todavía una guía sólida de PnP para WinUI o es demasiado pronto?

@GraniteStateHacker Creo que es demasiado pronto: WinUI 3 todavía es demasiado nuevo para tener mucho soporte del ecosistema (solo está en alfa), pero @hassanuz está comenzando un flujo de trabajo para investigar las opciones de compatibilidad / migración de bibliotecas.

¿WinUI es solo para aplicaciones de la tienda?

No, puede usarlo de varias formas, por ejemplo:

• inclúyalo en una aplicación win32 existente (WPF, WinForms, MFC, etc.) usando Xaml Islands
• Cree un instalador de MSIX e impleméntelo como desee
• cree una aplicación sin empaquetar y distribúyala a través de xcopy u otros medios (aún no es compatible con WinUI 3, pero está planeado para RTM)

¿Qué posibilidades hay de que WinUI 3.0 esté listo para iniciarse cuando se inicien los primeros dispositivos Windows 10X? Estoy interesado en saltar al mundo de los desarrolladores de Windows y estoy tratando de decidir qué enfoque tiene más sentido en este momento.

@dwalleck WinUI 3 ya tiene una salida alfa y debería tener una vista previa más funcional alrededor del período de tiempo de la conferencia de Build , y ambos apuntan a fines de 2020. Si comienza con UWP Xaml y / o WinUI, entonces debería estar en un buen camino para el desarrollo 10X .

Las aplicaciones tradicionales de Win32 se dibujan en la pantalla en WM_PAINT. Las aplicaciones XAML se mantienen en modo. Dibujamos MUY demasiadas cosas en la pantalla para crear objetos / controles individuales. ¿Seguirá habiendo un equivalente de WM_PAINT que me permita dibujar en la ventana pero con una API más moderna? ¿Win2D o alguna otra API de modo inmediato?

@jschroedl Los árboles y pinceles de elementos Xaml están en modo retenido, pero puede usar una o más de varias opciones para incluir primitivas de renderizado más ligeras:

• capas de composición Visuales
• Capa de composición Formas que permiten dibujar geometrías retenidas de muy alto rendimiento; también se utilizan para cosas como el control WinUI AnimatedVisualPlayer que puede reproducir formas / animaciones de Lottie
• Interoperabilidad de DirectX con Xaml usando SwapChainPanel, SurfaceImageSource o VirtualSurfaceImageSource (dependiendo de si desea una cadena de intercambio o un modelo de pincel virtualizado / no virtualizado)
• Win2D, que abstrae la interoperabilidad de DirectX anterior para usted (con Direct2D, DirectWrite) y proporciona una API .NET

La accesibilidad se maneja de manera diferente en Win32 (COM API) frente a, digamos, WPF (Automation Peers). Si escribo una aplicación Win32 + WinUI, ¿podré aumentar o controlar el árbol de accesibilidad más fácilmente? ¿O me quedaré con las antiguas API COM? ¿Cómo combinaría mi contenido dibujado personalizado con controles accesibles en el árbol de accesibilidad?

¡Gran pregunta! Paging @ marb2000 para asegurarse de que esto esté cubierto y brindar las últimas actualizaciones. En general, los árboles WinUI Xaml deberían usar AutomationPeers, pero aún no estoy seguro de si eso extenderá alguna funcionalidad nueva al contenido win32 que no sea de WinUI.

Hoy, imprimimos dibujando en una impresora DC. ¿Hay una nueva impresión con Win32 + WinUI?

La principal funcionalidad de impresión para el contenido de WinUI debe ser a través de una versión de WinUI de la API de WinRT PrintDocument .

Todavía estoy un poco desconcertado con respecto a la relación entre un HWND, un CoreWindow y lo que venga a continuación para WinUI. ¿Seguirán existiendo los HWND o reemplazaremos las llamadas a CreateWindow por algo más? Supongo que sí ... pero si ese es el caso, supongo que todavía debe haber un HWND subyacente para los casos en los que debemos entregar uno a componentes externos (HWND principal, por ejemplo

WinUI no reemplaza a los hwnds, pero el objetivo es abstraer su uso para casos de uso comunes al proporcionar una API Xaml, algo similar a cómo funciona WPF. De hecho, la API de Xaml seguirá usando hwnds / CoreWindows como un detalle de implementación subyacente, y es probable que tengamos API de "puerta trasera" / "escape-hatch" para obtener acceso directo a hwnds cuando sea necesario. Deberíamos tener un borrador de propuesta en unas pocas semanas que aclarará esto.

@jesbis Gracias por tu respuesta, pero lamentablemente mi inquietud no se resolvió.
Actualmente, la versión "C ++" (vista previa) de WebView2 SDK Win32 se publica en este sitio. Es compatible con Win7, 8 y 8.1.
https://docs.microsoft.com/en-us/microsoft-edge/hosting/webview2
Mi pregunta es sobre la versión .NET. Actualmente, la versión .NET solo es compatible con WinUI 3, pero, como saben, no podemos usar WinUI 3 en Win7, 8 y 8.1 (¿es así?).
Por lo tanto, he publicado mi pregunta de la siguiente manera.

Mi pregunta es ... ¿Está previsto que la versión .NET de WebView2 SDK sea aplicable para Win8.1, 8 y 7?

@jesbis Gracias por responder a mis preguntas, aunque me sentí desmotivador.

Tratando de ser constructivo aquí.

Entonces, lo mejor que Microsoft puede ofrecer con respecto a las herramientas de C ++ / WinRT es señalar algunas propuestas en el aire, que con suerte podrían aterrizar en ISO en algún lugar entre C ++ 23 o C ++ 26, si es que lo hacen. Y luego espere a que el equipo de Visual Studio eventualmente reconstruya C ++ / CX encima de ellos, lo que hace que sea dentro de 6 años.

Si quiero excelentes herramientas de interfaz de usuario de C ++, definitivamente WinUI no lo es, sino Qt o C ++ Builder, con el beneficio adicional de la portabilidad de la plataforma.

Entonces, después de ver la presentación, y aún con cicatrices de XNA (reescribir en C ++ con DirectXTK), WinRT 8.0, WinRT UAP 8.1, UWP W10, C ++ Direct2D en lugar de System. Dibujando (hasta que apareció Win2D, ahora estancado), WinUI es definitivamente algo que pondré en espera.

En el futuro, recomendaré a mis clientes que se pasen a WPF cuando usen .NET, Qt cuando usen C ++, o se concentren en PWA si es posible con tecnologías web.

La hoja de ruta de WinUI 3.0 no inspira ninguna confianza en que otro reinicio está a la vuelta de la esquina, si la venta de UWP sigue fallando en el mercado de las computadoras de escritorio.

En cierto sentido, lo que quiero señalar es que la administración de Microsoft debería pensar en cómo vendernos la idea de adoptar WinUI, después de fallarnos tantas veces desde el lanzamiento de Windows 8.

La retroalimentación general de

DirectXTK todavía está en desarrollo y recibe actualizaciones periódicas.

En términos de las API de marco Xaml, WinUI es el camino a seguir y tiene un linaje de compatibilidad bastante ininterrumpido con Windows 8; pasamos mucho tiempo tratando de mantener un alto grado de compatibilidad 🙂 Hay algunos cambios (debido a la integración de shell, VS estructura del proyecto, etc.), pero en su mayor parte probablemente podría portar Windows 8 Xaml a una aplicación actual de Windows 10, recompilarlo y ejecutarlo en el último vuelo interno y funcionaría.

Algunos de los beneficios de alto nivel de WinUI incluirán eliminar las barreras entre las API de WinRT de UWP y las API de win32, admitir .NET 5, permitir el soporte inmediato de nivel inferior para nuevas funciones, eliminar la necesidad de realizar muchas verificaciones condicionales de la versión del sistema operativo, habilitar contribuciones de OSS y habilitando actualizaciones incrementales para aplicaciones win32 existentes usando islas Xaml.

@ pnp0a03 también se están realizando esfuerzos para llevar elementos .NET al mercado. No puedo dar fechas específicas, pero somos conscientes de la demanda y estamos trabajando en los detalles.

@jschroedl queremos eliminar los problemas del espacio aéreo, estamos tratando de elaborar un plan de renderizado que nos ayude a lograrlo.

@jesbis Como se mencionó, no creo que quejarme sobre cppwinrt sirva para nada, prefiero quejarme al no adoptar C ++ / WinRT a menos que para los casos de uso que no puedo evitar, específicamente porque la hoja de ruta es adoptar una característica que podría ni siquiera ser aceptada en YO ASI.

Con respecto a DirectXTK, estaba dando otro ejemplo de cómo Microsoft nos ha obligado a reescribir nuestro código C # en C ++, con herramientas menos capaces, al eliminar XNA y proporcionar DirectXTK como "alternativa".

Afortunadamente, la comunidad de código abierto logró crear MonoGame y hacer el trabajo que Microsoft se negó a realizar con XNA.

Lo vi durante la presentación y en algunos de los comentarios aquí, cómo C ++ es genial y divertido, cómo WinDev (una vez más desde que Longhorn asumió el control) sigue vendiendo C ++ primero, .NET después.

Si quiero excelentes herramientas de C ++, Qt y C ++ Builder son mis entornos de elección, no Visual C ++.

Realmente debería pedirle a la gerencia que le permita a su equipo echar un vistazo a lo que es posible hoy en la competencia, en lugar de esperar que algunas metaclases e ideas de reflexión sean aceptadas en ISO.

No solo tenemos que preocuparnos por las API y las bibliotecas de terceros que no se transferirán de .NET Framework a .NET Core, sino que también tenemos que ocuparnos de todos los problemas de migración de WPF / UWP a WinUI y el "solo escribir en C ++ / WinRT, es genial y será mejor en un par de años "mentalidad.

La administración de Microsoft realmente tiene que pensar en cómo vender esta reescritura a los desarrolladores .NET quemados, de lo contrario no nos alejaremos de las pilas que ya hacen su trabajo.

@pjmlp Hablando de DirectX, estoy trabajando activamente en un marco de entrada, audio y gráficos de C # portátil y agnóstico en mi tiempo libre que será capaz de ejecutar D3D12 / 11, etc. en una vista WinUI ... entre muchas otras cosas.

Admite un enfoque de renderizado mucho más moderno y centrado en el rendimiento frente a algo como XNA. No está listo para usar, pero es algo que mucha gente ha querido, incluyéndome a mí mismo ... así que lo estoy haciendo. D3D12 y Vulkan serán los primeros objetivos admitidos. También podrá escribir sombreadores en C # en lugar de HLSL o GLSL, etc.

Cuando esté listo para usar, compartiré más, pero debido a que se trata de un marco y no de un SDK o motor de juego masivo, será muy portátil y liviano, pero potente y fácil de usar. Perfecto para renderizar contenido 3D en WinUI, WPF o alguna aplicación nativa de C # Win32 o WinRT.

https://github.com/reignstudios/Orbital-Framework

@ zezba9000 Gracias por la información, muchas cosas impresionantes que han hecho, ¡felicitaciones!

Supongo que en lo que respecta al soporte administrado para DirectX, solo podemos contar con esfuerzos de la comunidad como el suyo, después de derribar Managed DirectX y XNA, la multitud de C ++ MS se hizo cargo de los esfuerzos de desarrollo de DirectX.

Al menos cualquiera de estos proyectos puede contar con mi apoyo, como marketing para mostrar a los demás que no tiene que ser solo "C ++ o el camino principal" como le gusta impulsar a WinDev. Aquí podrían tomar una lección de OpenGL ES / Metal con Swift, o OpenGL ES / Vulkan con Java / Kotlin. Aparentemente, el uso de lenguajes administrados para la programación 3D no fue un problema para que las plataformas móviles se ganaran en Windows (lamentablemente, WP fue una gran experiencia).

Buena suerte por sus esfuerzos, escribir sombreadores en C # parece realmente atractivo y no estaba al tanto de CS2X.

@pjmlp Ya, la parte de CS2X es lo que permitirá escribir sombreadores de GPU agnósticos en C # (lo cual es genial porque, en teoría, podrá realizar pruebas unitarias de sus sombreadores). Para los objetivos que pueden hacer uso de un subconjunto de C #, CS2X me permite a mí / a otros apuntar a plataformas fuera de lo que admiten los tiempos de ejecución de .NET actuales con un tiempo de ejecución muy ligero, ya que CS2X puede compilar el subconjunto de C # en un tiempo de ejecución de C89 ... y porque Orbital-Framework puede apuntar al tiempo de ejecución de CS2X => C89, y a su vez también puede apuntar a estas plataformas.

Gran proyecto, pero es lo que me importa y estoy dedicado a hacerlo realidad.

¿Será posible usar HwndHost con WinUI 2.4?
Lo intenté en la versión preliminar y no funcionó.
También será posible con WinUI3 con todas estas nuevas ventanas planificadas (ventana XAML) y aplicación (aplicación XAML) y, en caso afirmativo, cuándo podemos esperar la primera vista previa para ver eso.
En realidad, si va a ser posible en WinUI3, ¿esta funcionalidad se agregará a las nuevas versiones de WinUI 2, o WinUI 2 simplemente funcionará en las aplicaciones Uwp?
Por ejemplo, en este momento, tenemos la aplicación WPF, que usa mucho código C ++ a través de HwndHost, y debido a que estamos planeando mover todo a WinUI, esta parte es muy crítica para nosotros para decidir ir con WinUI o algo más. Además, incluso WinUI 2 se ve bien para nosotros, la parte XAML es muy fácil de transferir, Composition Api funciona muy bien, Uwp Community Toolkit funciona muy bien, solo que no podemos usar HwndHost y el código c ++ Win32. Entonces, ¿y cuándo va a resolver esto WinUI3? También me gusta mucho x: Bind, pero esto incluso está en riesgo para el lanzamiento de WinUI3.

@ zezba9000

Hablando de DirectX, estoy trabajando activamente en un marco de entrada, audio y gráficos C # portátil y agnóstico en mi tiempo libre que será capaz de ejecutar D3D12 / 11, etc. en una vista WinUI ... entre muchas otras cosas.

¡Buena suerte con esto! ¡Es una gran cantidad de trabajo!

¿Será posible usar HwndHost con WinUI 2.4?
Lo intenté en la versión preliminar y no funcionó.
También será posible con WinUI3 con todas estas nuevas ventanas planificadas (ventana XAML) y aplicación (aplicación XAML) y, en caso afirmativo, cuándo podemos esperar la primera vista previa para ver eso.
En realidad, si va a ser posible en WinUI3, ¿esta funcionalidad se agregará a las nuevas versiones de WinUI 2, o WinUI 2 simplemente funcionará en las aplicaciones Uwp?
Por ejemplo, en este momento, tenemos la aplicación WPF, que usa mucho código C ++ a través de HwndHost, y debido a que estamos planeando mover todo a WinUI, esta parte es muy crítica para nosotros para decidir ir con WinUI o algo más.

Hay un problema abierto para una forma de alojar la interfaz de usuario de user32 / comctl o WPF dentro de WinUI XAML: https://github.com/microsoft/microsoft-ui-xaml/issues/1833

Parece que no se hará hasta después de 3.0, si está hecho.

Publico esto en # 1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833 pero lo copiaré
aquí también: ahora mismo tenemos la aplicación WPF que usa mucho código C ++ a través de
Control HwndHost. Estamos planeando mover la aplicación Wpf a WinUI y mover Xaml
funciona muy bien sin problemas, pero ¿qué pasa con HwndHost, esto va a ser
posible con WinUI3. En nuestro caso estamos haciendo interoperabilidad con
DirectShow a través de HwndHost y ahora mismo en WinUI 2, esto no es
posible. ¿Cuál será la fecha realista para usar HwndHost en WinUI3? También es
esta nueva ventana y aplicación Xaml como se discutió a más tardar en febrero
Llamada a la comunidad de WinUI, ¿podría ayudar o no?

El dom., 23 de feb. de 2020 a la (s) 13:42, Max Strini (
[email protected]) escribió:

¿Será posible usar HwndHost con WinUI 2.4?
Lo intenté en la versión preliminar y no funcionó.
También será posible con WinUI3 con todas estas novedades planificadas
Sistema de ventanas (ventana XAML) y aplicación (aplicación XAML) y, en caso afirmativo, cuándo
podemos esperar la primera vista previa para ver eso.
En realidad, si va a ser posible en WinUI3, ¿esta funcionalidad
se agregará a las nuevas versiones de WinUI 2, o WinUI 2 simplemente funcionará en las aplicaciones de Uwp.
Por ejemplo, ahora mismo, tenemos la aplicación WPF, que usa mucho código C ++ a través de
HwndHost, y como estamos planeando mover todo a WinUI, esta parte
Es muy importante para nosotros decidir ir con WinUI o algo más.

Hay un problema abierto para una forma de alojar la interfaz de usuario de user32 / comctl o WPF dentro
WinUI XAML: # 1833
https://github.com/microsoft/microsoft-ui-xaml/issues/1833

Parece que no se hará hasta después de 3.0, si está hecho.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVVOQ6W3Z6LBVYZVJ63REJVLPA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52GHS4DWMVLOXWWK3TUL52GHS4DVMVREX
o darse de baja
https://github.com/notifications/unsubscribe-auth/AG66BVRWNTNC7FUIBBP5C6DREJVLPANCNFSM4KUFQ6MA
.

-
Mario Rancic
Ingeniero de software
Profesional certificado de Microsoft

¡Realmente buena llamada de la comunidad de WinUI la semana pasada! El contenido era muy interesante y lo suficientemente detallado / técnico como para proporcionar mucha información. Las actualizaciones de la hoja de ruta / estado de desarrollo también son extremadamente valiosas para los consumidores de WinUI y nuestras propias hojas de ruta de desarrollo. ¡Espero la próxima llamada!

Acerca de HwndHost en WinUI 3.
HwndHost permite alojar contenido Win32 dentro de WPF. Desafortunadamente, no hay ningún plan en WinUI 3.0 para admitir esto, incluso en WinUI 3.0 Desktop o WinUI Islands. Acerca del escenario descrito por @ mariorancic01 , ¿evaluó las API de UWP MediaPlayer en lugar de DirectShow?

Bueno, la cámara Uwp se ve mejor, pero no estoy seguro de poder usarla en nuestro escenario.
Estamos usando la cámara como cámara virtual con DirectShow y lo necesitamos mostrar
video, para capturar la transmisión de la cámara para una foto y también con PjSip en el
Al mismo tiempo, antes de que pudiéramos hacerlo con DirectShow. ¿Podemos usar este Uwp?
MediaPlayer con PjSip.

El mié., 26 de feb. de 2020 a la (s) 23:47, Miguel Ramos (
[email protected]) escribió:

Acerca de HwndHost en WinUI 3.
HwndHost permite alojar contenido Win32 dentro de WPF. Desafortunadamente hay
No hay ningún plan en WinUI 3.0 para admitir esto, incluso en WinUI 3.0 Desktop o
Islas WinUI. Sobre el escenario @ mariorancic01
https://github.com/mariorancic01 descrito, ¿evaluó UWP
¿API de MediaPlayer en lugar de DirectShow?

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/microsoft/microsoft-ui-xaml/issues/1972?email_source=notifications&email_token=AG66BVR4ABZ7KA3S2RQVHELRE3WOJA5CNFSM4KUFQ6MKYY3PNVWWK3TUL52HS4WSDMVREXWWK3TUL52HS4WMDMVREXWK3TUL52HS4W2MVREXWHK15GHPWZDMVREX
o darse de baja
https://github.com/notifications/unsubscribe-auth/AG66BVSBFMKZMD3TD5RGDKTRE3WOJANCNFSM4KUFQ6MA
.

-
Mario Rancic
Ingeniero de software
Profesional certificado de Microsoft

Tengo una pregunta sobre la Tienda Windows para empresas, se ve muy bien y es muy útil para las aplicaciones LOB, pero leí que podría abandonarse. ¿Alguien puede decir algo sobre los planes sobre esto?

@ marionrancic01 No es realmente necesario, ya que ahora puede distribuir aplicaciones para UWP a través de paquetes MSIX.

triste, como @ mariorancic01 también encuentro útil la Tienda Windows para empresas 😞

@leoniDEV Honestamente, tengo curiosidad por saber por qué necesitaría Windows Store for Business, cuando simplemente puede publicar como msix, como dijo @kmgallahan

@kmgallahan @jtorjo Supongo que lo que buscan es tener un catálogo de aplicaciones privado. ¿MSIX no ofrece eso creo? A menos que cree un sitio web en el que enumere el MSIX que proporciona su empresa, o utilice alguna herramienta de gestión para implementar cosas para sus usuarios.
De manera similar, los antiguos instaladores de MSI tampoco proporcionan una forma de descubrir aplicaciones.

Publicar en la Tienda Windows no es un paseo por el parque, es mucho más complejo de lo que cree. En primer lugar, debe esperar un certificado de MS, el que usará para publicar (no recuerdo los pasos exactos en este momento). Luego, debe asegurarse de que su aplicación no infrinja los requisitos de la Tienda. Luego, cualquier actualización que realice puede tardar días en ser aceptada (o puede ser rechazada), y dependerá del algoritmo de la tienda para que las personas encuentren su aplicación.

Pero si se implementa usted mismo, será un poco difícil configurarlo (yo lo sabría), pero una vez hecho esto, será fácil. Pero sí, estarás a cargo de mostrar tu aplicación al mundo.

Como alguien que tiene varias aplicaciones en Microsoft Store, incluida la tienda para empresas, puedo decirle que la publicación en Microsoft Store ha mejorado mucho en los últimos meses. La certificación de actualizaciones periódicas a veces se realiza en unas pocas horas. Las pautas de la tienda también son bastante fáciles de cumplir.
Por otro lado, alterar un msix independiente puede resultar complicado. A diferencia de la tienda que firma paquetes por usted, si distribuye su aplicación fuera de la tienda, debe firmarla usted mismo.

@jtorjo No necesitas ningún certificado.

Para ser claros, hay problemas con la tienda y el panel del desarrollador se cae de vez en cuando, pero mi punto anterior fue que es bastante conveniente tener la tienda para aplicaciones comerciales.

Como alguien que tiene varias aplicaciones en Microsoft Store, incluida la tienda para empresas, puedo decirle que la publicación en Microsoft Store ha mejorado mucho en los últimos meses. La certificación de actualizaciones periódicas a veces se realiza en unas pocas horas. Las pautas de la tienda también son bastante fáciles de cumplir.

@yaichenbaum Definitivamente es bueno saberlo. Cuando estaba publicando (hace 2 años más o menos), era mucho más difícil. Sí, debe firmarlo usted mismo; de hecho, compra un certificado y lo firma como parte del proceso de "Publicación". Entonces, una vez que lo haya configurado, puede olvidarse de él.

@riverar Cuando estaba publicando (hace 2 años más o menos), recuerdo que necesitas reservar un nombre, y luego debes esperar algo que MS usará para firmar tu aplicación (que es lo que quise decir, con un certificado - > uno que MS emitirá para usted).