Request to add Win App SDK context to AppContextType

[sahandt]

Hi Stride team,

I'm currently working on migrating a UWP app that uses UrhoSharp to the Win App SDK with WinUI 3 elements. Unfortunately, UrhoSharp is no longer actively maintained and doesn't work well with the latest updates. I'm very interested in replacing it with an embedded Stride 3D control, as Stride seems like a powerful and modern alternative.

However, I've noticed that the AppContextType enum doesn't currently include a context for the Win App SDK. This makes it difficult to integrate Stride seamlessly into my WinUI 3 application.

Since there's already a context for UWP, I'm hoping that adding support for the Win App SDK wouldn't require a significant amount of work. Perhaps it could be achieved with some namespace changes and minor adjustments.

Would it be possible to consider adding this missing feature in a future release? I believe it would greatly benefit developers who are looking to utilize Stride in their modern Windows applications.

Thank you for your time and consideration.

Sincerely,

[IXLLEGACYIXL]

make the bridge yourself to run WINUI3 inside stride see embedding and bridging stride https://github.com/Doprez/Awesome-Stride?tab=readme-ov-file#alternative-ui-plugins

also UWP isnt supported anymore, but .NET made a new UWP version for modern .NET versions so the current UWP in stride is out of date until dotnet says what they want with uwp

[sahandt]

Thanks for the response and the link to the Awesome-Stride repository!
UWP is being superseded by the Win App SDK as the modern approach for Windows application development.
While I appreciate the suggestion to create a bridge myself, I believe that officially supporting the Win App SDK in Stride would be a significant improvement for developers. It would streamline the integration process and make it much easier to use Stride in WinUI 3 applications.
Ideally, I'd love to see the Stride team update the Stride.Engine and Stride.Graphics NuGet packages to include native support for Win App SDK. This would allow us to simply add a SwapChainPanel to our WinUI 3 project and render Stride content on it without having to build custom bridges or workarounds.
I believe this would be a valuable addition to Stride and would encourage wider adoption within the WinUI 3 developer community.
Thanks again for your time and consideration.

[IXLLEGACYIXL]

normal link: https://doc.stride3d.net/latest/en/community-resources/ui.html

[sahandt]

Thank you for pointing me to those community code examples. However, my goal is a bit different than what those resources address. I'm not looking to create custom UI elements within Stride. Instead, I want to embed Stride within a larger Win App SDK application and utilize the rich UI capabilities of WinUI 3.
Think of it this way: I want to use Stride to render 3D graphics within a specific area of my application, while the rest of the application utilizes standard WinUI 3 controls like sophisticated data grids, navigation menus, and interactive charts. These are UI elements that go beyond simple buttons and input fields, and they are readily available and highly optimized within the WinUI 3 framework.
Essentially, I envision a scenario where Stride acts as a high-performance rendering component within a modern WinUI 3 application. This would allow developers to leverage the strengths of both frameworks: Stride for 3D graphics and WinUI 3 for a rich and modern user interface.
Therefore, native support for Win App SDK in Stride would be incredibly helpful. It would enable seamless integration with WinUI 3 and allow developers to create compelling applications that combine the best of both worlds.
Thank you again for your time and consideration.

[Doprez]

I think Joreyk meant to share https://doc.stride3d.net/latest/en/community-resources/embedded-stride.html the embedded portion of UI. There are still going to be issues until #2404 goes through but it is technically possible now just with some work arounds.

[Doprez]

Until the PR for windowing gets finished this will not be something that will happen within source at least. #2404

It should be possible to complete it once these changes go through, I did some testing with Avalonia.
https://github.com/Doprez/custom-stride-window-poc
https://www.youtube.com/watch?v=fOMnDlgrBB4

The problem with the current hard coded enum of AppContextTypes is a manpower one. What my PR will allow is to set the context to Custom and then allow the user to implement what is needed for whichever framework they require. so ideally in the end it should work with Avalonia, Uno, WinUI, new UWP, GLFW, etc.

[sahandt]

Thanks for the reply. This is exactly what I'm looking for! Hopefully you find some time to finish the great job!